Helm Kubernetes: cómo armar tu primer chart en 2026

En pocas palabras: Helm empaqueta las apps de Kubernetes en un Chart reutilizable y, con un solo comando como helm install, crea un Release que genera Deployment, Service, ConfigMap, Secret, Ingress y HPA, permitiendo instalar, actualizar y revertir toda la aplicación sin editar YAML a mano.

Helm es el gestor de paquetes que usás para instalar, actualizar y revertir aplicaciones completas en Kubernetes con un solo comando, en vez de aplicar a mano una docena de YAML. Lo repasa en detalle la guía práctica publicada el 5 de noviembre de 2026 en dev.to, que arma un chart real con Ingress, autoscaling y persistencia desde cero. Pero antes de copiar esa estructura paso a paso conviene preguntarse algo más básico: ¿tu proyecto necesita Helm, o te alcanza con menos?

Helm es el gestor de paquetes oficial de Kubernetes: empaqueta los manifests de una aplicación (Deployments, Services, ConfigMaps, Secrets) en una unidad reutilizable llamada Chart. Cuando instalás ese Chart, Helm crea un Release, una instancia corriendo en tu clúster con su propia configuración. Podés tener varios Releases del mismo Chart, uno para desarrollo y otro para producción, con distinta configuración, según explica la guía de dev.to.

¿Qué problema resuelve Helm cuando se manejan muchos YAML de Kubernetes?

Helm resuelve el problema de mantener YAML casi idénticos por cada entorno: centraliza la configuración que cambia (tag de imagen, réplicas, contraseña de base) en un solo lugar, para que no tengas que editar a mano media docena de archivos cada vez que algo cambia. Según la guía de dev.to, sin Helm terminás con Deployments, Services y ConfigMaps duplicados que divergen con el tiempo.

Ponele que arrancaste con Kubernetes escribiendo tus propios manifests, cosa recomendable para aprender. El problema aparece cuando la app crece (y siempre crece): tenés una copia de cada YAML para development, otra para staging y otra para producción, y todas se parecen pero no son iguales. Subís el tag de la imagen en producción, te olvidás de actualizar el ConfigMap correspondiente, el Ingress sigue apuntando a un host viejo y nadie documentó qué versión quedó corriendo en cada lado. ¿Alguien se dio cuenta antes de que explotara en producción? Casi nunca.

Ahí es donde entra Helm.

Helm empaqueta todo eso (Deployments, Services, ConfigMaps, Secrets) en un Chart versionado. Instalás, actualizás y revertís esa aplicación completa con comandos de una línea, sin tocar YAML suelto ni rezar para que todos los archivos queden sincronizados. Para más detalles técnicos, mirá evitar errores comunes de sintaxis YAML.

Ejemplo hipotético: imaginá un equipo de dos personas que corre una sola app en un solo entorno de producción. Ahí Helm probablemente es gastar pólvora en chimangos: el costo de aprender charts, templates y values no compensa contra tres kubectl apply bien documentados. Ahora imaginá al mismo equipo con esa app corriendo en dev, staging y producción, con réplicas distintas, dominios de Ingress distintos y límites de recursos distintos en cada lado. Ahí el cálculo cambia: un chart con tres archivos (values-dev.yaml, values-staging.yaml, values-prod.yaml) reemplaza nueve YAML sueltos que antes había que mantener sincronizados a mano, con el riesgo de que alguno quede desactualizado sin que nadie lo note.

¿Qué es un Helm Chart y qué es un Release?

Un Helm Chart es una carpeta con todos los templates de Kubernetes de una app más sus valores por defecto. Un Release es la instancia de ese Chart corriendo en tu clúster, con nombre y configuración propios. Podés instalar el mismo Chart dos veces con nombres distintos y tener dos Releases totalmente independientes.

Concepto	Qué significa	Analogía real
Chart	Carpeta con templates YAML y valores por defecto	Un paquete .deb o .rpm
Release	Instancia corriendo de un Chart en el clúster	Una app ya instalada
Values	Configuración que llena los templates	Preferencias o settings
Template	YAML con placeholders tipo {`{ .Values.x }`}	Un formulario con campos en blanco
Repository	Lugar donde se guardan y comparten Charts	App Store o Docker Hub

Pensalo como el apt o el brew de Kubernetes (si es que la comparación te cierra): instalás, actualizás, desinstalás, y Helm se encarga de aplicar los manifests correctos en el orden correcto. El chart de ejemplo de la guía incluso trae soporte para Gateway API vía httpRoute, aunque viene deshabilitado por defecto, la “innovación” de turno que todavía no todos los clústers tienen listo para usar.

¿Cuándo conviene armar un chart y cuándo no vale la pena?

Helm resuelve un problema real, pero trae su propia complejidad: templates con sintaxis Go, un orden de precedencia entre values.yaml y –set que hay que aprender, y un chart que alguien tiene que mantener. Antes de copiar la estructura completa de un chart de referencia, conviene chequear si tu caso justifica ese costo.

