Helm — Cheat Sheet

Tag: kubernetes, helm, devops, k8s, packaging, deployment

Livello: intermedio

TL;DR: Package manager per Kubernetes per definire, installare e aggiornare applicazioni complesse tramite Chart e templating dichiarativo.

Concetti chiave

Package manager de facto per Kubernetes, organizza manifest YAML in pacchetti chiamati Chart.

Un Chart contiene la definizione dei template, i valori di default (values.yaml) e i metadati.

Release: istanza specifica di un Chart installata e in esecuzione in un cluster Kubernetes.

Helm 3 ha rimosso Tiller, interagendo direttamente con le Kubernetes API usando il kubeconfig locale.

Memorizza lo storico dei deploy e lo stato delle release come Secret nel namespace di installazione.

Il templating sfrutta il motore Go template con funzioni estese dalla libreria Sprig.

Permette upgrade atomici, rollback immediati a revisioni precedenti e gestione dipendenze con Chart.lock.

Supporta repository remoti HTTP/S e registri compatibili OCI (Open Container Initiative).

Domande tipiche e risposte pronte

Q: Qual è la differenza architetturale principale tra Helm 2 e Helm 3?R: In Helm 3 è stato rimosso Tiller; l'autenticazione e le autorizzazioni RBAC sono delegate direttamente all'utente Kubernetes via API, migliorando la sicurezza.

Q: Come gestisci configurazioni diverse per ambienti come dev, staging e prod?R: Mantengo un values.yaml di base nel Chart e applico file dedicati per ambiente con il flag -f durante la pipeline di deploy.

Q: Come previeni deploy incompleti o rotti durante un rilascio?R: Uso i flag --wait e --atomic con timeout definito, assicurando il rollback automatico se i pod non superano i readiness check.

Insidie e errori comuni

Eseguire helm install invece di helm upgrade --install nelle pipeline CI/CD, provocando fallimenti quando la release esiste già.

Tipi di dato errati nei flag --set: stringhe e booleani mal interpretati se privi di quoting corretto.

Modificare le risorse gestite direttamente con kubectl, creando derive rispetto allo stato salvato da Helm.

Assenza o cattiva configurazione di readiness probe sui container, invalidando l'efficacia del flag --wait.

Omessa gestione del Chart.lock quando si aggiornano versioni nei subchart.

Snippet e comandi

# Gestione repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# Installazione o aggiornamento idempotente con file di valori
helm upgrade --install my-app ./my-chart -f values-prod.yaml -n production --create-namespace

# Verifica locale del rendering dei template senza toccare il cluster
helm template my-app ./my-chart -f values-prod.yaml

# Ispezione dello stato e della cronologia
helm status my-app -n production
helm history my-app -n production

# Rollback a una revisione precedente
helm rollback my-app 2 -n production

Da ripassare

[ ] Gestione del ciclo di vita con i Chart Hook (pre-install, post-upgrade)

[ ] Sintassi e risoluzione delle dipendenze con subchart

[ ] Push e pull di Chart su artifact registry OCI

[x] Sintassi di Go templating e funzioni Sprig essenziali

[x] Modello di sicurezza RBAC e assenza di Tiller in Helm 3

Riferimenti

Documentazione ufficiale Helm (helm.sh/docs)

Helm Charts Best Practices Guide