Si trabajas con Kubernetes, tarde o temprano acabas con decenas de manifiestos YAML casi idénticos. Helm resuelve ese problema tratando tus despliegues como paquetes: los defines una vez y los reutilizas con distintos valores. Te cuento cómo lo uso.
Los tres conceptos clave
- Chart: el paquete. Una carpeta con plantillas YAML y metadatos que describe todo lo necesario para desplegar una aplicación.
- Values: la configuración. Un fichero
values.yamlcon los parámetros que varían entre entornos (réplicas, imagen, recursos…). - Release: la instalación. Cada despliegue de un chart en un clúster, con su historial de versiones y rollback incluido.
Lo esencial en cuatro comandos
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install mi-app bitnami/nginx -f values-prod.yaml
helm upgrade mi-app bitnami/nginx -f values-prod.yaml
helm rollback mi-app 1Buenas prácticas que aplico
- Un values por entorno (dev, staging, prod) y nada de editar plantillas a mano.
- Versiona los charts en Git y publícalos en un registro para que CI/CD consuma versiones concretas.
- Combínalo con GitOps: ArgoCD o Flux desplegando charts desde Git es de lo más sólido que existe hoy.
- helm template + helm diff en el pipeline para revisar qué va a cambiar antes de aplicar.
- No metas lógica compleja en las plantillas: si necesitas muchos condicionales, probablemente necesitas dos charts.
Conclusión
Helm no es perfecto —las plantillas pueden volverse crípticas— pero sigue siendo la forma más práctica de empaquetar aplicaciones para Kubernetes y la puerta de entrada a un flujo GitOps serio.
¿Helm, Kustomize o manifiestos a pelo? Cuéntame tu preferencia en los comentarios. 😊