🥇Introduzione a Helm 3

Nota di traduzione.: 16 maggio di quest'anno — una data importante nello sviluppo del gestore di pacchetti per Kubernetes — Helm. In questo giorno è stato presentato il primo rilascio alpha della futura grande versione del progetto — 3.0. Il suo lancio porterà in Helm cambiamenti significativi e attesi da tempo, sui quali molte persone nella comunità Kubernetes ripongono grandi speranze. Ci consideriamo tra questi, poiché utilizziamo attivamente Helm per il deployment delle applicazioni: lo abbiamo integrato nel nostro strumento per realizzare CI/CD werf e di tanto in tanto contribuiamo allo sviluppo upstream. Questa traduzione riunisce 7 articoli dal blog ufficiale di Helm, collegati al primo rilascio alpha di Helm 3 e che raccontano la storia del progetto e le principali caratteristiche di Helm 3. Il loro autore è Matt «bacongobbler» Fisher, dipendente Microsoft e uno dei principali maintainer di Helm.

Il 15 ottobre 2015 è nato il progetto, oggi conosciuto come Helm. Solo un anno dopo la sua fondazione, la comunità di Helm si è unita a Kubernetes, lavorando attivamente su Helm 2. Nel giugno 2018 Helm è entrato a far parte del CNCF come progetto incubante. Tornando al presente, ecco che si avvicina il primo rilascio alpha del nuovo Helm 3 (questo rilascio è già avvenuto a metà maggio — nota del traduttore.).

In questo materiale parlerò di come tutto è iniziato, come siamo arrivati all'attuale fase, presenterò alcune caratteristiche uniche disponibili nel primo rilascio alpha di Helm 3 e spiegherò come intendiamo svilupparci in futuro.

Sommario:

storia della creazione di Helm;
un dolce addio a Tiller;
repository dei chart;
gestione delle release;
modifiche alle dipendenze dei chart;
library charts;
cosa c'è dopo?

Storia della creazione di Helm

Nascita

Helm 1 è iniziato come progetto Open Source, creato dall'azienda Deis. Eravamo una piccola startup, acquisita da Microsoft nella primavera del 2017. Un altro nostro progetto Open Source, anch'esso chiamato Deis, aveva uno strumento deisctl, utilizzato (tra le altre cose) per installare e gestire la piattaforma Deis in un cluster Fleet. All'epoca, Fleet era una delle prime piattaforme per l'orchestrazione dei container.

Nel mezzo del 2015 abbiamo deciso di cambiare rotta e abbiamo migrato Deis (all'epoca rinominato in Deis Workflow) da Fleet a Kubernetes. Uno dei primi strumenti a essere rielaborato deisctl. Lo usavamo per installare e gestire Deis Workflow in un cluster Fleet.

Helm 1 è stato creato sull'esempio di noti gestori di pacchetti come Homebrew, apt e yum. Il suo obiettivo principale era semplificare compiti come l'imballaggio e l'installazione di applicazioni in Kubernetes. Helm è stato presentato ufficialmente nel 2015 durante la conferenza KubeCon a San Francisco.

Il nostro primo tentativo con Helm ha funzionato, ma non è stato privo di seri limiti. Prelevava un insieme di manifesti Kubernetes, arricchiti da generatori come input YAML-blocchi (front-matter)*, e caricava i risultati in Kubernetes.

* Nota di traduzione.: Dalla prima versione di Helm, è stata scelta la sintassi YAML per descrivere le risorse Kubernetes e nell'elaborazione delle configurazioni venivano supportati modelli Jinja e script Python. Abbiamo scritto di più su questo e sulla natura della prima versione di Helm nella sezione "Breve storia di Helm" di questo materiale.

Ad esempio, per sostituire un campo nel file YAML, era necessario aggiungere nel manifesto la seguente struttura:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

È fantastico che oggi esistano i motori di templating, non è vero?

Per molte ragioni, questo primo installer di Kubernetes richiedeva un elenco di file manifesto rigidamente definito e eseguiva solo una piccola sequenza fissa di eventi. Utilizzarlo era così difficile che al team R&D di Deis Workflow è andata male quando hanno cercato di migrare il loro prodotto a questa piattaforma; tuttavia, i semi dell'idea erano già stati piantati. Il nostro primo tentativo è stato un'ottima opportunità di apprendimento: abbiamo capito che eravamo davvero appassionati nella creazione di strumenti pragmatici che risolvono problemi quotidiani per i nostri utenti.

Basandoci sull'esperienza degli errori passati, abbiamo iniziato a sviluppare Helm 2.

Creazione di Helm 2

Alla fine del 2015, il team di Google ci ha contattato. Stava lavorando a uno strumento simile per Kubernetes. Il Deployment Manager per Kubernetes era un porting di uno strumento esistente utilizzato per Google Cloud Platform. "Non vogliamo passare qualche giorno a discutere delle somiglianze e delle differenze?"

Nel gennaio 2016, i team di Helm e del Deployment Manager si sono incontrati a Seattle per scambiare idee. I colloqui si sono conclusi con un ambizioso piano: unire entrambi i progetti per creare Helm 2. Insieme a Deis e Google, si sono uniti al team di sviluppatori anche ragazzi di SkippBox (ora parte di Bitnami — nota del traduttore), e abbiamo iniziato a lavorare su Helm 2.

Volevamo mantenere la semplicità d'uso di Helm, ma aggiungere quanto segue:

modelli di chart per la personalizzazione;
gestione interna del cluster per i team;
un repository di chart di prima classe;
un formato di pacchetti stabile con firma possibile;
un forte impegno per il versionamento semantico e per garantire la retrocompatibilità tra le versioni.

Per raggiungere questi obiettivi, è stato aggiunto un secondo elemento all'ecosistema Helm. Questo componente interno al cluster è stato chiamato Tiller e si occupava dell'installazione e della gestione dei chart Helm.

Sin dall'uscita di Helm 2 nel 2016, Kubernetes ha visto diverse innovazioni significative. È stata implementata la gestione degli accessi basata sui ruoli (RBAC), che ha infine sostituito il controllo degli accessi basato sugli attributi (ABAC). Sono stati introdotti nuovi tipi di risorse (le Deployments erano ancora in beta all'epoca). Sono state ideate le Custom Resource Definitions (inizialmente chiamate Third Party Resources o TPR). E, soprattutto, è emerso un set di best practice.

