Helm e Kustomize

O manifest de um Deployment é igual em desenvolvimento, homologação e produção — exceto por réplicas, tag de imagem, domínio, limites e um punhado de variáveis. Copiar o arquivo por ambiente funciona por um mês; depois os três divergem em silêncio e ninguém sabe qual é o certo. Helm e Kustomize resolvem essa duplicação por caminhos diferentes.

Kustomize: base e overlay

Kustomize compõe YAML válido com YAML válido. A base é o manifest completo e aplicável; o overlay descreve só a diferença daquele ambiente. Não há linguagem de template: o que você lê no arquivo é o que existe.

# kustomization.yaml do overlay de produção
cat <<'YAML' > overlays/prod/kustomization.yaml
resources:
  - ../../base
namespace: loja-prod
images:
  - name: registry.exemplo.com/loja
    newTag: 1.8.3            # substitua pela tag imutável do seu build
replicas:
  - name: loja
    count: 4
patches:
  - path: recursos.yaml      # patch estratégico com requests/limits de prod
    target: { kind: Deployment, name: loja }
YAML

kubectl kustomize overlays/prod            # renderiza sem aplicar — leia isto
kubectl diff -k overlays/prod              # o que mudaria no cluster
kubectl apply -k overlays/prod

kubectl kustomize é o comando que você mais vai usar: revisar o YAML final antes de aplicar evita quase todo erro de overlay. O limite aparece quando a diferença entre ambientes é estrutural (um ambiente tem CronJob, outro não) — aí o overlay vira uma pilha de patches difícil de ler.

Helm: chart, values e release

Helm empacota manifests como templates Go parametrizados por values.yaml e instala o resultado como uma release nomeada, com histórico e rollback.

helm template loja ./chart -f values-prod.yaml   # renderiza local, sem tocar no cluster
helm lint ./chart
helm upgrade --install loja ./chart \
  -n loja-prod --create-namespace \
  -f values-prod.yaml --atomic --timeout 5m
helm history loja -n loja-prod
helm rollback loja 3 -n loja-prod

--atomic reverte a release se o upgrade não ficar pronto no timeout — sem ele, uma falha deixa metade dos recursos atualizados. Helm é a melhor opção para distribuir software para terceiros: o chart carrega valores padrão, documentação e versionamento.

A armadilha é o chart escrito para o próprio time: cada exceção vira mais um if no template até o YAML ficar ilegível e o erro só aparecer no helm template. Antes de adicionar um condicional, pergunte se aquilo não é um overlay.

Escolha, ou use os dois

Para manifests próprios, comece com Kustomize — menos indireção, diff honesto. Para software de terceiros (ingress controller, Prometheus, cert-manager), use o chart oficial. Combinar é comum: renderize o chart e trate o resultado como base.

helm template ingress-nginx ingress-nginx/ingress-nginx \
  --version 4.11.2 -f values.yaml > base/ingress.yaml

Sempre fixe a versão do chart (--version) e a tag da imagem. latest transforma qualquer apply em uma mudança não revisada.

Valide antes do cluster

Renderize e valide no pipeline, não no cluster: kubeconform checa contra o schema da API e kubectl apply --dry-run=server valida contra os admission controllers reais, incluindo políticas.

kubectl kustomize overlays/prod | kubeconform -strict -summary
kubectl apply -k overlays/prod --dry-run=server

Próximo passo: dimensione as réplicas que você acabou de parametrizar em Escala automática. Se o apply for feito por um controlador a partir do Git, veja GitOps.