🥇 Introdução ao Helm 3

Nota do tradutor.: 16 de maio deste ano — um marco significativo no desenvolvimento do gerenciador de pacotes para Kubernetes — Helm. Nesse dia, foi apresentado o primeiro release alfa da futura versão importante do projeto — 3.0. Seu lançamento trará mudanças substanciais e esperadas ao Helm, nas quais muitos na comunidade Kubernetes depositam grandes expectativas. Nós mesmos nos incluímos entre esses, pois utilizamos ativamente o Helm para implantar aplicativos: o integramos à nossa ferramenta para implementação de CI/CD werf e, ocasionalmente, contribuímos para o desenvolvimento upstream. Esta tradução reúne 7 notas do blog oficial do Helm, que marcam o primeiro release alfa do Helm 3 e contam a história do projeto e suas principais funcionalidades. O 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 do Helm se juntou ao Kubernetes, trabalhando ativamente no Helm 2. Em junho de 2018, o Helm entrou para a CNCF como um projeto incubando. Vamos ao presente — e já está se aproximando o primeiro release alfa do novo Helm 3 (este release já ocorreu em meados de maio — nota do tradutor).

Neste material, contarei como tudo começou, como chegamos ao estágio atual, apresentarei algumas características únicas disponíveis no primeiro release alfa do Helm 3 e explicarei como planejamos seguir em frente.

Resumo:

história da criação do Helm;
uma despedida suave do Tiller;
repositórios de charts;
gestão de releases;
alterações nas dependências dos charts;
library charts;
e agora, o que fazer?

A História da Criação do Helm

Nascimento

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

No meio de 2015, decidimos mudar de direção e migramos o Deis (naquele momento rebatizado como Deis Workflow) do Fleet para o Kubernetes. Um dos primeiros a ser reformulado foi a ferramenta de instalação deisctl. Nós a utilizamos para instalar e gerenciar o Deis Workflow em um cluster Fleet.

O Helm 1 foi criado com base em conhecidos gerenciadores de pacotes, como Homebrew, apt e yum. Sua principal tarefa era simplificar tarefas como empacotamento e instalação de aplicativos no Kubernetes. O Helm foi oficialmente apresentado em 2015 na conferência KubeCon em San Francisco.

Nossa primeira tentativa com Helm funcionou, mas não sem limitações sérias. Ele usava um conjunto de manifestos do Kubernetes, enriquecidos por geradores, como blocos YAML de entrada. (front-matter)*, e carregava os resultados no Kubernetes.

* Nota do tradutor.: A partir da primeira versão do Helm, foi escolhido o syntax YAML para descrever os recursos do Kubernetes, e ao escrever as configurações, suportava-se templates Jinja e scripts Python. Mais sobre isso e sobre como era a primeira versão do Helm, escrevemos no capítulo "Uma breve história do Helm" deste material.

Por exemplo, para substituir um campo em um arquivo YAML, era necessário adicionar a seguinte construção no manifesto:

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

É incrível que hoje existam geradores de templates, não é mesmo?

Por muitas razões, esse primeiro instalador do Kubernetes exigia uma lista rigidamente definida de arquivos de manifestos e executava apenas uma sequência fixa de eventos. Usá-lo era tão difícil que a equipe de P&D do Deis Workflow teve dificuldades quando tentou migrar seu produto para essa plataforma — no entanto, as sementes da ideia já haviam sido plantadas. Nossa primeira tentativa foi uma excelente oportunidade de aprendizado: percebemos que estávamos realmente apaixonados por criar ferramentas pragmáticas que resolvessem problemas cotidianos para nossos usuários.

Baseando-se na experiência de erros passados, começamos a desenvolver o Helm 2.

Criação do Helm 2

No final de 2015, a equipe do Google entrou em contato conosco. Eles estavam trabalhando em uma ferramenta semelhante para o Kubernetes. O Deployment Manager para Kubernetes era um porto de uma ferramenta existente que era usada para a Google Cloud Platform. "Não queremos, — perguntaram eles, — passar alguns dias discutindo semelhanças e diferenças?"

