Manuelles Upgrade eines Clusters oder Knotenpools

In diesem Dokument wird erläutert, wie Sie manuell ein Upgrade oder Downgrade für die Steuerungsebene oder die Knoten eines Google Kubernetes Engine-Clusters (GKE) anfordern können. GKE aktualisiert die Version der Steuerungsebene und der Knoten automatisch, damit der Cluster neue Funktionen, Fehlerkorrekturen und Sicherheitspatches erhält. Wie in diesem Dokument beschrieben, können Sie diese Upgrades aber auch manuell durchführen.

Weitere Informationen zur Funktionsweise automatischer und manueller Clusterupgrades finden Sie unter GKE-GKE-ClusterClusterupgrades. Sie können auch festlegen, wann automatische Upgrades ausgeführt werden sollen. Dazu müssen Sie entsprechende Wartungsfenster und -ausschlüsse konfigurieren.

Sie können die Version manuell aktualisieren:

• Autopilot-Cluster: Version der Steuerungsebene aktualisieren.
• Standardcluster: Version der Steuerungsebene und die Knotenpool-Version aktualisieren.

Zum Upgrade eines Clusters aktualisiert GKE die Version, mit der die Steuerungsebene und die Knoten ausgeführt werden, in separaten Vorgängen. Cluster werden entweder auf eine neuere Nebenversion (z. B. 1.33 bis 1.34) oder eine neuere Patchversion (z. B. 1.33.4-gke.1350000 auf 1.33.5-gke.1080000) aktualisiert. Die Steuerungsebene und die Knoten eines Clusters haben nicht unbedingt immer dieselbe Version. Weitere Informationen zu Versionen finden Sie unter Versionsverwaltung und Support für GKE.

Weitere Informationen zur Funktionsweise von Clusterupgrades, einschließlich automatischer und manueller Upgrades, finden Sie unter GKE-GKE-ClusterClusterupgrades.

Neue GKE-Versionen werden regelmäßig angekündigt. Sie erhalten Benachrichtigungen zu den neuen Versionen, die für die einzelnen Cluster verfügbar sind, mit Clusterbenachrichtigungen. Wenn Sie bestimmte Auto-Upgrade-Ziele für Cluster suchen möchten, rufen Sie Informationen zu den Upgrades eines Clusters ab.

Weitere Informationen zu verfügbaren Versionen finden Sie unter Versionsverwaltung. Weitere Informationen zu Clustern finden Sie unter Clusterarchitektur. Weitere Informationen zum Upgrade von Clustern finden Sie unter Best Practices für das Upgrade von Clustern.

Hinweise

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 diesen Task 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 dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

• Prüfen Sie, ob Sie einen vorhandenen Autopilot- oder Standardcluster haben. Informationen zum Erstellen eines neuen Clusters finden Sie unter Autopilot-Cluster erstellen.

Informationen zu Upgrades

Die Steuerungsebene und Knoten eines Clusters werden separat aktualisiert. Die Steuerungsebene und die Knoten des Clusters haben nicht unbedingt immer dieselbe Version.

Cluster-Steuerungsebenen und Knoten werden regelmäßig aktualisiert, unabhängig davon, ob Ihr Cluster in einer Release-Version registriert ist oder nicht.

Beschränkungen

Für Alphacluster kann kein Upgrade durchgeführt werden.

Unterstützte Versionen

Die Versionshinweise informieren darüber, wann neue Versionen verfügbar sind und wann frühere Versionen nicht mehr erworben werden können. Mit dem folgenden Befehl können Sie jederzeit alle unterstützten Cluster- und Knotenversionen auflisten:

gcloud container get-server-config \
    --location=CONTROL_PLANE_LOCATION

Ersetzen Sie CONTROL_PLANE_LOCATION durch den Standort (Region oder Zone) für die Steuerungsebene, z. B. us-central1 oder us-central1-a.

Wenn Ihr Cluster in einem Release-Kanal registriert ist, können Sie ein Upgrade auf eine Patch-Version in einer anderen Release-Version mit derselben Nebenversion wie auf Ihrer Steuerungsebene durchführen. Beispielsweise können Sie Ihren Cluster von Version 1.33.4-gke.1350000 im Regular Channel auf 1.33.5-gke.1162000 im Rapid Channel aktualisieren. Weitere Informationen finden Sie unter Patchversionen aus einem neueren Kanal ausführen. Alle Autopilot-Cluster sind in Release-Versionen registriert.

Informationen zum Downgrade

In bestimmten Szenarien können Sie ein Downgrade der Version Ihres Clusters auf eine frühere Version ausführen:

• Downgrade des Steuerungsebenen-Patches: Um einem fehlgeschlagenen Upgrade der Cluster-Steuerungsebene entgegenzuwirken, können Sie ein Downgrade der Steuerungsebene auf einen vorherigen Patchrelease durchführen, wenn die Version ein früherer Patchrelease innerhalb der gleichen Nebenversion ist. Wenn auf der Steuerungsebene Ihres Clusters beispielsweise GKE 1.33.5-gke.1080000 ausgeführt wird, können Sie ein Downgrade der Steuerungsebene auf 1.33.4-gke.1350000 durchführen, wenn diese Version noch verfügbar ist.
• Rollback während des zweistufigen Nebenversionsupgrades der Steuerungsebene (Vorschau): Sie können ein Downgrade der Steuerungsebene eines Kubernetes-Clusters auf eine frühere Nebenversion erst nach dem Binär-Upgrade eines zweistufigen Nebenversionsupgrades der Steuerungsebene mit Rollback-Sicherheit durchführen. Wenn GKE den zweiten Schritt des zweistufigen Upgrades, das Upgrade der emulierten Version, bereits abgeschlossen hat, können Sie kein Rollback zur vorherigen Nebenversion durchführen.
• Downgrade des Knotenpools: Um einem fehlgeschlagenen Upgrade des Knotenpools entgegenzuwirken, können Sie für einen Knotenpool ein Downgrade auf einen früheren Patchrelease oder eine Nebenversion durchführen. Achten Sie darauf, dass Sie die Knoten nicht auf eine Version downgraden, die mehr als zwei Nebenversionen hinter der Version der Cluster-Steuerungsebene liegt.

Abgesehen von den in den vorherigen Punkten beschriebenen Szenarien können Sie einen Cluster nicht downgraden. Sie können kein Downgrade einer Cluster-Steuerungsebene auf eine frühere Nebenversion ausführen, auch nicht nach einem einmaligen Nebenversions-Upgrade der Steuerungsebene. Wenn auf der Steuerungsebene beispielsweise die GKE-Version 1.34 ausgeführt wird, ist ein Downgrade auf 1.33 nicht möglich. Wenn Sie dies versuchen, wird die folgende Fehlermeldung angezeigt:

ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400,
message=Master cannot be upgraded to "1.33.4-gke.1350000": specified version is
not newer than the current version.

Wir empfehlen, Upgrades von Nebenversionen mit Clustern in einer Testumgebung zu testen und zu qualifizieren, wenn eine neue Nebenversion verfügbar wird, aber bevor die Version zum Ziel für automatische Upgrades für Ihren Cluster wird. Dies wird insbesondere empfohlen, wenn Ihr Cluster von erheblichen Änderungen in der nächsten Nebenversion betroffen sein könnte, z. B. das Entfernen verworfener APIs oder Features. Weitere Informationen zur Verfügbarkeit von Versionen finden Sie unter Welche Versionen sind in einem Kanal verfügbar?.

Upgrade der Cluster-Steuerungsebene durchführen

GKE führt automatisch Upgrades für die Steuerungsebenen und Knoten von Clustern aus. Informationen dazu, wie Sie steuern können, wie GKE Ihre Cluster aktualisiert, finden Sie unter Cluster-Upgrades steuern.

Bei Autopilot-Clustern und regionalen Standardclustern bleibt die Steuerungsebene während der Upgrades der Steuerungsebene verfügbar. Wenn Sie jedoch ein Upgrade der Steuerungsebene für zonale Cluster initiieren, können Sie die Konfiguration des Clusters erst ändern, wenn die Steuerungsebene nach einigen Minuten wieder zugänglich ist. Upgrades der Steuerungsebene wirken sich nicht auf die Verfügbarkeit der Worker-Knoten aus, auf denen Ihre Arbeitslasten ausgeführt werden, da diese während Upgrades der Steuerungsebene verfügbar bleiben.

Im Rahmen der Verwaltung der Versionen Ihres Clusters können Sie jederzeit ein manuelles Upgrade starten, nachdem eine neue Version verfügbar ist. Verwenden Sie dazu eine der folgenden Methoden:

• Ein-Schritt-Upgrade: Führen Sie so schnell wie möglich ein Upgrade Ihrer Steuerungsebene direkt auf eine spätere Neben- oder Patchversion durch. Sie können diesen Ansatz verwenden, wenn Sie die Leistung Ihres Clusters und Ihrer Arbeitslasten in der neuen Nebenversion bereits validiert haben.
• Zweistufiges Nebenversionsupgrade der Steuerungsebene mit Rollback-Sicherheit (Vorabversion): Aktualisieren Sie die Steuerungsebene in einem zweistufigen Verfahren auf eine höhere Nebenversion. Dabei können Sie die neue Nebenversion über einen bestimmten Zeitraum hinweg validieren und bei Bedarf ein Rollback durchführen. Diese Upgrademethode ist nur für das Upgrade auf Version 1.33 oder höher für manuelle Nebenversionsupgrades der Steuerungsebene verfügbar.

Manuelles Upgrade der Steuerungsebene mit einem Einzelschritt-Upgrade

Sie können Ihre Autopilot- oder Standard-Steuerungsebene manuell über die Cloud de Confiance Console oder die Google Cloud CLI aktualisieren.

gcloud container get-server-config \
    --location=CONTROL_PLANE_LOCATION

gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION

gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=VERSION

Nach dem Upgrade einer Standard-Steuerungsebene können Sie ein Upgrade der Knoten ausführen. Bei Standardknoten, die mit der Cloud de Confiance Console erstellt wurden, ist das automatische Upgrade standardmäßig aktiviert. Autopilot aktualisiert Knoten immer automatisch.

Zweistufiges Nebenversionsupgrade der Steuerungsebene mit Rollback-Sicherheit

Sie können die Steuerungsebene Ihres GKE Autopilot- oder Standard-Clusters manuell in zwei Schritten auf die nächste Nebenversion aktualisieren. In diesem zweistufigen Prozess können Sie testen, wie Ihr Cluster mit der neuen Nebenversion, der binären Version, funktioniert, während Sie die Funktionen und APIs der vorherigen Nebenversion, der emulierten Version, verwenden. Während dieser Testphase, in der die Steuerungsebene im sogenannten emulierten Modus ausgeführt wird, können Sie bei Bedarf ein Rollback auf die vorherige Nebenversion durchführen. Weitere Informationen dazu, wie Kubernetes diese Art von Upgrade ermöglicht, finden Sie unter Compatibility Version For Kubernetes Control Plane Components.

So funktionieren Upgrades in zwei Schritten:

1. Binäres Upgrade: GKE aktualisiert die Binärdatei der Steuerungsebene auf die neue Nebenversion, emuliert aber die vorherige Nebenversion:

   • Emuliert die vorherige Version: Im Cluster wird das neue Binärprogramm ausgeführt, aber das Verhalten der API der vorherigen Nebenversion wird weiterhin emuliert. Sie können beispielsweise APIs aufrufen, die in der neuen Nebenversion entfernt wurden, aber in der vorherigen Nebenversion noch verfügbar sind.
   • Neues Binärprogramm testen: Sie können die neuen Binärprogramme auf Regressionen, Fehlerkorrekturen und Leistungsänderungen testen, bevor Sie die Kubernetes-Funktionen, die mit der neuen Nebenversion verfügbar sind, zugänglich machen. Anwendungsbezogene Messwerte, Logs, Pod-Status, Fehlerraten und Latenz überwachen.
   • Änderungen wirken lassen: Warten Sie sechs Stunden bis sieben Tage, um Zeit zum Testen und Beobachten zu haben. Danach führt GKE das emulierte Versionsupgrade durch.
   • Rollback oder Abschluss des Upgrades: Bei Bedarf können Sie ein Rollback durchführen. Sie können auch mit der nächsten Phase fortfahren, wenn Sie mit der neuen Nebenversion zufrieden sind, nicht warten möchten, bis die Soak-Zeit abgeschlossen ist, und die neuen Funktionen und API-Änderungen nutzen möchten.

2. Emulated version upgrade (Upgrade der emulierten Version): GKE aktualisiert die emulierte Version, damit sie der neuen Binärversion entspricht.

   • Aktiviert neue Funktionen: Alle neuen Funktionen und API-Änderungen der neuen Nebenversion werden aktiviert.
   • Kein Rollback: Nach diesem Schritt können Sie nicht mehr zur ursprünglichen Nebenversion zurückkehren. Das Upgrade ist abgeschlossen.

Bei diesem Vorgang gelten die folgenden Einschränkungen:

• Sie können kein einstufiges Nebenversionsupgrade der Steuerungsebene starten.
• Sie können die Knoten nicht auf eine Version erstellen oder aktualisieren, die neuer als die emulierte Version ist.
• GKE führt keine automatischen Upgrades der Steuerungsebene oder der Knoten durch.

Zweistufiges Upgrade starten

Starten Sie ein zweistufiges Upgrade mit dem folgenden Befehl:

gcloud beta container clusters upgrade CLUSTER_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION \
  --control-plane-soak-duration SOAK_DURATION \
  --master

Ersetzen Sie Folgendes:

• CLUSTER_NAME ist der Name des Clusters.
• CONTROL_PLANE_LOCATION: Der Standort (Region oder Zone) für die Steuerungsebene, z. B. us-central1 oder us-central1-a.
• VERSION: Ein bestimmter Patch der nächsten Nebenversion. Wenn Ihr Cluster beispielsweise Version 1.33 ausführt, 1.34.1-gke.1829001.
• SOAK_DURATION: Die Zeit, die in der Rollback-sicheren Phase gewartet werden soll. Sie können diesen Wert mit den Formaten für absolute Dauer, wie in der Referenz für gcloud topic datetimes beschrieben, auf mindestens 6 Stunden und maximal 7 Tage festlegen. Verwenden Sie beispielsweise 2d1h für eine Einweichzeit von zwei Tagen und einer Stunde.

Neues Binärprogramm während eines zweistufigen Upgrades testen

