Escrevendo mais uma ferramenta de modelagem do Kubernetes

Se você estiver trabalhando com o ambiente Kubernetes, provavelmente utilizará várias ferramentas de modelagem existentes, algumas delas fazendo parte de gerenciadores de pacotes, como Helm ou Ksonnet , ou apenas linguagens de modelagem (Jinja2, modelo Go etc.). Todos eles têm suas próprias desvantagens, além de vantagens, e vamos analisá-los e escrever nossa própria ferramenta que tentará combinar os melhores recursos.

Então, por que não Helm?

Existem vários artigos que criticam o Helm (por exemplo, apenas um deles: pense duas vezes antes de usar o Helm ). O principal problema do Helm é que ele funciona com representações de strings e os manifestos do Kubernetes são objetos (json) . O verdadeiro inferno para um desenvolvedor de gráficos Helm começa quando ele precisa calcular recuos para um manifesto yaml , às vezes parece com isso (é um exemplo real do meu gráfico):

 spec: jobTemplate: spec: template: spec: containers: - name: my-awesome-container resources: {{ toYaml .Values.resources | indent 14 }} 

Hoje, porém, o Helm é de fato o padrão para o empacotamento de aplicativos Kubernetes. A principal vantagem do Helm é uma grande comunidade e um grande número de repositórios públicos com gráficos. E, recentemente, os desenvolvedores do Helm anunciaram um hub Helm . O Helm hoje é como o Docker - não é o único, mas tem comunidade e suporte.

Existem mudanças promissoras no lançamento do Helm 3, mas ninguém sabe quando poderia ser.

Para concluir, as vantagens do Helm:

• Grande comunidade e vários gráficos públicos
• (Relativamente) sintaxe amigável ao ser humano. Pelo menos é o modelo yaml + go;)

Desvantagens:

• Trabalhando com strings e não objetos
• Número limitado de operadores e funções que você pode usar

OK, então talvez Ksonnet?

Se você está comparando o Helm ao Ksonnet, o último possui uma enorme vantagem, a saber, funciona com objetos. O Ksonnet é uma ferramenta baseada na linguagem de modelagem JSON Jsonnet. Outro recurso interessante sobre o Ksonnet é que ele possui bibliotecas Jsonnet compatíveis com a API do Kubernetes que você pode importar para o seu modelo e trabalhar com objetos do Kubernetes, como em qualquer linguagem OOP:

 local k = import "k.libsonnet"; local deployment = k.apps.v1beta1.deployment; local appDeployment = deployment .new( params.name, params.replicas, container .new(params.name, params.image) .withPorts(containerPort.new(targetPort)), labels); 

Parece impressionante, não é?
É um pouco menos interessante quando você trabalha não com objetos API, mas apenas com objetos json importados do arquivo yaml / json :

 { global: {}, components: { "deployment-nginx-deployment-dkecx"+: { spec+: { replicas: 10, template+: { spec+: { containers+: [ { name: "nginx", image: "nginx:latest", ports: [ { containerPort: 80, }, ], }, ], }, }, }, }, }, } 

Mas ainda é algo e é melhor do que trabalhar com strings no Helm. A desvantagem do Ksonnet é que ele possui uma comunidade menor e menos pacotes que o Helm (embora você possa importar gráficos do Helm para o seu projeto Ksonnet, mas você estará trabalhando com eles como objetos json, não como objetos da biblioteca jsonnet). E, como resultado de uma comunidade e contribuição menores, faltam alguns recursos ao tentar escrever seu próprio gráfico. Um deles eu experimentei: você sabe que no Helm você pode criar um ConfigMap partir de um diretório que contém vários arquivos de configuração desta maneira:

 apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{- (.Files.Glob "foo/*").AsConfig | nindent 2 }} 

Você pode imaginar minha frustração quando descobri que não existe esse recurso no Ksonnet. Existem soluções alternativas. Mas o ponto é que é apenas um exemplo da situação em que você está escrevendo seu gráfico com alegria e, de repente, a falta de algum recurso o impede no meio do caminho.
No total, vantagens do Ksonnet:

• Trabalhando com objetos
• Bibliotecas Jsonnet compatíveis com API do Kubernetes
• Suporte à importação de gráficos de leme

Desvantagens:

• Comunidade menor e menor número de pacotes nativos do Ksonnet
• Falta de algumas funcionalidades que você pode usar no Helm
• Nova sintaxe => aumento do tempo de aprendizado => aumento do fator de barramento
• Às vezes, a sintaxe pode se tornar feia e menos legível por humanos (especialmente quando você faz soluções alternativas por falta de recursos)

Vamos pensar em uma ferramenta de modelagem ideal

Aqui estão alguns critérios para a ferramenta de modelagem "ideal":

• Deve funcionar com objetos, não com strings
• Ele deve ter a capacidade de trabalhar com objetos compatíveis com a API do Kubernetes
• Deve ter um conjunto decente de funções para trabalhar com strings
• Deve funcionar bem com os formatos json e yaml
• Deve ser amigável ao ser humano
• Deveria ser simples
• Deve ter a capacidade de importar gráficos Helm existentes (porque isso é realidade e queremos fazer uso da comunidade Helm)

