Ricerca nel sito web

Aggiornamenti in sequenza e rollback in Kubernetes


Su questa pagina

  1. Prerequisiti
  2. Cosa faremo?
  3. Aggiornamento in sequenza e rollback
  4. 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

  1. 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?

  1. 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.