Helm

Kustomize transforma tus manifiestos; Helm los empaqueta. Un chart contiene todo lo necesario para desplegar una aplicación (Deployments, Services, ConfigMaps, Ingress...) junto con sus valores configurables, versionado y distribuible. Cada instalación de un chart en el clúster es un release con nombre propio e historial de revisiones. Esto convierte a Helm en la herramienta estándar para instalar software de terceros (bases de datos, monitorización, controllers) y para distribuir tus propias aplicaciones entre equipos y entornos.

En esta lección recorrerás el ciclo de vida completo con un chart creado por ti: es la forma de ver la maquinaria entera sin depender de registros externos. Trabaja desde la pestaña dev-machine (Helm ya está instalado).

El mundo de los repositorios, primero en teoría

El uso más frecuente de Helm empieza en un repositorio de charts públicos:

¿Cómo añado un repositorio y lo mantengo actualizado?

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

¿Cómo busco un chart y estudio su configuración antes de instalarlo?

helm search repo postgresql
helm show values bitnami/postgresql

Ese show values es el primer paso obligado de cualquier instalación: entender qué puedes configurar y con qué valores viene de fábrica.

Note

💡 En este playground practicaremos con un chart local en vez de con Bitnami: sus charts descargan imágenes de Docker Hub, cuyos límites de descarga anónima llevamos esquivando todo el curso. La mecánica de releases que vas a aprender es idéntica.

Misión 1: tu primer chart

Helm sabe fabricar el esqueleto de un chart completo:

cd /home/laborant
helm create tienda

Explora el resultado en la pestaña IDE: Chart.yaml (los metadatos del paquete), values.yaml (la configuración expuesta al usuario) y templates/ (los manifiestos que ya conoces, salpicados de plantillas {{ .Values... }}). Esa es la diferencia filosófica con Kustomize: aquí los manifiestos sí son plantillas.

El chart generado usa la imagen nginx de Docker Hub y deja el tag vacío. Ajusta ambos en values.yaml:

image:
  repository: ghcr.io/iximiuz/labs/nginx
  pullPolicy: IfNotPresent
  tag: "alpine"

¿Por qué es importante fijar el tag y no dejarlo vacío?

Porque el chart generado tiene un valor por defecto traicionero: con el tag vacío usa el appVersion del Chart.yaml (1.16.0), y la imagen ghcr.io/iximiuz/labs/nginx:1.16.0 no existe. Es una primera lección de Helm en miniatura: los defaults de un chart siempre se leen antes de instalar.

Misión 2: instalar el release

Antes de tocar el clúster, la costumbre que ya tienes de kubectl aplica igual en Helm:

¿Cómo renderizo el YAML final que generaría un chart sin aplicarlo?

helm template web ./tienda

Es el equivalente a kubectl diff antes de aplicar: los manifiestos exactos que se crearían, con las plantillas ya resueltas.

Antes de instalar, una pieza más. El values.yaml que acabas de tocar es el del chart: los valores de fábrica, los que viajan dentro del paquete. Lo que un entorno concreto necesita cambiar no se edita ahí, se pasa aparte. Crea values-prod.yaml, fuera del chart:

cat << 'EOF' > /home/laborant/values-prod.yaml
service:
  type: NodePort
resources:
  requests:
    cpu: 50m
    memory: 64Mi
EOF

¿Cómo instalo un chart por primera vez, con mis valores?

helm install web ./tienda -n tienda --create-namespace -f values-prod.yaml

Y las preguntas de inventario que responden qué hay instalado y con qué configuración:

helm list -A

helm get values web -n tienda

Ahí están, y solo ellos: los dos bloques de tu values-prod.yaml. Eso es lo que get values responde, y conviene tenerlo claro porque casi todo el mundo se lleva la sorpresa al revés: no muestra la configuración efectiva del release, sino lo que el usuario suministró por encima del chart. Si instalas sin -f ni --set, la respuesta es un null desconcertante aunque el release lleve meses funcionando.

Para ver la configuración completa —los valores del chart con tus overrides ya fundidos encima— hay que pedirla:

helm get values web -n tienda --all

Esa pareja de comandos es la que resuelve de verdad la pregunta "¿con qué se instaló esto?" cuando heredas un clúster: el primero te dice qué decidió alguien, el segundo con qué acabó corriendo. Fíjate también en el objeto creado: el Deployment se llama web-tienda (release más chart), la convención de nombres de Helm.

Misión 3: el upgrade idempotente

Toca subir a 3 réplicas, y lo harás con la variante de comando que domina el mundo del CI/CD:

¿Cómo actualizo un release ya instalado, o lo instalo si todavía no existe?

helm upgrade --install web ./tienda -n tienda -f values-prod.yaml --set replicaCount=3

upgrade --install es idempotente por definición: no falla si el release ya existe ni si todavía no existe, que es exactamente lo que un pipeline necesita. El --set sobrescribe un valor puntual, y el -f vuelve a pasar el fichero de siempre.

¿Por qué repetir el -f si ya lo pasé al instalar? Porque un upgrade no hereda los valores de la revisión anterior: los que no vuelvas a suministrar desaparecen. Si aquí omites el -f, el Service vuelve a ser ClusterIP y las requests se esfuman, sin un solo aviso. Compruébalo después con helm get values web -n tienda. (Existe --reuse-values para heredarlos, pero en un pipeline la costumbre sana es la contraria: pasar siempre el fichero completo, que está en el repositorio, y que el estado del release no dependa de lo que alguien hizo la última vez.)

Misión 4: marcha atrás

La versión nueva ha resultado regular (día par, tocaba). Consulta el historial y revierte:

¿Cómo veo el historial de un release y lo revierto a una versión anterior?

helm history web -n tienda
helm rollback web 1 -n tienda

El número es la revisión de destino. Igual que el rollout undo de los Deployments, el rollback de Helm no borra historia: crea una revisión 3 cuyo contenido es el de la 1. Compruébalo repitiendo el history.

Resumen

Un chart empaqueta manifiestos como plantillas más valores; un release es un chart instalado con historial.
Antes de instalar: show values (charts ajenos) y helm template (siempre).
El values.yaml del chart son los valores de fábrica; lo que cambia cada entorno va en un fichero aparte que se pasa con -f, y hay que repetirlo en cada upgrade.
get values enseña lo que suministró el usuario; get values --all, la configuración efectiva.
upgrade --install es el comando de los pipelines: idempotente por diseño.
history y rollback dan a cualquier aplicación empaquetada el mismo botón de emergencia que aprendiste con los Deployments.
Helm y Kustomize no compiten tanto como parece: charts para empaquetar y distribuir, overlays para adaptar por entorno. Verás ambos convivir en el mundo real.

Course progress