Em janeiro de 2016, as equipes do Helm e do Deployment Manager se reuniram em Seattle para trocar ideias. As negociações terminaram com um plano ambicioso: unir os dois projetos para criar o Helm 2. Juntamente com o Deis e o Google, a equipe de desenvolvedores foi reforçada por pessoal do SkippBox (hoje parte da Bitnami — nota do tradutor), e começamos a trabalhar no Helm 2.

Queríamos manter a simplicidade de uso do Helm, mas adicionar o seguinte:

modelos de charts para personalização;
gerenciamento intra-cluster para equipes;
um repositório de charts de primeira classe;
um formato de pacotes estável com suporte à assinatura;
um forte compromisso com versionamento semântico e manutenção da compatibilidade reversa entre versões.

Para alcançar esses objetivos, foi adicionado um segundo elemento ao ecossistema Helm. Este componente intra-cluster foi chamado de Tiller e era responsável pela instalação e gerenciamento de charts do Helm.

Desde o lançamento do Helm 2 em 2016, o Kubernetes passou por várias inovações significativas. O gerenciamento de acesso baseado em funções (RBAC), que eventualmente substituiu o controle de acesso baseado em atributos (ABAC). Novos tipos de recursos foram introduzidos (os Deployments ainda estavam em status beta na época). As Custom Resource Definitions foram inventadas (originalmente chamadas de Third Party Resources ou TPRs). E, o mais importante, um conjunto de melhores práticas foi estabelecido.

Em meio a todas essas mudanças, o Helm continuou a servir com lealdade os usuários do Kubernetes. Após três anos e muitas novas adições, ficou claro que era hora de fazer mudanças significativas na base de código para que o Helm pudesse continuar a atender às crescentes necessidades do ecossistema em evolução.

Uma despedida delicada ao Tiller

Durante o desenvolvimento do Helm 2, apresentamos o Tiller como parte da nossa integração com o Deployment Manager do Google. O Tiller desempenhou um papel importante para as equipes que trabalhavam dentro de um cluster compartilhado: permitia que diferentes especialistas, que gerenciavam a infraestrutura, interagissem com um mesmo conjunto de releases.

Desde que o controle de acesso baseado em funções (RBAC) foi ativado por padrão no Kubernetes 1.6, trabalhar com o Tiller em produção tornou-se mais difícil. Devido ao grande número de políticas de segurança possíveis, nossa posição era oferecer uma configuração permissiva como padrão. Isso permitia que iniciantes experimentassem com o Helm e o Kubernetes sem a necessidade de se aprofundar primeiro nas configurações de segurança. Infelizmente, essa configuração permissiva poderia conceder ao usuário um intervalo de permissões muito amplo, que não era necessário. Engenheiros de DevOps e SRE precisam aprender passos operacionais adicionais ao instalar o Tiller em um cluster multi-tenant.

Ao entender como os membros da comunidade utilizam o Helm em situações específicas, percebemos que o sistema de gerenciamento de lançamentos do Tiller não precisava depender de um componente intra-cluster para manter estados ou funcionar como um hub central com informações sobre lançamentos. Em vez disso, poderíamos simplesmente obter informações da API do servidor Kubernetes, gerar o chart no lado do cliente e manter um registro da instalação no Kubernetes.

A tarefa principal do Tiller poderia ser realizada sem ele, portanto, uma das nossas primeiras decisões em relação ao Helm 3 foi a completa eliminação do Tiller.

Com a saída do Tiller, o modelo de segurança do Helm foi radicalmente simplificado. O Helm 3 agora suporta todos os modernos métodos de segurança, identificação e autorização do Kubernetes atual. As permissões do Helm são definidas através do arquivo kubeconfig. Administradores de cluster podem restringir os direitos dos usuários com qualquer nível de detalhe. Os lançamentos ainda são mantidos dentro do cluster, e a funcionalidade restante do Helm é preservada.

Repositórios de charts

Em um nível alto, um repositório de charts é um lugar para armazenar e compartilhar charts. O cliente Helm empacota e envia charts para o repositório. Em termos simples, um repositório de charts é um servidor HTTP primitivo com um arquivo index.yaml e alguns charts empacotados.

