Cosa è Kubernetes Helm

Cosa è Kubernetes Helm

La gestione dei pacchetti non è un concetto nuovo. In Linux, gestori di pacchetti come YUM, RPM o APT sono essenziali per installare e rimuovere pacchetti. Gli sviluppatori di Node.js si affidano molto a NPM, il Node Package Manager (NPM), che ha migliaia di pacchetti che possono fare praticamente qualsiasi cosa in un ambiente Node.js.

Helm è un gestore di pacchetti per Kubernetes che consente di automatizzare i manifesti YAML per gli oggetti Kubernetes, impacchettando le informazioni in grafici e distribuendole in un cluster Kubernetes. Tiene traccia della cronologia delle versioni di ogni installazione e modifica del grafico, consentendo di utilizzare semplici comandi per eseguire il rollback a una versione precedente o l’aggiornamento a una più recente. Semplifica inoltre l’installazione di applicazioni popolari su Kubernetes tramite grafici Helm condivisi dalla community.

Possiamo sfruttare Helm per distribuire e testare più facilmente un ambiente, aumentando la produttività e riducendo il tempo necessario per passare dal test alla produzione. Inoltre, Helm può aiutarci a semplificare e automatizzare il processo di invio delle applicazioni agli utenti finali per l’installazione.

Approfondiamo di seguito l’architettura di Kubernetes .

Come funziona Helm?
Helm funziona definendo e gestendo grafici, che sono pacchetti di risorse Kubernetes preconfigurate. Quando un grafico viene distribuito, Helm comunica con l’API Kubernetes per creare e gestire le risorse definite all’interno del cluster. Un file denominato “values.yaml” fornisce le variabili necessarie per distribuire correttamente risorse specifiche.