• Más de un entorno con configuración distinta: si dev, staging y producción difieren en réplicas, dominios o límites de recursos, un chart con varios archivos de values evita mantener YAML duplicados a mano.
• Necesitás rollback rápido y auditable: si un cambio malo en producción te tiene que durar cinco minutos y no toda la tarde, el historial de revisiones de Helm vale la inversión.
• Varios equipos o proyectos reutilizan la misma app: un chart compartido evita que cada equipo mantenga su propia copia de los manifests, con el riesgo de que diverjan.
• Un solo entorno, app simple, equipo chico, cambios poco frecuentes: ahí kubectl apply con unos pocos YAML bien versionados en git puede seguir siendo más simple que aprender templates de Helm.

¿Cómo instalar Helm y preparar el entorno con Minikube?

Para instalar Helm corré el script oficial curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash y confirmá la versión con helm version. Si vas a probar en local, Minikube necesita los addons de ingress y metrics-server habilitados antes de crear cualquier chart con HPA o Ingress. Tema relacionado: generar políticas de red automáticamente.

• Minikube arrancado: minikube start levanta el clúster local donde vas a instalar el chart.
• Addons habilitados: minikube addons enable ingress y minikube addons enable metrics-server, necesarios porque el chart de ejemplo usa Ingress y HPA.
• Verificación de pods: kubectl get pods -n ingress-nginx y kubectl get pods -n kube-system | grep metrics-server confirman que los addons quedaron corriendo antes de seguir.
• Helm instalado: el script get-helm-3 instala la versión 3 del CLI; helm version te confirma que quedó bien.

Si esto después lo llevás a un clúster real en producción, va a correr en algún lado: on-premise, en un cloud grande o en un VPS. Para eso, en donweb.com hay opciones de cloud y VPS pensadas para cargas de este tipo.

¿Cómo crear un Helm Chart desde cero con helm create?

helm create demo-app genera automático la estructura completa de un chart (Chart.yaml, values.yaml, carpeta templates/ y charts/) con los manifests más comunes ya armados, para que no tengas que escribir cada template desde cero.

• Chart.yaml: metadata del chart (nombre, versión, descripción).
• values.yaml: configuración por defecto que vas a editar vos.
• templates/: trae deployment.yaml, service.yaml, serviceaccount.yaml, ingress.yaml, hpa.yaml, httproute.yaml, NOTES.txt, _helpers.tpl y una carpeta tests/ con test-connection.yaml.
• charts/: carpeta para dependencias de otros charts, vacía al arrancar.

A partir de ahí el trabajo real es otro: ajustar esos templates a lo que tu app necesita de verdad, no dejarlos con los valores de ejemplo que trae helm create.

¿Qué configura el archivo values.yaml de un chart de Helm?

El values.yaml es el punto central de configuración de un chart: ahí definís réplicas, imagen, ingress, autoscaling y secrets sin tocar un solo template, según indica la guía de buenas prácticas de Helm.

• replicaCount: 2 define cuántos pods arrancan si el autoscaling está apagado.
• image.repository y image.tag apuntan a la imagen (en el ejemplo, nginx:1.25); image.pullPolicy controla cuándo se vuelve a bajar.
• serviceAccount.create decide si Helm crea una identidad propia para los pods o usa una existente.
• service.type y service.port definen cómo se expone el Service: ClusterIP en el puerto 80 por defecto.
• ingress.enabled, con className nginx y el host demo.local, prende o apaga la exposición externa.
• autoscaling con minReplicas: 2, maxReplicas: 10 y targetCPUUtilizationPercentage: 50 configura el HPA.
• resources.requests y resources.limits (100m/128Mi de request, 200m/256Mi de límite) son obligatorios para que el HPA pueda calcular el porcentaje de uso de CPU.
• persistence.size: 1Gi y accessMode: ReadWriteOnce reservan el almacenamiento para el PVC.
• secret.dbPassword guarda la contraseña en texto plano en values.yaml, que Helm después codifica en base64 al armar el Secret.

Ojo con un detalle que la documentación de Helm remarca: hay que quotear todos los strings. Un version: 1.0 sin comillas, YAML lo puede interpretar como número y no como texto, y ahí empiezan los dolores de cabeza raros. Lo mismo pasa con un git commit SHA que arranca con números: YAML lo puede leer como notación científica. Te puede servir nuestra cobertura de probar la demo Online Boutique de Google.

¿Qué hace cada template dentro de un Helm Chart?

Cada archivo en templates/ genera un recurso de Kubernetes distinto: serviceaccount.yaml crea la identidad del pod, configmap.yaml guarda configuración no sensible, secret.yaml codifica datos sensibles en base64, pvc.yaml reserva almacenamiento, deployment.yaml levanta los pods, y service.yaml e ingress.yaml los exponen.

