🥇Introduzione a Helm 3

Nota. trad.: Il 16 maggio di quest'anno segna una pietra miliare significativa nello sviluppo del gestore di pacchetti per Kubernetes - Helm. In questo giorno è stata presentata la prima versione alpha della futura versione principale del progetto, la 3.0. Il suo rilascio porterà cambiamenti significativi e tanto attesi a Helm, per i quali molti nella comunità Kubernetes ripongono grandi speranze. Noi stessi siamo uno di questi, poiché utilizziamo attivamente Helm per il deploy delle applicazioni: lo abbiamo integrato nel nostro strumento per implementare CI/CD werf e di volta in volta diamo il nostro contributo allo sviluppo dell'upstream. Questa traduzione combina 7 note dal blog ufficiale di Helm, che sono dedicate alla prima versione alpha di Helm 3 e parlano della storia del progetto e delle caratteristiche principali di Helm 3. Il loro autore è Matt “bacongobbler” Fisher, un dipendente Microsoft e uno dei principali manutentori di Helm.

Il 15 ottobre 2015 nasce il progetto oggi conosciuto come Helm. Appena un anno dopo la sua fondazione, la comunità Helm si è unita a Kubernetes, mentre lavorava attivamente su Helm 2. Nel giugno 2018, Helm aderito al CNCF come progetto in via di sviluppo (incubazione). Avanti veloce al presente e la prima versione alpha del nuovo Helm 3 è in arrivo. (questa edizione ha già avuto luogo a metà maggio - ca. trad.).

In questo articolo parlerò di dove tutto ha avuto inizio, di come siamo arrivati dove siamo oggi, presenterò alcune delle funzionalità uniche disponibili nella prima versione alpha di Helm 3 e spiegherò come intendiamo andare avanti.

Sommario:

la storia della creazione di Helm;
un tenero addio a Tiller;
archivi di grafici;
gestione dei rilasci;
cambiamenti nelle dipendenze dei grafici;
grafici di biblioteche;
e poi?

La storia di Elmo

La nascita di

Helm 1 è iniziato come un progetto Open Source creato da Deis. Eravamo una piccola startup assorbito Microsoft nella primavera del 2017. L'altro nostro progetto Open Source, anch'esso chiamato Deis, aveva uno strumento deisctl, che è stato utilizzato (tra le altre cose) per installare e far funzionare la piattaforma Deis Gruppo di flotte. All'epoca, Fleet era una delle prime piattaforme di orchestrazione dei container.

A metà del 2015 abbiamo deciso di cambiare rotta e di spostare Deis (allora ribattezzato Deis Workflow) da Fleet a Kubernetes. Uno dei primi ad essere riprogettato è stato lo strumento di installazione. deisctl. Lo abbiamo utilizzato per installare e gestire Deis Workflow nel cluster Fleet.

Helm 1 è stato creato a immagine di famosi gestori di pacchetti come Homebrew, apt e yum. Il suo obiettivo principale era semplificare attività come il confezionamento e l'installazione di applicazioni su Kubernetes. Helm è stato presentato ufficialmente nel 2015 alla conferenza KubeCon di San Francisco.

Il nostro primo tentativo con Helm ha funzionato, ma non è stato privo di serie limitazioni. Ha preso una serie di manifest Kubernetes, arricchiti con generatori come blocchi YAML introduttivi (argomento principale)* e ho caricato i risultati in Kubernetes.

* Nota. trad.: dalla prima versione di Helm, è stata scelta la sintassi YAML per descrivere le risorse Kubernetes e durante la scrittura delle configurazioni sono stati supportati i modelli Jinja e gli script Python. Abbiamo scritto di più su questo e sulla struttura della prima versione di Helm in generale nel capitolo “Una breve storia di Helm” questo materiale.

Ad esempio, per sostituire un campo in un file YAML, dovevi aggiungere il seguente costrutto al manifest:

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

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

Per molte ragioni, questo primo programma di installazione di Kubernetes richiedeva un elenco codificato di file manifest ed eseguiva solo una piccola sequenza fissa di eventi. Era così difficile da usare che il team di ricerca e sviluppo di Deis Workflow ha avuto difficoltà quando ha provato a trasferire il proprio prodotto su questa piattaforma, tuttavia, i semi dell'idea erano già stati gettati. Il nostro primo tentativo è stato una grande opportunità di apprendimento: ci siamo resi conto che la nostra passione era creare strumenti pragmatici in grado di risolvere i problemi quotidiani dei nostri utenti.

