🥇Introdução ao Helm 3

Observação. trad.: 16 de maio deste ano marca um marco significativo no desenvolvimento do gerenciador de pacotes para Kubernetes - Helm. Neste dia foi apresentada a primeira versão alfa da futura versão principal do projeto - 3.0. Seu lançamento trará mudanças significativas e há muito esperadas ao Helm, nas quais muitos na comunidade Kubernetes têm grandes esperanças. Nós mesmos somos um deles, pois usamos ativamente o Helm para implantação de aplicativos: nós o integramos em nossa ferramenta para implementação de CI/CD bem e de tempos em tempos damos a nossa contribuição para o desenvolvimento do upstream. Esta tradução combina 7 notas do blog oficial do Helm, que são dedicadas à primeira versão alfa do Helm 3 e falam sobre a história do projeto e as principais características do Helm 3. Seu autor é Matt “bacongobbler” Fisher, funcionário da Microsoft e um dos principais mantenedores do Helm.

No dia 15 de outubro de 2015 nasceu o projeto hoje conhecido como Helm. Apenas um ano após sua fundação, a comunidade Helm juntou-se ao Kubernetes, enquanto trabalhava ativamente no Helm 2. Em junho de 2018, Helm ingressou na CNCF como um projeto em desenvolvimento (incubação). Avançando para o presente, a primeira versão alfa do novo Helm 3 está a caminho. (esta liberação já aconteceu em meados de maio - aprox. trad.).

Neste artigo, falarei sobre onde tudo começou, como chegamos onde estamos hoje, apresentarei alguns dos recursos exclusivos disponíveis na primeira versão alfa do Helm 3 e explicarei como planejamos desenvolver ainda mais.

Resumo:

a história da criação de Helm;
uma terna despedida 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 depois?

A história de Helm

Nascimento

Helm 1 começou como um projeto Open Source criado por Deis. Éramos uma pequena startup absorvido Microsoft na primavera de 2017. Nosso outro projeto Open Source, também chamado Deis, tinha uma ferramenta deisctl, que foi usado (entre outras coisas) para instalar e operar a plataforma Deis em Cluster de frota. Na época, o Fleet foi uma das primeiras plataformas de orquestração de contêineres.

Em meados de 2015, decidimos mudar de rumo e transferimos o Deis (na época renomeado como Deis Workflow) do Fleet para o Kubernetes. Uma das primeiras a ser redesenhada foi a ferramenta de instalação. deisctl. Nós o usamos para instalar e gerenciar o Deis Workflow no cluster Fleet.

O Helm 1 foi criado à imagem de gerenciadores de pacotes famosos como Homebrew, apt e yum. Seu principal objetivo era simplificar tarefas como empacotamento e instalação de aplicativos no Kubernetes. Helm foi apresentado oficialmente em 2015 na conferência KubeCon em São Francisco.

Nossa primeira tentativa com Helm funcionou, mas teve algumas limitações sérias. Ele pegou um conjunto de manifestos do Kubernetes, temperados com geradores como blocos YAML introdutórios (matéria inicial)* e carregou os resultados no Kubernetes.

* Observação. trad.: Desde a primeira versão do Helm, a sintaxe YAML foi escolhida para descrever os recursos do Kubernetes, e os modelos Jinja e scripts Python foram suportados ao escrever configurações. Escrevemos mais sobre isso e a estrutura da primeira versão do Helm em geral no capítulo “Uma Breve História do Helm” este material.

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

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

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

Por vários motivos, esse instalador inicial do Kubernetes exigia uma lista codificada de arquivos de manifesto e executava apenas uma sequência pequena e fixa de eventos. Era tão difícil de usar que a equipe de P&D do Deis Workflow teve dificuldades ao tentar transferir seu produto para esta plataforma - porém, as sementes da ideia já haviam sido plantadas. Nossa primeira tentativa foi uma grande oportunidade de aprendizado: percebemos que éramos verdadeiramente apaixonados por criar ferramentas pragmáticas que resolvessem problemas cotidianos de nossos usuários.

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

Fazendo o Elmo 2

No final de 2015, a equipe do Google nos contatou. Eles estavam trabalhando em uma ferramenta semelhante para Kubernetes. O Deployment Manager for Kubernetes era uma versão de uma ferramenta existente usada para o Google Cloud Platform. “Gostaríamos”, perguntaram eles, “de passar alguns dias discutindo as 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: combinar os dois projetos para criar o Helm 2. Junto com Deis e Google, o pessoal da SkippBox (agora parte do Bitnami - trad. aprox.), e começamos a trabalhar no Helm 2.

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

modelos de gráficos para personalização;
gestão intra-cluster para equipes;
repositório de gráficos de classe mundial;
formato de pacote estável com opção de assinatura;
um forte compromisso com o versionamento semântico e com a manutenção da compatibilidade retroativa entre versões.

