Rolling Updates und Rollbacks in Kubernetes

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

Eine Update-Strategie (k8s rollingupdate, k8s update strategy) ist die wichtigste Option zur Konfiguration von Rolling Updates. In der Deployment-Definition 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.

Es gibt 2 weitere Optionen beim Aktualisieren des Deployments mit RollingUpdate.

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

Mit Deployment Rolling Updates können wir das von einem Deployment verwendete Image aktualisieren. Der Status des Deployments (kubectl rollout status) wird gespeichert, was es uns ermöglicht, auf frühere Versionen des Deployments zurückzurollen.

Wenn eine Anwendung aufgrund eines falschen Images fehlschlägt oder das Deployment instabil ist, möchten wir möglicherweise das Deployment zurückrollen (k8s rollback). Standardmäßig wird die gesamte Rollout-Historie des Deployments im System gespeichert, die später verwendet werden kann, um im Falle eines instabilen Deployments zurückzurollen. Wir können diese Historie verwenden, um jederzeit zurückzurollen, wenn wir möchten.

Um mehr über Rolling Updates und Rollbacks zu erfahren, besuchen Sie die offizielle Dokumentation von Kubernetes hier.

In diesem Artikel werden wir das Deployment mit der standardmäßigen Rolling Update-Strategie aktualisieren und das Deployment zurückrollen. Um das Deployment zurückzurollen, verwenden wir das falsche Image in einem der Updates des Deployments.

Voraussetzungen

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

Was werden wir tun?

1. Rolling Update und Rollback

Rolling Update und Rollback

Erstellen Sie eine Deployment-Definitionsdatei für Nginx mit der Pod-Vorlage des Deployments. In dieser 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

Lassen Sie uns nach vorhandenen Pods suchen und ein Deployment erstellen.

kubectl get pods

kubectl create -f my-deployment.yml

Holen Sie sich die Details des Deployments, das wir gerade erstellt haben. Dieses Deployment hat 4 Pods erstellt und wird von der ReplicaSet gesteuert.

kubectl get deployments

kubectl get pods

kubectl get replicaset

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

Jetzt ändern wir die Nginx-Version von “nginx:1.14.2” auf “nginx:1.61.1”

vim my-deployment.yml

Wenden Sie die Änderung auf das Deployment an und holen Sie sich die Details der Pods, des ReplicaSets und des Deployments.

kubectl apply -f my-deployment.yml

kubectl get pods

kubectl get deployments

kubectl get replicaset

Im obigen Screenshot ist zu sehen, dass ein neues ReplicaSet erstellt wurde und 4 Pods darunter hat. Aber wir sehen immer noch das ältere ReplicaSet mit 0 Pods.

Jetzt, wenn wir die Nginx-Version erneut ändern, aber diesmal eine falsche Nginx-Version angeben, wird das Deployment fehlschlagen, da das Nginx-Image für die falsche Version nicht existiert.

vim my-deployment.yml

Lassen Sie uns die Änderung auf das Deployment anwenden.

kubectl apply -f my-deployment.yml

kubectl get pods

kubectl get deployments

Jetzt versuchen wir, die Details des ReplicaSets zu erhalten.

kubectl get replicaset

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

Jetzt, wenn wir zu den vorherigen funktionierenden Images zurückkehren möchten, können wir auf eine vorherige Revision zurückrollen, wenn der Rollout-Status nicht in Ordnung ist.

Um zurückzurollen, können wir zuerst die Rollout-Historie des Deployments mit dem folgenden Befehl abrufen.

kubectl rollout history deployments rolling-update-demo

Jetzt können wir mit dem folgenden Befehl mit “–revision=2” die Details des Deployments abrufen, die wir in “–revision=2” haben.

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

Im obigen Screenshot sehen Sie, dass die Revision-2 die Nginx-Image-Version “nginx:1.16.1” hat, die funktionierte, bevor wir unser Deployment mit der Nginx-Version “ngin:1.1.1” aktualisiert haben, die fehlgeschlagen ist.

Jetzt lassen Sie uns das Deployment auf die letzte Revision zurückrollen, die wir vor dem aktuellen fehlgeschlagenen Deployment hatten.

kubectl get deployments

kubectl rollout undo deployment rolling-update-demo

kubectl get pods

kubectl get replicaset

Im obigen Screenshot sehen Sie, dass wir das letzte Deployment zurückgesetzt haben und jetzt haben wir eine Deployment-Revision, die vor dem letzten Update funktionierte.

Um mehr über das Deployment zu erfahren, kann es mit dem folgenden Befehl beschrieben werden.

kubectl get deployments

kubectl describe deployment rolling-update-demo

Fazit

In diesem Artikel haben wir die Schritte zum Erstellen eines Deployments und dessen Aktualisierung gesehen. Wir haben gesehen, wie ein Deployment zurückgerollt werden kann, wenn es aus irgendeinem Grund fehlschlägt; hier war der Fehler, den wir für das fehlgeschlagene Deployment gesehen haben, “ErrImagePull”. Wir haben gesehen, wie das Deployment seine Revisionen beibehält, auf die es zurückgerollt werden kann, falls wir die neuesten Updates im Deployment nicht beibehalten möchten.