Helm 3: il package manager di Kubernetes senza Tiller

Servizi & Sistemi Linux

Domini, hosting, PEC, infrastruttura email, servizi di rete e sistemi Linux. Assistenza e gestione dell’infrastruttura Open Source.

Scopri →

Il package manager di Kubernetes

Helm — nato nel 2015 presso Deis (poi acquisita da Microsoft nel 2017) — è il package manager per Kubernetes. Helm definisce il concetto di chart: una collezione di template YAML che, parametrizzata con valori, genera un insieme coordinato di manifest K8s (Deployment, Service, Ingress, ConfigMap, Secret, …) per deployare un’applicazione.

La 2.x era la prima release mainstream, adottata ampiamente come standard de facto per la distribuzione di applicazioni Kubernetes. Il 13 novembre 2019 è stato rilasciato Helm 3, major release con riprogettazione architetturale.

L’errore di Helm 2: Tiller

L’architettura Helm 2 prevedeva un componente server-side chiamato Tiller — deployment Kubernetes con permessi cluster-admin. Il client helm inviava richieste a Tiller, che eseguiva le operazioni sul cluster a nome dell’utente.

Questa scelta era stata criticata fin dall’inizio per problemi di sicurezza:

• Permessi eccessivi — Tiller aveva privilegi globali anche quando l’utente richiedeva operazioni limitate
• Single point of authorization — authZ difficile da granularizzare per tenant
• Compatibilità RBAC — RBAC Kubernetes (introdotto in 1.6, giugno 2017) rendeva Tiller problematico per cluster multi-tenant
• Superficie di attacco — compromissione di Tiller → accesso completo al cluster

Helm 3: architettura client-only

Helm 3 rimuove Tiller completamente. Il client helm ora:

1. Si autentica con Kubernetes usando il kubeconfig dell’utente
2. Applica le permission RBAC assegnate all’utente direttamente
3. Memorizza lo state dei release come Kubernetes Secrets nel namespace di deploy

Il modello è client-only: tutte le operazioni passano per l’API Kubernetes come qualunque altra interazione kubectl. Nessun componente privilegiato in esecuzione sul cluster.

Vantaggi:

• Sicurezza — permission basate su utente, namespace, RBAC standard
• Multi-tenant — Helm diventa utilizzabile in cluster condivisi
• Semplicità — un componente in meno da gestire
• Isolation — diversi team/utenti possono usare Helm indipendentemente

Altre novità

3-way merge patch

Helm 3 introduce logica di merge che considera:

• Lo stato corrente del cluster
• L’ultimo release applicato da Helm
• Il nuovo release

Questo risolve problemi precedenti in cui modifiche manuali (via kubectl) venivano sovrascritte alla successiva upgrade Helm. Ora Helm 3 preserva modifiche non contese.

OCI registry support

Le chart possono essere ospitate in OCI-compliant registries (Docker Hub, Harbor, GCR, Quay, ECR) invece che in Helm repository classici (HTTP). Unifica con il registry delle immagini container.

Library charts

Nuovo tipo di chart: library chart, per condividere template riutilizzabili tra chart multipli senza essere installabili da soli.

JSON Schema validation

Chart values possono essere validati contro un JSON Schema dichiarato, con errori strutturati.

Namespace handling

helm install non crea più automaticamente namespace; richiede --create-namespace o namespace esistente. Scelta coerente con altre operazioni Kubernetes.

Migrazione da Helm 2

Helm 3 è non backward-compatible su alcune dimensioni chiave:

• Release store formato diverso (Secrets invece di ConfigMap in kube-system)
• Il client non parla con Tiller
• Alcuni flag CLI cambiano nome

Il team Helm fornisce il plugin helm-2to3 per migrare release esistenti. Il processo di adozione è:

1. Installare Helm 3 affianco a Helm 2
2. Migrare release storici con helm 2to3
3. Disinstallare Tiller
4. Rimuovere Helm 2 client

Adozione

Al rilascio Helm 3 è adottato:

• CNCF ecosystem — Helm è progetto Incubating dal 2018, diventerà Graduated nel 2020
• Chart repositories — Helm Hub (poi Artifact Hub) distribuisce migliaia di chart
• Provider cloud — GCP Marketplace, AWS Marketplace pubblicano chart
• Operators integration — pattern ibrido Helm + Operator emerge con Operator SDK

Il ruolo nell’ecosistema

Helm 3 consolida una pratica: distribuire applicazioni Kubernetes complesse come pacchetti versionati. Simile al pattern apt/dnf per Linux ma per il dominio Kubernetes. Le chart pubbliche (Artifact Hub al 2024 contiene >10.000 chart) permettono di installare in un comando applicazioni sofisticate: PostgreSQL con HA, Redis cluster, Prometheus con Grafana, Istio, ArgoCD, Harbor.

Alternative

• Kustomize (integrato in kubectl dal 1.14) — approccio senza template, overlay-based
• Jsonnet (Google) — linguaggio funzionale per generare config
• CDK8s (AWS) — IaC-style in TypeScript/Python per Kubernetes
• Kapitan, Tanka — sistemi di templating alternativi

Helm rimane dominante per la sua semplicità e l’ecosistema di chart esistenti.

Nel contesto italiano

Al 2019 Helm è ampiamente adottato nei team DevOps italiani che hanno portato applicazioni in Kubernetes. La migrazione da Helm 2 a Helm 3 è graduata ma pianificata con urgenza per i team sensibili alla sicurezza: multi-tenant, regolati, PA.

Riferimenti: Helm 3.0 (13 novembre 2019). Helm originariamente di Deis (2015), poi Microsoft. Kubernetes RBAC (1.6, giugno 2017). OCI Image Spec. CNCF Incubating (2018) → Graduated (2020). Plugin helm-2to3 per migrazione.