Aggiornamenti Rolling e Rollback in Kubernetes

Uno dei vantaggi dell’utilizzo di un Deployment è la possibilità di eseguire aggiornamenti rolling e creare una strategia di aggiornamento rolling. Gli aggiornamenti rolling ci consentono di aggiornare gradualmente la configurazione dei pod.

Una strategia di aggiornamento (k8s rollingupdate, k8s update strategy) è l’opzione più importante da configurare per gli aggiornamenti rolling. Nella definizione del Deployment, spec.strategy.type ha due possibili valori:

• RollingUpdate: I nuovi pod vengono aggiunti gradualmente e i vecchi pod vengono terminati gradualmente.
• Recreate: Tutti i vecchi pod vengono terminati contemporaneamente prima che vengano aggiunti nuovi pod.

Ci sono altre 2 opzioni durante l’aggiornamento del deployment utilizzando RollingUpdate.

• maxSurge: Il numero di pod che possono essere creati oltre il numero desiderato di pod durante un aggiornamento.
• maxUnavailable: Il numero di pod che possono essere non disponibili durante il processo di aggiornamento.

Utilizzando gli aggiornamenti rolling del deployment possiamo aggiornare l’immagine utilizzata da un deployment. Lo stato del deployment (kubectl rollout status) viene salvato, il che ci consente di tornare a versioni precedenti del deployment.

Quando un’applicazione fallisce a causa di un’immagine errata o il deployment è instabile, potremmo voler eseguire il rollback del Deployment (k8s rollback). Per impostazione predefinita, tutta la cronologia di rollout del Deployment viene mantenuta nel sistema e può essere utilizzata in seguito per il rollback in caso di deployment instabile. Possiamo utilizzare questa cronologia per eseguire il rollback ogni volta che vogliamo.

Per saperne di più su Aggiornamento rolling e Rollback, visita la documentazione ufficiale di Kubernetes qui.

In questo articolo, aggiorneremo il deployment con la strategia di aggiornamento rolling predefinita e faremo il rollback del deployment. Per fare il rollback del deployment, utilizzeremo l’immagine errata in uno degli aggiornamenti al deployment.

Requisiti

1. Cluster Kubernetes con almeno 1 nodo worker.
   Se vuoi imparare a creare un Cluster Kubernetes, clicca qui. Questa guida ti aiuterà a creare un cluster Kubernetes con 1 Master e 2 Nodes su AWS Ubuntu 18.04 EC2 Instances.

Cosa faremo?

1. Aggiornamento Rolling e Rollback

Aggiornamento rolling e Rollback

Crea un file di definizione del deployment per Nginx con il template del pod del deployment. In questo, abbiamo specificato la versione di Nginx come “nginx:1.14.2”.

vim my-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update-demo
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Controlliamo i pod esistenti e creiamo un deployment.

kubectl get pods

kubectl create -f my-deployment.yml

Ottieni i dettagli del deployment che abbiamo appena creato. Questo deployment ha creato 4 pod ed è controllato dal replicaset.

kubectl get deployments

kubectl get pods

kubectl get replicaset

Nello screenshot sopra, puoi vedere che abbiamo 1 deployment sotto il quale abbiamo 1 replicaset e 4 pod controllati dal replicaset.

Ora, cambiamo la versione di Nginx da “nginx:1.14.2” a “nginx:1.61.1”

vim my-deployment.yml

Applica la modifica al deployment e ottieni i dettagli dei pod, del replicaset e del deployment.

kubectl apply -f my-deployment.yml

kubectl get pods

kubectl get deployments

kubectl get replicaset

Nello screenshot sopra, si può vedere che è stato creato un nuovo replicaset e ha 4 pod sotto di esso. Ma vediamo ancora il vecchio replicaset con 0 pod.

Ora, se cambiamo di nuovo la versione di Nginx, ma questa volta diamo una versione errata di Nginx, il deployment fallirà poiché l’immagine di Nginx non esiste per la versione errata.

vim my-deployment.yml

Applichiamo la modifica al deployment.

kubectl apply -f my-deployment.yml

kubectl get pods

kubectl get deployments

Ora, proviamo a ottenere i dettagli del replicaset.

kubectl get replicaset

Nello screenshot sopra, si può vedere che i nuovi Pod stanno fallendo con errore “ErrImagePull”. I pod stanno fallendo poiché l’immagine di Nginx non esiste per la versione “ngin:1.1.1”.

Ora, se vogliamo tornare alle immagini funzionanti precedenti, possiamo eseguire il rollback a una revisione precedente se lo stato del rollout non è ok.

Per eseguire il rollback, possiamo prima ottenere la cronologia del rollout del deployment utilizzando il seguente comando.

kubectl rollout history deployments rolling-update-demo

Ora, utilizzando il seguente comando con “–revision=2” possiamo controllare i dettagli del deployment che abbiamo in “–revision=2”

kubectl rollout history deployments rolling-update-demo --revision=2

Nello screenshot sopra, puoi vedere che la revisione-2 ha la versione dell’immagine Nginx “nginx:1.16.1” che funzionava prima che aggiornassimo il nostro deployment con la versione di Nginx “ngin:1.1.1” che ha fallito.

Ora, facciamo il rollback del deployment all’ultima revisione che abbiamo prima dell’attuale deployment fallito.

kubectl get deployments

kubectl rollout undo deployment rolling-update-demo

kubectl get pods

kubectl get replicaset

Nello screenshot sopra, puoi vedere che abbiamo ripristinato l’ultimo deployment e ora abbiamo una revisione del deployment che funzionava prima dell’ultimo aggiornamento.

Per saperne di più sul deployment, può essere descritto utilizzando il seguente comando.

kubectl get deployments

kubectl describe deployment rolling-update-demo

Conclusione

In questo articolo, abbiamo visto i passaggi per creare un deployment e aggiornarlo. Abbiamo visto come un deployment può essere ripristinato se fallisce per qualche motivo, qui l’errore che abbiamo visto per il deployment fallito era “ErrImagePull”. Abbiamo visto come il deployment mantiene la sua revisione a cui può essere eseguito il rollback nel caso in cui non vogliamo mantenere gli ultimi aggiornamenti nel deployment.