Empacotando aplicações Kubernetes com Helm

Na Movile, temos diversas aplicações rodando em nossa infraestrutura distribuídas em datacenters e provedores de cloud, como AWS, Google e Azure. Com isso, sempre nos preocupamos em disponibilizar o deploy dessas aplicações, da melhor maneira, possibilitando: fácil gerenciamento, rastreabilidade e atualização. Atualmente construímos pacotes RPM dessas aplicações a cada release e nossa automação com o Chef se encarrega de fazer o deploy nos servidores. Assim, o objetivo deste artigo é demonstrar com um exemplo bem simples como estamos fazendo o deploy de aplicações “conteinerizadas”, orquestrado pelo Kubernetes.

Kubernetes

Atualmente estamos migrando algumas aplicações para contêineres e escolhemos o Kubernetes para orquestração devido às principais características:

• Self-healing

Se ocorrer alguma falha, como um crash na aplicação, o contêiner é recriado de maneira instantânea ao invés de ficar parado, com problema, esperando uma ação manual.

• Auto-scaling

É possível realizar o auto-scaling de maneira extremamente simples definindo o número de réplicas de seu pod.

• Gerenciamento de DNS

Para cada pod é criado sua entrada de DNS e, se desenvolvido seu devido manifesto, também cria um nome que pode responder para vários pods (DNS round-robin).

• Load Balancer

É possível criar load balancers externos e internos para publicar os Front-ends.

• Rolling Update e Rollback

Atualização de suas aplicações controladas e graduais assim como a facilidade de reversão caso algo dê errado!

Exemplo de aplicação em Kubernetes

Para facilitar o entendimento, irei demonstrar uma configuração extremamente simples de deploy em Kubernetes:

Como visto no exemplo acima, fizemos o deploy do nginx pelo Kubernetes expondo sua porta publicamente pelo load balancer.

Quando temos uma aplicação somente, é fácil de controlar seus arquivos YAML, mas e quando temos diversas aplicações onde a grande maioria é semelhante, muitas vezes, só mudando de nome e porta? E se eu quiser alterar a versão ou alterar o valor de um campo? Por causa dessas e outras perguntas,tive a necessidade de encontrar algo que facilitasse o templating desses arquivos YAML e encontrei o Helm.

Helm

O Helm é um gerenciador de aplicações Kubernetes que te ajuda a criar, versionar, compartilhar e publicar seus artefatos. Você consegue desenvolver templates dos seus arquivos YAML e durante a instalação de cada aplicação personalizar por parâmetros as variáveis com facilidade. O Helm é mantido pela comunidade e gigantes como Google e Microsoft.

Componentes

O Helm tem dois principais componentes:

•     Helm Client

É o CLI onde gerenciamos repositórios, desenvolvemos localmente os charts e interagimos com o Tiller server. Escrito em Go, utiliza o protocolo gRPC para interagir com o servidor Tiller.

•       Tiller Server

É o servidor que interage com a API do Kubernetes através dos comandos executados pelo Helm Client. Também é escrito em Go.

Instalação

A instalação é bem simples mas exige atenção na pós-instalação, pois em alguns casos é necessário criar uma role para garantir o acesso do Tiller no cluster Kubernetes:

•       Instalação do Client:

•    Criar o ServiceAccount e ClusterRoleBinding:

•       Inicializar o Tiller no cluster e atualizar o repositório:

Pronto! Agora você pode procurar e instalar pacotes do repositório público e criar os seus próprios!

Charts

O Helm utiliza um formato de empacotamento chamado “charts“. Um chart é uma coleção de arquivos que descrevem os recursos que serão aplicados no Kubernetes (os YAMLs).

•    Estrutura do Chart

•       Criando nosso chart

Agora vamos ao que interessa! Vamos transformar nossa aplicação “exemplo” em um chart! Primeiro vamos iniciá-lo:

Será criado um diretório chamado “exemplo” já com alguns arquivos de apoio, recomendo fortemente verificar esses arquivos para entender melhor sua estrutura.

No nosso caso, vamos apagar tudo da pasta templates e começar do zero!

Agora vamos mover nosso exemplo-deploy.yaml e exemplo-service.yaml para a pasta exemplo/templates e alterar onde queremos colocar as diretivas de template:

E o exemplo/values.yaml irá conter alguns valores padrão que poderão ser alterados pelo usuário na instalação do chart:

Vamos testar o chart no modo dry-run e debug para verificar se tudo está conforme esperamos:

Como podem ver, simulei a instalação para ver o template renderizado sem ser instalado de fato, sem passar parâmetros adicionais para ver os valores padrão. Ele gerou automaticamente o Release Name (fair-salamander).

•       Instalando e testando o Chart

Agora vamos ver o resultado final da instalação do que seriam duas aplicações iguais, mas com parâmetros diferentes na instalação, sem a necessidade de retrabalho.

  

Ambos pacotes instalados com sucesso! Vamos conferir se realmente funcionou?

Conclusão

O Helm é uma ferramenta muito flexível na construção de nossos pacotes para Kubernetes. Há muito o que ser explorado como assinatura de charts, criação e sincronização dos pacotes para um repositório privado e até testes para validação! Espero que este simples artigo desperte o seu interesse e traga novas ideias para serem aplicadas com o Helm.

* https://kubernetes.io/

* https://helm.sh/

* https://medium.com/@abhaydiwan/kubernetes-introduction-and-twelve-key-features-cdfe8a1f2d21