O Helm é frequentemente descrito como o "gerenciador de pacotes do Kubernetes", comparável a ferramentas como apt, yum ou Homebrew, mas para aplicações que rodam em clusters Kubernetes. Ele permite empacotar, versionar, publicar, instalar, atualizar e reverter aplicações Kubernetes de forma consistente e repetível. Sem o Helm, a implantação de uma aplicação envolve gerenciar dezenas de arquivos YAML soltos, o que é propenso a erros e difícil de versionar. Com o Helm, você define uma estrutura de diretórios contendo todos os manifestos necessários, parametriza configurações e implanta tudo com um único comando.

Nesta aula, vamos mergulhar nos conceitos fundamentais do Helm: o que ele é, como funcionam os Charts (pacotes), como o sistema de templates permite flexibilidade e quais são os casos de uso mais comuns. Você aprenderá a criar seus próprios Charts, a usar templates para customizar instalações e a aplicar boas práticas de empacotamento e versionamento.

O que é Helm

O Helm é um projeto open-source que facilita o gerenciamento de aplicações Kubernetes. Ele foi criado pela Deis e depois doado à CNCF (Cloud Native Computing Foundation), onde hoje é um projeto graduado. O Helm utiliza um formato de empacotamento chamado Chart, que é uma coleção de arquivos que descrevem um conjunto relacionado de recursos Kubernetes. Um único Chart pode ser usado para implantar algo simples, como um pod, ou algo complexo, como uma stack completa de aplicação com banco de dados, cache, serviços web e workers.

A arquitetura do Helm consiste em dois componentes principais: o cliente (helm CLI) e o servidor (Tiller, nas versões antigas, ou diretamente o Kubernetes API, na versão 3). No Helm 3, o Tiller foi removido, e o cliente interage diretamente com a API do Kubernetes, o que melhora a segurança e simplifica a arquitetura. O Helm 3 também introduziu o conceito de Release, que é uma instância de um Chart instalado em um cluster. Cada release tem um nome único e pode ser atualizado ou rollback de forma independente.

Além de instalar e gerenciar aplicações, o Helm também oferece repositórios de Charts, como o Artifact Hub, onde você pode publicar ou buscar Charts prontos para uso. Isso promove o compartilhamento e a reutilização de configurações entre equipes e comunidades.

Charts

Um Chart é a unidade de empacotamento do Helm. Ele é um diretório estruturado que contém todos os recursos Kubernetes necessários para executar uma aplicação. A estrutura básica de um Chart inclui:

mychart/
├── Chart.yaml
├── values.yaml
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── _helpers.tpl
└── charts/

O arquivo Chart.yaml contém metadados como nome, versão, descrição e dependências. O values.yaml contém valores padrão que podem ser sobrescritos pelo usuário no momento da instalação. O diretório templates/ contém os manifestos Kubernetes no formato de templates Go, que podem ser parametrizados. O diretório charts/ é usado para incluir Charts dependentes (sub-charts).

Os Charts são versionados e podem ser empacotados em arquivos .tgz para distribuição. O comando helm package cria esses arquivos. A versão do Chart segue o SemVer (Semantic Versioning), e é comum também ter uma versão da aplicação separada (appVersion).

Exemplo de um Chart.yaml simples:

apiVersion: v2
name: myapp
description: A simple Helm chart for Kubernetes
version: 0.1.0
appVersion: "1.16.0"

Para instalar um Chart, você pode usar um Chart local ou um repositório remoto. O comando helm install [nome-release] [chart] cria uma release. Por exemplo:

helm install my-release ./mychart

Isso instalará a aplicação no cluster atual usando os valores padrão. Você pode sobrescrever valores com --set ou com um arquivo de valores personalizado:

helm install my-release ./mychart --set service.port=8080

Templates

Os templates são uma das características mais poderosas do Helm. Eles permitem que os manifestos sejam parametrizados, gerando diferentes configurações para diferentes ambientes (dev, staging, prod) sem duplicar código. Os templates são escritos em Go templates, com funções adicionais fornecidas pelo Helm (como quote, default, upper, etc.).

