Altri Comandi Helm

Fasi di Esecuzione

Fasi di esecuzione di una installazione (o di un upgrade) di un chart di Helm:

Caricamento del chart e delle sue dipendenze
Attualizzazione dei parametri e dei valori
Esecuzione dei templati e generazione dei file di specifiche Yaml
Verifica dei dati di generazione di oggetti Kubernetes
Invio al cluster Kubernetes

Ciascuna di queste fasi può generare errori.

Se nella fase 5 il server Kubernetes accetta i files Yaml, Helm dichiara il successo dell'operazione.

Questo non vuol dire che l'applicativo sia pronto, poichè i pod possono impiegare tempo considerevole a scaricare le immagini.

Alcune opzioni di installazione aiutano:

helm install mysite bitnami/drupal \
  --wait --timeout 120

Helm compie allora ripetute queries a Kubernetes e attende che tutti i pod dell'applicativo installato siano running.

E' buona prassi includere una opzione --timeout espressa in secondi, per non attendere rventualmente per sempre. Al termine del periodo di timeout lo stato dell'installazione è failed. Questo può dare delle inconsistenze se il periodo non è abbastanza lungo.

Un'alternativa è:

helm install mysite bitnami/drupal \
  --atomic --timeout 120

E'simile a --wait ma in caso di fallimento Helm compie un rollback automatico all'ultima versione di successo.

Dry Run

helm install mysite bitnami/drupal \
  --values ~/scripts/drupal/values.yml \
  --set drupalEmail=foo@example.com \
  --dry-run

Non genera l'applicativo descritto nel chart. Non invia le specifiche al cluster Kubernetes.

Produce molte informazioni di debugging.

identificativi della release
lista di tutti i file di specifiche Yaml generati
note e istruzioni per l'utente

Anche se non viene generato l'applicativo sul cluster, un dry run può contattare il cluster più volte durante le sue fasi, e generare files di specifiche legati al particolare cluster.

Helm Template

Il comando helm template genera solo l'identificativo della release e la lista dei file di specifiche Yaml. Non contatta mai il server Kubernetes.

helm template mysite bitnami/drupal \
  --values ~/scripts/drupal/values.yml \
  --set drupalEmail=foo@example.com

Non compie validazione dei file Yaml generati.

Ha praticamente le stesse opzioni di helm install.

Release

Partendo da una situazione pulita, installiamo la prima release di drupal:

helm install mysite bitnami/drupal \
  --values ~/scripts/drupal/values.yml \
  --set drupalEmail=foo@example.com

Vengono generati dei Secrets:

kubectl get secret

NAME                           TYPE                 DATA   AGE
mysite-drupal                  Opaque               1      13s
mysite-mariadb                 Opaque               2      13s
sh.helm.release.v1.mysite.v1   helm.sh/release.v1   1      13s

Helm mantiene le informazioni di release nel secret sh.helm.release.v1.mysite.v1.

L'ultimo è il numero di versione di upgrade. Ad ogni nuovo upgrade compare un nuovo secret con versione v2, v2, ecc. Vengono mantenute al massimo 10 versioni, le più vecchie sono rimosse.

Si può ispezionare il secret di versione con:

kubectl get secret sh.helm.release.v1.mysite.v1 -o json

La sezione maggiore, data, contiene informazioni per ricreare la release, compresse e trascodificate con Base64.

Si possono estrarre queste informazioni con dei comandi.

`helm get notes`

Note finali per l'utente:

helm get notes mysite

`helm get values`

Valori parametrici della release.

Valori forniti nel comando di unstallazione o upgrade:

helm get values mysite

Tutti i valori:

helm get values mysite --all

`helm get manifest`

Tutti i file di specifiche Yaml:

helm get manifest mysite

Helm Upgrade e History

Upgrade

Compiamo un upgrade alla release.

Prepariamo le variabili d'ambiente necessarie:

