Ispirato dalla mia presentazione “Hell in Helm: una storia d’amore tra i gironi dell’inferno di un OTTIMO strumento” a IDI 2026.

Helm è un nome molto noto in ambito Kubernetes come il package manager più popolare per installare e gestire applicazioni in questa tipologia di ambienti. Tanta è la sua popolarità, tanta è l’attenzione da avere nel suo uso per evitare errori e comportamenti inattesi, a volte per specifiche scelte di design dello strumento, a volte per veri e propri bug.

Standard di sviluppo dei pacchetti? Non pervenuti

Helm pone poche regole su come sviluppare le Helm Chart, ovvero i pacchetti Helm, aprendo ad ambiguità e forti differenze tra una chart e l’altra: diventa quindi impossibile configurare in maniera uniforme, con i file di values, tutte le chart che si desidera installare sui propri cluster. Ad esempio, alcune chart chiedono di elencare le variabili d’ambiente come array nei file di values, altre come oggetti: gli array risultano più vicini al formato che Kubernetes usa nelle proprie Custom Resources, ma gli oggetti risultano più comodi da gestire nel caso si usino multipli file di values.

Il risultato della mancanza di regole? Ognuno svilupperà le chart come gli è più comodo e, a ogni installazione, sarà necessario verificare il formato da utilizzare.

Go Template: bug e limitazioni

Helm si basa su Go Template, che però presenta alcuni bug nel suo uso all’interno di Helm e ha altri funzionamenti più o meno inaspettati che spesso vanno a limitare l’uso che si vuole fare di Helm.

Un noto bug è la gestione dello spazio dei nomi delle funzioni, che è unico per tutte le Chart aggregate in un’unica Chart “genitore”. Se più Chart dipendenti usano al loro interno funzioni con lo stesso nome, ma implementazioni diverse, esse verranno “collassate” su un’unica funzione, la cui implementazione è presa da una delle Chart dipendenti non nota a priori.

Una nota limitazione, ma perfettamente in linea con il fatto che Helm sia un package manager, è che non si possono templatizzare file esterni alla Chart, perché essendo esterni non verrebbero distribuiti con essa. Questo però è un caso d’uso spesso desiderato, ad esempio per includere all’interno di ConfigMap dei file di configurazione: l’identità del tool si scontra con l’uso reale che se ne fa (o che se ne vorrebbe fare).

Template e install: differenze inaspettate

I comandi helm template ed helm install sono generalmente, da chi si approccia per la prima volta a Helm, considerati interscambiabili, con l’unica differenza che install crea le risorse sul cluster Kubernetes, mentre template ne produce solo una rappresentazione in formato Yaml.

In realtà, install fa molto di più, gestendo l’ordine di creazione delle risorse e configurandole, se richiesto, in base allo stato del cluster al momento dell’installazione. Questa differenza mette in difficoltà chi desidera valutare le risorse da applicare prima dell’applicazione effettiva, ad esempio tool di generazione di grafici o il noto ArgoCD, che usa appunto il comando helm template.

FluxCD, diretto concorrente di ArgoCD, usa invece helm install, in maniera più coerente con le buone pratiche di Helm. Di fatto, entrambe le filosofie d’uso sono valide, ma richiedono attenzione e consapevolezza dei loro limiti.

C’è fare templating e c’è abusare del templating…

Un rischio nell’uso di Helm è di vedere le sue capacità di templating e gli strumenti compatibili con essi e farsi prendere la mano… andando ad esempio a sviluppare un plugin Maven che a partire da un file di values genera una Helm Chart, la quale viene gestita insieme ad altre Helm Chart generate allo stesso modo da Helmfile, che coordina la loro installazione sul cluster previa applicazione di una Kustomization. Quattro tool, ognuno con i suoi problemi, limiti e complessità, utilizzati per fare ciò che avrebbero potuto fare Helmfile, Helm e delle chart ben sviluppate.

Un consiglio: non stratificare più strumenti di templating del necessario, o il debugging sarà davvero un inferno…

Usare o non usare Helm?

Viste le complessità di Helm, c’è chi potrebbe cercare strumenti alternativi, e nella ricerca potrebbe trovare sicuramente come opzioni Kustomize e Timoni. Rispetto a Helm, hanno entrambi i loro vantaggi e svantaggi: Kustomize è più limitato nelle funzionalità, ma è integrato in kubectl e si basa sul patching di documenti Yaml, invece che sul templating di documenti Yaml. Timoni è un package manager come Helm con molti miglioramenti, avendo imparato dal suo predecessore, che però usa CUE, un linguaggio più complesso e formale della combinazione di Yaml e go template usata da Helm.

Viste le alternative, quindi, vale la pena continuare a usare Helm?
La risposta, che non sorprenderà nessuno, è “dipende”. Dipende da ciò per cui uno lo vuole usare, da quanto impegno e attenzione ci si può dedicare e dall’ecosistema di strumenti in cui lo si vuole inserire: nonostante i suoi difetti Helm è comunque uno strumento solido, con un ampio ecosistema e poco difficile da iniziare a usare.

Qualunque sia lo strumento scelto per gestire le proprie applicazioni su Kubernetes, l’importante è farne un uso coerente che segua le linee guida e gli standard disponibili, limitando le stratificazioni di strumento. E nel caso la scelta sia Helm, è particolarmente importante anche non abusarne!