👂🏼 🤵🏼 🕺 Apresentando o Helm 3 👞 👍 ☠️

Nota perev. : 16 de maio deste ano é um marco significativo no desenvolvimento do gerenciador de pacotes para o Kubernetes - Helm. Neste dia, foi lançada a primeira versão alfa da futura versão principal do projeto - 3.0. Sua libertação trará mudanças significativas e há muito esperadas em Helm, que muitos na comunidade Kubernetes têm grandes esperanças. Nós mesmos os tratamos, como usamos ativamente o Helm para implantar aplicativos: o integramos à nossa ferramenta para implementar o werf de CI / CD e, de tempos em tempos, fazemos uma contribuição viável para o desenvolvimento upstream. Esta tradução combina 7 notas do blog oficial do Helm, que são programadas para a primeira versão alfa do Helm 3 e contam sobre a história do projeto e os principais recursos do Helm 3. Seu autor é Matt "bacongobbler" Fisher, funcionário da Microsoft e um dos principais mantenedores do Helm.

15 de outubro de 2015 nasceu o projeto, agora conhecido como Helm. Apenas um ano após sua fundação, a comunidade Helm ingressou no Kubernetes, trabalhando simultaneamente ativamente no Helm 2. Em junho de 2018, Helm ingressou no CNCF como um projeto de incubação. Avanço rápido para o presente - e agora a primeira versão alfa do novo Helm 3 está a caminho (esta versão já ocorreu em meados de maio - aprox. Transl.) .

Neste artigo, falarei sobre como tudo começou, como chegamos ao estágio atual, apresentarei alguns recursos exclusivos disponíveis na primeira versão alfa do Helm 3 e explicarei como planejamos desenvolver ainda mais.

Resumo:

história da criação de Helm;
despedida gentil de Tiller;
repositórios de gráficos;
gerenciamento de liberação;
mudanças nas dependências do gráfico;
gráficos de biblioteca;
o que vem a seguir?

História do Helm

Nascimento

O Helm 1 começou como um projeto de código aberto criado pela Deis. Fomos uma pequena startup absorvida pela Microsoft na primavera de 2017. Nosso outro projeto de código aberto, também chamado Deis, tinha uma ferramenta deisctl que foi usada (entre outras coisas) para instalar e operar a plataforma Deis no cluster Fleet . A frota era uma das primeiras plataformas para orquestração de contêineres na época.

Em meados de 2015, decidimos mudar de rumo e transferimos o Deis (na época renomeado para Deis Workflow) de Fleet para Kubernetes. Um dos primeiros a redesenhar a deisctl instalação deisctl . Nós o usamos para instalar e gerenciar o Deis Workflow em um cluster da Frota.

O Helm 1 foi criado à imagem de conhecidos gerenciadores de pacotes, como Homebrew, apt e yum. Sua principal tarefa era simplificar tarefas como empacotar e instalar aplicativos no Kubernetes. Helm foi introduzido oficialmente em 2015 na conferência KubeCon em San Francisco.

Nossa primeira tentativa com Helm funcionou, mas havia sérias restrições. Ele pegou um conjunto de manifestos do Kubernetes, aromatizado com geradores, como blocos YAML de matéria- prima e carregou os resultados no Kubernetes.

* Nota perev. : Na primeira versão do Helm, a sintaxe YAML foi escolhida para descrever os recursos do Kubernetes, e os modelos Jinja e os scripts Python foram suportados ao escrever configurações. Escrevemos mais sobre isso e o dispositivo da primeira versão do Helm no capítulo "Uma Breve História do Helm" deste material .

Por exemplo, para substituir um campo em um arquivo YAML, você deve adicionar a seguinte construção ao manifesto:

 #helm:generate sed -i -es|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

É legal que existam mecanismos de modelo hoje, não é?

Por muitas razões, esse instalador inicial do Kubernetes exigia uma lista codificada de arquivos de manifesto e executava apenas uma pequena sequência fixa de eventos. Era tão difícil de usar que a equipe de P&D da Deis Workflow enfrentou dificuldades ao tentar transferir seu produto para essa plataforma - no entanto, as sementes da idéia já foram semeadas. Nossa primeira tentativa foi uma grande oportunidade de aprendizado: percebemos que éramos realmente apaixonados por criar ferramentas pragmáticas que resolvem os problemas cotidianos de nossos usuários.

Com base na experiência de erros passados, começamos a desenvolver o Leme 2.

