Rolling Updates and Rollbacks in Kubernetes

Einer der Vorteile der Verwendung eines Deployment ist die Möglichkeit, Rolling Updates durchzuführen. Rolling Updates ermöglichen es uns, die Konfiguration der Pods schrittweise zu aktualisieren.

Die Aktualisierungsstrategie ist die wichtigste Option zur Konfiguration rollender Aktualisierungen. In der Einsatzdefinition hat spec.strategy.type zwei mögliche Werte:

  • RollingUpdate: Neue Pods werden schrittweise hinzugefügt und die alten Pods werden schrittweise beendet.
  • Recreate: Alle alten Pods werden auf einmal beendet, bevor neue Pods hinzugefügt werden.

Während der Aktualisierung der Bereitstellung mit RollingUpdate gibt es 2 weitere Optionen.

  • maxSurge: Die Anzahl der Pods, die während einer Aktualisierung über die gewünschte Anzahl von Pods hinaus erstellt werden können.
  • maxUnavailable: Die Anzahl der Pods, die während des Aktualisierungsvorgangs nicht verfügbar sein können.

Mit Hilfe von rollenden Updates für den Einsatz können wir das von einem Einsatz verwendete Image aktualisieren. Der Stand des Einsatzes wird gespeichert, so dass wir zu allen früheren Versionen des Einsatzes zurückgehen können.

Wenn eine Anwendung aufgrund eines falschen Images fehlschlägt oder die Bereitstellung instabil ist, möchten wir die Bereitstellung möglicherweise zurücksetzen. Standardmäßig wird die gesamte Rollout-Historie des Einsatzes im System gespeichert, die später im Falle eines instabilen Einsatzes zum Rollback verwendet werden kann. Wir können diese Historie jederzeit zum Rollback verwenden.

Um mehr über RollingUpdate und Rollback zu erfahren, besuchen Sie die offizielle Dokumentation der Kubernetes hier.

In diesem Artikel aktualisieren wir die Bereitstellung mit der Standard-Rollout-Aktualisierungsstrategie und rollen die Bereitstellung zurück. Zum Rollback der Bereitstellung werden wir das falsche Image in einem der Updates der Bereitstellung verwenden.

Vorraussetzungen

  1. Kubernetes Cluster mit mindestens 1 Worker-Knoten.
    Wenn Sie lernen möchten, wie man einen Kubernetes-Cluster erstellt, klicken Sie hier. Dieses Handbuch hilft Ihnen, einen Kubernetes-Cluster mit 1 Master- und 2 Worker-Knoten auf AWS Ubuntu 18.04 EC2-Instanzen zu erstellen.

Was werden wir tun?

  1. Rollende Aktualisierung und Rollback

Aktualisierung und Rollback durchführen

Erstellen Sie eine Einsatzdefinitionsdatei für Nginx. Darin haben wir die Nginx-Version als „nginx:1.14.2“ angegeben.

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

Definition meines Einsatzes

Lassen Sie uns nach vorhandenen Pods suchen und eine Bereitstellung erstellen.

kubectl get pods
kubectl create -f my-deployment.yml

Informieren Sie sich über die Einzelheiten des Einsatzes, den wir gerade erstellt haben. Bei diesem Einsatz wurden 4 Hülsen erstellt und vom Replikat gesteuert.

kubectl get deployments
kubectl get pods
kubectl  get replicaset

Erstellen einer Bereitstellung

Im obigen Screenshot sehen Sie, dass wir 1 Deployment haben, unter dem wir 1 Replikat und 4 Pods haben, die vom Replikat gesteuert werden.

Ändern wir nun die Nginx-Version von „nginx:1.14.2“ in „nginx:1.61.1“.

vim my-deployment.yml

edit-image-in-the-deployment

Wenden Sie die Änderung auf den Einsatz an und erhalten Sie Einzelheiten zu den Pods, dem Replikat und dem Einsatz.

kubectl apply -f my-deployment.yml
kubectl get pods
kubectl get deployments
kubectl get replicaset

anwenden-Ändern-auf-den-Einsatz

Auf dem obigen Screenshot ist zu sehen, dass ein neues Replikat erstellt wurde, das 4 Pods unter sich hat. Wir sehen aber immer noch das ältere Replikat mit 0 Pods.

Wenn wir nun erneut die Nginx-Version ändern, diesmal aber eine falsche Nginx-Version angeben, schlägt die Bereitstellung fehl, da das Nginx-Image für die falsche Version nicht existiert.

vim my-deployment.yml

Bild ändern - mit falscher Version

Wenden wir die Änderung auf die Bereitstellung an.

kubectl apply -f my-deployment.yml
kubectl get pods
kubectl get deployments

Lassen Sie uns nun versuchen, Details der Replikate zu erhalten.

kubectl get replicaset

bei der Bereitstellung falsche Änderungen anwenden

Auf dem obigen Screenshot ist zu sehen, dass die neuen Pods mit dem Fehler „ErrImagePull“ fehlschlagen. Die Pods schlagen fehl, da das Nginx-Image für die Version „ngin:1.1.1“ nicht existiert.

Wenn wir nun zu den vorherigen Arbeitsbildern zurückkehren wollen, können wir ein Rollback durchführen.

Um ein Rollback durchzuführen, können wir zunächst die Rollout-Historie der Einsätze mit dem folgenden Befehl abrufen.

kubectl rollout history deployments rolling-update-demo

Wenn wir nun den folgenden Befehl mit „–revision=2“ verwenden, können wir die Details des Einsatzes, den wir in „–revision=2“ haben, überprüfen

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

rollback-to-the-working-deployment-version-with-the-correct-image

Auf dem obigen Screenshot sehen Sie, dass die Revision-2 die Nginx-Image-Version „nginx:1.16.1“ hat, die funktionierte, bevor wir unsere Bereitstellung mit der Nginx-Version „nginx:1.1.1“ aktualisiert haben, was fehlgeschlagen ist.

Lassen Sie uns nun den Einsatz auf die letzte Revision zurücksetzen, die wir vor dem aktuellen gescheiterten Einsatz haben.

kubectl get deployments
kubectl rollout undo deployment rolling-update-demo
kubectl get pods
kubectl get replicaset

check-rollback-status

Im obigen Screenshot sehen Sie, dass wir die letzte Bereitstellung zurückgesetzt haben und jetzt eine Bereitstellungsrevision haben, die vor der letzten Aktualisierung funktionierte.

Um mehr über die Bereitstellung zu erfahren, kann sie mit dem folgenden Befehl beschrieben werden.

kubectl get deployments
kubectl describe deployment rolling-update-demo

Einsatz beschreiben

Schlussfolgerung

In diesem Artikel haben wir die Schritte zum Erstellen und Aktualisieren eines Deployments gesehen. Wir haben gesehen, wie eine Bereitstellung rückgängig gemacht werden kann, wenn sie aus irgendeinem Grund fehlschlägt; hier war der Fehler, den wir für die fehlgeschlagene Bereitstellung sahen, „ErrImagePull“. Wir haben gesehen, wie die Bereitstellung ihre Revision behält, auf die sie zurückgerollt werden kann, falls wir nicht die neuesten Aktualisierungen in der Bereitstellung behalten wollen.

Das könnte Dich auch interessieren …