Helm: gestire in maniera semplice ed efficace i pod Kubernetes
Imparare a editare un file YAML per Kubernetes può essere un’attività talvolta stressante, soprattutto se deve essere svolta per configurare in tempi brevi un sistema a microservizi per un’applicazione già esistente.
Non disperate, una soluzione esiste e ha un nome: Helm, un framework molto utile per la gestione di pod Kubernetes.
Cos’è Helm?
Helm è un’applicazione utilizzabile da riga di comando per lavorare con i “chart“, che di fatto sono descrizioni di risorse Kubernetes.
Questo piccolo ma potente tool permette non solo di generare uno scheletro per un’applicazione generica ma possiede anche tante funzionalità interessanti. Ne cito giusto qualcuna:
- Repository con chart già completi: Usando il comando
helm search hub
seguito per esempio dalla parolawordpress
si potranno trovare numerosi chart per usare questo sistema di blogging su Kubernetes. - Sistema di release: È possibile con pochi comandi recuperare versioni di chart installati che permettono anche un eventuale rollback.
- Gestione ad-hoc per file YAML: Helm sfrutta una logica per parametrizzare ogni YAML anche in maniera complessa per qualunque evenienza di progetto. Si può facilmente ottenere un file YAML di configurazione per ogni ambiente o creare degli array di dati da inserire automaticamente nella configurazione (e molto altro ancora).
Come si installa Helm?
È molto semplice, dalla pagina Releases del progetto GitHub si scarica lo zip/tar adatto per il sistema operativo, lo si scompatta e si salva il file .exe nelle variabili d’ambiente (esattamente come si farebbe per la configurazione di Java).
Come si utilizza Helm?
Guardiamo insieme qualche comando Helm e il suo effetto.
Creazione di un chart
Eseguendo il comando helm create hello
si crea un nuovo chart con la seguente alberatura:
Il primo impatto può risultare sconcertante ma se avete un minimo di conoscenza di Kubernetes noterete poche differenze, ovvero qualche file di troppo:
_helpers.tpl
, un insieme di funzioni di aiuto.Values.yaml
, contenente vari parametri di default. Questo file può essere duplicato e passato come input ai comandi che mostrerò più avanti. Diversi file di questo tipo permettono di dividere le configurazioni su vari ambienti.Chart.yaml
, contenente parametri da considerare più come un classico file “Readme”. Questo file che viene modificato solo per aggiornare la versione del progetto.- La cartella
charts
, dove possono essere inseriti altri chart e quindi altri microservizi con i rispettivi file di configurazione. Da questo livello si può addirittura rieseguire il comandohelm create
.
Per farvi comprendere la semplicità di Helm apriamo il file Values.yaml
e modifichiamo il contenuto della riga repository
come segue:
image: repository: tutum/hello-world pullPolicy: IfNotPresent # Override the image tag whose default is the chart appVersion. tag: "latest"
Procediamo ora con l’installazione del chart.
Installazione di un pod e visualizzazione
Il comando helm install
è composto da due parametri obbligatori: il nome della release e il nome del chart.
Per il nostro esempio il nome della release è libero (io per esempio utilizzerò i3tips
), mentre il nome del chart deve coincidere con lo stesso nome scelto in fase di creazione (se non lo ricordate coincide con il nome della directory padre).
Il comando da scrivere sarà helm install i3tips hello
che genererà il seguente log:
Et voilà, abbiamo finito! Il nostro pod è pronto e funzionante.
Eseguendo il comando kubectl describe pods
sarà possibile visualizzare le informazioni del vostro pod e perché no connettervi con l’utilizzo di una shell.
Proviamo ora a spingerci un po’ più in là e tentiamo di aggiornare il nostro pod.
Aggiornamento di un pod con Helm
Aggiorniamo il precedente repository come segue:
image: repository: alpine pullPolicy: IfNotPresent # Override the image tag whose default is the chart appVersion. tag: "latest"
Eseguiamo ora il comando helm upgrade i3tips hello
e osserviamo l’output:
Sfortunatamente abbiamo “rotto” il nostro pod, ma niente panico. Tramite Helm potremo analizzare bene la situazione:
Il container attivo è il container in attesa di essere aggiornato, mentre quello arancione con i 2 tentativi di “Restarts” è il pod nuovo (il nostro deployment dice che deve servire la porta 80 ma alpine da solo non può servire nulla).
Rollback di un pod con Helm
Eseguendo il comando helm rollback i3tips 1
riporteremo il pod alla precedente revisione.
Modifichiamo ora il nostro file deployment come segue:
containers: - name: {{ .Chart.Name }} securityContext: {{- toYaml -Values.securityContext | nindent 12 }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}" imagePullPolicy: {{ .Values.image.pullPolicy }} command: ['sleep', 'infinity'] resources: {{- toYaml .Values.resources | nindent 12 }} {{- with .Values.nodeSelector }} nodeSelector: {{ - toYaml . | nindent 8 }} {{ - end }} {{- with .Values.affinity }} affinity: {{- toYaml . | nindent 8 }} {{ - end }} {{- with .Values.tolerations }}
Brevemente, in questa configurazione abbiamo eliminato i settaggi per ports
, livenessProbe
, readinessProbe
e aggiunto un comando per mantenere il pod online.
Vedere la storia di un pod con Helm
Eseguendo il comando helm history i3tips
otterremo l’elenco di tutte le revisioni di un pod:
Per recuperare una versione specifica del pod, basta eseguire il comando di rollback
specificando il numero della versione come ultimo parametro del comando appunto.
Prima di salutarci, vediamo come eliminare un pod.
Eliminazione di un pod con Helm
Tramite l’esecuzione del comando helm uninstall i3tips
i pod creati verranno eliminati. La riprova l’avrete eseguendo nuovamente il comando di history
che non sarà più in grado di estrarre nulla per il pod specificato con il nome i3tips
.