Prüfen Sie während der Betriebszeit, ob Ihr Cluster, auf dessen Steuerungsebene das neue Binärprogramm ausgeführt wird, und die Arbeitslasten wie erwartet funktionieren. Je nachdem, ob Sie bestätigen können, dass die Arbeitslasten mit dem neuen Binärprogramm kompatibel sind, können Sie einen der folgenden Schritte ausführen:

• Rollback: Wenn Sie ein Problem mit Ihren Arbeitslasten feststellen, die mit dem neuen Binärprogramm ausgeführt werden, können Sie ein Rollback auf die vorherige Nebenversion durchführen.
• Upgrade abschließen: Wenn Sie überprüft haben, dass Ihre Arbeitslasten auf dem neuen Binärprogramm ohne Probleme ausgeführt werden, können Sie das Upgrade abschließen, wenn Sie die Funktionen und APIs der neuen Version verwenden möchten.
• Warten: Sie können auch warten, bis die Einwirkzeit abgelaufen ist. Danach führt GKE das emulierte Versionsupgrade durch, bei dem die Funktionen und APIs der neuen Nebenversion verwendet werden.

Laufendes Upgrade beobachten

Informationen zu einem laufenden Upgrade finden Sie in einer der folgenden Ressourcen:

• Wenn Sie Details zum Upgrade sehen möchten, folgen Sie der Anleitung unter Informationen zu Upgrades auf Clusterebene abrufen.
• Clusterbenachrichtigungen verwenden GKE sendet eine UpgradeEvent-Benachrichtigung, wenn das binäre Upgrade beginnt, und eine UpgradeInfoEvent vom Typ Upgradevorgang abgeschlossen, wenn das binäre Upgrade abgeschlossen ist und die Betriebszeit beginnt.
• Wenn Sie Details zu Ihrem Cluster aufrufen möchten, einschließlich des laufenden Upgrades, führen Sie den Befehl gcloud container clusters describe aus.
• Relevante Logs in Cloud Logging ansehen

Rollback eines zweistufigen Upgrades nach dem Upgrade der binären Version

Bei einem zweistufigen Upgrade folgt auf das Upgrade der binären Version die Testphase. Während dieses Zeitraums können Sie bei Bedarf ein Rollback zur vorherigen Nebenversion durchführen. Nachdem GKE das emulierte Versionsupgrade durchgeführt hat, können Sie kein Rollback mehr ausführen.

Nach Abschluss des Rollback-Vorgangs wird auf der Steuerungsebene die vorherige Nebenversion ausgeführt, die vor dem Start des zweistufigen Upgrades verwendet wurde.

Führen Sie die folgenden Schritte aus, um ein Rollback durchzuführen, sofern dies möglich ist:

1. Prüfen Sie, ob Sie die Steuerungsebene weiterhin auf die vorherige Nebenversion zurücksetzen können, indem Sie den gcloud CLI-Befehl unter Upgrade-Informationen auf Clusterebene abrufen ausführen. Anhand der Ausgabe des Befehls können Sie feststellen, ob Sie ein Rollback durchführen können:

   • Sie können ein Rollback durchführen, wenn in der Ausgabe ein Abschnitt rollbackSafeUpgradeStatus vorhanden ist. Speichern Sie in diesem Abschnitt die previousVersion für die Variable VERSION im nächsten Schritt. Fahren Sie mit dem nächsten Schritt fort.
   • Wenn kein rollbackSafeUpgradeStatus-Abschnitt vorhanden ist, können Sie kein Rollback durchführen. Das bedeutet, dass GKE das emulierte Versionsupgrade bereits durchgeführt hat. Sie können den nächsten Schritt nicht ausführen.

2. Wenn im vorherigen Schritt festgestellt wurde, dass ein Rollback möglich ist, führen Sie ein Rollback auf die vorherige Version durch:

   gcloud container clusters upgrade CLUSTER_NAME \
     --location=CONTROL_PLANE_LOCATION \
     --cluster-version VERSION
     --master
   

   Die VERSION muss genau der zuvor verwendete Patch sein. Sie haben diese Version im vorherigen Schritt gespeichert.

Nachdem Sie diesen Befehl ausgeführt und ein Downgrade auf die vorherige Version durchgeführt haben, können Sie herausfinden, warum Ihre Arbeitslast nicht korrekt mit dem neuen Binärprogramm ausgeführt wurde. Bei Bedarf können Sie sich an Cloud Customer Care wenden und relevante Logs, Fehlermeldungen und Details zum aufgetretenen Validierungsfehler angeben. Weitere Informationen

Nachdem Sie das Problem behoben haben, können Sie noch einmal manuell auf die neue Nebenversion upgraden.

Upgrade in zwei Schritten durchführen

Wenn Sie während der Testphase bestätigt haben, dass die Arbeitslasten mit dem neuen Binärprogramm erfolgreich ausgeführt werden, können Sie die restliche Testzeit überspringen:

gcloud beta container clusters clusters complete-control-plane-upgrade CLUSTER_NAME  \
  --location=CONTROL_PLANE_LOCATION