Embora haja algumas vantagens em um API de repositório de charts atender aos requisitos mais básicos de armazenamento, ele também apresenta algumas desvantagens:

Os repositórios de charts são mal compatíveis com a maioria das implementações de segurança necessárias em ambientes de produção. Ter uma API padrão para autenticação e autorização é extremamente importante em cenários de produção.
As ferramentas do Helm para rastreamento da origem do chart, usadas para assinatura, verificação de integridade e origem do chart, são uma parte opcional do processo de publicação do Chart.
Em cenários multusuário, o mesmo chart pode ser carregado por outro usuário, dobrando a quantidade de espaço necessária para armazenar o mesmo conteúdo. Para resolver esse problema, repositórios mais inteligentes foram desenvolvidos, mas eles não fazem parte da especificação formal.
O uso de um único arquivo de índice para buscar, armazenar metadados e obter charts complicou o desenvolvimento de implementações multusuário seguras.

Projeto Docker Distribution (também conhecido como Docker Registry v2) é o sucessor do Docker Registry e, de fato, serve como um conjunto de ferramentas para empacotar, enviar, armazenar e entregar imagens Docker. Muitos grandes provedores de serviços em nuvem oferecem produtos baseados no Distribution. Devido a essa atenção aumentada, o projeto Distribution se beneficiou de anos de melhorias, melhores práticas de segurança e testes em condições de "campo", transformando-o em um dos heróis não cantados mais bem sucedidos do mundo Open Source.

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

Graças aos esforços Open Container Initiative (ou OCI), os charts do Helm podem ser hospedados em qualquer instância do Distribution. Enquanto esse processo ainda está em caráter experimental. O trabalho para suportar logins e outras funções necessárias para um Helm 3 completo ainda não foi concluído, mas estamos muito animados com a oportunidade de aprender com as descobertas feitas pelas equipes da OCI e do Distribution ao longo dos anos. E graças à sua orientação e supervisão, estamos descobrindo o que significa operar um serviço de alta disponibilidade em grande escala.

Uma descrição mais detalhada de algumas alterações futuras nos repositórios dos charts do Helm está disponível no link.

Gerenciamento de lançamentos

No Helm 3, o estado do aplicativo é rastreado dentro do cluster por meio de um par de objetos:

o objeto release — representa uma instância do aplicativo;
o 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).

Chamada helm install cria o objeto de lançamento e o segredo da versão de lançamento. A chamada helm upgrade exige a presença do objeto de lançamento (que pode ser alterado) e cria um novo segredo de versão de lançamento, contendo novos valores e um manifesto preparado.

O objeto de lançamento contém informações sobre o lançamento, onde o lançamento é uma instalação específica de um gráfico nomeado e seus valores. Este objeto descreve os metadados de nível superior sobre o lançamento. O objeto de lançamento é mantido durante todo o ciclo de vida do aplicativo e é o proprietário de todos os segredos de versão de lançamento, assim como de todos os objetos que são diretamente criados pelo gráfico Helm.

O segredo de versão de lançamento vincula o lançamento a uma série de revisões (instalação, atualizações, reversões, exclusões).

No Helm 2, as revisões eram exclusivamente sequenciais. A chamada helm install criou v1, a atualização seguinte (upgrade) — v2, e assim por diante. O lançamento e o segredo da versão de lançamento foram combinados em um único objeto, conhecido como revisão. As revisões eram armazenadas no mesmo namespace que o Tiller, o que significava que cada lançamento era 'global' em termos de namespace; como resultado, apenas uma instância de nome poderia ser usada.

No Helm 3, cada lançamento está associado a um ou mais segredos de versão de lançamento. O objeto de lançamento sempre descreve o lançamento atual implantado no Kubernetes. Cada segredo de versão de lançamento descreve apenas uma versão desse lançamento. Uma atualização (upgrade), por exemplo, criará um novo segredo de versão de lançamento e em seguida alterará o objeto de lançamento para apontar para essa nova versão. Em caso de reversão (rollback), é possível utilizar os segredos de versão de lançamento anteriores para reverter o lançamento ao estado anterior.

