Kustomize e Helm: qual è la differenza?

Quando si tratta di gestire e implementare applicazioni Kubernetes, due strumenti si distinguono costantemente: Kustomize e Helm. Entrambi semplificano la complessità delle implementazioni Kubernetes, ma adottano approcci fondamentalmente diversi per risolvere la stessa sfida.

Helm è un gestore di pacchetti per Kubernetes che include tutto il necessario per un'applicazione all'interno di un unico pacchetto riutilizzabile, chiamato grafico Helm. Kustomize, uno strumento nativo di Kubernetes, adotta un approccio dichiarativo, utilizzando patch e overlay per modificare le configurazioni di base che richiedono l'uso di linguaggi per modelli.

La scelta tra questi strumenti non è solo una preferenza tecnica, poiché influisce direttamente sulla produttività del team di sviluppo, sui costi operativi e sulla capacità di scalare le applicazioni in modo affidabile. Molte organizzazioni scoprono un valore significativo nell'usare entrambi gli strumenti insieme, tuttavia capire quando e perché scegliere ciascun approccio è essenziale per creare una strategia di implementazione di Kubernetes efficace e scalabile.

Prima di esplorare Kustomize ed Helm, è utile comprendere la containerizzazione, alla base delle moderne applicazioni cloud-native.

La containerizzazione racchiude le applicazioni, con tutto il necessario per l'esecuzione (codice, librerie e configurazione), in unità leggere e portatili chiamate container, che in genere vengono eseguite su sistemi basati su Linux. Questo processo consente al software di funzionare in modo uniforme in vari ambienti, dai laptop per sviluppatori all'infrastruttura cloud di produzione.

Kubernetes, noto anche come k8s o kube, orchestra i contenitori (in genere basati su Docker) su larga scala, automatizzando la distribuzione, il ridimensionamento e la gestione delle risorse tra cluster di macchine.

Secondo un sondaggio del 2024 della Cloud Native Computing Foundation (CNCF), l'adozione del cloud-native ha raggiunto il massimo storico dell'89% tra le organizzazioni intervistate e il 93% delle organizzazioni che utilizzano, testano o valutano Kubernetes.¹

Man mano che le organizzazioni si spostano da semplici applicazioni a complesse architetture multiservizi, i file di configurazione necessari per gestire le distribuzioni Kubernetes diventano sempre più complessi. Una tipica applicazione aziendale potrebbe richiedere dozzine di file di configurazione, ognuno dei quali ha bisogno di una personalizzazione per diversi ambienti: sviluppo, staging e produzione.

 Questa complessità introduce diverse sfide aziendali:

• Difficoltà a mantenere la coerenza tra gli ambienti

• Spese operative più elevate

• Mancanza di automazione della distribuzione, che causa errori manuali

• Tempi di commercializzazione più lunghi per le nuove funzionalità

Sia Kustomize che Helm sono stati creati per affrontare queste sfide, ma adottano approcci diversi. Helm è entrato per primo nel mercato quando Deis (successivamente acquisita da Microsoft) l'ha presentato come uno dei primi strumenti progettati per semplificare la gestione delle applicazioni Kubernetes. Il progetto ha acquisito ulteriore credibilità quando Deis lo ha donato al CNCF nel 2018 e ha ottenuto lo status di laurea CNCF a pieno titolo nel 2020.

Nel frattempo, Kubernetes ha intrapreso una strada diversa integrando Kustomize direttamente nell'interfaccia a riga di comando (CLI) di kubectl con il rilascio di Kubernetes 1.14 nel 2019.

Kustomize utilizza un approccio dichiarativo alla gestione della configurazione. Piuttosto che scrivere come raggiungere uno stato specifico, DevOps e altri team descrivono come vogliono che sia la configurazione finale. 

Lo strumento utilizza una metodologia "base and overlay". I team mantengono una configurazione di base standard che acquisisce le caratteristiche principali dell'applicazione. Quindi, per ogni ambiente o variante, creano sovrapposizioni che specificano solo le differenze necessarie per quel contesto specifico.

Consideriamo una configurazione di base che definisce un'applicazione web con requisiti di risorse standard e una configurazione di rete di base. Un overlay di sviluppo potrebbe ridurre i limiti delle risorse e le repliche per ridurre i costi, mentre un overlay di produzione potrebbe aumentare le impostazioni di sicurezza e aggiungere componenti di monitoraggio. Kustomize unisce queste configurazioni per produrre i manifesti Kubernetes di implementazione finale (file YAML o JSON) che descrivono lo stato desiderato delle risorse Kubernetes.

