Chart.yaml
values.yaml
Un chart agrupa plantillas YAML parametrizadas con el lenguaje de plantillas de Go ({{ .Values.replicaCount }}). Incluye dependencias opcionales (charts/) y pruebas en templates/tests.
Versionado: version del chart vs appVersion de la app — no son lo mismo.
revision
history
Cada helm upgrade crea una nueva revisión. Helm guarda el manifiesto renderizado en el Secret sh.helm.release.v1.* (no en etcd “mágico” aparte: es el mecanismo de almacenamiento por defecto).
Rollback: vuelve a una revisión anterior sin reescribir el chart — útil tras un deploy roto.
template
lint
helm template imprime YAML final sin tocar el cluster — ideal para CI y revisiones. helm lint detecta problemas comunes del chart. Combina con --dry-run en install/upgrade para validar contra el API server.
helm diff (plugin) muestra cambios entre revisiones antes de aplicar.
Estructura típica de un chart
mi-app/
Chart.yaml # metadatos, nombre, version, dependencias
values.yaml # valores por defecto (sobrescribibles con -f o --set)
values-prod.yaml
templates/
deployment.yaml
service.yaml
ingress.yaml
_helpers.tpl # funciones reutilizables {{ include "mi-app.fullname" . }}
NOTES.txt
helm upgrade --install mi-release ./charts/mi-app -n prod --create-namespace \
-f values-prod.yaml --set image.tag=v2.3.1 --wait --timeout 5m
helm template mi-release ./charts/mi-app -f values-prod.yaml | less
helm install mi-dryrun ./charts/mi-app --dry-run --debug -f values.yaml
helm history mi-release -n prod
helm rollback mi-release 4 -n prod
helm dependency update ./charts/mi-app
bases
patches
images
El archivo kustomization.yaml declara qué manifiestos fusionar, qué imágenes reescribir, qué parches JSON o estratégicos aplicar y cómo generar ConfigMaps desde archivos. No usa plantillas con lógica: solo composición y parches sobre YAML existente.
Uso: kubectl apply -k overlays/prod/ o integrado en helmfile / pipelines.
namePrefix
commonLabels
Patrón clásico: carpeta base/ con manifiestos “neutros” y overlays/staging que referencia la base y añade réplicas, recursos o ConfigMaps distintos.
Helm + Kustomize: puedes renderizar un chart con helm template y luego post-procesar con Kustomize (patrón usado en algunos equipos).
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: prod
resources:
- ../../base
patchesStrategicMerge:
- replicas-patch.yaml
images:
- name: mi-app
newTag: v2.3.1
configMapGenerator:
- name: app-config
files:
- application.properties
Parametrización
Plantillas con lógica, bucles, helpers — mucha flexibilidad
Sin lógica en plantilla: parches y generadores sobre YAML fijo
Curva y revisión
Equipo debe entender Go templates y patrones del chart
Diffs más lineales; menos “magia” en el YAML final
Lifecyle / releases
Primera clase: historial, rollback, hooks pre/post deploy
Gestión de revisiones la haces tú (Git, Argo CD, kubectl)
Ecosistema
Artifact Hub, charts oficiales, operators empaquetados
Nativo en kubectl; encaja con GitOps “manifestos por carpeta”
🔐
Secretos en charts
No commitees valores sensibles en values.yaml. Usa Sealed Secrets, SOPS, Vault o CI que inyecte --set-file en runtime.
📌
Hooks de Helm
Jobs anotados con helm.sh/hook (pre-install, post-upgrade…) para migraciones o tests. Ojo: pueden bloquear el release si fallan o si los TTL no están bien definidos.
🤝
Convive con GitOps
Argo CD y Flux entienden Helm charts y/o carpetas Kustomize. El manifiesto “fuente de verdad” suele vivir en Git; Helm/Kustomize son la capa de renderizado hacia el cluster.