Elmo da Criação 2

No final de 2015, a equipe do Google entrou em contato conosco. Eles trabalharam em uma ferramenta semelhante para o Kubernetes. O Deployment Manager para Kubernetes era a porta da ferramenta existente usada para o Google Cloud Platform. "Nós", eles perguntaram, "passar alguns dias discutindo as semelhanças e diferenças?"

Em janeiro de 2016, as equipes do Helm and Deployment Manager se reuniram em Seattle para trocar idéias. As negociações terminaram com um plano ambicioso: combinar os dois projetos para criar o Helm 2. Juntamente com Deis e Google, os caras da SkippBox (agora parte do Bitnami - aprox. Transl.) Se juntaram à equipe de desenvolvimento e começamos a trabalhar no Helm 2.

Queríamos manter a facilidade de uso do Helm, mas adicione o seguinte:

modelos de gráficos para personalização;
gerenciamento intracluster para equipes;
Repositório de gráficos de primeira classe
formato de pacote estável com a capacidade de assinar;
Forte compromisso com a versão semântica e manutenção da compatibilidade com versões anteriores.

Para atingir esses objetivos, um segundo elemento foi adicionado ao ecossistema Helm. Esse componente intracluster foi chamado Tiller e estava envolvido na instalação dos gráficos Helm e em seu gerenciamento.

Desde o lançamento do Helm 2 em 2016, o Kubernetes ganhou várias inovações importantes. O controle de acesso baseado em função ( RBAC ) foi introduzido , o que acabou substituindo o controle de acesso baseado em atributo (ABAC). Novos tipos de recursos foram introduzidos (as implantações naquele momento ainda permaneciam no status beta). As definições de recursos personalizados (originalmente chamadas de recursos de terceiros ou TPRs) foram inventadas. E o mais importante, um conjunto de práticas recomendadas apareceu.

Em meio a todas essas mudanças, Helm continuou a servir fielmente aos usuários do Kubernetes. Após três anos e muitas novas adições, ficou claro que era hora de fazer alterações significativas na base de códigos para que o Helm continuasse atendendo às necessidades crescentes de um ecossistema em desenvolvimento.

Adeus gentil a Tiller

Durante o desenvolvimento do Helm 2, apresentamos o Tiller como parte de nossa integração com o Deployment Manager do Google. O Tiller desempenhou um papel importante para as equipes que trabalham em um cluster comum: permitiu que vários especialistas que operavam a infraestrutura interagissem com o mesmo conjunto de lançamentos.

Como o controle de acesso baseado em função (RBAC) foi ativado por padrão no Kubernetes 1.6, o trabalho com o Tiller na produção ficou mais difícil. Devido ao grande número de possíveis políticas de segurança, nossa posição foi propor permissões por padrão. Isso permitiu que os iniciantes experimentassem Helm e Kubernetes sem precisar mergulhar nas configurações de segurança primeiro. Infelizmente, essa configuração permissiva pode dotar o usuário de uma gama excessivamente ampla de permissões que ele não precisa. Os engenheiros do DevOps e do SRE precisaram aprender etapas operacionais adicionais instalando o Tiller em um cluster com vários locatários.

Depois de aprender como os membros da comunidade usam o Helm em situações específicas, percebemos que o sistema de gerenciamento de liberação de Tiller não precisava contar com um componente intra-cluster para manter o estado ou a função como um hub central com informações sobre a liberação. Em vez disso, pudemos obter informações do servidor da API do Kubernetes, gerar um gráfico do lado do cliente e salvar o registro de instalação no Kubernetes.

A principal tarefa do Tiller poderia ser realizada sem o Tiller, portanto, uma de nossas primeiras decisões sobre o Leme 3 foi uma completa rejeição do Tiller.

Com a partida de Tiller, o modelo de segurança Helm foi radicalmente simplificado. O Helm 3 agora suporta todos os métodos modernos de segurança, identificação e autorização dos Kubernetes atuais. As permissões de leme são determinadas usando o arquivo kubeconfig . Os administradores de cluster podem restringir os direitos do usuário com qualquer nível de granularidade. As liberações ainda são armazenadas dentro do cluster, o restante da funcionalidade Helm é preservado.

Repositórios de gráficos

Em um nível alto, o repositório de gráficos é um local onde você pode armazenar e compartilhar gráficos. O cliente Helm compacta e envia os gráficos para o repositório. Simplificando, o repositório de gráficos é um servidor HTTP primitivo com um arquivo index.yaml e alguns gráficos compactados.