Kustomize funziona direttamente con i file manifest YAML nativi (come deployment.yaml) che contengono campi Kubernetes standard come apiVersion. Questo approccio elimina la necessità di un linguaggio di template, facilitando l'adozione da parte dei team senza apprendere ulteriori sintassi di codifica oltre alle configurazioni YAML standard di Kustomize. Di conseguenza, i team possono implementare rapidamente una sofisticata gestione della configurazione lavorando con la familiare sintassi YAML di Kubernetes che già conoscono.

Helm, il gestore di pacchetti Kubernetes più popolare sul mercato, funziona essenzialmente come un app store per le applicazioni Kubernetes, gestendo e installando con facilità applicazioni preconfezionate. Secondo recenti sondaggi di CNCF, Helm è il gestore di pacchetti Kubernetes preferito, con un'adozione del 75% tra le organizzazioni che utilizzano Kubernetes.²

Helm impacchetta le applicazioni nei "grafici Helm", ovvero collezioni di risorse Kubernetes preconfigurate che i team possono installare, aggiornare e gestire come un'unica unità. Ogni grafico include dei file di configurazione (ad esempio chart.yaml) e utilizza template Go per supportare la configurazione dinamica basata sui valori di input.

Il vantaggio di Helm è rappresentato dal suo motore di template e dalle sue funzionalità di gestione dei pacchetti. Invece di mantenere più versioni di configurazioni simili, Helm consente ai team di creare grafici con placeholder e di utilizzare file di valori separati (come values.yaml) per popolare quei placeholder durante l'implementazione. I team possono utilizzare il template helm per visualizzare in anteprima la configurazione finale renderizzata prima di applicarla al cluster Kubernetes.  

Oltre ai modelli, Helm offre funzionalità complete di gestione del ciclo di vita, inclusa la possibilità di ripristinare le distribuzioni, gestire le versioni e tenere traccia della cronologia delle distribuzioni. Queste funzionalità rendono Helm prezioso per le organizzazioni che gestiscono dei portfolio di applicazioni complessi in cui le funzioni di orchestrazione e di rollback sono fondamentali.

Ad esempio, una società di e-commerce può utilizzare un grafico per il proprio archivio online ma personalizzarlo per ambienti diversi: meno server per i test, più server per la produzione, senza creare file di configurazione separati.

Per distribuire questi grafici, i team utilizzano helm install, che applica automaticamente tutte le risorse al cluster di destinazione tramite l'application programming interface (API) di Kubernetes. Helm gestisce automaticamente il controllo delle versioni e la gestione delle dipendenze, garantendo implementazioni coerenti e affidabili

La scelta tra Kustomize e Helm dipende da specifiche sfide di distribuzione e obiettivi aziendali. Le organizzazioni che personalizzano la stessa applicazione per ambienti diversi in genere traggono il maggior beneficio da Kustomize. Chi gestisce più applicazioni o richiede sofisticati controlli di distribuzione trova Helm più adatto.

La sezione successiva approfondisce i casi in cui è meglio utilizzare ciascuna soluzione.

La maggior parte delle organizzazioni deve distribuire la stessa applicazione in ambienti di sviluppo, staging e produzione con differenze sottili ma significative. Kustomize eccelle in questo scenario consentendo ai team di mantenere una singola fonte affidabile applicando modifiche specifiche dell'ambiente.

Gli ambienti di sviluppo potrebbero richiedere limiti di risorse ridotti per risparmiare sui costi, mentre gli ambienti di produzione richiedono impostazioni di sicurezza avanzate, ConfigMaps diversi e componenti di monitoraggio. Kustomize consente alle organizzazioni di definire queste differenze senza duplicare interi file di configurazione.

Situazioni di implementazione diverse spesso richiedono politiche di sicurezza o misure di conformità diverse. Kustomize consente ai team di aggiungere questi requisiti alle configurazioni di base, senza creare set di configurazione completamente separati. Questa funzionalità si rivela preziosa per le organizzazioni che operano in più regioni o settori con requisiti normativi diversi.

Quando si implementano modifiche alla configurazione su ampi portafogli di applicazioni, Kustomize consente ai team di apportare modifiche incrementali senza interrompere l'intera struttura di configurazione. Questo approccio riduce i rischi e semplifica l'identificazione e la risoluzione di problemi come configurazioni errate o errori di implementazione.