Nachdem Sie diesen Befehl ausgeführt haben, können Sie kein Downgrade auf die vorherige Nebenversion mehr durchführen.

Downgrade der Steuerungsebene auf eine frühere Patchversion durchführen

1. Legen Sie vor dem Downgrade einen Wartungsausschluss fest, um zu verhindern, dass GKE nach dem Downgrade automatisch ein Upgrade der Steuerungsebene durchführt.

2. Führen Sie ein Downgrade der Cluster-Steuerungsebene auf eine frühere Patchversion durch:

    gcloud container clusters upgrade CLUSTER_NAME \
        --master \
        --location=CONTROL_PLANE_LOCATION \
        --cluster-version=VERSION
   

Automatische Upgrades von Clustern deaktivieren

Die Infrastruktursicherheit hat für GKE höchste Priorität. Daher werden die Steuerungsebenen regelmäßig aktualisiert und können nicht deaktiviert werden. Sie können jedoch Wartungsfenster und -ausschlüsse anwenden, um Upgrades für Steuerungsebenen und Knoten vorübergehend zu blockieren.

Sie können das automatische Upgrade von Knoten für Standardknotenpools deaktivieren. Dieser Vorgang wird jedoch nicht empfohlen.

Letzten Upgradeverlauf der Steuerungsebene prüfen

Einen Snapshot des letzten automatischen Upgradeverlaufs eines Clusters erhalten Sie, wenn Sie Informationen zu den Upgrades eines Clusters abrufen.

Alternativ können Sie die letzten Vorgänge auflisten, um zu sehen, wann die Steuerungsebene aktualisiert wurde:

gcloud container operations list --filter="TYPE:UPGRADE_MASTER AND TARGET:CLUSTER_NAME" \
    --location=CONTROL_PLANE_LOCATION

Upgrade der Knotenpools durchführen

Für Standard-Knotenpools ist standardmäßig auto-upgrade aktiviert. Für alle von Autopilot verwalteten Knotenpools in Standardclustern ist immer „auto-upgrade“ aktiviert. Automatische Knotenupgrades sorgen dafür, dass die Steuerungsebene und die Knotenversion Ihres Clusters synchron bleiben und die Versionsinkompatibilitätsrichtlinie von Kubernetes einhalten. Dadurch wird sichergestellt, dass die Steuerungsebenen mit Knoten kompatibel sind, die bis zu zwei Nebenversionen älter als die Steuerungsebene sind. Die Steuerungsebenen von Kubernetes 1.34 sind beispielsweise mit den Knoten von Kubernetes 1.32 kompatibel.

Bei GKE Standard-Knotenpool-Upgrades haben Sie die Wahl zwischen drei konfigurierbaren Upgradestrategien, darunter Surge-Upgrades, Blau/Grün-Upgrades und automatisch skalierte Blau/Grün-Upgrades (Vorabversion). Für Autopilot-verwaltete Knotenpools in Standardclustern werden immer Surge-Upgrades verwendet.

Bei Standardknotenpools wählen Sie eine Strategie aus und verwenden Sie die Parameter, um die Strategie so zu optimieren, dass sie die Anforderungen Ihrer Clusterumgebung am besten erfüllt.

So funktionieren Knotenupgrades

Beim Upgrade von Knoten wird die Planung neuer Pods für diese Knoten in GKE beendet. In diesem Fall werden die neu geplanten Pods nach Möglichkeit auf anderen Knoten geplant. Dies ist mit anderen Ereignissen vergleichbar, bei denen der Knoten neu erstellt wird, z. B. beim Aktivieren oder Deaktivieren eines Features im Knotenpool.

Während automatischer oder manueller Knotenupgrades werden PodDisruptionBudgets (PDBs) und der Kulanzzeitraum für die Beendigung von Pods maximal eine Stunde lang berücksichtigt. Wenn Pods, die auf dem Knoten ausgeführt werden, nach einer Stunde nicht auf neuen Knoten geplant werden können, führt GKE das Upgrade trotzdem aus. Dieses Verhalten gilt auch, wenn Sie Ihre PDBs so konfigurieren, dass immer alle Repliken verfügbar sind. Dazu setzen Sie das Feld maxUnavailable auf 0 oder 0% oder das Feld minAvailable auf 100% oder auf die Anzahl der Repliken. In all diesen Fällen löscht GKE die Pods nach einer Stunde, damit der Knoten gelöscht werden kann.

Das Upgrade ist erst abgeschlossen, wenn alle Knoten neu erstellt wurden und der Cluster den neuen Status hat. Die aktualisierten Knoten werden bei der Registrierung auf der Steuerungsebene in GKE als planbar gekennzeichnet.

Neue Knoteninstanzen führen die neue Kubernetes-Version aus sowie:

• Knoten-Image
• kubelet
• kube-proxy