• serviceaccount.yaml: crea el ServiceAccount que usan los pods, útil si después necesitás darle permisos RBAC específicos.
• configmap.yaml: en el ejemplo, guarda una página HTML que nginx sirve, armada con los valores de app.name, app.version y app.environment.
• secret.yaml: toma el valor plano de secret.dbPassword y lo codifica con la función b64enc de Helm antes de guardarlo como Secret.
• pvc.yaml: pide un PersistentVolumeClaim según persistence.size y accessMode; si no hay un StorageClass o volumen compatible, queda en Pending.
• deployment.yaml: es el archivo más importante. Define réplicas (o deja que el HPA las controle), monta el ConfigMap y el Secret, y fija requests y limits de CPU y memoria.
• service.yaml: crea un Service ClusterIP que recibe el tráfico y lo redirige a los pods.
• ingress.yaml: solo se crea si ingress.enabled es true, y usa el controlador nginx para rutear demo.local hacia el Service.

¿Cómo instalar, actualizar y hacer rollback de un Release con Helm?

helm install arma el primer Release de un chart, helm upgrade aplica cambios de configuración sin recrear todo desde cero, y helm rollback vuelve a una revisión anterior si algo salió mal, porque cada cambio genera una revisión nueva sin que vos tengas que hacer nada extra.

Eso significa que si hacés un upgrade y el Deployment nuevo no levanta bien, no tenés que reconstruir YAML a mano ni acordarte qué tenía la versión anterior: helm rollback demo-app 1 te devuelve al estado exacto de la revisión 1. Para un equipo que gestiona varios entornos, esa trazabilidad es la diferencia entre un incidente de cinco minutos y uno que te arruina la tarde. Ya lo cubrimos antes en elegir el patrón de arquitectura adecuado.

Errores comunes al armar un chart de Helm

• No quotear los strings en values.yaml: un appVersion: 1.0 sin comillas puede terminar interpretado como número, y Helm lo castea mal. Corrección: quotear todo lo que sea texto, como recomienda la guía oficial de valores.
• Usar listas en vez de mapas: definir servers como lista hace que –set servers.port=80 dependa del orden y se rompa si alguien reordena. Corrección: usar mapas (servers.foo.port) como sugiere Helm.
• Habilitar HPA sin definir resources.requests.cpu: el autoscaler necesita ese valor para calcular el porcentaje de uso; sin request, no tiene con qué medir. Corrección: fijar siempre requests antes de activar autoscaling.enabled: true.
• Confundir version con appVersion en Chart.yaml: version versiona el chart, appVersion versiona la aplicación que contiene, y son campos independientes. Corrección: revisar ambos por separado en cada release, no asumir que uno arrastra al otro.

Preguntas Frecuentes

¿Qué es Helm en Kubernetes?

Helm es el gestor de paquetes oficial de Kubernetes que empaqueta los manifests de una aplicación en una unidad reutilizable llamada Chart, instalable con un solo comando. Funciona como apt o brew, pero para recursos de Kubernetes.

¿Cómo se crea un Helm Chart?

Con el comando helm create nombre-del-chart, que genera automático Chart.yaml, values.yaml y la carpeta templates/ con los manifests más comunes (Deployment, Service, Ingress, HPA) ya armados.

¿Para qué sirve el archivo values.yaml en Helm?

values.yaml centraliza toda la configuración que llena los templates del chart (réplicas, imagen, ingress, autoscaling, secrets), para que cambiar un valor no implique editar manifests sueltos.

¿Cómo instalar Helm en Kubernetes?

Corriendo el script oficial curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash y confirmando con helm version. Después de eso, helm install arma el primer Release de cualquier chart sobre tu clúster.

¿Cómo hacer upgrade y rollback de un release con Helm?

helm upgrade nombre-release chart aplica cambios de configuración sobre un release existente sin recrearlo desde cero, y helm rollback nombre-release número-de-revisión lo devuelve a un estado anterior porque cada cambio queda guardado como revisión aparte.

¿Cuándo conviene no usar Helm?

Cuando hay un solo entorno, la app es simple y los cambios son poco frecuentes. Ahí mantener unos pocos YAML versionados en git con kubectl apply puede ser más simple que sumar la curva de aprendizaje de charts y templates.

Conclusión

Helm no elimina la complejidad de Kubernetes, la organiza, y solo tiene sentido cuando esa organización pesa más que la curva de aprendizaje. Si manejás varios entornos con configuración distinta, si necesitás rollbacks rápidos o si varios equipos comparten la misma app, armar un chart como el demo-app de esta guía es el paso lógico siguiente: te va a ahorrar errores de sincronización (que no es poco) y te va a dar un historial de revisiones que hoy probablemente no tenés. Si en cambio tenés un solo entorno y pocos cambios, quizás el paso lógico siguiente sea simplemente seguir con kubectl apply un rato más.

Lo que Helm no resuelve, en ningún escenario, es la disciplina del equipo. Un values.yaml mal documentado, sin quotear strings o con listas donde deberían ir mapas, sigue rompiendo cosas, chart o no.

Fuentes

• Documentación oficial de Helm – Charts
• Documentación oficial de Helm – Buenas prácticas de values
• Helm Hands-On: A Practical Guide to Packaging Kubernetes Apps – dev.to