Qué construimos con él
Un servicio corriendo en Kubernetes no es una sola cosa: es un deployment, un service, un ingress, un autoescalador y un conjunto de secretos que tienen que estar todos de acuerdo entre sí. Helm convierte esa colección en un único chart con valores, así que un entorno es un archivo de values y no un directorio de manifiestos casi idénticos que se van separando.
El beneficio práctico es que una release pasa a ser un objeto único, revisable y versionado. Puedes ver qué cambió entre dos despliegues, promover el mismo chart de staging a producción con valores distintos y revertirlo todo como unidad cuando un despliegue sale mal, en vez de deshacer cinco recursos a mano con el sitio caído.
Dónde encaja
Este sitio se publica así. Su chart lleva el deployment, el ingress, el autoescalador horizontal de pods, los secretos de descarga de imágenes y los secretos de aplicación, y CI lo aplica después de construir y subir la imagen de contenedor.
Cuándo lo recomendamos
En cuanto tienes más de un entorno o más de un servicio. Ese es el punto en que los manifiestos mantenidos a mano empiezan a divergir y nadie sabe con seguridad qué clúster corresponde a qué archivo.
Para un único servicio en un único entorno, manifiestos planos en Git son más fáciles de leer y un lenguaje de plantillas menos que depurar. El templating de Helm es genuinamente incómodo —YAML sensible a los espacios generado por plantillas de Go—, así que debería estar ganándose algo. Cuando es un solo deployment, no lo hace.