Isso é o suficiente por enquanto. Examinei esta lista na minha cabeça e pensei: tudo bem, por que não tentar o Python? Vamos ver se ele se encaixa nos nossos critérios:

• Trabalhe com objetos, não cordas . Sim, podemos usar tipos de dict e list para isso.
• Possibilidade de trabalhar com objetos compatíveis com a API do Kubernetes . Sim, from kubernetes import client
• Tenha um conjunto decente de funções para trabalhar com strings . Muito!
• Trabalhe bem com os formatos json e yaml . Muito bem.
• Amigo do Homem Não brinca.
• Simples Sim
• Capacidade de importar gráficos Helm existentes . Vamos nos adicionar.

Ok, parece promissor. Decidi escrever uma ferramenta simples de modelagem no topo da biblioteca cliente oficial do Python para o kubernetes e agora deixe-me mostrar o que saiu dela.

Conheça karavel

Não há nada de especial ou complicado nessa ferramenta. Acabei de pegar a biblioteca Kubernetes (que me permitiu trabalhar com objetos Kubernetes) e escrevi algumas funcionalidades básicas para gráficos Helm existentes (para que alguém pudesse buscá-los e adicioná-los ao seu próprio gráfico). Então, vamos fazer um tour.
Primeiro, esta ferramenta está acessível no repositório do Github e você pode encontrar um diretório com exemplos lá.

Início rápido com a imagem do Docker

Se você quiser experimentar, a maneira mais simples é usar esta imagem do docker :

 $ docker run greegorey/karavel -h usage: karavelcli.py [-h] subcommand ... optional arguments: -h, --help show this help message and exit list of subcommands: subcommand template generates manifests from template ensure ensure helm dependencies 

Obviamente, se você deseja modelar gráficos, precisará montar o diretório do seu gráfico:

 $ cd example $ docker run -v $PWD:/chart greegorey/karavel template . 

Então, vamos dar uma olhada na estrutura do gráfico. É muito semelhante a um dos Helm:

 $ cd example $ tree . . ├── dependencies ├── prod.yaml ├── requirements.yaml ├── templates │  ├── custom-resource.py │  ├── deployment.py │  └── service-helm.py └── values.yaml 2 directories, 6 files 

Como o Helm, ele possui o arquivo requirements.yaml com o mesmo layout:

 dependencies: - name: mysql version: 0.13.1 repository: https://kubernetes-charts.storage.googleapis.com/ 

Aqui, você apenas lista as dependências do Helm que deseja importar para o seu gráfico. As dependências vão para o diretório de dependencies . Para buscá-los ou atualizá-los, use o comando ensure :

 $ karavel ensure . 

Depois disso, o diretório de dependencies ficará assim:

 $ tree dependencies dependencies └── mysql-0.13.1 └── mysql ├── Chart.yaml ├── README.md ├── templates │  ├── NOTES.txt │  ├── _helpers.tpl │  ├── configurationFiles-configmap.yaml │  ├── deployment.yaml │  ├── initializationFiles-configmap.yaml │  ├── pvc.yaml │  ├── secrets.yaml │  ├── svc.yaml │  └── tests │  ├── test-configmap.yaml │  └── test.yaml └── values.yaml 4 directories, 13 files 

Agora, depois de garantirmos nossas dependências, vamos dar uma olhada nos modelos. Primeiro, criamos uma implantação simples do nginx:

 from kubernetes import client from karavel.helpers import Values def template(): values = Values().values # Configure Pod template container container = client.V1Container( name='nginx', image='{}:{}'.format(values.nginx.image.repository, values.nginx.image.tag), ports=[client.V1ContainerPort(container_port=80)]) # Create and configurate a spec section template = client.V1PodTemplateSpec( metadata=client.V1ObjectMeta(labels={'app': 'nginx'}), spec=client.V1PodSpec(containers=[container])) # Create the specification of deployment spec = client.ExtensionsV1beta1DeploymentSpec( replicas=3, template=template) # Instantiate the deployment object deployment = client.ExtensionsV1beta1Deployment( api_version='extensions/v1beta1', kind='Deployment', metadata=client.V1ObjectMeta(name='nginx-deployment'), spec=spec) return deployment # [deployment], (deployment, deployment) are valid 

Portanto, para que o modelo seja válido, você precisa ter a função template() que retorna um único objeto Kubernetes ou uma list / tuple deles. Você pode encontrar a lista de objetos de API para o cliente Python aqui .
Como você pode ver, o código é limpo, simples, legível. Você pode se perguntar de onde vem o values.nginx.image.repository ? Ele obtém valores dos arquivos de valores que você passa ao modelar o gráfico, assim como no Helm: karavel template -f one.yaml --values two.yaml . Vamos dar uma olhada neles mais tarde.

