🥇Introduzione a Helm 3

Nota del traduttore.: il 16 maggio di quest'anno segna una tappa significativa nello sviluppo del gestore di pacchetti per Kubernetes: Helm. In questo giorno è stata presentata la prima versione alpha della prossima grande versione del progetto — 3.0. Il suo rilascio porterà cambiamenti sostanziali e tanto attesi in Helm, su cui molti nel community di Kubernetes nutrono grandi speranze. Noi stessi facciamo parte di questi poiché utilizziamo attivamente Helm per il deployment delle applicazioni: lo abbiamo integrato nel nostro strumento per l'implementazione del CI/CD. werf E di volta in volta contribuiamo nello sviluppo upstream. Questa traduzione raccoglie 7 note dal blog ufficiale di Helm, in occasione del primo rilascio alpha di Helm 3, che raccontano la storia del progetto e le principali caratteristiche di Helm 3. L'autore è Matt «bacongobbler» Fisher, dipendente di Microsoft e uno dei principali manutentori di Helm.

Il progetto ora conosciuto come Helm è nato il 15 ottobre 2015. Solo un anno dopo la sua creazione, la community di Helm si è unita a Kubernetes, lavorando attivamente su Helm 2. A giugno 2018, Helm è entrato a far parte della CNCF come progetto in incubazione. Voltiamo lo sguardo 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 articolo parlerò di come è iniziata la storia, come siamo arrivati all'attuale stadio, presenterò alcune caratteristiche uniche disponibili nella prima alpha release di Helm 3 e spiegherò come intendiamo svilupparci in futuro.

Sintesi:

la storia di Helm;
un addio affettuoso a Tiller;
repository dei chart;
gestione delle release;
modifiche alle dipendenze dei chart;
library charts;
E poi?

La storia di Helm

Nascita

Helm 1 è nato come progetto Open Source creato da 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.