Sulla base dell'esperienza degli errori passati, abbiamo iniziato a sviluppare Helm 2.

Realizzare il timone 2

Alla fine del 2015, il team di Google ci ha contattato. Stavano lavorando su uno strumento simile per Kubernetes. Deployment Manager per Kubernetes era un port di uno strumento esistente utilizzato per Google Cloud Platform. “Vorremmo”, hanno chiesto, “passare qualche giorno a discutere le somiglianze e le differenze?”

Nel gennaio 2016, i team Helm e Deployment Manager si sono incontrati a Seattle per uno scambio di idee. Le trattative si sono concluse con un piano ambizioso: unire i due progetti per creare Helm 2. Insieme a Deis e Google, i ragazzi di SkippBox (ora parte di Bitnami - trad. ca.)e abbiamo iniziato a lavorare su Helm 2.

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

modelli di grafici per la personalizzazione;
gestione intra-cluster per i team;
repository di carte di livello mondiale;
formato del pacchetto stabile con opzione di firma;
un forte impegno nel controllo delle versioni semantico e nel mantenimento della compatibilità con le versioni precedenti tra le versioni.

Per raggiungere questi obiettivi, è stato aggiunto un secondo elemento all'ecosistema Helm. Questo componente intra-cluster si chiamava Tiller ed era responsabile dell'installazione dei grafici Helm e della loro gestione.

Dal rilascio di Helm 2 nel 2016, Kubernetes ha aggiunto diverse importanti innovazioni. Aggiunto controllo degli accessi basato sui ruoli (RBAC), che alla fine ha sostituito il controllo dell'accesso basato sugli attributi (ABAC). Sono stati introdotti nuovi tipi di risorse (all'epoca le distribuzioni erano ancora in versione beta). Sono state inventate le definizioni di risorse personalizzate (originariamente chiamate risorse di terze parti o TPR). E, cosa più importante, è emersa una serie di migliori pratiche.

Nonostante tutti questi cambiamenti, Helm ha continuato a servire fedelmente gli utenti Kubernetes. Dopo tre anni e molte nuove aggiunte, era chiaro che era giunto il momento di apportare modifiche significative al codice base per garantire che Helm potesse continuare a soddisfare le crescenti esigenze di un ecosistema in evoluzione.

Un tenero addio a Tiller

Durante lo sviluppo di Helm 2, abbiamo introdotto Tiller come parte della nostra integrazione con Deployment Manager di Google. Tiller ha svolto un ruolo importante per i team che lavorano all'interno di un cluster comune: ha consentito a diversi specialisti che gestiscono l'infrastruttura di interagire con lo stesso insieme di versioni.

Poiché il controllo degli accessi basato sui ruoli (RBAC) era abilitato per impostazione predefinita in Kubernetes 1.6, lavorare con Tiller in produzione è diventato più difficile. A causa dell’enorme numero di possibili politiche di sicurezza, la nostra posizione è stata quella di offrire una configurazione permissiva per impostazione predefinita. Ciò ha consentito ai neofiti di sperimentare Helm e Kubernetes senza dover prima immergersi nelle impostazioni di sicurezza. Sfortunatamente, questa configurazione dei permessi potrebbe fornire all'utente una gamma troppo ampia di permessi di cui non ha bisogno. Gli ingegneri DevOps e SRE hanno dovuto apprendere ulteriori passaggi operativi durante l'installazione di Tiller in un cluster multi-tenant.

Dopo aver appreso come la community utilizzava Helm in situazioni specifiche, ci siamo resi conto che il sistema di gestione dei rilasci di Tiller non aveva bisogno di fare affidamento su un componente intra-cluster per mantenere lo stato o funzionare come hub centrale per le informazioni sui rilasci. Invece, potremmo semplicemente ricevere informazioni dal server API Kubernetes, generare un grafico sul lato client e archiviare un record dell'installazione in Kubernetes.

L'obiettivo principale di Tiller avrebbe potuto essere raggiunto senza Tiller, quindi una delle nostre prime decisioni riguardo Helm 3 è stata quella di abbandonare completamente Tiller.

Con la scomparsa di Tiller, il modello di sicurezza di Helm è stato radicalmente semplificato. Helm 3 ora supporta tutti i moderni metodi di sicurezza, identità e autorizzazione dell'attuale Kubernetes. Le autorizzazioni del timone vengono determinate utilizzando file kubeconfig. Gli amministratori del cluster possono limitare i diritti utente a qualsiasi livello di granularità. Le versioni vengono comunque salvate all'interno del cluster e il resto delle funzionalità di Helm rimane intatto.