export DRUPAL_PASSWORD=$(kubectl get secret \
  --namespace "default" mysite-drupal \
  -o jsonpath="{.data.drupal-password}" | base64 -d)
export MARIADB_ROOT_PASSWORD=$(kubectl get secret \
  --namespace "default" mysite-mariadb \
  -o jsonpath="{.data.mariadb-root-password}" | base64 -d)
export MARIADB_PASSWORD=$(kubectl get secret \
  --namespace "default" mysite-mariadb \
  -o jsonpath="{.data.mariadb-password}" | base64 -d)

Compiamo l'upgrade:

helm upgrade mysite bitnami/drupal --set ingress.enabled=true \
  --set drupalPassword=$DRUPAL_PASSWORD \
  --set mariadb.auth.rootPassword=$MARIADB_ROOT_PASSWORD \
  --set mariadb.auth.password=$MARIADB_PASSWORD

History

Ispezioniamo ora la storia delle release:

helm history mysite

REVISION  UPDATED                  STATUS     CHART         APP VERSION  DESCRIPTION     
1         Sun Feb 11 09:37:53 2024  superseded  drupal-17.3.4 10.2.3      Install complete
2         Sun Feb 11 10:20:18 2024  deployed    drupal-17.3.4 10.2.3      Upgrade complete

Lo status può essere:

pending-install
deployed
pending-upgrade
superseded
pending-rollback
uninstalling
uninstalled
failed

Verifichiamo i valori della release:

helm get values mysite -o json

{"drupalPassword":"dcC54IVRFH","ingress":{"enabled":true},"mariadb":{"auth":{"password":"RzY3j10Azv","rootPassword":"3CVLN2SHFV"}}}

Restart dei Pod

Un upgrade è il meno invasivo possibile: Helm richiede il restart di pods solo se ve n'è bisogno. Si può forzare il restart di tutti i pod con l'opzione --force.

Cleanup

Un'installazione o upgrade fallita può lasciare lo stato di Kubernetes inconsistente. Per esempio possono essere stati creati dei Secrets prima del fallimento.

Questo è più probabile se è stata usata l'opzione --wait o --atomic.

Con l'opzione --cleanup-on-fail viene richiesta la rimozione di tutti gli oggetti della release in caso di fallimento.

Questo però non aiuta nell'eventuale debugging.

Rollback

Compiamo un rollback alla versione 1:

helm rollback mysite 1

Verifichiamo che i valori sono ora quelli della versione 1:

helm get values mysite -o json

{"drupalEmail":"foo@example.com","drupalUsername":"admin","mariadb":{"db":{"name":"my-database"}}}

Ispezioniamo la storia:

helm history mysite

REVISION  UPDATED                   STATUS      CHART         APP VERSION DESCRIPTION     
1         Sun Feb 11 09:37:53 2024  superseded  drupal-17.3.4 10.2.3       Install complete
2         Sun Feb 11 10:20:18 2024  superseded  drupal-17.3.4 10.2.3      Upgrade complete
3         Sun Feb 11 10:37:54 2024  deployed    drupal-17.3.4 10.2.3      Rollback to 1

Si possono compiere queries di un'altra revisione della storia, per esempio:

helm get values mysite --revision 2

E in modo simile per notes e manifest.

Mantenere la Storia

Si può disinstallare una release, ma mantenere la sua storia:

helm uninstall mysite --keep-history

La storia è ora:

helm history mysite

REVISION  UPDATED                   STATUS      CHART         APP VERSION DESCRIPTION            
1         Sun Feb 11 09:37:53 2024  superseded  drupal-17.3.4 10.2.3      Install complete       
2         Sun Feb 11 10:20:18 2024 superseded  drupal-17.3.4 10.2.3      Upgrade complete       
3        Sun Feb 11 10:37:54 2024 uninstalled drupal-17.3.4 10.2.3      Uninstallation complete

Con la storia presente, si può compiere un rollback ad una previa versione anche se quella corrente non è installata.

Kubernetes Avanzaato