Embora existam algumas vantagens em que a API do repositório de gráficos atende aos requisitos mais básicos para o repositório, também possui várias desvantagens:

Os repositórios de gráficos são pouco compatíveis com a maioria das implementações de segurança necessárias em um ambiente de produção. Ter uma API padrão para autenticação e autorização é crucial nos cenários de produção.
As ferramentas do Helm para rastrear a origem do gráfico, usadas para assinar, verificar a integridade e a origem do gráfico, são uma parte opcional do processo de publicação do gráfico.
Em cenários com vários usuários, o mesmo gráfico pode ser carregado por outro usuário, dobrando a quantidade de espaço necessária para armazenar o mesmo conteúdo. Repositórios mais inteligentes foram desenvolvidos para resolver esse problema, mas eles não fazem parte da especificação formal.
O uso de um único arquivo de índice para pesquisar, armazenar metadados e obter gráficos complicou o desenvolvimento de implementações seguras para vários usuários.

O projeto Docker Distribution (também conhecido como Docker Registry v2) é o sucessor do Docker Registry e, na verdade, atua como um conjunto de ferramentas para empacotar, enviar, armazenar e entregar imagens do Docker. Muitos serviços de nuvem grandes oferecem produtos baseados em distribuição. Graças a essa atenção cada vez maior, o projeto Distribution se beneficiou de muitos anos de aprimoramentos, melhores práticas no campo da segurança e testes em condições de "combate", que o transformaram em um dos heróis desconhecidos mais bem-sucedidos do mundo de código aberto.

Mas você sabia que o projeto Distribution foi desenvolvido para distribuir qualquer forma de conteúdo, não apenas imagens de contêineres?

Graças aos esforços da Open Container Initiative (ou OCI), os gráficos Helm podem ser colocados em qualquer instância da Distribuição. Até agora, esse processo é experimental. O trabalho de suporte para logins e outras funções necessárias para um Helm 3 completo ainda não terminou, mas estamos muito satisfeitos em aprender com as descobertas feitas pelas equipes de OCI e Distribuição ao longo dos anos. E, graças à sua orientação e liderança, aprendemos qual é a operação de um serviço altamente acessível em larga escala.

Uma descrição mais detalhada de algumas das próximas alterações nos repositórios de Helm-charts está disponível aqui .

Gerenciamento de Liberação

No Helm 3, o estado de um aplicativo é monitorado dentro de um cluster por alguns objetos:

liberar objeto - representa uma instância do aplicativo;
segredo da versão de lançamento - representa o estado desejado do aplicativo em um momento específico (por exemplo, o lançamento de uma nova versão).

A helm install chamada cria um objeto de liberação e um segredo de versão de liberação. A chamada de helm upgrade requer um objeto de liberação (que pode ser alterado) e cria um novo segredo da versão de liberação que contém novos valores e um manifesto preparado.

O objeto release contém informações sobre o release, em que release é uma instalação específica de um gráfico e valores nomeados. Este objeto descreve os metadados de nível superior sobre a liberação. O objeto de liberação é preservado durante todo o ciclo de vida do aplicativo e atua como o proprietário de todos os segredos da versão de liberação, bem como de todos os objetos criados diretamente pelo gráfico Helm.

A versão secreta da versão associa uma versão a uma série de revisões (instalação, atualizações, reversões, desinstalação).

No Helm 2, as revisões foram extremamente consistentes. A chamada de helm install criou a v1, a atualização subseqüente da atualização v2 e assim por diante. O segredo de lançamento e versão de lançamento foi recolhido em um único objeto, conhecido como revisão. As revisões foram armazenadas no mesmo espaço para nome do Tiller, o que significava que cada versão era "global" em termos de espaço para nome; como resultado, apenas uma instância do nome poderia ser usada.

No Helm 3, cada release é associado a um ou mais segredos da versão do release. O objeto release sempre descreve a versão atual implantada no Kubernetes. Cada segredo da versão do release descreve apenas uma versão deste release. Uma atualização, por exemplo, criará um novo segredo da versão de lançamento e modificará o objeto de lançamento para apontar para essa nova versão. No caso de reversão, você pode usar os segredos da versão anterior para reverter a liberação para o estado anterior.

