O que é Helm e Por Que Você Precisa Dele
Helm é um gerenciador de pacotes para Kubernetes, similar ao npm para Node.js ou pip para Python. Ele simplifica a distribuição, instalação e gerenciamento de aplicações containerizadas em clusters Kubernetes através de abstrações chamadas Charts. Um Chart é um pacote contendo templates YAML pré-configurados que descrevem todos os recursos Kubernetes necessários para rodar uma aplicação.
Sem o Helm, você teria que escrever centenas de linhas de YAML manualmente, lidar com variações entre ambientes (desenvolvimento, staging, produção) através de cópias-pasta de arquivos, e gerenciar dependências entre componentes de forma frágil. O Helm resolve esses problemas oferecendo templating, versionamento de releases e a capacidade de empacotar aplicações inteiras em um único comando. Pense nele como um gestor de dependências e deployment unificado.
Instalação e Conceitos Fundamentais
Instalando o Helm
A instalação é direta. No Linux ou macOS, execute:
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
Verifique a instalação:
helm version
O Helm 3 não requer nenhuma configuração especial no cluster (diferente do Helm 2, que precisava do Tiller). Ele comunica-se diretamente com o API Server do Kubernetes usando seu kubeconfig.
Os Três Conceitos Principais
Chart: Um pacote contendo templates, valores padrão e metadados. É como uma receita de bolo — descreve os ingredientes e proporções, mas não é o bolo pronto.
Release: Uma instância de um Chart executada no cluster. Você pode instalar o mesmo Chart várias vezes com diferentes valores, gerando releases diferentes. É o bolo assado.
Repository: Um servidor HTTP que hospeda Charts. Pense como PyPI para Python ou npm Registry. O Helm oficial mantém repositórios públicos que qualquer pessoa pode acessar.
# Adicionar repositório oficial do Helm
helm repo add stable https://charts.helm.sh/stable
# Listar repositórios cadastrados
helm repo list
# Atualizar informações dos repositórios
helm repo update
Criando Seu Primeiro Chart
Estrutura de um Chart
Vamos criar um Chart do zero para uma aplicação simples. Execute:
helm create minha-aplicacao
Isso gera a seguinte estrutura:
minha-aplicacao/
├── Chart.yaml
├── values.yaml
├── templates/
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── ingress.yaml
│ └── _helpers.tpl
└── charts/
O arquivo Chart.yaml contém metadados:
apiVersion: v2
name: minha-aplicacao
description: Uma aplicação web simples
type: application
version: 0.1.0
appVersion: "1.0"
maintainers:
- name: Seu Nome
email: seu.email@example.com
O arquivo values.yaml define os valores padrão que serão injetados nos templates:
replicaCount: 2
image:
repository: nginx
tag: "1.21.0"
pullPolicy: IfNotPresent
service:
type: ClusterIP
port: 80
ingress:
enabled: true
className: "nginx"
hosts:
- host: app.local
paths:
- path: /
pathType: Prefix
resources:
limits:
cpu: 500m
memory: 256Mi
requests:
cpu: 250m
memory: 128Mi
Usando Templates com Variáveis
Os templates usam a sintaxe de Go templating. Abra templates/deployment.yaml e veja como os valores são injetados:
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "minha-aplicacao.fullname" . }}
labels:
{{- include "minha-aplicacao.labels" . | nindent 4 }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
{{- include "minha-aplicacao.selectorLabels" . | nindent 6 }}
template:
metadata:
labels:
{{- include "minha-aplicacao.selectorLabels" . | nindent 8 }}
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
- name: http
containerPort: 80
protocol: TCP
resources:
{{- toYaml .Values.resources | nindent 12 }}
Note a sintaxe {{ .Values.replicaCount }} — isso é substituído pelo valor definido em values.yaml. O arquivo _helpers.tpl contém funções reutilizáveis (como minha-aplicacao.fullname) para evitar repetição.
Instalando, Atualizando e Removendo Releases
Instalando um Chart Localmente
Supondo que seu Chart esteja na pasta minha-aplicacao/, instale-o no cluster padrão (namespace default):
helm install minha-release ./minha-aplicacao
O Helm retorna informações sobre os recursos criados. Para visualizar a release:
helm list
Para detalhar a release:
helm status minha-release
Sobrescrevendo Valores na Instalação
Você pode sobrescrever valores sem editar values.yaml:
helm install minha-release ./minha-aplicacao \
--set replicaCount=3 \
--set image.tag="1.22.0" \
--namespace producao \
--create-namespace
Ou usando um arquivo YAML alternativo:
helm install minha-release ./minha-aplicacao \
-f valores-producao.yaml
Onde valores-producao.yaml contém:
replicaCount: 5
image:
tag: "1.22.0"
service:
type: LoadBalancer
Atualizando uma Release
Depois de fazer mudanças no Chart ou nos valores, atualize a release sem fazer downtime total:
helm upgrade minha-release ./minha-aplicacao --set replicaCount=4
Você pode visualizar o histórico de releases:
helm history minha-release
Se algo der errado, reverta para a versão anterior:
helm rollback minha-release 1
Removendo uma Release
helm uninstall minha-release
Isso remove todos os recursos Kubernetes associados à release.
Trabalhando com Repositórios e Charts Públicos
Instalando Charts de Repositórios
Após adicionar um repositório (como stable), você pode buscar e instalar Charts:
# Buscar um chart
helm search repo nginx
# Instalar a última versão
helm install meu-nginx stable/nginx-ingress
# Instalar uma versão específica
helm install meu-nginx stable/nginx-ingress --version 3.26.0
Criando Dependências Entre Charts
Se sua aplicação depende de um banco de dados, você pode declarar isso em Chart.yaml:
apiVersion: v2
name: aplicacao-completa
dependencies:
- name: postgresql
version: "11.x.x"
repository: "https://charts.bitnami.com/bitnami"
condition: postgresql.enabled
Depois, execute:
helm dependency update ./aplicacao-completa
Isso baixa o Chart do PostgreSQL. Configure-o em values.yaml:
postgresql:
enabled: true
auth:
username: appuser
password: senhaSegura123
database: appdb
Agora, quando você instalar aplicacao-completa, o PostgreSQL será provisionado automaticamente junto.
Publicando Seu Chart em um Repositório
Se você quer compartilhar seu Chart, empacote-o:
helm package ./minha-aplicacao
Isso cria um arquivo minha-aplicacao-0.1.0.tgz. Para hostar em um repositório HTTP, você pode usar o GitHub Pages ou qualquer servidor estático. Basta criar um arquivo index.yaml:
helm repo index . --url https://seu-usuario.github.io/helm-charts/
Depois, outras pessoas podem usar seu Chart:
helm repo add meus-charts https://seu-usuario.github.io/helm-charts/
helm install minha-app meus-charts/minha-aplicacao
Helm Hooks e Ciclo de Vida
Helm suporta hooks que executam ações em momentos específicos do deployment. Um caso de uso comum é executar migrations de banco de dados antes de um upgrade.
Crie templates/pre-upgrade-job.yaml:
{{- if eq .Values.environment "production" }}
apiVersion: batch/v1
kind: Job
metadata:
name: {{ include "minha-aplicacao.fullname" . }}-pre-upgrade
annotations:
"helm.sh/hook": pre-upgrade
"helm.sh/hook-weight": "-5"
"helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded
spec:
template:
spec:
serviceAccountName: {{ include "minha-aplicacao.serviceAccountName" . }}
restartPolicy: Never
containers:
- name: migrate
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
command: ["./migrate.sh"]
{{- end }}
As anotações definem quando o Job executa:
- helm.sh/hook: pre-upgrade — roda antes do upgrade
- helm.sh/hook-weight: "-5" — define ordem de execução (menor = primeiro)
- helm.sh/hook-delete-policy — remove o Job após sucesso
Outros hooks disponíveis: pre-install, post-install, pre-delete, post-delete, pre-rollback, post-rollback.
Testes e Validação de Charts
Validando a Sintaxe
Antes de instalar, valide seu Chart:
helm lint ./minha-aplicacao
Isso verifica indentação YAML, nomes obrigatórios e outras validações básicas.
Visualizando o YAML Gerado
Para ver exatamente o que será criado no cluster, sem instalar:
helm template minha-release ./minha-aplicacao --values valores-producao.yaml
Isso mostra todos os manifestos YAML processados. É útil para debug e review antes de deploy.
Dry-Run: Simulando a Instalação
Para testar sem criar recursos:
helm install minha-release ./minha-aplicacao --dry-run --debug
O --debug mostra detalhes adicionais da renderização.
Testes Automatizados
Helm permite definir testes dentro do Chart. Crie templates/tests/test-connection.yaml:
apiVersion: v1
kind: Pod
metadata:
name: "{{ include "minha-aplicacao.fullname" . }}-test-connection"
labels:
{{- include "minha-aplicacao.labels" . | nindent 4 }}
annotations:
"helm.sh/hook": test
spec:
containers:
- name: wget
image: busybox
command: ['wget']
args: ['{{ include "minha-aplicacao.fullname" . }}:{{ .Values.service.port }}']
restartPolicy: Never
Execute os testes:
helm test minha-release
O Helm criará um Pod que valida a conectividade com sua aplicação.
Conclusão
Você agora domina os conceitos fundamentais do Helm e pode utilizá-lo para gerenciar deployments Kubernetes de forma profissional. Os três aprendizados principais são: (1) Helm simplifica drasticamente o gerenciamento de aplicações Kubernetes através de templating e versionamento, eliminando a necessidade de copiar YAML repetitivamente entre ambientes; (2) Charts são compostos por templates, valores e metadados que trabalham juntos, permitindo reutilização e configuração flexível sem modificar código-base; (3) O ciclo de vida completo — instalação, upgrade, rollback, testes e hooks — oferece segurança e controle fino sobre deployments em produção.