Após a eliminação do Tiller, o Helm 3 armazena os dados do lançamento em um namespace que é o mesmo do lançamento. Essa mudança permite instalar um gráfico com o mesmo nome de lançamento em um namespace diferente, e os dados são mantidos entre atualizações/reinicializações do cluster no etcd. Por exemplo, é possível instalar o WordPress no namespace 'foo' e depois no namespace 'bar', e ambos os lançamentos podem ser chamados de 'wordpress'.

Mudanças nas dependências dos gráficos

Gráficos empacotados (usando helm package) para uso com o Helm 2, pode ser instalado com o Helm 3, no entanto, o fluxo de trabalho de desenvolvimento de charts foi completamente revisado, portanto, algumas alterações são necessárias para continuar o desenvolvimento de charts com o Helm 3. Em particular, o sistema de gerenciamento de dependências de charts mudou.

O sistema de gerenciamento de dependências do chart passou a ser requirements.yaml e requirements.lock para Chart.yaml e Chart.lock. Isso significa que os charts que usavam o comando helm dependency, requerem algumas ajustes para funcionar no Helm 3.

Vamos considerar um exemplo. Vamos adicionar uma dependência ao chart do Helm 2 e ver o que muda ao migrar para o Helm 3.

No Helm 2 requirements.yaml parecia o seguinte:

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

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

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

Os charts ainda são baixados e colocados no diretório charts/, portanto, os subcharts (subcharts), localizados na pasta charts/, continuarão a funcionar sem alterações.

Apresentando Library Charts

O Helm 3 suporta uma classe de charts conhecida como charts de biblioteca (library chart). Este chart é utilizado por outros charts, mas não cria nenhum artefato de lançamento por si só. Os templates dos library charts podem declarar apenas elementos definir. Conteúdos diferentes são simplesmente ignorados. Isso permite que os usuários reutilizem e compartilhem fragmentos de código que podem ser usados em muitos charts, evitando a duplicação e seguindo o princípio DRY.

Os library charts são declarados na seção dependencies no arquivo Chart.yaml. A instalação e gerenciamento deles não diferem de outros charts.

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

Estamos ansiosos pelas possibilidades de uso que este componente abrirá para os desenvolvedores de charts, bem como pelas melhores práticas que podem surgir através dos library charts.

E agora?

Helm 3.0.0-alpha.1 é a base sobre a qual começamos a construir uma nova versão do Helm. Neste artigo, descrevi algumas possibilidades interessantes do Helm 3. Muitas delas ainda estão em estágios iniciais de desenvolvimento, e isso é normal; a natureza do alpha release é testar a ideia, coletar feedback dos primeiros usuários e validar nossas suposições.

Assim que a versão alpha for lançada (lembrando que isso já ocorreu — nota do tradutor.), começaremos a aceitar patches para o Helm 3 da comunidade. É necessário criar uma base sólida que permita desenvolver e aceitar novas funcionalidades, e que os usuários possam se sentir envolvidos no processo, abrindo tickets e fazendo correções.

Neste artigo, procurei destacar algumas melhorias significativas que virão com o Helm 3, no entanto, esta lista não pode ser considerada exaustiva. O plano abrangente para o Helm 3 inclui inovações como estratégias de atualização aprimoradas, uma integração mais profunda com registros OCI e o uso de esquemas JSON para validação de valores de charts. Também planejamos limpar a base de código e atualizar partes que foram negligenciadas nos últimos três anos.

Se você sentir que esquecemos de algo, adoraríamos ouvir suas opiniões!

Junte-se à discussão em nossos canais do Slack:

#helm-users para perguntas e para um bate-papo simples com a comunidade;
#helm-dev para discussão de pull requests, código e bugs.

Você também pode participar de nossas Public Developer Calls semanais, às quintas-feiras às 19:30 MSK. As reuniões são dedicadas à discussão de tarefas em que os principais desenvolvedores e a comunidade estão trabalhando, bem como aos tópicos de discussão da semana. Qualquer um pode se juntar e participar da reunião. O link está disponível no canal do Slack #helm-dev.

P.S. do tradutor

Confira também em nosso blog:

Fonte: habr.com