Damit ein Knotenpool-Upgrade als abgeschlossen gilt, müssen alle Knoten im Knotenpool neu erstellt werden. Wenn ein Upgrade gestartet, aber nicht abgeschlossen wurde und sich in einem teilweise aktualisierten Zustand befindet, spiegelt die Knotenpoolversion möglicherweise nicht die Version aller Knoten wider. Weitere Informationen finden Sie unter Einige Knotenversionen stimmen nach einem unvollständigen Knotenpool-Upgrade nicht mit der Knotenpoolversion überein. Prüfen Sie den Status des Knotenpool-Upgrades, um festzustellen, ob das Upgrade abgeschlossen ist. Wenn der Upgradevorgang über den Aufbewahrungszeitraum hinausgeht, prüfen Sie, ob jede einzelne Knotenversion mit der Knotenpoolversion übereinstimmt.

Daten vor dem Upgrade auf nichtflüchtigen Speichern speichern

Prüfen Sie vor dem Upgrade eines Knotenpools, ob alle Daten, die Sie beibehalten möchten, in einem Pod mit nichtflüchtigen Volumes gespeichert sind, die nichtflüchtige Speicher verwenden. Nichtflüchtige Speicher werden während der Upgrades getrennt, aber nicht gelöscht. Die darin enthaltenen Daten werden zwischen den Pods übertragen.

Die folgenden Einschränkungen gelten für nichtflüchtige Speicher:

• Die Knoten, auf denen Pods ausgeführt werden, müssen Compute Engine-VMs sein.
• Diese VMs müssen sich im selben Compute Engine-Projekt und in derselben Zone wie der nichtflüchtige Speicher befinden.

Informationen zum Hinzufügen eines nichtflüchtigen Speichers zu einer vorhandenen Knoteninstanz finden Sie in der Compute Engine-Dokumentation unter Zonale nichtflüchtige Speicher hinzufügen oder ihre Größe anpassen.

Knotenpool manuell aktualisieren

Sie können die Version eines Standard-Knotenpools oder eines von Autopilot verwalteten Knotenpools in einem Standardcluster manuell aktualisieren. Sie können die Version der Steuerungsebene verwenden oder eine frühere Version, die noch verfügbar und mit der Steuerungsebene kompatibel ist. Sie können mehrere Knotenpools gleichzeitig manuell aktualisieren, während GKE automatisch jeweils nur einen Knotenpool nacheinander aktualisiert.

Wenn Sie einen Knotenpool manuell aktualisieren, entfernt GKE alle Labels, die Sie einzelnen Knoten mit kubectl hinzugefügt haben. Um dies zu vermeiden, können Sie stattdessen Labels auf Knotenpools anwenden.

Beachten Sie vor dem manuellen Upgrade Ihres Knotenpools die folgenden Bedingungen:

• Das Upgrade eines Knotenpools kann zu Problemen mit den Arbeitslasten führen, die in diesem Knotenpool ausgeführt werden. Dies lässt sich vermeiden, wenn Sie einen neuen Knotenpool mit der erforderlichen Version erstellen und die Arbeitslast migrieren. Nach der Migration können Sie den alten Knotenpool löschen.
• Wenn Sie einen Knotenpool mit einem Ingress-Objekt in einem fehlerhaften Zustand aktualisieren, wird die Instanzgruppe nicht synchronisiert. Zur Umgehung dieses Problems prüfen Sie zuerst den Status mit dem Befehl kubectl get ing. Wenn die Instanzgruppe nicht synchronisiert ist, können Sie das Problem umgehen, indem Sie das Manifest, das zum Erstellen des Ingress-Objekts verwendet wurde, noch einmal anwenden.

Sie können Ihre Knotenpools manuell auf eine Version aktualisieren, die mit der Steuerungsebene kompatibel ist:

• Für Standardknotenpools können Sie die Cloud de Confiance -Konsole oder die Google Cloud CLI verwenden.

• Für von Autopilot verwaltete Knotenpools können Sie nur die Google Cloud CLI verwenden.

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION

Downgrade von Knotenpools ausführen

Sie können beispielsweise ein Downgrade für einen Knotenpool ausführen, um einem fehlgeschlagenen Knotenpool-Upgrade entgegenzuwirken. Lesen Sie sich die Einschränkungen durch, bevor Sie ein Downgrade für einen Knotenpool durchführen.

1. Legen Sie einen Wartungsausschluss für den Cluster fest, um zu verhindern, dass der Knotenpool nach dem Downgrade von GKE automatisch aktualisiert wird.
2. Geben Sie für das Downgrade eines Knotenpools eine frühere Version an, wenn Sie der Anleitung unter Manuelles Upgrade für einen Knotenpool ausführen folgen.

Surge-Upgradeparameter ändern

Weitere Informationen zum Ändern von Surge-Upgrade-Parametern finden Sie unter Surge-Upgrades konfigurieren.

Upgradestatus eines Knotenpools prüfen

Sie können den Status eines Upgrades mit gcloud container operations prüfen.

Rufen Sie eine Liste aller ausgeführten und abgeschlossenen Vorgänge im Cluster auf,die in den letzten 12 Tagen ausgeführt wurden, wenn es weniger als 5.000 Vorgänge gibt,oder die letzten 5.000 Vorgänge:

gcloud container operations list \
    --location=CONTROL_PLANE_LOCATION

Jedem Vorgang werden eine Vorgangs-ID, ein Vorgangstyp, Start- und Endzeiten, Zielcluster und ein Status zugewiesen. Eine solche Liste sieht etwa so aus:

NAME                              TYPE                ZONE           TARGET              STATUS_MESSAGE  STATUS  START_TIME                      END_TIME
operation-1505407677851-8039e369  CREATE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT16:47:57.851933021Z  20xx-xx-xxT16:50:52.898305883Z
operation-1505500805136-e7c64af4  UPGRADE_CLUSTER     us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:40:05.136739989Z  20xx-xx-xxT18:41:09.321483832Z
operation-1505500913918-5802c989  DELETE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:41:53.918825764Z  20xx-xx-xxT18:43:48.639506814Z

Weitere Informationen zu einem bestimmten Vorgang erhalten Sie, wenn Sie die Vorgangs-ID wie im folgenden Befehl angeben:

gcloud container operations describe OPERATION_ID \
    --location=CONTROL_PLANE_LOCATION

Beispiel:

gcloud container operations describe operation-1507325726639-981f0ed6
endTime: '20xx-xx-xxT21:40:05.324124385Z'
name: operation-1507325726639-981f0ed6
operationType: UPGRADE_CLUSTER
selfLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/operations/operation-1507325726639-981f0ed6
startTime: '20xx-xx-xxT21:35:26.639453776Z'
status: DONE
targetLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/clusters/...
zone: us-central1-a

Wenn das Upgrade abgebrochen wurde oder fehlgeschlagen ist und teilweise abgeschlossen wurde, können Sie das Upgrade fortsetzen oder ein Rollback durchführen.

Upgrade-Einstellungen für Knotenpools prüfen

Mit dem Befehl gcloud container node-pools describe können Sie Details zur Aktualisierungsstrategie für Knoten abrufen, die für Ihre Knotenpools verwendet wird. Bei Blau/Grün-Upgrades gibt der Befehl auch die aktuelle Phase des Upgrades zurück.

Führen Sie dazu diesen Befehl aus:

gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Dabei gilt:

• NODE_POOL_NAME ist der Name des zu beschreibenden Knotenpools.
• CLUSTER_NAME ist der Name des Clusters des zu beschreibenden Knotenpools.
• CONTROL_PLANE_LOCATION: Der Standort (Region oder Zone) für die Steuerungsebene, z. B. us-central1 oder us-central1-a.

Mit diesem Befehl werden die aktuellen Upgrade-Einstellungen ausgegeben. Das folgende Beispiel zeigt die Ausgabe, wenn Sie die Blau/Grün-Upgrade-Strategie verwenden.

upgradeSettings:
  blueGreenSettings:
    nodePoolSoakDuration: 1800s
    standardRolloutPolicy:
      batchNodeCount: 1
      batchSoakDuration: 10s
  strategy: BLUE_GREEN

Wenn Sie die Blau/Grün-Upgrade-Strategie verwenden, enthält die Ausgabe auch Details zu den Blau/Grün-Upgrade-Einstellungen und deren aktuelle Zwischenphase. Das folgende Beispiel zeigt, wie dies aussehen könnte:

updateInfo:
  blueGreenInfo:
    blueInstanceGroupUrls:
    - https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{BLUE_INSTANCE_GROUP_NAME}
    bluePoolDeletionStartTime: {BLUE_POOL_DELETION_TIME}
    greenInstanceGroupUrls:
    - https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{GREEN_INSTANCE_GROUP_NAME} 
    greenPoolVersion: {GREEN_POOL_VERSION}
    phase: DRAINING_BLUE_POOL

Upgrade eines Knotenpools abbrechen

Sie können ein Upgrade jederzeit abbrechen. Weitere Informationen dazu, was beim Abbrechen eines Surge-Upgrades geschieht, finden Sie unter Surge-Upgrade abbrechen. Weitere Informationen dazu, was beim Abbrechen eines Blau/Grün-Upgrades geschieht, finden Sie unter Blau/Grün-Upgrade abbrechen.

1. Rufen Sie die Vorgangs-ID des Upgrades ab:

   gcloud container operations list \
         --location=CONTROL_PLANE_LOCATION
   

2. Upgrade abbrechen:

   gcloud container operations cancel OPERATION_ID \
         --location=CONTROL_PLANE_LOCATION
   

Weitere Informationen finden Sie in der Dokumentation zu gcloud container operations cancel.

Upgrade des Knotenpools fortsetzen

Sie können ein Upgrade fortsetzen, indem Sie das Upgrade noch einmal manuell starten und dabei die Zielversion aus dem ursprünglichen Upgrade angeben.