[questa è un’immagine protetta da copyright, non usarla così com’è. Ti consigliamo di ricostruirla con il tuo grafico. Cambia il testo come segue:

Cos’è Helm Chart?
Un Helm Chart è una raccolta di file che descrivono un set correlato di risorse Kubernetes. Ciò include:

• chart.yaml: contiene metadati sul grafico, come nome, versione e descrizione.
• values.yaml: specifica i valori di configurazione predefiniti per il grafico.
• cartella templates: una directory contenente i template delle risorse Kubernetes. Questi vengono elaborati utilizzando i valori specificati in values.yaml per generare i file di configurazione YAML finali.
• Cartella grafici: una directory contenente dipendenze, ovvero altri grafici su cui si basa questo grafico.
• README.md: fornisce una panoramica e istruzioni per l’uso del grafico.

Confezionando i manifest di Kubernetes in un chart, Helm semplifica l’implementazione e la gestione delle applicazioni. I grafici possono essere condivisi e riutilizzati, promuovendo la coerenza e riducendo la duplicazione degli sforzi.

Che cos’è un Helm Chart repository?
Un repository di Helm chart è una raccolta di chart Helm che vengono resi disponibili per l’installazione. Questi repository possono essere pubblici o privati ​​e sono spesso ospitati su piattaforme come GitHub o servizi di repository Helm dedicati.

I repository sono definiti da un file index.yaml, che elenca i grafici disponibili e le loro versioni. Gli utenti possono aggiungere repository al loro client Helm usando il comando helm repo add e quindi installare i grafici da questi repository con helm install. I repository pubblici, come Helm stable e Helm incubator, forniscono accesso a un’ampia gamma di grafici gestiti dalla community per applicazioni e servizi popolari.

Architettura e componenti Helm
Client Helm
Il client Helm è l’interfaccia utente principale per Helm. Fornisce l’interfaccia a riga di comando (CLI) utilizzata per eseguire comandi Helm, come l’installazione, l’aggiornamento o il rollback dei grafici. Il client Helm interagisce con la libreria Helm per elaborare i grafici e gestire le release. Comunica inoltre con il server API Kubernetes per distribuire e gestire le risorse nel cluster.

Libreria Helm
La libreria Helm contiene la logica di base per Helm. Gestisce il rendering dei template, la gestione delle release e la comunicazione con l’API Kubernetes. La libreria Helm è responsabile delle seguenti attività:

• Modelli di rendering: elabora i modelli nel grafico utilizzando i valori forniti in values.yaml per generare i manifesti Kubernetes finali.
• Gestione delle versioni: tiene traccia dello stato di ogni distribuzione, consentendo agli utenti di aggiornare, ripristinare o disinstallare i grafici mantenendo la cronologia delle versioni.
• Interfaccia con Kubernetes: invia i manifesti generati al server API di Kubernetes per creare o aggiornare le risorse nel cluster.

Helm vs Operatori Kubernetes
Ad alto livello, i chart Helm e gli operatori Kubernetes fanno quasi la stessa cosa, ma l’adozione varia in base a diversi criteri, come l’adozione del cluster, la maturità del team e i requisiti dell’applicazione.

Come vengono utilizzate i chart Helm?

Per i team che stanno appena iniziando a gestire cluster Kubernetes e vogliono fornire applicazioni semplici ai propri utenti, impacchettare queste applicazioni con grafici Helm ha il vantaggio di semplificare i manifesti YAML dei template. I chart Helm consentono ai team delle operazioni IT di distribuire rapidamente le applicazioni impacchettandole, creando versioni e condividendole, insieme alle loro dipendenze.

Per creare grafici Helm, è necessario avere familiarità con YAML e utilizzare il motore di template https://innovaformazione.net/corso/corso-go-golang/Go e la libreria di template Sprig.

I chart Helm sono spesso più utili quando si imposta per la prima volta un cluster Kubernetes per distribuire un’applicazione semplice. Possono gestire l’intero ciclo di vita di installazione, aggiornamento e disinstallazione delle applicazioni distribuite su un cluster.

Come vengono utilizzati gli operatori?

Man mano che il nostro team e ilnostro utilizzo dei cluster Kubernetes maturano, potremmo dover affrontare attività quotidiane e requisiti complessi per eseguire le nostre applicazioni. È qui che il team delle operazioni IT deve aggiungere operatori Kubernetes al mix. Scrivere operatori Kubernetes significa anche che il team deve manutunere questa base di codice nel tempo.

Gli operatori sono utili per i team che implementano configurazioni personalizzate complesse o distribuiscono applicazioni specializzate che richiedono notevoli competenze operative.

Tutorial rapido: Introduzione a Kubernetes Helm
Per installare Helm sulla nostra macchina locale, dovremo scaricare il binario Helm e aggiungerlo al nostro PATH. Il modo più semplice per farlo è usare lo script di installazione Helm:

1.Scarica lo script di installazione di Helm:

curl -fsSL -o get_helm.sh
https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3

2.Rendere eseguibile lo script:

chmod +x get_helm.sh

3.Esegui lo script per installare Helm:

./get_helm.sh

Questo installerà Helm e lo aggiungerà al tuo PATH. Possiamo quindi usare il comando helm per interagire con il nostro cluster.

Per installare un chart usando Helm, dovremo prima aggiungere un repository di chart. Un repository di chart è una raccolta di grafici da cui puoi effettuare l’installazione. Puoi aggiungere il repository di grafici Helm ufficiale eseguendo:

helm repo add chartmuseum http://localhost:8080

Questo aggiungerà il repository di grafici “stable” al tuo elenco di repository. Puoi quindi cercare grafici in questo repository eseguendo:

helm search repo stable

Questo elencherà tutti i grafici disponibili nel repository stabile. Per installare un chart, usiamo il comando helm install e specifichiamo il nome del chart e il nome della release (un nome univoco per questa istanza del grafico):

helm install myrelease stable/mysql

Questo installerà il grafico MySQL e creerà un’istanza dell’applicazione denominata “myrelease”. Helm si occuperà di creare tutte le risorse Kubernetes necessarie e di distribuire l’applicazione sul tuo cluster.

È anche possibile installare un grafico da una directory locale utilizzando il helm installcomando e specificando il percorso della directory del grafico:

helm install chartmuseum/mychart --generate-name

Questo installerà il grafico dalla directory locale e creerà un’istanza dell’applicazione denominata myrelease.

Limitazioni delle Helm Chart
Come ogni nuovo strumento, Helm ha una curva di apprendimento. Creare e distribuire il proprio primo Helm chart non è facile. I chart creano anche codice aggiuntivo che deve essere gestito e maneggiato. Ciò include il sovraccarico di gestione, manutenzione e archiviazione dei repository dei grafici Helm. Per distribuzioni semplici, Helm potrebbe essere eccessivo.

È ovviamente possibile utilizzare chart Helm gestiti da altri. Ma dobbiamo essere sicuri che questi chart Helm siano ben testati e contengano solo componenti sicuri, senza vulnerabilità di sicurezza.

Tieniamo presente che le applicazioni che utilizzano numerose risorse Kubernetes possono risultare difficili da risolvere tramite Helm, perché la visibilità sui singoli componenti è ridotta.

5 best practice per Kubernetes Helm
Comprendere le funzioni template
Helm modella i file di risorse usando i template Go. Go fornisce diverse funzioni integrate, ma possiamo aggiungerne altre. Ad esempio, possiamo aggiungere le funzioni dalla libreria Sprig (anche se dovremo evitare expandenv ed except env per motivi di sicurezza). Altre funzioni utili sono required e include, che ci consentono di importare un altro template e inoltrare i risultati a un’altra funzione template.

Ad esempio, il seguente frammento di modello utilizza la includefunzione per importare il extpl modello, convertire il risultato in maiuscolo e racchiuderlo tra virgolette doppie.

value: {{ include "extpl" . | upper | quote }}

Possiamo usare la funzione required per dichiarare voci di valore specifiche necessarie per il rendering del modello. Il rendering del modello fallisce se il valore è vuoto.

Ad esempio, la seguente funzione required fornisce una voce per l’ .Values.who elemento e stampa un messaggio di errore se la voce richiesta è mancante:

value: {{ required "A valid .Values.who entry required!" .Values.who }}

Assicuriamoci che i tipi siano chiari
YAML ha regole di coercizione dei tipi che possono essere controintuitive. Ad esempio, c’è una differenza tra foo: false e foo: “false”. In alcuni casi, gli interi grandi vengono convertiti in notazioni scientifiche.

Il modo più semplice per prevenire errori di conversione di tipo è rendere esplicite le stringhe mentre gli altri elementi rimangono impliciti, ovvero racchiudere tra virgolette ogni stringa.

Spesso è utile memorizzare gli interi come stringhe per evitare problemi di cast di interi: utilizzare l’ {{ int $value }} elemento nel modello per convertire le stringhe di nuovo in interi. Di solito, il sistema rispetterà i tag di tipo espliciti, ovvero foo: !!string 3287 tratterà 3287 come una stringa. Tuttavia, il parser YAML consumerà il tag, il che significa che si perdono i dati di tipo dopo una singola analisi.

Individuare le risorse facilmente con le etichette
Le etichette sono importanti per le operazioni interne di Kubernetes: quasi tutte le risorse Kubernetes offrono etichette per scopi specifici come raggruppamento, bilanciamento del carico, allocazione delle risorse e pianificazione.

Possiamo usare un comando Helm per installare diverse risorse, ma devi sapere da dove proviene ogni risorsa. Le etichette ti consentono di trovare rapidamente le risorse create da una release Helm.

Il modo più comune per definire le etichette è nell’elemento helpers.tpl:

{{/*

Le mie etichette

*/}}

{{- definisci "mie.etichette" -}}

app.kubernetes.io/istanza: {{ .Release.Name }}

app.kubernetes.io/gestito-da: {{ .Release.Service }}

{{- FINE -}}

È quindi necessario utilizzare la funzione include per le etichette in ogni modello di risorsa:

apiVersion: apps/v1

tipo: Distribuzione

metadati:

nome: la-mia-coda

etichette:

{{ include "my.labels" . | rientro 4 }}

Ora possiamo elencare tutte le risorse usando i selettori di etichetta. Ad esempio, puoi usare il seguente comando per elencare tutti i pod nella distribuzione my-queue:

kubectl get pods -l app.kubernetes.io/instance=[Helm Release]

Questo passaggio consente di individuare ed eseguire il debug delle risorse gestite da Helm.

Mantenere le password al sicuro
Kubernetes memorizza dati sensibili come password e chiavi come segreti. Mentre puoi proteggere i segreti dal lato di Kubernetes, è più comune memorizzarli come file di testo in modelli e valori Helm.

Il helm-secretsplugin può gestire e proteggere segreti e dati critici. Mozilla SOPS gestirà la crittografia segreta, supportando AWS KMS, PGP, Cloud KMS su GCP e Azure

Il plugin helm-secrets può essere installato utilizzando il seguente comando:

helm plugin install https://github.com/jkroepke/helm-secrets

Oppure una versione specifica

helm plugin install https://github.com/jkroepke/helm-secrets --version v4.1.1

Segretare le chiavi.

Supponiamo di mettere tutti i dati sensibili in un file chiamato secrets.yaml:

postgresql:

postgresqlNome utente: postgres

Password postgresql: ZoWpBAlCsg

database postgresql: wp

Possiamo utilizzare il plugin per crittografare il nostro file:

$ helm secrets enc secrets.yaml

Encrypting secrets.yaml

Encrypted secrets.yaml

Quindi aggiornerà e crittograferà tutti i valori:

postgresql:

    postgresqlUsername: ENC\[AES256\_GCM,data:D14/CcA3WjY=,iv...==,type:str\]

    postgresqlPassword: ENC\[AES256\_GCM,data:Wd7VEKSoqV...,type:str\]

    postgresqlDatabase: ENC\[AES256\_GCM,data:8ur9pqDxUA==,iv:R...,type:str\]

sops:

  ...

I dati nello YAML sopra riportato non sono sicuri, ma l’elemento helm-secrets consente di memorizzare informazioni sensibili nei grafici Helm.

Utilizzare i comandi per eseguire il debug dei grafici Helm
I file modello Helm offrono molte funzioni e fonti di valori per creare risorse Kubernetes. Gli utenti devono sapere quali risorse sono distribuite nel loro cluster. Pertanto, dovremo imparare a verificare i grafici Helm e a eseguire il debug dei modelli.

Per il debug è possibile utilizzare questi quattro comandi chiave:

• helm lint: lo strumento linter eseguirà diversi test per garantire che il grafico sia formato correttamente.
• helm install –dry-run –debug :questa funzione esegue il rendering del template per mostrare i manifesti delle risorse. Possiamo controllare tutte le risorse prima di distribuirle per assicurarti che siano impostati i valori corretti e che le funzioni del template funzionino come previsto.
• helm get manifest : questo comando recupererà i manifest di tutte le risorse installate nel cluster. È il primo comando che dovremo usare se la release non funziona come previsto, poiché ti mostra cosa è in esecuzione nel tuo cluster.
• helm get values ​​: questo comando recupera i valori delle release installate nel cluster. È utile se non si è sicuri di alcun valore predefinito o calcolato.

Creare una Helm Dashboard
Helm Dashboard è un progetto open source che offre un modo basato sull’interfaccia utente per visualizzare i grafici Helm installati, vedere la cronologia delle revisioni e le risorse k8s corrispondenti. Consente inoltre agli utenti di eseguire semplici azioni come il rollback a una revisione o l’aggiornamento a una versione più recente. È importante notare che Helm Dashboard NON è un progetto ufficiale del team helm .

Principali funzionalità dello strumento:

• Visualizzare tutti i grafici installati e la cronologia delle revisioni
• Vedere la differenza manifesta delle revisioni passate
• Sfogliare le risorse di k8s risultanti dal grafico
• Versione di rollback o aggiornamento facile con una chiara e semplice differenza di manifesto
• Integrazione con i più diffusi scanner di problemi
• Facile passaggio tra più cluster
• Può essere utilizzato localmente o installato nel cluster Kubernetes
• Non richiede l’installazione di Helm o Kubectl

(fonte)

Innovaformazione, scuola informatica specialistica promuove l’utilizzo di Kubernetes in maniera consapevole ed organizza formazione per aziende IT. Trovate il Corso Kubernetes Fundamental ed altri Corsi Microservices.

INFO: info@innovaformazione.net – Tel. 3471012275 (Dario Carrassi)