Para atingir estes objetivos, um segundo elemento foi adicionado ao ecossistema Helm. Esse componente intra-cluster foi chamado de Tiller e foi responsável por instalar os gráficos do Helm e gerenciá-los.

Desde o lançamento do Helm 2 em 2016, o Kubernetes adicionou várias inovações importantes. Adicionado controle de acesso baseado em função (RBAC), que eventualmente substituiu o Controle de Acesso Baseado em Atributos (ABAC). Novos tipos de recursos foram introduzidos (as implantações ainda estavam em beta na época). Definições de recursos personalizados (originalmente chamados de recursos de terceiros ou TPRs) foram inventados. E o mais importante, surgiu um conjunto de melhores práticas.

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

Uma terna despedida de 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 dentro de um cluster comum: permitiu que diferentes especialistas que operam a infraestrutura interagissem com o mesmo conjunto de versões.

Como o controle de acesso baseado em função (RBAC) foi habilitado por padrão no Kubernetes 1.6, trabalhar com o Tiller na produção tornou-se mais difícil. Devido ao grande número de políticas de segurança possíveis, nossa posição tem sido oferecer uma configuração permissiva por padrão. Isso permitiu que iniciantes experimentassem Helm e Kubernetes sem precisar primeiro mergulhar nas configurações de segurança. Infelizmente, essa configuração de permissão poderia dotar o usuário de uma gama muito ampla de permissões que ele não precisava. Os engenheiros de DevOps e SRE tiveram que aprender etapas operacionais adicionais ao instalar o Tiller em um cluster multilocatário.

Depois de aprender como a comunidade usava 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 intracluster para manter o estado ou funcionar como um hub central para informações de lançamento. Em vez disso, poderíamos simplesmente receber informações do servidor API do Kubernetes, gerar um gráfico no lado do cliente e armazenar um registro da instalação no Kubernetes.

O principal objetivo do Tiller poderia ter sido alcançado sem o Tiller, então uma das nossas primeiras decisões em relação ao Helm 3 foi abandonar completamente o Tiller.

Com a saída do Tiller, o modelo de segurança do Helm foi radicalmente simplificado. Helm 3 agora oferece suporte a todos os métodos modernos de segurança, identidade e autorização do Kubernetes atual. As permissões do Helm são determinadas usando arquivo kubeconfig. Os administradores de cluster podem restringir os direitos do usuário a qualquer nível de granularidade. As versões ainda são salvas no cluster e o restante da funcionalidade do Helm permanece intacto.

Repositórios de gráficos

Em um nível superior, um repositório de gráficos é um local onde os gráficos podem ser armazenados e compartilhados. O cliente Helm empacota e envia os gráficos para o repositório. Simplificando, um repositório de gráficos é um servidor HTTP primitivo com um arquivo index.yaml e alguns gráficos empacotados.

Embora existam algumas vantagens em a API do Charts Repository atender aos requisitos mais básicos de armazenamento, também existem algumas desvantagens:

Os repositórios de gráficos não são compatíveis com a maioria das implementações de segurança exigidas em um ambiente de produção. Ter uma API padrão para autenticação e autorização é extremamente importante em cenários de produção.
As ferramentas de proveniência de gráficos do Helm, usadas para assinar, verificar a integridade e a procedência de um gráfico, são uma parte opcional do processo de publicação de gráficos.
Em cenários multiusuário, o mesmo gráfico pode ser carregado por outro usuário, duplicando a quantidade de espaço necessária para armazenar o mesmo conteúdo. Repositórios mais inteligentes foram desenvolvidos para resolver este problema, mas não fazem parte da especificação formal.
O uso de um único arquivo de índice para pesquisar, armazenar metadados e recuperar gráficos dificultou o desenvolvimento de implementações seguras para vários usuários.

Projeto Distribuição Docker (também conhecido como Docker Registry v2) é o sucessor do Docker Registry e atua essencialmente como um conjunto de ferramentas para empacotar, enviar, armazenar e entregar imagens Docker. Muitos grandes serviços em nuvem oferecem produtos baseados em distribuição. Graças a esta maior atenção, o projeto Distribution beneficiou de anos de melhorias, melhores práticas de segurança e testes de campo que o tornaram um dos heróis desconhecidos de maior sucesso do mundo Open Source.

Mas você sabia que o Projeto Distribuição foi pensado para distribuir qualquer forma de conteúdo, não apenas imagens contêineres?

