Auf dieser Seite wird erläutert, wie Rolling Updates für Anwendungen in Google Kubernetes Engine (GKE) durchgeführt werden.
Übersicht
Sie können ein Rolling Update durchführen, um Images, Konfiguration, Labels, Anmerkungen und Ressourcenlimits/-anforderungen der Arbeitslasten in Ihren Clustern zu aktualisieren. Durch Rolling Updates werden die Pods Ihrer Ressourcen schrittweise durch neue Pods ersetzt, die anschließend Knoten mit verfügbaren Ressourcen zugeordnet werden. Rolling Updates sind darauf ausgelegt, eine Aktualisierung von Arbeitslasten ohne Ausfallzeiten zu ermöglichen.
Die folgenden Objekte stellen Kubernetes-Arbeitslasten dar. Wenn Sie ein Rolling Update für diese Arbeitslasten auslösen möchten, aktualisieren Sie die jeweilige Pod-Vorlage:
- DaemonSets
- Deployments
- StatefulSets
Jedes dieser Objekte hat eine Pod-Vorlage, die durch das Feld spec: template im Manifest des Objekts dargestellt wird. Das Pod-Vorlagenfeld enthält eine Spezifikation für die Pods, die vom Controller erstellt werden, um den gewünschten Zustand oder das gewünschte Verhalten zu erreichen. Wenn Sie ein Update-Rollout auslösen möchten, aktualisieren Sie spec: template des Objekts.
Die Pod-Vorlage enthält die folgenden Felder:
Weitere Informationen zur Pod-Vorlage finden Sie in der Dokumentation zu PodTemplateSpec.
Das Skalieren einer Ressource oder das Aktualisieren von Feldern außerhalb der Pod-Vorlage löst kein Rollout aus.
Vorbereitung
Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:
- Aktivieren Sie die Google Kubernetes Engine API. Google Kubernetes Engine API aktivieren
- Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit
gcloud components updateab.
Anwendungen aktualisieren
Im folgenden Abschnitt wird erläutert, wie Sie eine Anwendung mithilfe der Google Cloud Console oder kubectl aktualisieren können.
kubectl set
Mithilfe von kubectl set können Sie die Felder image, resources (Rechenressource wie CPU und Arbeitsspeicher) oder selector eines Objekts ändern.
Führen Sie beispielsweise den folgenden Befehl aus, um ein Deployment von nginx-Version 1.7.9 auf Version 1.9.1 zu aktualisieren:
kubectl set image deployment nginx nginx=nginx:1.9.1
Mit dem Befehl kubectl set image wird das nginx-Image der Deployment-Pods einzeln aktualisiert.
Folgendermaßen können Sie die Ressourcenanforderungen und -limits des Deployments festlegen:
kubectl set resources deployment nginx --limits cpu=200m,memory=512Mi --requests cpu=100m,memory=256Mi
Sie können auch die Ressourcenanforderungen des Deployments entfernen:
kubectl set resources deployment nginx --limits cpu=0,memory=0 --requests cpu=0,memory=0
kubectl apply
Mit kubectl apply können Sie eine Ressource aktualisieren, indem Sie eine neue oder aktualisierte Konfiguration anwenden.
Führen Sie den folgenden Befehl aus, um eine neue oder aktualisierte Konfiguration auf eine Ressource anzuwenden:
kubectl apply -f MANIFEST
Ersetzen Sie MANIFEST durch den Namen der Manifestdatei.
Wenn die Datei nicht vorhanden ist, erstellt dieser Befehl die Ressource und wendet die Konfiguration an. Andernfalls wird die aktualisierte Konfiguration angewendet.
Console
Gehen Sie so vor, um die Livekonfiguration einer Anwendung zu bearbeiten:
Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf.
Wählen Sie die Arbeitslast aus, die Sie aktualisieren möchten.
Klicken Sie auf der Seite Bereitstellungsdetails auf list Aktionen > Rolling Update.
Legen Sie im Dialogfeld Rolling Update das Image der Arbeitslast fest.
Klicken Sie auf Aktualisieren.
Update-Rollout verwalten
Mit kubectl rollout können Sie ein Rollout untersuchen, während es ausgeführt wird, ein Rollout anhalten und fortsetzen, ein Rollback einer Aktualisierung ausführen und sich den Rollout-Verlauf eines Objekts anzeigen lassen.
Rollout mit kubectl rollout status überprüfen
Sie können den Status eines Rollouts mit dem Befehl kubectl rollout status überprüfen.
So haben Sie zum Beispiel die Möglichkeit, das Rollout eines nginx-Deployments zu prüfen. Führen Sie dazu den folgenden Befehl aus:
kubectl rollout status deployment nginx
Die Ausgabe sieht etwa so aus:
Waiting for rollout to finish: 2 out of 3 newreplicas have been updated...
deployment "nginx" successfully rolled out
Nach dem erfolgreichen Rollout führen Sie kubectl get deployment nginx aus, um zu überprüfen, ob alle Pods ausgeführt werden. Die Ausgabe sieht etwa so aus:
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 3 3 3 3 36s
Rollout anhalten und fortsetzen
Mit kubectl rollout pause können Sie ein Rollout pausieren.
Wenn Sie etwa das Rollout des nginx-Deployments pausieren möchten, führen Sie den folgenden Befehl aus:
kubectl rollout pause deployment nginx
Zum Fortsetzen führen Sie Folgendes aus:
kubectl rollout resume deployment nginx
Rollout-Verlauf mit kubectl rollout history aufrufen
Mit kubectl rollout history können Sie den Rollout-Verlauf eines Objekts anzeigen lassen.
Wenn Sie zum Beispiel den Rollout-Verlauf für das nginx-Deployment abrufen möchten, führen Sie den folgenden Befehl aus:
kubectl rollout history deployment nginx
Führen Sie den folgenden Befehl aus, um den Verlauf der dritten Überarbeitung anzuzeigen:
kubectl rollout history deployment nginx --revision 3
Rollback für ein Update mit kubectl rollout undo ausführen
Sie können das Rollout eines Objekts mit dem Befehl kubectl rollout undo zurücksetzen.
Wenn Sie beispielsweise das nginx-Deployment auf die vorherige Version zurücksetzen möchten, führen Sie den folgenden Befehl aus:
kubectl rollout undo deployments nginx
Wenn Sie zur dritten Überarbeitung des Deployments zurückkehren möchten, führen Sie den folgenden Befehl aus:
kubectl rollout undo deployment nginx --to-revision 3
Hinweise zu StatefulSets und DaemonSets
StatefulSets (seit Kubernetes 1.7) und DaemonSets (seit Kubernetes 1.6) verwenden eine Updatestrategie, um automatisierte Rolling Updates für Container, Labels, Ressourcenanforderungen/-limits und Anmerkungen für die zugehörigen Pods zu konfigurieren und zu deaktivieren. Die Updatestrategie wird über das Feld spec.updateStrategy konfiguriert.
Das Feld spec.updateStrategy.type akzeptiert als Wert entweder OnDelete oder RollingUpdate.
OnDelete ist das Standardverhalten, wenn spec.updateStrategy.type nicht angegeben ist. OnDelete verhindert, dass die Pods des Controllers automatisch aktualisiert werden. Sie müssen die Pods manuell löschen, damit vom Controller neue Pods erstellt werden, die Ihre Änderungen widerspiegeln. OnDelete ist nützlich, wenn Sie es vorziehen, Pods manuell zu aktualisieren.
Durch RollingUpdate werden automatisierte Rolling Updates für die Pods im StatefulSet implementiert. RollingUpdate sorgt dafür, dass der Controller jeden seiner Pods einzeln löscht und neu erstellt. Der Befehl wartet, bis ein aktualisierter Pod bereit ist, bevor sein Vorgänger aktualisiert wird.
Der StatefulSet-Controller aktualisiert alle Pods in umgekehrter ordinaler Reihenfolge und hält dabei die StatefulSet-Garantien ein.
Strategie RollingUpdate verwenden
Mit der Strategie RollingUpdate können Sie alle Pods in einem StatefulSet oder DaemonSet automatisch aktualisieren.
Wenn Sie beispielsweise das StatefulSet web patchen möchten, um die Strategie RollingUpdate anzuwenden, führen Sie den folgenden Befehl aus:
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}'
Nehmen Sie als Nächstes eine Änderung an spec.template des StatefulSet vor. Mit kubectl set können Sie z. B. das Container-Image ändern. Im folgenden Beispiel wird für das StatefulSet web festgelegt, dass sein Container nginx das Image nginx-slim:0.7 ausführen soll:
kubectl set image statefulset web nginx=nginx-slim:0.7
Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Pods im StatefulSet, in dem der Container nginx ausgeführt wird, aktualisiert werden:
kubectl get pods -l app=nginx -w
Die Ausgabe sieht etwa so aus:
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 7m
web-1 1/1 Running 0 7m
web-2 1/1 Running 0 8m
web-2 1/1 Terminating 0 8m
web-2 1/1 Terminating 0 8m
web-2 0/1 Terminating 0 8m
web-2 0/1 Terminating 0 8m
web-2 0/1 Terminating 0 8m
web-2 0/1 Terminating 0 8m
web-2 0/1 Pending 0 0s
web-2 0/1 Pending 0 0s
web-2 0/1 ContainerCreating 0 0s
web-2 1/1 Running 0 19s
web-1 1/1 Terminating 0 8m
web-1 0/1 Terminating 0 8m
web-1 0/1 Terminating 0 8m
web-1 0/1 Terminating 0 8m
web-1 0/1 Pending 0 0s
web-1 0/1 Pending 0 0s
web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 6s
web-0 1/1 Terminating 0 7m
web-0 1/1 Terminating 0 7m
web-0 0/1 Terminating 0 7m
web-0 0/1 Terminating 0 7m
web-0 0/1 Terminating 0 7m
web-0 0/1 Terminating 0 7m
web-0 0/1 Pending 0 0s
web-0 0/1 Pending 0 0s
web-0 0/1 ContainerCreating 0 0s
web-0 1/1 Running 0 10s
Die Pods im StatefulSet werden in umgekehrter ordinaler Reihenfolge aktualisiert. Der StatefulSet-Controller beendet jeden Pod einzeln und wartet, bis er wieder bereit ist, bevor der nächste Pod aktualisiert wird.
RollingUpdate partitionieren
Sie können einen Partitionsparameter (partition) für das Feld RollingUpdate eines StatefulSet angeben.
Wenn Sie eine partition angeben, werden alle Pods mit einer Ordinalzahl aktualisiert, die größer oder gleich dem Wert von partition ist. Alle Pods mit einer Ordinalzahl, die kleiner als der partition-Wert ist, werden nicht aktualisiert und werden in der vorherigen Version neu erstellt, selbst wenn sie gelöscht werden.
Wenn der Wert der partition größer ist als die Anzahl von replicas, werden die Aktualisierungen nicht auf die zugehörigen Pods übertragen. Partitionierungen sind nützlich, wenn Sie eine Aktualisierung, ein Rollout eines Canary-Updates oder ein phasenweises Rollout durchführen möchten.
Wenn Sie beispielsweise das StatefulSet web partitionieren möchten, führen Sie den folgenden Befehl aus:
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}'
Dadurch werden Pods aktualisiert, deren Ordinalzahl größer oder gleich 3 ist.
Parameter maxUnavailable und maxSurge von DaemonSet
Die optionalen Parameter maxUnavailable und maxSurge von DaemonSet sind dem DaemonSet-Feld rollingUpdate untergeordnet.
maxUnavailable legt die maximal mögliche Anzahl von DaemonSet-Pods fest, die während Aktualisierungen nicht verfügbar sind. Der Standardwert, wenn keine Angabe gemacht wird, ist 1.
maxSurge ist die maximale Anzahl von Pods, die während Aktualisierungen hochskaliert werden können.
Der Standardwert, wenn keine Angabe gemacht wird, ist 0.
Keiner der Werte kann 0 sein, wenn der andere Wert 0 ist. Beide Werte können eine absolute Zahl oder ein Prozentsatz sein.
Weitere Informationen finden Sie in der DaemonSetSpec.
Mit der Strategie OnDelete aktualisieren
Wenn Sie ein StatefulSet oder DaemonSet manuell aktualisieren möchten, können Sie das Feld spec.updateStrategy weglassen. Dadurch wird der Controller angewiesen, die Strategie OnDelete zu verwenden.
Wenn Sie einen Controller aktualisieren möchten, der die Strategie OnDelete verwendet, müssen Sie die zugehörigen Pods manuell löschen, nachdem Sie die Pod-Vorlage geändert haben.
So können Sie z. B. beim StatefulSet web einstellen, dass es das Image nginx-slim:0.7 verwendet:
kubectl set image statefulset web nginx=nginx-slim:0.7
Führen Sie anschließend den folgenden Befehl aus, um den ersten web-Pod zu löschen:
kubectl delete pod web-0
Wenn Sie beobachten möchten, wie der Pod durch das StatefulSet wiederhergestellt und wieder ausgeführt wird, führen Sie den folgenden Befehl aus:
kubectl get pod web-0 -w
Die Ausgabe dieses Befehls sieht so aus:
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 54s
web-0 1/1 Terminating 0 1m
web-0 0/1 Terminating 0 1m
web-0 0/1 Terminating 0 1m
web-0 0/1 Terminating 0 1m
web-0 0/1 Pending 0 0s
web-0 0/1 Pending 0 0s
web-0 0/1 ContainerCreating 0 0s
web-0 1/1 Running 0 3s
Jobs aktualisieren
Wenn Sie die Konfiguration eines Jobs aktualisieren, werden der neue Job und die zugehörigen Pods mit der neuen Konfiguration ausgeführt. Der alte Job und die zugehörigen Pods müssen nach der Aktualisierung manuell gelöscht werden, falls erforderlich.
Führen Sie den folgenden Befehl aus, um einen Job und alle zugehörigen Pods zu löschen:
kubectl delete job my-job
Wenn Sie einen Job löschen, seine Pods aber weiterhin ausführen möchten, geben Sie das Flag --cascade=false an:
kubectl delete job my-job --cascade=false
Sie können auch kubectl describe deployment nginx ausführen. Dadurch erhalten Sie noch mehr Informationen zum Deployment.