Aggiornamenti in sequenza e rollback in Kubernetes
Su questa pagina
- Prerequisiti
- Cosa faremo?
- Aggiornamento in sequenza e rollback
- Conclusione
Uno dei vantaggi dell'utilizzo di una distribuzione è la possibilità di eseguire aggiornamenti in sequenza e creare una strategia di aggiornamento in sequenza. Gli aggiornamenti in sequenza ci consentono di aggiornare gradualmente la configurazione dei pod.
Una strategia di aggiornamento (k8s rollingupdate, strategia di aggiornamento k8s) è l'opzione più importante per configurare gli aggiornamenti in sequenza. Nella definizione di distribuzione, spec.strategy.type ha due possibili valori:
- RollingUpdate: i nuovi pod vengono aggiunti gradualmente e i vecchi pod vengono chiusi gradualmente.
- Ricrea: tutti i vecchi pod vengono terminati immediatamente prima che vengano aggiunti nuovi pod.
Sono disponibili altre 2 opzioni durante l'aggiornamento dell'implementazione tramite RollingUpdate.
- maxSurge: il numero di pod che è possibile creare oltre il numero desiderato di pod durante un aggiornamento.
- maxUnavailable: il numero di pod che possono non essere disponibili durante il processo di aggiornamento.
Utilizzando gli aggiornamenti in sequenza della distribuzione, possiamo aggiornare l'immagine utilizzata da una distribuzione. Lo stato della distribuzione (stato di implementazione kubectl) viene salvato, il che ci consente di eseguire il rollback a qualsiasi versione precedente della distribuzione.
Prerequisiti
- Cluster Kubernetes con almeno 1 nodo di lavoro.
Se vuoi imparare a creare un cluster Kubernetes, fai clic qui. Questa guida ti aiuterà a creare un cluster Kubernetes con 1 master e 2 nodi su istanze AWS Ubuntu 18.04 EC2.
Che cosa faremo?
- Aggiornamento in sequenza e rollback
Aggiornamento in sequenza e rollback
Crea un file di definizione della distribuzione per Nginx con il modello di pod delle distribuzioni. 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'implementazione.
kubectl get pods
kubectl create -f my-deployment.yml
Ottieni i dettagli della distribuzione che abbiamo appena creato. Questa distribuzione ha creato 4 pod e controllato dal set di repliche.
kubectl get deployments
kubectl get pods
kubectl get replicaset
Nello screenshot sopra, puoi vedere che abbiamo 1 distribuzione in cui 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 set di repliche 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 set di repliche con 4 pod sotto di esso. Ma vediamo ancora il set di repliche precedente con 0 pod.
Ora, se cambiamo nuovamente la versione di Nginx ma questa volta forniamo una versione Nginx errata, il deployment fallirà perché l'immagine Nginx non esiste per la versione sbagliata.
vim my-deployment.yml
Applichiamo la modifica alla distribuzione.
kubectl apply -f my-deployment.yml
kubectl get pods
kubectl get deployments
Ora, proviamo a ottenere i dettagli del set di repliche.
kubectl get replicaset
Nello screenshot sopra, si può vedere che i nuovi pod non funzionano con l'errore \ErrImagePull\. I pod non funzionano poiché l'immagine Nginx non esiste per la versione \ngin:1.1.1\.
Ora, se vogliamo tornare alle precedenti immagini funzionanti, possiamo eseguire il rollback a una revisione precedente se lo stato di rollout non è ok.
Per eseguire il rollback, possiamo prima ottenere la cronologia dell'implementazione dell'implementazione delle distribuzioni utilizzando il seguente comando.
kubectl rollout history deployments rolling-update-demo
Ora, usando 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 Nginx Image \nginx:1.16.1\ che funzionava prima che aggiornassimo la nostra distribuzione con la versione Nginx \ngin:1.1.1\ che non è riuscita.
Ora, eseguiamo il rollback del deployment all'ultima revisione che abbiamo prima dell'attuale deployment non riuscito.
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'ultima implementazione e ora abbiamo una revisione dell'implementazione che funzionava prima dell'ultimo aggiornamento.
Per saperne di più sulla distribuzione, può essere descritta 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 è possibile eseguire il rollback di un deployment se non riesce per qualche motivo, qui l'errore che abbiamo riscontrato per il deployment non riuscito era \ErrImagePull\. Abbiamo visto come la distribuzione mantiene la sua revisione a cui può essere ripristinata nel caso in cui non si desideri conservare gli ultimi aggiornamenti nella distribuzione.