Nel contesto di tutti questi cambiamenti, Helm ha continuato a servire con fedeltà agli utenti di Kubernetes. Dopo tre anni e molte nuove aggiunte, è diventato chiaro che era il momento di apportare modifiche significative alla base di codice affinché Helm potesse continuare a soddisfare le esigenze crescenti di un ecosistema in evoluzione.

Un dolce addio a Tiller

Durante lo sviluppo di Helm 2, abbiamo presentato Tiller come parte della nostra integrazione con il Deployment Manager di Google. Tiller svolgeva un ruolo fondamentale per i team operanti all'interno di un cluster condiviso: consentiva ai diversi specialisti che gestivano l'infrastruttura di interagire con lo stesso set di rilasci.

Poiché il controllo degli accessi basato sui ruoli (RBAC) è stato abilitato per impostazione predefinita in Kubernetes 1.6, lavorare con Tiller in produzione è diventato più complesso. A causa del numero elevato di politiche di sicurezza possibili, la nostra posizione era quella di offrire per impostazione predefinita una configurazione permissiva. Questo ha permesso ai principianti di sperimentare con Helm e Kubernetes senza dover prima approfondire le impostazioni di sicurezza. Sfortunatamente, questa configurazione permissiva poteva conferire all'utente un intervallo troppo ampio di autorizzazioni, di cui non aveva bisogno. Gli ingegneri DevOps e SRE dovevano studiare ulteriori passaggi operativi per installare Tiller in un cluster multi-tenant.

Scoprendo come i membri della comunità utilizzano Helm in situazioni specifiche, abbiamo capito che il sistema di gestione delle release di Tiller non doveva fare affidamento su un componente intra-cluster per mantenere stati o funzionare come hub centrale con informazioni sulla release. Invece, potevamo semplicemente ottenere informazioni dall'API server di Kubernetes, generare il chart sul lato client e conservare una registrazione dell'installazione in Kubernetes.

La funzione principale di Tiller poteva essere svolta anche senza Tiller, quindi una delle prime decisioni riguardo Helm 3 è stata l'eliminazione completa di Tiller.

Con l'uscita di Tiller, il modello di sicurezza di Helm si è semplificato radicalmente. Helm 3 ora supporta tutti i moderni metodi di sicurezza, identificazione e autorizzazione dell'attuale Kubernetes. Le autorizzazioni di Helm sono definite tramite file kubeconfig. Gli amministratori del cluster possono limitare i diritti degli utenti con qualsiasi grado di dettaglio. Le release rimangono comunque memorizzate all'interno del cluster, e il resto della funzionalità di Helm viene mantenuta.