Depois de abandonar o Tiller, o Helm 3 armazena os dados da liberação em um único espaço para nome com a liberação. Essa alteração permite instalar um gráfico com o mesmo nome de versão em um espaço para nome diferente e os dados são salvos entre atualizações / reinicializações de cluster no etcd. Por exemplo, você pode instalar o Wordpress no espaço para nome "foo" e, em seguida, no espaço para nome "bar", e as duas versões podem ser chamadas "wordpress".

Alterações de dependência do gráfico

Os gráficos empacotados (usando o helm package ) para uso no Helm 2 podem ser instalados no Helm 3, mas o fluxo de trabalho de desenvolvimento de gráficos foi completamente revisado; portanto, é necessário fazer algumas alterações para continuar o desenvolvimento de gráficos com o Helm 3. Em particular, o sistema de gerenciamento mudou dependências do gráfico.

O sistema de gerenciamento de dependências do gráfico mudou de requirements.yaml e requirements.lock para Chart.yaml e Chart.lock . Isso significa que os gráficos que usam o helm dependency exigem alguma configuração para funcionar no Leme 3.

Vejamos um exemplo. Adicione uma dependência ao gráfico no Helm 2 e veja o que muda quando você alterna para o Helm 3.

No Helm 2 requirements.yaml era assim:

 dependencies: - name: mariadb version: 5.xx repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database

No Helm 3, a mesma dependência será refletida no seu Chart.yaml :

 dependencies: - name: mariadb version: 5.xx repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database

Os charts/ ainda são carregados e colocados no diretório charts/ , portanto os subcharts no diretório charts/ continuarão a funcionar sem alterações.

Introdução aos Gráficos da Biblioteca

O Helm 3 suporta uma classe de gráfico chamada gráfico de biblioteca . Esse gráfico é usado por outros gráficos, mas não cria artefatos de liberação por si próprio. Os modelos de gráfico de biblioteca podem declarar apenas elementos de define . Outro conteúdo é simplesmente ignorado. Isso permite que os usuários reutilizem e compartilhem fragmentos de código que podem ser usados em muitos gráficos, evitando assim a duplicação e aderindo ao princípio DRY .

Os gráficos da biblioteca são declarados na seção dependencies do arquivo Chart.yaml . A instalação e o gerenciamento deles não são diferentes de outros gráficos.

 dependencies: - name: mylib version: 1.xx repository: quay.io

Esperamos ansiosamente os casos de uso que esse componente abrirá para os desenvolvedores de gráficos, bem como as práticas recomendadas que podem surgir dos gráficos de bibliotecas.

O que vem a seguir?

Helm 3.0.0-alpha.1 - a base sobre a qual estamos começando a criar uma nova versão do Helm. No artigo, descrevi alguns recursos interessantes do Helm 3. Muitos deles ainda estão nos estágios iniciais de desenvolvimento e isso é normal; A essência da versão alfa é testar a ideia, coletar feedback dos primeiros usuários e confirmar nossas suposições.

Assim que a versão alfa for lançada (lembre-se de que isso já aconteceu - aprox. Transl.) , Começaremos a receber patches para o Helm 3 da comunidade. É necessário criar uma base sólida que permita desenvolver e adotar novas funcionalidades, e os usuários podem se sentir envolvidos no processo, abrindo tickets e fazendo correções.

No artigo, tentei destacar algumas melhorias sérias que aparecerão no Helm 3, mas essa lista não é de forma alguma exaustiva. O plano em grande escala do Helm 3 inclui inovações como estratégias de atualização aprimoradas, integração mais profunda com registros da OCI e o uso de esquemas JSON para verificar os valores do gráfico. Também planejamos limpar a base de código e atualizar as partes dela que foram negligenciadas nos últimos três anos.

Se você sente que perdemos alguma coisa, teremos o maior prazer em ouvir seus pensamentos!

Participe da discussão em nossos canais do Slack :

#helm-users para perguntas e comunicação fácil com a comunidade;
#helm-dev para discutir solicitações pull, código e bugs.

Você também pode conversar em nossas chamadas semanais para desenvolvedores públicos às quintas-feiras, às 19:30 MSK. As reuniões são dedicadas a discutir as tarefas nas quais os principais desenvolvedores e a comunidade estão trabalhando, bem como os tópicos de discussão da semana. Qualquer pessoa pode participar e participar da reunião. O link está disponível no canal #helm-dev Slack.

Apresentando o Helm 3