Wenn beispielsweise ein Upgrade fehlgeschlagen ist oder Sie ein laufendes Upgrade pausiert haben, können Sie das abgebrochene Upgrade fortsetzen. Starten Sie dazu das gleiche Upgrade im Knotenpool noch einmal und geben Sie dabei die Zielversion aus dem ursprünglichen Upgradevorgang an.

Weitere Informationen dazu, was beim Fortsetzen eines Upgrades geschieht, finden Sie unter Surge-Upgrade fortsetzen und Blau/Grün-Upgrade.

Verwenden Sie den folgenden Befehl, um ein Upgrade fortzusetzen:

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION

Dabei gilt:

• NODE_POOL_NAME ist der Name des Knotenpools, für den Sie das Upgrade des Knotenpools fortsetzen möchten.
• CLUSTER_NAME ist der Name des Clusters des Knotenpools, für den Sie das Upgrade fortsetzen möchten.
• CONTROL_PLANE_LOCATION: Der Standort (Region oder Zone) für die Steuerungsebene, z. B. us-central1 oder us-central1-a.
• VERSION ist die Zielversion des abgebrochenen Knotenpool-Upgrades.

Weitere Informationen erhalten Sie in der Dokumentation zu gcloud container clusters upgrade.

Rollback für Knotenpool-Upgrade durchführen

Sie können ein Rollback für einen Knotenpool ausführen, um die aktualisierten Knoten auf ihren ursprünglichen Zustand vor dem Upgrade des Knotenpools zurücksetzen.

Verwenden Sie den Befehl rollback, wenn ein laufendes Upgrade abgebrochen wurde, das Upgrade fehlgeschlagen ist oder aufgrund einer Zeitüberschreitung des Wartungsfensters unvollständig ist. Wenn Sie die Version angeben möchten, folgen Sie der Anleitung zum Ausführen eines Downgrades des Knotenpools.

Weitere Informationen dazu, was beim Rollback eines Knotenpool-Upgrades geschieht, finden Sie unter Rollup bei einem Surge-Upgrade rückgängig machen oder Rollvorgang für Blau/Grün-Upgrades durchführen.

Führen Sie den folgenden Befehl aus, um ein Upgrade rückgängig zu machen:

gcloud container node-pools rollback NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Dabei gilt:

• NODE_POOL_NAME ist der Name des Knotenpools, für den ein Rollback durchgeführt werden soll.
• CLUSTER_NAME ist der Name des Clusters des Knotenpools, für den das Upgrade rückgängig gemacht werden soll.
• CONTROL_PLANE_LOCATION: Der Standort (Region oder Zone) für die Steuerungsebene, z. B. us-central1 oder us-central1-a.

Weitere Informationen finden Sie in der Dokumentation zu gcloud container node-pools rollback.

Upgrade für Knotenpools ausführen

Wenn Sie die Blau/Grün-Upgradestrategie verwenden, können Sie während der Betriebsphase ein Upgrade für einen Knotenpool ausführen und die restliche Betriebszeit überspringen.

Informationen zum Abschluss eines Knotenpool-Upgrades finden Sie unter Knoten-Upgrade abschließen.

Führen Sie den folgenden Befehl aus, um ein Upgrade bei Verwendung der Blau/Grün-Upgradestrategie durchzuführen:

gcloud container node-pools complete-upgrade NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Dabei gilt:

• NODE_POOL_NAME ist der Name des Knotenpools, für den Sie das Upgrade ausführen möchten.
• CLUSTER_NAME ist der Name des Clusters des Knotenpools, für den Sie das Upgrade ausführen möchten.
• CONTROL_PLANE_LOCATION: Der Standort (Region oder Zone) für die Steuerungsebene, z. B. us-central1 oder us-central1-a.

Weitere Informationen finden Sie in der Dokumentation zu gcloud container node-pools complete-upgrade.

Bekannte Probleme

Wenn Sie PodDisruptionBudget-Objekte konfiguriert haben, die keine zusätzlichen Unterbrechungen zulassen, werden Knotenupgrades nach wiederholten Versuchen möglicherweise nicht auf die Version der Steuerungsebene aktualisiert. Zur Vermeidung dieses Fehlers empfehlen wir eine vertikale Skalierung von Deployment oder HorizontalPodAutoscaler, damit der Knoten unter Berücksichtigung der PodDisruptionBudget-Konfiguration entleert wird.

So rufen Sie alle PodDisruptionBudget-Objekte auf, die keine Unterbrechungen zulassen:

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Obwohl das Problem bei automatischen Upgrades auftreten kann, erzwingt der automatische Upgrade-Prozess ein Upgrade der Knoten. Das Upgrade dauert jedoch für jeden Knoten im Namespace istio-system, der gegen das PodDisruptionBudget verstößt, eine zusätzliche Stunde.

Fehlerbehebung

Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung bei Clusterupgrades.

Nächste Schritte

• Weitere Informationen zu Knotenupgrade-Strategien
• Informationen zu Clusterupgrades
• Automatische Knotenupgrades
• Informationen zu Wartungsfenstern und ‑ausschlüssen