A metà del 2015 abbiamo deciso di cambiare rotta e abbiamo migrato Deis (all'epoca rinominato Deis Workflow) da Fleet a Kubernetes. Tra i primi strumenti a essere riprogettato, c'era quello dell'installazione. deisctlLo abbiamo utilizzato per l'installazione e la gestione di Deis Workflow in un cluster Fleet.

Helm 1 è stato creato sulla falsariga di noti gestori di pacchetti, come Homebrew, apt e yum. Il suo obiettivo principale era semplificare compiti come il pacchettizzazione e l'installazione di applicazioni in Kubernetes. Helm è stato ufficialmente presentato nel 2015 alla conferenza KubeCon a San Francisco.

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

* Nota del traduttore.: Con la prima versione di Helm è stato scelto il sintassi YAML per descrivere le risorse Kubernetes, e durante la scrittura delle configurazioni venivano supportati modelli Jinja e script Python. Abbiamo discusso di più su questo e sull'architettura della prima versione di Helm nel capitolo "Breve storia di Helm". di questo materiale.

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

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

È fantastico che oggi esistano i generatori di modelli, vero?

Per molti motivi, questo primo installatore di Kubernetes richiedeva un elenco fisso di file manifest e seguiva solo una piccola sequenza di eventi. Era così difficile da usare che il team R&D di Deis Workflow ha avuto non pochi problemi quando ha cercato di migrare il proprio prodotto su questa piattaforma; tuttavia, i semi dell'idea erano già stati piantati. Il nostro primo tentativo è stato un'opportunità preziosa per apprendere: abbiamo capito di essere davvero appassionati di creare strumenti pragmatici che risolvano i problemi quotidiani dei nostri utenti.

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

Creazione di Helm 2

Alla fine del 2015, ci ha contattati il team di Google. Stavano lavorando a uno strumento simile per Kubernetes. Deployment Manager per Kubernetes era un porting di uno strumento esistente utilizzato per Google Cloud Platform. "Non vogliamo dedicarci alcuni giorni per discutere somiglianze e differenze?"

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

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

modelli di chart per la personalizzazione;
gestione intra-cluster per i team;
un repository di chart di prima classe;
un formato di pacchetto stabile con supporto per la firma;
un forte impegno per il versioning semantico e il mantenimento della compatibilità retroattiva tra le versioni.

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

Dalla sua uscita, Helm 2 ha visto Kubernetes crescere con importanti innovazioni. È stata introdotta la gestione degli accessi basata sui ruoli (RBAC), che alla fine ha sostituito il controllo accessi basato su attributi (ABAC). Sono stati introdotti nuovi tipi di risorse (i Deployments erano ancora in fase beta). Sono state inventate le Custom Resource Definitions (inizialmente chiamate Third Party Resources o TPR). E soprattutto, è emerso un insieme di best practices.

Nel contesto di tutti questi cambiamenti, Helm ha continuato a servire diligentemente gli utenti di Kubernetes. Dopo tre anni e numerosi nuovi aggiornamenti, è diventato chiaro che era il momento di apportare modifiche sostanziali alla base di codice, affinché Helm potesse continuare a soddisfare le crescenti esigenze dell'ecosistema in evoluzione.

Un dolce addio a Tiller

Durante lo sviluppo di Helm 2, abbiamo presentato Tiller come parte della nostra integrazione con Deployment Manager di Google. Tiller ha svolto un ruolo cruciale per i team che lavorano su un cluster condiviso: consentiva a diversi specialisti, che gestivano l'infrastruttura, di interagire con lo stesso set di rilasci.

Dal momento che il controllo degli accessi basato sui ruoli (RBAC) è stato abilitato di default in Kubernetes 1.6, l'uso di Tiller in produzione è diventato più complesso. A causa dell'enorme numero di politiche di sicurezza possibili, la nostra posizione è stata quella di offrire una configurazione permissiva di default. Questo ha permesso ai neofiti di sperimentare con Helm e Kubernetes senza dover prima immergersi nelle impostazioni di sicurezza. Purtroppo, questa configurazione permissiva poteva conferire all'utente un intervallo di autorizzazioni troppo ampio, che non gli era necessario. Gli ingegneri DevOps e SRE dovevano apprendere ulteriori passaggi operativi per installare Tiller in un cluster multi-tenant.

Scoprendo come i membri della comunità utilizzano Helm in situazioni specifiche, ci siamo resi conto che il sistema di gestione delle release di Tiller non deve dipendere da un componente interno al cluster per mantenere stati o fungere da hub centrale per le informazioni sulla release. Invece, possiamo semplicemente ottenere informazioni dal server API di Kubernetes, generare il chart lato client e mantenere un record dell'installazione in Kubernetes.

La funzionalità principale di Tiller poteva essere realizzata anche senza di esso, quindi una delle prime decisioni che abbiamo preso riguardo Helm 3 è stata quella di eliminare completamente Tiller.

Con la scomparsa di Tiller, il modello di sicurezza di Helm si è radicalmente semplificato. Helm 3 ora supporta tutti i moderni metodi di sicurezza, identificazione e autorizzazione dell'attuale Kubernetes. Le autorizzazioni di Helm sono determinate tramite il file kubeconfig.Gli amministratori del cluster possono limitare i diritti degli utenti con qualsiasi livello di dettaglio. Le release continuano a essere mantenute all'interno del cluster, mentre il resto della funzionalità di Helm rimane.

I repository dei chart

A un livello elevato, il repository dei chart è il luogo in cui archiviare e condividere i chart. Il client Helm impacchetta e invia i chart al repository. In parole semplici, il repository dei chart è un server HTTP primitivo con un file index.yaml e alcuni chart impacchettati.

Sebbene ci siano alcuni vantaggi nel fatto che l'API del repository dei chart risponda ai requisiti fondamentali di archiviazione, presenta anche diversi svantaggi:

I repository dei chart sono poco compatibili con la maggior parte delle implementazioni di sicurezza necessarie in un ambiente di produzione. È fondamentale avere un'API standard per l'autenticazione e l'autorizzazione in scenari di produzione.
Gli strumenti di Helm per il tracciamento dell'origine del chart, utilizzati per la firma, la verifica dell'integrità e l'origine del chart, sono una parte facoltativa del processo di pubblicazione del Chart.
Nei 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 state sviluppate soluzioni di repository più intelligenti, tuttavia queste non fanno parte della specifica formale.
L'uso di un unico file indice per la ricerca, la memorizzazione dei metadati e il recupero dei chart ha complicato lo sviluppo di implementazioni multiutente sicure.

Progetto Docker Distribution (noto anche come Docker Registry v2) è il successore di Docker Registry e funge essenzialmente da insieme di strumenti per imballare, inviare, memorizzare e fornire immagini Docker. Molti grandi servizi cloud offrono prodotti basati su Distribution. Grazie a questa maggiore attenzione, il progetto Distribution ha beneficiato di anni di miglioramenti, delle migliori pratiche in materia di sicurezza e di test in condizioni "reali", diventando uno degli eroi non celebrati più di successo nel mondo dell'Open Source.

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

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

Una descrizione più dettagliata di alcune delle modifiche imminenti 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:

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

La chiamata helm install crea release object e release version secret. La chiamata helm upgrade richiede l'esistenza di un release object (che può modificare) e crea un nuovo release version secret contenente nuovi valori e un manifesto preparato.

L'oggetto di rilascio contiene informazioni sul rilascio, dove il rilascio è un'installazione specifica di un chart nominato e dei valori. Questo oggetto descrive i metadati di alto livello sul rilascio. L'oggetto di rilascio viene mantenuto per tutto il ciclo di vita dell'applicazione e funge da proprietario di tutti i segreti delle versioni di rilascio, oltre a tutti gli oggetti creati direttamente dal chart Helm.

Il segreto della versione di rilascio collega il rilascio a una serie di revisioni (installazioni, aggiornamenti, rollback, eliminazione).

In Helm 2, le revisioni erano esclusivamente sequenziali. La chiamata helm install creava v1, l'aggiornamento successivo (upgrade) - v2, e così via. Il rilascio e il segreto della versione di rilascio erano uniti in un unico oggetto, noto come revisione. Le revisioni erano memorizzate nello stesso spazio dei nomi di Tiller, il che significava che ogni rilascio era "globale" in termini di spazio dei nomi; di conseguenza, era possibile utilizzare solo un'istanza di un nome.

In Helm 3, ogni rilascio è associato a uno o più segreti di versione del rilascio. L'oggetto di rilascio descrive sempre l'attuale rilascio distribuito in Kubernetes. Ogni segreto di versione del rilascio descrive solo una versione di quel rilascio. Un aggiornamento, ad esempio, creerà un nuovo segreto di versione del rilascio e quindi modificherà l'oggetto di rilascio per puntare a questa nuova versione. In caso di rollback, è possibile utilizzare i segreti di versione del rilascio precedenti per riportare il rilascio allo stato precedente.

Dopo l'abbandono di Tiller, Helm 3 memorizza i dati sul rilascio in uno spazio dei nomi unito al rilascio. Questa modifica consente di installare un chart con lo stesso nome di rilascio in un altro spazio dei nomi, e i dati vengono mantenuti tra aggiornamenti/riavvii del cluster in etcd. Ad esempio, è possibile installare WordPress nello spazio dei nomi "foo" e poi nello spazio dei nomi "bar", e entrambi i rilasci possono chiamarsi "wordpress".

Modifiche alle dipendenze dei chart

Chart impacchettati (con helm package) per l'uso con Helm 2, è possibile installare con Helm 3, tuttavia il processo di sviluppo dei chart è stato completamente rivisto, quindi è necessario apportare alcune modifiche per continuare lo sviluppo dei chart con Helm 3. In particolare, il sistema di gestione delle dipendenze dei chart è cambiato.

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

Esaminiamo un esempio. Aggiungiamo una dipendenza al 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 vengono ancora caricati e posizionati nella directory charts/, quindi i subchart (subcharts), presenti 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 template dei library chart possono dichiarare solo elementi. definire. Altro contenuto viene semplicemente ignorato. Questo permette agli utenti di riutilizzare e condividere frammenti di codice che possono essere impiegati in molti chart, evitando così duplicazioni e seguendo il principio DRY.

I library chart sono dichiarati nella sezione dependencies nel file Chart.yaml. L'installazione e la gestione sono simili a quelle degli altri chart.

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

Siamo entusiasti delle possibilità d'uso che questo componente offrirà agli sviluppatori di chart, così come delle migliori pratiche che possono emergere grazie ai library chart.

E ora?

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 fasi iniziali di sviluppo e va bene così; l'essenza di un rilascio alpha è testare l'idea, raccogliere feedback dai primi utenti e confermare le nostre ipotesi.

Una volta che la versione alpha sarà rilasciata (ricordiamo che questo è già avvenuto — nota di traduzione), inizieremo ad accettare patch per Helm 3 dalla comunità. È necessario creare una base solida che consenta di sviluppare e accettare nuove funzionalità, e gli utenti potranno sentirsi coinvolti nel processo aprendo ticket e proponendo correzioni.

Nell'articolo ho cercato di evidenziare alcuni dei miglioramenti significativi che arriveranno con Helm 3, ma questa lista non può in alcun modo essere considerata esaustiva. Il piano completo per Helm 3 include innovazioni come strategie di aggiornamento migliorate, integrazione più profonda con i registri OCI e uso di schemi JSON per la convalida dei valori dei chart. Prevediamo anche di ripulire la base di codice e aggiornare quelle parti che sono rimaste trascurate negli ultimi tre anni.

Se pensi che ci sia qualcosa che abbiamo trascurato, saremo felici di sentire le tue opinioni!

Unisciti alla discussione nei nostri canali Slack:

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

Puoi anche partecipare alle nostre Public Developer Calls settimanali ogni giovedì alle 19:30 MSK. Gli incontri sono dedicati alla discussione delle attività su cui lavorano i principali sviluppatori e la comunità, nonché ai temi da discutere durante la settimana. Chiunque può unirsi e partecipare all'incontro. Il link è disponibile nel canale Slack. #helm-dev.