Graças aos esforços Iniciativa de Contêiner Aberto (ou OCI), os gráficos Helm podem ser colocados em qualquer instância de distribuição. Por enquanto, esse processo é experimental. O suporte de login e outros recursos necessários para um Helm 3 completo são um trabalho em andamento, mas estamos entusiasmados em aprender com as descobertas que as equipes de OCI e Distribuição fizeram ao longo dos anos. E através da sua orientação e orientação, aprendemos como é operar um serviço altamente disponível em grande escala.

Uma descrição mais detalhada de algumas alterações futuras nos repositórios de gráficos do Helm está disponível по ссылке.

Gerenciamento de liberação

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

objeto release - 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).

Desafio helm install cria um objeto de lançamento e um segredo de versão de lançamento. Chamar helm upgrade requer um objeto de lançamento (que pode ser alterado) e cria um novo segredo de versão de lançamento contendo os novos valores e um manifesto preparado.

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

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

No Helm 2, as revisões foram extremamente consistentes. Chamar helm install criou v1, a atualização subsequente (upgrade) - v2 e assim por diante. O lançamento e o segredo da versão de lançamento foram recolhidos em um único objeto conhecido como revisão. As revisões foram armazenadas no mesmo namespace do Tiller, o que significava que cada versão era "global" em termos de namespace; como resultado, apenas uma instância do nome poderia ser usada.

No Helm 3, cada versão está associada a um ou mais segredos de versão de lançamento. O objeto release sempre descreve a versão atual implantada no Kubernetes. Cada segredo de versão de lançamento descreve apenas uma versão desse lançamento. Uma atualização, 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. No caso de uma reversão, você pode usar segredos da versão anterior para reverter a versão para um estado anterior.

Depois que o Tiller é abandonado, o Helm 3 armazena os dados da versão no mesmo namespace da versão. Essa alteração permite que você instale um gráfico com o mesmo nome de versão em um namespace diferente e os dados sejam salvos entre atualizações/reinicializações do cluster no etcd. Por exemplo, você pode instalar o WordPress no namespace “foo” e depois no namespace “bar”, e ambas as versões podem ser chamadas de “wordpress”.

Mudanças nas dependências do gráfico

Gráficos compactados (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 gráficos foi completamente reformulado, portanto, algumas alterações devem ser feitas para continuar o desenvolvimento de gráficos com o Helm 3. Em particular, o sistema de gerenciamento de dependências de gráficos mudou.

O sistema de gerenciamento de dependências do gráfico mudou de requirements.yaml и requirements.lock em Chart.yaml и Chart.lock. Isso significa que os gráficos que usaram o comando helm dependency, requer alguma configuração para funcionar no Helm 3.

Vejamos um exemplo. Vamos adicionar uma dependência ao gráfico no Helm 2 e ver o que muda ao passar para o Helm 3.

No Leme 2 requirements.yaml ficou assim:

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 gráficos ainda são baixados e colocados no diretório charts/, então subgráficos (subgráficos), deitado no catálogo charts/, continuará funcionando sem alterações.

Apresentando gráficos de biblioteca

Helm 3 oferece suporte a uma classe de gráficos chamada gráficos de biblioteca (gráfico da biblioteca). Este gráfico é usado por outros gráficos, mas não cria nenhum artefato de liberação por si só. Os modelos de gráfico de biblioteca só podem declarar elementos define. Outros conteúdos são simplesmente ignorados. Isso permite que os usuários reutilizem e compartilhem trechos de código que podem ser usados em vários 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 no arquivo Chart.yaml. Instalá-los e gerenciá-los não é diferente de outros gráficos.

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

Estamos entusiasmados com os casos de uso que este componente abrirá para os desenvolvedores de gráficos, bem como com as práticas recomendadas que podem surgir dos gráficos da biblioteca.

Qual é o próximo?

Helm 3.0.0-alpha.1 é a base sobre a qual começamos a construir 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; O objetivo de uma 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 que isso é já aconteceu - Aproximadamente. trad.), começaremos a aceitar patches da comunidade para o Helm 3. Você precisa criar uma base sólida que permita o desenvolvimento e a adoção de novas funcionalidades e que os usuários se sintam envolvidos no processo, abrindo tickets e fazendo correções.

Tentei destacar algumas das principais melhorias do Helm 3, mas esta lista não é de forma alguma exaustiva. O roteiro completo do Helm 3 inclui recursos como estratégias de atualização aprimoradas, integração mais profunda com registros OCI e o uso de esquemas JSON para validar valores de gráficos. Também planejamos limpar a base de código e atualizar partes dela que foram negligenciadas nos últimos três anos.

Se você acha que perdemos alguma coisa, adoraríamos ouvir sua opinião!

Participe da discussão em nosso Canais Slack:

#helm-users para dúvidas e comunicação simples com a comunidade;
#helm-dev para discutir solicitações pull, código e bugs.

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

Apresentando o Helm 3