Errores de Helm – Ideas tras 3 años con el principal gestor de paquetes de K8s

Artículo original ↗ Discusión en Hacker News ↗

Helm, el gestor de paquetes de facto de Kubernetes, recibe críticas por depender de templating basado en cadenas sobre YAML, por sus extensas “APIs” `values.yaml` sin esquemas fuertes y por comportamientos frágiles en upgrades, CRDs y hooks. Muchos ingenieros sostienen que Helm funciona mejor para distribuir aplicaciones de terceros, pero es poco adecuado para despliegues internos del día a día, y prefieren alternativas como Kustomize, operadores con CRDs o enfoques completos con lenguajes de programación (Pulumi, Jsonnet, CUE, Starlark, cdk8s). Un tema recurrente es que tratar la configuración como código real —con tipos, herramientas y propiedad clara del estado— produce flujos de trabajo de Kubernetes más mantenibles y fáciles de depurar que el modelo de templating de Helm.

Rol de Helm y cuándo encaja

  • Muchos ven la principal fortaleza de Helm como empaquetar y distribuir públicamente aplicaciones complejas de Kubernetes, especialmente cuando los consumidores no quieren entender todos los detalles.
  • Otros sostienen que Helm es un mal “gestor de paquetes” y más bien un motor de plantillas mediocre; lo comparan desfavorablemente con los gestores de paquetes tradicionales de sistemas operativos.
  • Para aplicaciones internas, varios prefieren otros modelos: YAML estático simple, overlays de kustomize o operadores/CRDs completos.

Puntos de dolor comunes con Helm

  • values.yaml es, en la práctica, una API no tipada y específica de cada chart. Los árboles de values grandes y mal documentados se perciben como abrumadores y propensos a errores.
  • La falta de validación estricta de esquema para los values es una queja recurrente; algunos quieren tipos inferidos a partir de la API subyacente de Kubernetes.
  • El templating de texto de Go sobre YAML sensible a los espacios produce charts frágiles, plantillas difíciles de leer y mensajes de error y números de línea confusos.
  • Mantener charts complejos y ampliamente distribuidos tiende a empujar cada campo a values, lo que conduce a superficies de configuración desmesuradas.
  • Problemas operativos señalados: los hooks se consideran un antipatrón, upgrades inseguros o sorprendentes, capacidades limitadas de diff/plan, problemas de manejo de CRD y versiones de API, e imposibilidad de ver fácilmente los logs de hooks en CI.

Alternativas y soluciones provisionales

  • Patrón común: usar helm template para renderizar manifiestos y luego aplicarlos con otras herramientas (Pulumi, Terraform, kapp, kustomize, Tanka/Jsonnet).
  • A Kustomize se le elogia por su modelo base+patch y su personalización de última milla (incluido parchear la salida de Helm), pero se le critica por una sintaxis incómoda y varios archivos por entorno.
  • Muchos abogan por “config as code” con lenguajes reales: Pulumi (TS/Python/etc.), cdk8s, scripts simples de Python/TypeScript/Kotlin, modelos Pydantic o Terraform+generadores.
  • Los lenguajes de configuración dedicados (Jsonnet, CUE, Dhall, Starlark) se ven por algunos como un mejor punto intermedio; otros los encuentran aún demasiado toscos o difíciles de depurar.
  • Los operadores + CRDs se consideran más idiomáticos para comportamientos y upgrades complejos, pero más difíciles de escribir y a veces bloqueados por equipos de ops cautelosos.

Reflexiones más amplias sobre lenguajes de configuración

  • Fuerte rechazo al templating de cadenas para datos estructurados y al “YAML por todas partes”.
  • Varios prevén un cambio hacia herramientas tipadas, conscientes de esquemas y basadas en lenguajes y/o módulos aislados en WASM, con herramientas GitOps (ArgoCD, Flux, Carvel) orquestando los manifiestos finalmente aplicados.