Kapitan no comando de Kubernetes

Conheça Kapitan . Ele ajuda a trazer beleza e ordem à sua configuração do Kubernetes .

A Kapitan obtém uma reputação de análises de usuários satisfeitas e, portanto, dispensa documentação extensa e marketing caro. Temos estrelas suficientes e algumas menções de blogueiros e pregadores do Kubernetes. Kapitan até se tornou o protagonista de um capítulo inteiro do livro . Mais importante, ele atraiu a atenção de várias empresas promissoras, porque a Kapitan, como ninguém mais, é capaz de desvendar a configuração ligada ao nó do mar .

No kubernetes.slack.com #kapitan conseguiu reunir uma comunidade pequena, mas dedicada (participe!), Por isso estamos orgulhosos do nosso trabalho :)

Muitos ainda acreditam que Kapitan é uma mistura de jsonnet e jinja, mas eles não entendem.
Neste post, mostrarei como o Kapitan gerencia as implantações do Kubernetes, mas, em geral, é capaz de mais do que isso. Isso é importante: o Kapitan é universal e não está fixado em um Kubernetes. Kubernetes é simplesmente um dos muitos usos.

Este não é um guia (embora eu prometa um guia também). Eu só quero lhe dizer por que fizemos isso e quais problemas com as implantações das configurações do Kubernetes devem ser resolvidas.

Do que eu não gostei

Comecei a experimentar o Kubernetes em 2015 e imediatamente me apaixonei.
É verdade que existem várias desvantagens que não quero aturar:

• Contexto . Para mim, este é um dos conceitos mais difíceis de entender Kubernetes - e um dos mais perigosos. O contexto refere-se ao cliente, é difícil de entender, é chamado de forma confusa e cria confusão ao executar os comandos kubectl . Eu odeio contextos no kubectl!
• Configuração aninhada detalhada (yaml!) . Eu tive que suar para descobrir cada nível de configuração do yaml no manifesto. Qual é o sentido de repetir rótulos duas a três vezes em vários lugares?
• Uma bagunça com equipes imperativas e declarativas . Os recém-chegados ao Kubernetes são incentivados a aprender por equipes imperativas, embora seja claro que as pessoas normais não os usam. Na minha opinião, é apenas mais difícil encaixar o Kubernetes na estratégia de implantação certa para sua empresa. Spoiler: Não existe uma “estratégia certa”.
• Configuração de tempo de execução . Jesse Suen está certo quando desaconselha a passagem de parâmetros de configuração para a linha de comando do leme (ou kubectl e outros assim). Com parâmetros, o mesmo comando pode ser executado de forma diferente a cada vez.
• Configuração da Aplicação Nós aprendemos a gerenciar manifestos yaml em Kubernetes, somos ótimos. Isso é pouco e implantar - esta é uma tigela vazia. Ele ainda precisa flutuar o aplicativo com toda a sua configuração.
• Os desenvolvedores querem férias e o fluxo de trabalho no Kubernetes ainda é um pouco lento. Os fãs do Kubernetes estão forçando todo mundo a fazer isso ali mesmo. É necessário? Obedeça Kelsey Hightower!
• Operadores Eu tenho sentimentos contraditórios por eles, então, por enquanto, deixo este tópico :) Só posso dizer que eles são frequentemente abusados.
• Idempotência . Pelo contrário, a ausência dela. Se somarmos todas as falhas acima, não obtemos fluxos de trabalho idempotentes, o que é triste para o Kubernetes.

O que fazer

Tentei resolver esses problemas e montei um pequeno sistema de modelos que usava o j2cli e alguns scripts bash para gerenciar as configurações do Kubernetes.

O sistema colocou tudo no arquivo environmentA.yaml e o usou no modelo Jinja2. A implantação de aplicativos no estilo de microsserviço de vários componentes foi possível com um comando simples:

bin/apply.sh environments/environmentA.yaml 

Legal! Yaml era tudo sobre deploy. É muito conveniente, porque eu poderia usar o mesmo arquivo como fonte de informações para outra coisa. Diga para ... bash scripts !

Eu descobri como importar valores do yaml para scripts para executar comandos semelhantes:

 bin/create_kafka_topics.sh environments/environmentA.yaml 

E então tudo ficou fora de controle de uma vez :

• Não pude fazer nada com a estrutura no arquivo yaml. Era uma confusão dos mesmos campos, valores, configuração confusa.
• Você nunca saberá como se comportar na implantação no ambiente até tentar. Frequentemente, isso ocorreu devido a alterações nos modelos jinja2 devido a um novo valor de inventário (por exemplo, feature_X) que não funcionava em ambientes onde essa função não está definida.
• O mesmo problema com scripts: se você não tenta, não sabe.
• Às vezes, o Kubernetes mudava tão rapidamente que me incomodava mudar constantemente de manifesto para diferentes versões, principalmente brincando com anotações nos valores.
• Fator externo : a equipe de desenvolvimento mudou dos arquivos de configuração para os parâmetros da linha de comando. Uma mudança tão pequena nos confundiu todos os cartões, e tivemos que pensar em uma nova solução.
• Mais importante : modelar o yaml com o Jinja (ou modelos Go) NÃO É DIVERTIDO! Tivemos então um enigma: “ O que parece texto, lê texto, cheira a texto, mas não texto? " Ou, como Lee Briggs colocou apropriadamente: “ Por que diabos somos modelos yaml? "

Kapitan: Tornando-se