Repository di grafici

Ad alto livello, un repository di grafici è un luogo in cui i grafici possono essere archiviati e condivisi. Il client Helm crea pacchetti e invia i grafici al repository. In poche parole, un repository di grafici è un server HTTP primitivo con un file index.yaml e alcuni grafici impacchettati.

Anche se il fatto che l'API Charts Repository soddisfi la maggior parte dei requisiti di archiviazione di base presenta alcuni vantaggi, presenta anche alcuni svantaggi:

I repository di grafici non sono compatibili con la maggior parte delle implementazioni di sicurezza richieste in un ambiente di produzione. Disporre di un'API standard per l'autenticazione e l'autorizzazione è estremamente importante negli scenari di produzione.
Gli strumenti di provenienza delle carte di Helm, utilizzati per firmare, verificare l'integrità e la provenienza di una carta, sono una parte facoltativa del processo di pubblicazione delle carte.
Negli scenari multiutente, lo stesso grafico può essere caricato da un altro utente, raddoppiando la quantità di spazio necessaria per archiviare lo stesso contenuto. Sono stati sviluppati repository più intelligenti per risolvere questo problema, ma non fanno parte delle specifiche formali.
L'utilizzo di un unico file di indice per la ricerca, l'archiviazione di metadati e il recupero di grafici ha reso difficile lo sviluppo di implementazioni multiutente sicure.

Progetto Distribuzione Docker (noto anche come Docker Registry v2) è il successore di Docker Registry e funge essenzialmente da insieme di strumenti per il confezionamento, la spedizione, l'archiviazione e la distribuzione di immagini Docker. Molti servizi cloud di grandi dimensioni offrono prodotti basati sulla distribuzione. Grazie a questa maggiore attenzione, il progetto Distribution ha beneficiato di anni di miglioramenti, migliori pratiche di sicurezza e test sul campo che lo hanno reso uno degli eroi non celebrati di maggior successo del mondo Open Source.

Ma sapevi che il Distribution Project è stato progettato per distribuire qualsiasi forma di contenuto, non solo immagini contenitore?

Grazie agli sforzi Iniziativa container aperti Open (o OCI), i grafici Helm possono essere posizionati su qualsiasi istanza di distribuzione. Per ora, questo processo è sperimentale. Il supporto per l'accesso e altre funzionalità necessarie per un Helm 3 completo sono ancora in fase di elaborazione, ma siamo entusiasti di imparare dalle scoperte che i team OCI e Distribuzione hanno fatto nel corso degli anni. E attraverso il loro tutoraggio e guida, impariamo cosa vuol dire gestire un servizio altamente disponibile su larga scala.

È disponibile una descrizione più dettagliata di alcune modifiche imminenti ai repository dei grafici Helm collegamento.

Gestione dei rilasci

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

oggetto di rilascio: rappresenta un'istanza dell'applicazione;
segreto della versione di rilascio: 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 rilascio e un segreto della versione di rilascio. Chiamata helm upgrade richiede un oggetto di rilascio (che può modificare) e crea un nuovo segreto della versione di rilascio contenente i nuovi valori e un manifest preparato.

L'oggetto di rilascio contiene informazioni sul rilascio, dove rilascio è un'installazione specifica di un grafico e di valori denominati. Questo oggetto descrive i metadati di livello superiore relativi alla versione. L'oggetto di rilascio persiste per tutto il ciclo di vita dell'applicazione ed è il proprietario di tutti i segreti della versione di rilascio, nonché di tutti gli oggetti creati direttamente dal grafico Helm.

Il segreto della versione del rilascio associa un rilascio a una serie di revisioni (installazione, aggiornamenti, rollback, cancellazione).

In Helm 2, le revisioni erano estremamente coerenti. Chiamata helm install creato v1, il successivo aggiornamento (upgrade) - v2 e così via. Il rilascio e il segreto della versione di rilascio sono stati compressi in un unico oggetto noto come revisione. Le revisioni venivano archiviate nello stesso spazio dei nomi di Tiller, il che significava che ogni versione era "globale" in termini di spazio dei nomi; di conseguenza, è possibile utilizzare solo un'istanza del nome.

