Armadilhas do Helm – Insights de 3 anos com o principal gerenciador de pacotes do K8s

Artigo original ↗ Discussão no Hacker News ↗

Helm, o gerenciador de pacotes de fato do Kubernetes, recebe críticas por depender de templating baseado em strings sobre YAML, por APIs `values.yaml` espalhadas sem esquemas fortes e por comportamentos frágeis em upgrades, CRDs e hooks. Muitos engenheiros argumentam que o Helm funciona melhor para distribuir apps de terceiros, mas é inadequado para deployments internos do dia a dia, preferindo alternativas como Kustomize, operadores com CRDs ou abordagens com linguagens de programação completas (Pulumi, Jsonnet, CUE, Starlark, cdk8s). Um tema recorrente é que tratar configuração como código de verdade — com tipos, ferramentas e propriedade clara do estado — produz workflows Kubernetes mais mantíveis e depuráveis do que o modelo de templating do Helm.

Papel do Helm e Quando Ele Se Encaixa

  • Muitos veem a principal força do Helm como empacotar e distribuir publicamente apps Kubernetes complexos, especialmente quando os consumidores não querem entender todos os detalhes.
  • Outros argumentam que o Helm é um mau “gerenciador de pacotes” e mais um motor de templates mediano; eles o comparam desfavoravelmente aos gerenciadores de pacotes tradicionais de sistemas operacionais.
  • Para apps internos, vários preferem outros modelos: YAML estático simples, overlays do kustomize ou operadores/CRDs completos.

Pontos de Dor Comuns com o Helm

  • values.yaml é, na prática, uma API sem tipos e específica do chart. Árvores grandes de values, mal documentadas, são vistas como esmagadoras e propensas a erros.
  • A falta de validação forte de esquema para values é uma reclamação recorrente; alguns querem tipos inferidos da API subjacente do Kubernetes.
  • O templating de texto do Go sobre YAML sensível a espaços em branco gera charts frágeis, templates difíceis de ler e mensagens de erro e números de linha confusos.
  • Manter charts complexos e amplamente distribuídos tende a empurrar cada campo para values, levando a superfícies de configuração inchadas.
  • Problemas operacionais levantados: hooks considerados um antipadrão, upgrades inseguros ou surpreendentes, capacidades limitadas de diff/plan, problemas no tratamento de CRDs e versões de API, e impossibilidade de ver facilmente logs de hooks em CI.

Alternativas e Workarounds

  • Padrão comum: usar helm template para renderizar manifests e depois aplicá-los com outras ferramentas (Pulumi, Terraform, kapp, kustomize, Tanka/Jsonnet).
  • Kustomize é elogiado por um modelo base+patch e personalização de última milha (incluindo patching da saída do Helm), mas criticado por sintaxe estranha e vários arquivos por ambiente.
  • Muitos defendem “config as code” com linguagens reais: Pulumi (TS/Python/etc.), cdk8s, scripts simples em Python/TypeScript/Kotlin, modelos Pydantic, ou Terraform+geradores.
  • Linguagens dedicadas de configuração (Jsonnet, CUE, Dhall, Starlark) são vistas por alguns como um meio-termo melhor; outros ainda as acham complicadas demais ou difíceis de depurar.
  • Operadores + CRDs são vistos como mais idiomáticos para comportamento e upgrades complexos, mas mais difíceis de escrever e, às vezes, bloqueados por equipes de ops cautelosas.

Reflexões Mais Amplas Sobre Linguagens de Configuração

  • Forte reação contra templating de strings para dados estruturados e “YAML em todo lugar”.
  • Vários preveem uma mudança para ferramentas tipadas, conscientes de esquema e baseadas em linguagem e/ou módulos em sandbox com WASM, com ferramentas GitOps (ArgoCD, Flux, Carvel) orquestrando os manifests finais aplicados.