Reunimos toda a nossa experiência amarga e, junto com Ricardo Amaro, começamos a fantasiar sobre um sistema de gerenciamento de configuração ideal. Então ainda não tínhamos uma imagem clara, mas sabíamos que amamos e que não amamos.

Amor :

• Git.
• Padronização em geral: dados / valores separados dos padrões.
• Valores separados para diferentes aspectos (aplicativo, Kubernetes, tempo de execução ...).
• Abordagem orientada a objetos.
• Yaml simplificado como uma interface onde ocultar a complexidade do Kubernetes.
• Uma compreensão clara do que está acontecendo e por quê.
• Reutilização de valores em diferentes componentes.
• E os scripts devem ter acesso aos valores.

Nós não gostamos de :

• Contextos Kubectl
• Mecanismos de modelo de texto para criar yaml.
• Contagem de indentação: {{ toYaml .Values.resources | indent 10 }} {{ toYaml .Values.resources | indent 10 }} .
• Magia: tudo deve estar claro e claro. Sem truques.
• Gerenciamento manual de senhas e segredos do aplicativo.
• Abordagem do leme: queríamos controlar o uso de manifestos.
• Abordagem Git-Crypt: segredos no disco não são criptografados.
• Pipeline de modelo diretamente para o kubectl.
• Passando opções de linha de comando.

E então duas coisas aconteceram :

1. Descobrimos o jsonnet de Dave Cunningham para modelar yaml / json em uma linguagem orientada a objetos.
2. Gustavo Buriola nos mostrou a reclasse , e sem ele não teríamos ido longe.

Ricardo Amaro começou a trabalhar e logo toda a equipe se sentou na Kapitan - alguns trabalhavam na funcionalidade básica, outros no uso em nossos projetos internos. Gerenciamento de segredos, suporte a gpg \ kms, funções definidas pelo usuário: agora o Kapitan é um produto completo que faz mais do que o prometido.

Quem é Kapitan?

Kapitan está tentando resolver todos (ou quase todos) os problemas de que falei.

Do ponto de vista técnico, o Kapitan é muito simples:

• Inventário : uma coleção hierárquica de valores que descreve a implementação com base no yaml. Baseado em reclasse. Como hiera.
• Mecanismos de modelo : agora é Jinja2, Jsonnet, Kadet. Eles fazem inventário e criam arquivos (scripts yaml, json, documentação ou bash).
• Segredos : segredos de modelos, e Kapitan vai lidar com eles.

Estamos usando o jsonnet para modelar manifestos e o Jinja para fazer o resto.

Às vezes, as pessoas reclamam que o arquivo jsonnet é completamente diferente do mesmo yaml, por isso é difícil para elas mudarem para o jsonnet.

Tentamos resolver esse problema com o Kadet envolvendo o yaml no Python. Tome seu yaml favorito como base e adicione Python a ele.

Considere isso um exoesqueleto Python para yaml! De alguma forma eu vou falar sobre isso.

No fluxo de trabalho, Kapitan mostra imediatamente o caractere:

• Liberdade de escolha : não impomos nenhum processo e tecnologia de trabalho, mas geralmente trabalhamos com os princípios descritos abaixo. De fato, o Kapitan pode ser usado como você quiser. Você não é obrigado a usar o git, não deve compilar arquivos nele, e pode até ficar sem o jsonnet! Faça o que quiser.
• GitOps para a medula óssea: tudo no git, tudo em uma luz- mestre que reflete nossa intenção.
• Declarabilidade : Kapitan congratula-se com a compilação de modelos de manifesto em representações específicas. E você compila seus scripts.
• Contexto controlado : usamos scripts compilados para simplificar nosso trabalho, por exemplo, ao definir contextos e configurar clusters.
  Configuração do Kubernetes: compiled/target_A/setup/setup.sh
  Aplicar alterações: compiled/target_A/setup/apply.sh
• Idempotência : o Kapitan permite alterar modelos e ferramentas de refatoração de código. Manifestos e códigos compilados não serão alterados sem o seu comando, portanto você não tem nada a temer ao refatorar.
• Causa e efeito : somos a favor de um fluxo de trabalho em que alterações no inventário ou modelos e arquivos compilados são incluídas em uma solicitação de mesclagem. Portanto, o revisor poderá avaliar suas alterações e suas consequências reais. É bom saber se uma alteração no modelo afetará uma, duas ou mais metas.
• E finalmente : Kapitan não está ligado ao Kubernetes. Apenas cria arquivos. A implantação das mudanças envolveu o kubectl . Nós fornecemos apenas um shell para que os comandos sejam executados de maneira consistente.

Eu preciso disso?

Vamos deixar claro : você provavelmente ainda não precisa do Kapitan.

Mas tudo depende do que você está tentando fazer e da complexidade do seu sistema.

O Kapitan é uma poderosa ferramenta de investimento. Use-o em cenários complexos em que você precisa implantar vários aplicativos em um monte de clusters.

Se você possui aplicativos padrão, está apenas aprendendo o Kubernetes ou já está satisfeito com seu fluxo de trabalho, o Helm ou sua alternativa atual funcionará.

Imagino Helm como o apt-get para Kubernetes , e Kapitan é algo como Puppet .

No próximo post, darei exemplos específicos e descreverei em detalhes o inventário. Escreva sobre o que você quer saber ou o que concorda / discorda nesta postagem.

Obrigado a Jacek Gruzewski .