Um exemplo simples de template em templates/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Values.name }}
  template:
    metadata:
      labels:
        app: {{ .Values.name }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        ports:
        - containerPort: {{ .Values.service.port }}

No exemplo acima, .Values.name, .Values.replicaCount, etc., são valores que vêm do arquivo values.yaml. O objeto .Chart contém metadados do Chart, e .Release contém informações da release (como nome).

Os templates também suportam condicionais, loops e variáveis. Por exemplo, você pode incluir um bloco somente se uma condição for verdadeira:

{{- if .Values.service.enabled }}
apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.name }}
{{- end }}

Para testar seus templates, você pode usar helm template para renderizar os manifestos sem instalar:

helm template my-release ./mychart

Isso é útil para depurar e revisar o que será aplicado.

Casos de uso

O Helm é amplamente utilizado em diversos cenários de DevOps. Alguns dos principais casos de uso incluem:

  • Implantação de aplicações complexas: stacks como WordPress, GitLab, ou Jenkins podem ser instaladas com um único comando, graças a Charts prontos.
  • Gerenciamento de múltiplos ambientes: usando diferentes values files para dev, staging e prod, você pode manter a mesma base de código com configurações distintas.
  • Reversão de atualizações: o Helm mantém o histórico de releases, permitindo rollback para uma versão anterior facilmente.
  • Distribuição de aplicações internas: equipes podem empacotar suas aplicações como Charts e publicá-las em um repositório privado para reuso.
  • Integração com CI/CD: pipelines podem usar Helm para implantar versões específicas em clusters, garantindo consistência e auditabilidade.

Por exemplo, em um pipeline de CI/CD, você pode usar o comando helm upgrade --install para implantar a aplicação:

helm upgrade --install myapp ./mychart --namespace production --values values-prod.yaml

Isso cria a release se não existir, ou atualiza a existente, facilitando a entrega contínua.

Boas práticas

Ao trabalhar com Helm, é importante seguir algumas boas práticas:

  • Mantenha os Charts pequenos e focados em uma única aplicação ou serviço.
  • Use values.yaml para parametrizar tudo que pode variar entre ambientes.
  • Documente os valores no próprio values.yaml com comentários.
  • Versionar os Charts e usar repositórios para distribuição.
  • Teste os templates com helm template e considere usar ferramentas como helm lint para validação.
  • Use namespaces para separar ambientes e releases.

Seguindo essas práticas, você garantirá que suas implantações sejam confiáveis e fáceis de manter.

Referências

Exercícios

  1. Explique a diferença entre Chart, Release e Repositório no contexto do Helm.

    2. ✓ Resposta: Um Chart é um pacote de arquivos que descrevem recursos Kubernetes, incluindo metadados e templates. Uma Release é uma instância específica de um Chart instalado em um cluster, com um nome único. Um Repositório é um local onde Charts são versionados e armazenados, podendo ser público ou privado, permitindo compartilhamento e instalação fácil.
  2. Qual é a finalidade do arquivo values.yaml em um Chart? Dê um exemplo de uso.

    3. ✓ Resposta: O arquivo values.yaml define os valores padrão que podem ser usados nos templates. Ele permite parametrizar a configuração da aplicação, como imagem, réplicas, portas etc. Por exemplo, podemos definir replicaCount: 3 e image.repository: nginx, e nos templates usar {{ .Values.replicaCount }} e {{ .Values.image.repository }}. Assim, podemos alterar esses valores ao instalar o Chart com --set ou um arquivo de valores específico.
  3. Como você faria para instalar um Chart local chamado "meu-chart" com nome de release "app1" e sobrescrever a réplica para 5?

    4. ✓ Resposta: O comando seria: 
    helm install app1 ./meu-chart --set replicaCount=5
  4. Escreva um template simples para um ConfigMap que use o nome da release e um valor de configuração chamado "mensagem".

    5. ✓ Resposta: Um exemplo de template em templates/configmap.yaml seria: 
    apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-config
data:
  mensagem: {{ .Values.mensagem | quote }}
  5. Qual comando você usaria para reverter a release "app1" para a versão anterior? Explique o que o comando faz.

    6. ✓ Resposta: O comando é helm rollback app1. Ele reverte a release para o estado da versão anterior (revisão anterior), usando o histórico de releases que o Helm mantém. Isso é útil para desfazer uma atualização problemática.