Uno dei principali benefici di Helm sono le sue funzionalità di packaging, che avvantaggiano in particolare le organizzazioni che creano piattaforme o cercano di standardizzare le implementazioni delle applicazioni tra i team.

I team possono creare grafici riutilizzabili che raccolgono best practice e standard organizzativi, distribuendoli poi in tutta l'azienda.

Le applicazioni che richiedono un'orchestrazione di implementazione sofisticata, come dei rollout in più fasi, gestione delle dipendenze e funzionalità di rollback, sono particolarmente adatte alle caratteristiche di gestione delle versioni di Helm. Se qualcosa va storto, Helm può ripristinare immediatamente la versione funzionante precedente, riducendo l'impatto sugli utenti.

Quando si integrano le più diffuse applicazioni open source o le soluzioni dei fornitori, l'ampio archivio di grafici (repository dei grafici) di Helm fornisce pacchetti predefiniti in grado di ridurre in modo significativo i tempi di implementazione.

Invece di creare le configurazioni da zero, i team possono utilizzare i grafici gestiti dalla community per i database, monitorare le pipeline di continuous integration or continuous delivery (CI/CD) del sistema e altri componenti standard dell'infrastruttura IT .

Le piattaforme SaaS utilizzano spesso Helm per gestire le implementazioni di applicazioni specifiche per il cliente, distribuendo la stessa applicazione più volte con configurazioni diverse in namespace separati. Questo approccio fornisce l'isolamento e la personalizzazione necessari per le architetture multitenant.

Kustomize offre diversi benefici per la gestione della configurazione Kubernetes, tra cui:

Le organizzazioni scelgono Helm per benefici come questi.

Piuttosto che considerare Kustomize e Helm come soluzioni concorrenti, molte organizzazioni trovano un valore significativo nell'usare entrambi gli strumenti insieme. Questo approccio ibrido utilizza i punti di forza di ogni strumento, mitigandone i limiti.

Ecco alcuni casi d'uso diffusi:

• Implementazione iniziale e personalizzazione dell'ambiente

• Applicazioni di terze parti con configurazioni personalizzate

• Ambienti multi-team

Un tipico modello di uso congiunto prevede l'implementazione di Helm per il packaging e l'implementazione iniziale delle applicazioni, seguita dall'uso di Kustomize per applicare personalizzazioni specifiche dell'ambiente. Questo approccio offre i benefici della gestione dei pacchetti e delle funzionalità di rilascio di Helm, mantenendo la semplicità e la trasparenza di Kustomize per la gestione continua della configurazione.

Ad esempio, un'organizzazione potrebbe usare un grafico Helm per implementare un'applicazione di microservizi con tutte le relative dipendenze. Il passaggio successivo consiste nell'utilizzare gli overlay di Kustomize per aggiungere policy di sicurezza per la produzione o configurare diverse regole di ingress Kubernetes per lo staging.

Le organizzazioni spesso usano Helm per implementare applicazioni di terze parti dal suo ampio archivio di grafici, mentre utilizzano Kustomize per applicazioni personalizzate in cui desiderano un controllo più diretto sulla gestione della configurazione.

Questa combinazione consente ai team di utilizzare grafici gestiti dalla community per gli strumenti più diffusi, come i sistemi di monitoraggio o le code di messaggi, mantenendo il controllo completo sulle loro applicazioni proprietarie.

Nelle grandi organizzazioni con più team di sviluppo, i team di piattaforma spesso creano Helm standardizzati che contengono le best practice e i requisiti di conformità. Questi grafici funzionano insieme a strumenti Infrastructure as Code (IaC) come Terraform per gestire l'intera pipeline di implementazione.

I singoli team di sviluppo utilizzano quindi Kustomize per personalizzare questi grafici per le loro applicazioni e i loro ambienti specifici senza modificare i grafici di base. Questo approccio crea una separazione netta che si integra perfettamente con gli strumenti GitOps come ArgoCD per i workflow di implementazione automatizzati.

Una gestione efficace della configurazione di Kubernetes richiede una strategia flessibile che si adatti alle esigenze delle applicazioni in evoluzione.

Comprendere le differenze tra Helm e Kustomize (e sapere come integrarli in modo efficace) aiuta a ridurre la complessità e a mantenere la coerenza. Questa combinazione strategica porta in definitiva ad ambienti Kubernetes più gestibili e scalabili.