I repository dei chart

A un livello alto, un repository di chart è un luogo dove è possibile memorizzare e condividere i chart. Il client Helm imballa e invia i chart al repository. In parole semplici, un repository di chart è un server HTTP primitivo con un file index.yaml e alcuni chart imballati.

Sebbene ci siano alcuni vantaggi nel fatto che l'API del repository dei chart soddisfi i requisiti di base per lo storage, ha anche alcuni svantaggi:

I repository dei chart sono poco compatibili con la maggior parte delle implementazioni di sicurezza necessarie in un ambiente di produzione. Avere un'API standard per l'autenticazione e l'autorizzazione è estremamente importante negli scenari di produzione.
Gli strumenti di Helm per il tracciamento dell'origine dei chart, utilizzati per la firma, il controllo dell'integrità e l'origine dei chart, costituiscono una parte facoltativa del processo di pubblicazione del Chart.
Negli scenari multiutente, lo stesso chart può essere caricato da un altro utente, raddoppiando lo spazio necessario per memorizzare lo stesso contenuto. Per affrontare questo problema sono stati sviluppati repository più intelligenti, ma non fanno parte della specifica formale.
L'uso di un unico file indice per cercare, memorizzare metadati e ottenere chart ha complicato lo sviluppo di implementazioni sicure multiutente.

Progetto Docker Distribution (noto anche come Docker Registry v2) è il successore di Docker Registry e funge effettivamente da insieme di strumenti per impacchettare, inviare, memorizzare e distribuire immagini Docker. Molti grandi servizi cloud offrono prodotti basati su Distribution. Grazie a questa attenzione, il progetto Distribution ha beneficiato di anni di miglioramenti, migliori pratiche in materia di sicurezza e test in condizioni 'reali', trasformandolo in uno dei più riusciti eroi non celebrati del mondo Open Source.

Ma sapevate che il progetto Distribution è stato sviluppato per distribuire qualsiasi forma di contenuto, e non solo immagini di contenitori?

Grazie agli sforzi Open Container Initiative (o OCI), i chart di Helm possono essere ospitati su qualsiasi istanza di Distribution. Finora, questo processo è di natura sperimentale. Il lavoro per supportare il login e altre funzionalità necessarie per un completo Helm 3 non è ancora concluso, ma siamo molto entusiasti di poter apprendere dalle scoperte fatte dai team OCI e Distribution negli anni. E grazie alla loro guida e mentorship, stiamo imparando cosa significa gestire un servizio ad alta disponibilità su larga scala.

Una descrizione più dettagliata di alcuni dei prossimi cambiamenti nei repository dei chart di Helm è disponibile al link.

Gestione delle release

In Helm 3, lo stato dell'applicazione è tracciato all'interno del cluster da una coppia di oggetti:

l'oggetto release — rappresenta un'istanza dell'applicazione;
release version secret — rappresenta lo stato desiderato dell'applicazione in un momento specifico (ad esempio, il rilascio di una nuova versione).

Chiamata helm install crea un oggetto di release e un segreto della versione di release. Chiamata helm upgrade richiede un oggetto di release (che può modificare) e crea un nuovo segreto della versione di release, contenente nuovi valori e un manifesto preparato.

L'oggetto di release contiene informazioni sulla release, dove la release è un'installazione specifica di un chart nominato e dei valori. Questo oggetto descrive i metadati a livello superiore sulla release. L'oggetto di release viene mantenuto per tutto il ciclo di vita dell'applicazione e funge da proprietario di tutti i segreti della versione di release, così come di tutti gli oggetti creati direttamente dal chart di Helm.

Il segreto della versione di release collega la release a una serie di revisioni (installazione, aggiornamenti, rollback, rimozione).

In Helm 2, le revisioni erano esclusivamente sequenziali. Chiamata helm install creava v1, l'aggiornamento successivo (upgrade) — v2, e così via. La release e il segreto della versione di release erano accorpati in un unico oggetto, noto come revisione. Le revisioni erano memorizzate nello stesso namespace di Tiller, il che significava che ogni release era "globale" in termini di namespace; di conseguenza, si poteva utilizzare solo un'istanza del nome.

In Helm 3, ogni release è collegata a uno o più segreti della versione di release. L'oggetto di release descrive sempre la release corrente, distribuita in Kubernetes. Ogni segreto della versione di release descrive solo una versione di questa release. L'aggiornamento (upgrade), ad esempio, creerà un nuovo segreto della versione di release e poi cambierà l'oggetto di release per riferirsi a questa nuova versione. In caso di rollback, è possibile utilizzare i segreti della versione di release precedenti per ripristinare la release allo stato precedente.