Ok, e os gráficos Helm?

Agora, criamos nossa própria implantação. Mas e se quisermos importar o gráfico Helm ou parte dele? Vamos dar uma olhada em templates/service-helm.py :

 from kubernetes import client from karavel.helm import HelmChart from karavel.helpers import Values def template(): values = Values().values # Initialize the chart (== helm template --values) chart = HelmChart(name='mysql', version='0.13.1', values=values.mysql.helm) # Get the desired object from chart service = chart.get(name='svc', obj_class=client.V1Service) # Create custom objects to add custom_ports = [ client.V1ServicePort( name='my-custom-port', protocol=values.mysql.protocol, port=values.mysql.port, target_port=39000, ) ] # Add custom objects to the service service.spec['ports'] = custom_ports # Change Helm-generated label service.metadata['labels']['release'] += '-suffix' # Delete Helm-generated label `heritage: Tiller` del service.metadata['labels']['heritage'] return service # [service], (service, service) are valid 

Simples, né? Observe esta linha: service = chart.get(name='svc', obj_class=client.V1Service) - criamos o objeto da classe yaml arquivo Helm yaml . Se você não quiser / precisar fazer isso - sempre poderá trabalhar com apenas dict .

E se eu quiser criar um recurso personalizado?

Bem, há um pequeno problema com isso. A API do Kubernetes não adiciona objetos CRD à definição swagger json em /openapi/v2 , e os objetos cliente Python são /openapi/v2 base nessa definição. Mas você ainda pode trabalhar facilmente com objetos de dict . Assim:

 from kubernetes import client def template(): resource = { 'apiVersion': 'stable.example.com/v1', 'kind': 'Whale', 'metadata': client.V1ObjectMeta( name='my-object', ), 'spec': { 'image': 'my-whale-image:0.0.1', 'tail': 1, 'fins': 4, } } return resource # [resource], (resource, resource) are valid 

Ainda parece bom, não é?

Posso ter valores para ambientes diferentes, por exemplo, dev / prod?

Sim você pode!
Vamos dar uma olhada em values.yaml primeiro:

 nginx: image: repository: nginx tag: 1.15-alpine mysql: port: 3307 protocol: TCP helm: releaseName: my-release namespace: prod imageTag: '5.7.14' service: type: NodePort 

Observe a chave helm no dict do mysql : usamos quando especificamos valores para o gráfico do helm chart chart = HelmChart(name='mysql', version='0.13.1', values=values.mysql.helm) . Alguns gráficos Helm precisam de releaseName para nomeação de aplicativos e namespace para políticas RBAC. Esses dois valores são transmitidos ao Helm como argumentos --namespace e NAME no helm template .

Agora, você pode especificar um arquivo adicional para prod env e modelar todos os nossos exemplos:

 $ karavel template -f values.yaml -f prod.yaml . --- # Source: templates/custom-resource.py apiVersion: stable.example.com/v1 kind: Whale metadata: name: my-object spec: fins: 4 image: my-whale-image:0.0.1 tail: 1 --- # Source: templates/deployment.py apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 template: metadata: labels: app: nginx spec: containers: - image: nginx:1.14-alpine name: nginx ports: - containerPort: 80 --- # Source: templates/service-helm.py apiVersion: v1 kind: Service metadata: annotations: null labels: app: prod-release-mysql chart: mysql-0.13.1 release: prod-release-suffix name: prod-release-mysql spec: ports: - name: my-custom-port port: 3308 protocol: TCP targetPort: 39000 selector: app: prod-release-mysql type: NodePort 

Depois disso, você pode kubeclt apply e implantar esses objetos no cluster.

Legal! E quanto a codificação e base64?

import base64

Que tal usar o Vault para segredos?

import hvac

Buscando URLs?

import importlib

Funções hash seguras?

import Crypto

Você entendeu. Com o Python, você pode fazer muitas coisas com seus manifestos do Kubernetes.

É síndrome do NIH?

Não :)
Eu sou alegremente usando Helm em meus projetos atuais. Mas há coisas que sinto falta. Também usei o Ksonnet em alguns dos meus projetos.
Gostaria de pensar nessa ferramenta como uma prova de conceito de que podemos ter ferramentas de modelagem melhores que o Helm e não é muito difícil desenvolvê-las usando o Python. Se houver um interesse / necessidade da comunidade em tal ferramenta, podemos juntos continuar a desenvolvê-la. Ou podemos esperar pelo lançamento do Helm 3;)

Conclusão

Eu mostrei a você a ferramenta de modelagem baseada em Python para o Kubernetes, que possui suporte a objetos compatíveis com a API do Kubernetes e suporta a importação de gráficos Helm. Quaisquer comentários e discussões da comunidade são bem-vindos e novamente bem-vindos ao repositório .

Obrigado por ler isso e tenha um bom dia!

Referências

• Biblioteca oficial do cliente Python para kubernetes
• Elmo
• Ksonnet
• Este artigo no Medium