In Helm 3, ogni versione è associata a uno o più segreti della versione di rilascio. L'oggetto di rilascio descrive sempre la versione corrente distribuita su Kubernetes. Ogni segreto della versione di rilascio descrive solo una versione di quella versione. Un aggiornamento, ad esempio, creerà un segreto della nuova versione di rilascio e quindi modificherà l'oggetto di rilascio in modo che punti a quella nuova versione. In caso di rollback, è possibile utilizzare i segreti della versione del rilascio precedente per riportare il rilascio a uno stato precedente.

Dopo che Tiller viene abbandonato, Helm 3 archivia i dati della versione nello stesso spazio dei nomi della versione. Questa modifica consente di installare un grafico con lo stesso nome di versione in uno spazio dei nomi diverso e i dati vengono salvati tra gli aggiornamenti/riavvii del cluster in etcd. Ad esempio, puoi installare WordPress nello spazio dei nomi "foo" e poi nello spazio dei nomi "bar", ed entrambe le versioni possono essere denominate "wordpress".

Modifiche alle dipendenze del grafico

Grafici compressi (utilizzando helm package) da utilizzare con Helm 2 può essere installato con Helm 3, tuttavia il flusso di lavoro di sviluppo dei grafici è stato completamente revisionato, quindi è necessario apportare alcune modifiche per continuare lo sviluppo dei grafici con Helm 3. In particolare, è cambiato il sistema di gestione delle dipendenze dei grafici.

Il sistema di gestione delle dipendenze del grafico è passato da requirements.yaml и requirements.lock su Chart.yaml и Chart.lock. Ciò significa che i grafici che hanno utilizzato il comando helm dependency, richiedono alcune configurazioni per funzionare in Helm 3.

Diamo un'occhiata a un esempio. Aggiungiamo una dipendenza al grafico in Helm 2 e vediamo cosa cambia quando si passa a Helm 3.

Nel timone 2 requirements.yaml assomigliava a questo:

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 si rifletterà nel tuo Chart.yaml:

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

I grafici vengono comunque scaricati e inseriti nella directory charts/, quindi grafici secondari (sottografici), giacente nel catalogo charts/, continuerà a funzionare senza modifiche.

Presentazione dei grafici della biblioteca

Helm 3 supporta una classe di grafici denominata grafici di libreria (schema della biblioteca). Questo grafico viene utilizzato da altri grafici, ma non crea autonomamente alcun artefatto di rilascio. I modelli di grafici della libreria possono dichiarare solo elementi define. Altri contenuti vengono semplicemente ignorati. Ciò consente agli utenti di riutilizzare e condividere frammenti di codice che possono essere utilizzati su più grafici, evitando così duplicazioni e aderendo al principio ASCIUTTO.

I grafici della libreria sono dichiarati nella sezione dependencies in archivio Chart.yaml. Installarli e gestirli non è diverso dagli altri grafici.

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

Siamo entusiasti dei casi d'uso che questo componente aprirà agli sviluppatori di grafici, nonché delle migliori pratiche che possono emergere dai grafici della libreria.

Quali sono le prospettive?

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

Non appena verrà rilasciata la versione alpha (ricordate che questo è è già successo - ca. trad.), inizieremo ad accettare le patch per Helm 3 dalla community. È necessario creare una base solida che consenta lo sviluppo e l'adozione di nuove funzionalità e che gli utenti si sentano coinvolti nel processo aprendo ticket e apportando correzioni.

Ho provato a evidenziare alcuni dei principali miglioramenti introdotti in Helm 3, ma questo elenco non è affatto esaustivo. La roadmap completa per Helm 3 include funzionalità come strategie di aggiornamento migliorate, integrazione più profonda con i registri OCI e l'uso di schemi JSON per convalidare i valori dei grafici. Abbiamo anche in programma di ripulire il codice base e di aggiornarne le parti che sono state trascurate negli ultimi tre anni.

Se ritieni che ci sia sfuggito qualcosa, ci piacerebbe sentire i tuoi pensieri!

Partecipa alla discussione sul nostro Canali lenti:

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

Puoi anche chattare durante le nostre chiamate settimanali agli sviluppatori pubblici il giovedì alle 19:30 MSK. Le riunioni sono dedicate alla discussione delle questioni su cui stanno lavorando gli sviluppatori chiave e la comunità, nonché agli argomenti di discussione della settimana. Chiunque può iscriversi e prendere parte all'incontro. Link disponibile nel canale Slack #helm-dev.

Presentazione di Helm 3