Dopo l'abbandono di Tiller, Helm 3 memorizza i dati della release in un unico namespace insieme alla release. Questo cambiamento consente di installare un chart con lo stesso nome di release in un altro namespace, e i dati vengono mantenuti tra aggiornamenti/reboot del cluster in etcd. Ad esempio, è possibile installare WordPress nel namespace "foo", e poi nel namespace "bar", e entrambe le release possono chiamarsi "wordpress".

Modifiche nelle dipendenze dei chart

Chart impacchettati (con helm package) per l'uso con Helm 2, può essere installato con Helm 3, tuttavia il flusso di lavoro per lo sviluppo dei chart è stato completamente ristrutturato, quindi è necessario apportare alcune modifiche per continuare a sviluppare i chart con Helm 3. In particolare, è cambiato il sistema di gestione delle dipendenze dei chart.

Il sistema di gestione delle dipendenze del chart è passato a requirements.yaml e requirements.lock in Chart.yaml e Chart.lock. Questo significa che i chart che utilizzavano il comando helm dependency, richiedono qualche configurazione per funzionare in Helm 3.

Esaminiamo un esempio. Aggiungiamo una dipendenza a un chart in Helm 2 e vediamo cosa cambia passando a Helm 3.

In Helm 2 requirements.yaml si presentava come segue:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

In Helm 3, la stessa dipendenza sarà riflessa nel tuo Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

I chart continuano a essere scaricati e posizionati nella directory charts/, quindi i subchart (subcharts), che si trovano nella cartella charts/, continueranno a funzionare senza modifiche.

Presentazione dei Library Charts

Helm 3 supporta una classe di chart chiamata chart di libreria (library chart). Questo chart è utilizzato da altri chart, ma non crea autonomamente alcun artefatto di rilascio. I modelli dei library chart possono dichiarare solo elementi define. Altri contenuti vengono semplicemente ignorati. Questo consente agli utenti di riutilizzare e condividere frammenti di codice che possono essere utilizzati in molti chart, evitando così duplicazioni e rispettando il principio DRY.

I library chart sono dichiarati nella sezione dependencies nel file Chart.yaml. L'installazione e la gestione di essi non differiscono da altri chart.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Non vediamo l'ora di esplorare le possibilità che questo componente aprirà per gli sviluppatori di chart, così come le migliori pratiche che potrebbero emergere grazie ai library chart.

Cosa succede dopo?

Helm 3.0.0-alpha.1 è la base su cui iniziamo a costruire una nuova versione di Helm. In questo articolo ho descritto alcune interessanti funzionalità di Helm 3. Molte di esse sono ancora nelle prime fasi di sviluppo ed è normale; il senso di una versione alpha è testare l'idea, raccogliere feedback dai primi utenti e confermare le nostre ipotesi.

Non appena la versione alpha sarà rilasciata (ricordiamo che questo è già accaduto — nota del traduttore.), inizieremo a ricevere patch per Helm 3 dalla comunità. È necessario creare una base solida che permetta di sviluppare e integrare nuove funzionalità, in modo che gli utenti possano sentirsi coinvolti nel processo, aprendo ticket e apportando correzioni.

Nell'articolo ho cercato di evidenziare alcuni importanti miglioramenti che verranno introdotti in Helm 3, ma questo elenco non può in alcun modo essere considerato esaustivo. Il piano completo per Helm 3 include innovazioni come strategie di aggiornamento migliorate, integrazione più profonda con i registri OCI e utilizzo di schemi JSON per la validazione dei valori dei chart. Inoltre, prevediamo di ripulire il codice sorgente e aggiornare le sue parti che sono rimaste trascurate negli ultimi tre anni.

Se senti che ci siamo persi qualcosa, saremo felici di conoscere le tue opinioni!

Unisciti alla discussione nei nostri canali Slack:

#helm-users per domande e semplici interazioni con la comunità;
#helm-dev per discutere di pull request, codice e bug.

Puoi anche partecipare alle nostre Public Developer Calls settimanali giovedì alle 19:30 MSK. Gli incontri sono dedicati alla discussione delle attività su cui stanno lavorando i principali sviluppatori e la comunità, oltre ad argomenti di discussione per la settimana. Chiunque può unirsi e partecipare all'incontro. Il link è disponibile nel canale Slack #helm-dev.