Standardmäßig sind automatische Upgrades für GKE-Cluster und -Knotenpools (Google Kubernetes Engine-Cluster) aktiviert.
Auf dieser Seite wird gezeigt, wie Sie manuell ein Upgrade oder Downgrade für einen GKE-Cluster oder dessen Knoten anfordern. Weitere Informationen zur Funktionsweise automatischer und manueller Clusterupgrades erhalten Sie unter Clusterupgrades. Sie können auch festlegen, wann automatische Upgrades ausgeführt werden sollen. Dazu müssen Sie entsprechende Wartungsfenster und -ausschlüsse konfigurieren.
Neue GKE-Versionen werden regelmäßig angekündigt. 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.
Hinweis
Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:
- Achten Sie darauf, dass die Google Kubernetes Engine API aktiviert ist. Google Kubernetes Engine API aktivieren
- Prüfen Sie, ob die Google Cloud CLI installiert ist.
- Mit den folgenden Methoden können Sie die Standardeinstellungen der Google Cloud CLI für Ihr Projekt einrichten:
- Verwenden Sie
gcloud init
, wenn Sie die Standardeinstellungen für Projekte ansehen möchten. - Verwenden Sie
gcloud config
, um Ihre Projekt-ID, Zone und Region individuell festzulegen. -
Führen Sie
gcloud init
aus und folgen Sie der Anleitung:gcloud init
Wenn Sie SSH auf einem Remote-Server verwenden, können Sie mit dem Flag
--console-only
verhindern, dass mit dem Befehl ein Browserfenster geöffnet wird:gcloud init --console-only
- Folgen Sie der Anleitung, um die gcloud CLI für die Nutzung Ihres Google Cloud-Kontos zu autorisieren.
- Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene aus.
- Wählen Sie ein Google Cloud-Projekt aus.
- Wählen Sie eine Compute Engine-Standardzone aus.
- Wählen Sie eine Compute Engine-Standardregion aus.
- Legen Sie Ihre standardmäßige Projekt-ID fest:
gcloud config set project PROJECT_ID
- Legen Sie Ihre standardmäßige Compute Engine-Region fest (z. B.
us-central1
):gcloud config set compute/region COMPUTE_REGION
- Legen Sie Ihre standardmäßige Compute Engine-Zone fest (z. B.
us-central1-c
):gcloud config set compute/zone COMPUTE_ZONE
- Aktualisieren Sie
gcloud
auf die neueste Version:gcloud components update
gcloud init
gcloud config
Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location
vermeiden.
Daten 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üchtigen Speicher verwenden. Nichtflüchtige Speicher werden während der Upgrades getrennt, aber nicht gelöscht. Die darin enthaltenen Daten werden zwischen den Pods "übergeben".
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.
Informationen zu Upgrades
Die Steuerungsebene und Knoten eines Clusters werden separat aktualisiert.
Cluster-Steuerungsebenen werden immer regelmäßig aktualisiert, unabhängig davon, ob Ihr Cluster in einer Release-Version registriert ist oder nicht.
Wie Sie proaktiv Upgrade-Benachrichtigungen erhalten, erfahren Sie unter Clusterbenachrichtigungen erhalten.
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 ältere 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
Downgrade-Einschränkungen
Ein Downgrade einer Cluster-Steuerungsebene wird nicht empfohlen. Das Downgrade einer Cluster-Steuerungsebene von einer Nebenversion auf eine andere ist nicht möglich. Wenn auf der Steuerungsebene beispielsweise die GKE-Version 1.17.17 ausgeführt wird, ist ein Downgrade auf 1.16.15 nicht möglich. Wenn Sie dies versuchen, wird ein Fehler wie der folgende angezeigt.
ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400,
message=Master cannot be upgraded to "1.16.15-gke.6000": specified version is not
newer than the current version.
Ein Downgrade von Kubernetes-Nebenversionen oder -Patches wird nicht empfohlen und sollte nur als Abhilfe für ein fehlgeschlagenes Upgrade verwendet werden.
Sie können ein Upgrade Ihres Clusters auf eine vorherige Patchversion durchführen, um einem fehlgeschlagenen Upgrade der Cluster-Steuerungsebene entgegenzuwirken. Die Patchversion ist dabei die gleiche Nebenversion wie Ihr Cluster. Wenn in Ihrem Cluster beispielsweise GKE 1.17.17 ausgeführt wird, können Sie ein Downgrade auf 1.17.16 durchführen, sofern diese Version noch verfügbar ist.
Um einem fehlgeschlagenen Upgrade des Knotenpools entgegenzuwirken, können Sie für einen Knotenpool ein Downgrade auf eine Patchversion durchführen, die älter als die Version der Cluster-Steuerungsebene ist. Knoten können nicht mehr als zwei Nebenversionen hinter der Version der Cluster-Steuerungsebene sein.
Upgrade des Clusters ausführen
Google führt automatisch Upgrades für Cluster und Knoten aus. Für eine bessere Kontrolle automatischer Upgrades für Ihren Cluster und seine Knoten können Sie ihn für einen Releasekanal registrieren.
Weitere Informationen zur Verwaltung der GKE-Version des Clusters finden Sie unter Upgrades.
Sie können jederzeit ein manuelles Upgrade ausführen, wenn eine neue Version zur Verfügung steht.
Manuelles Upgrade der Steuerungsebene
Wenn Sie ein Clusterupgrade ausführen, können Sie die Konfiguration des Clusters erst dann ändern, wenn die Steuerungsebene wieder zugänglich ist. Dies kann mehrere Minuten dauern. Durch das Verwenden eines regionalen Clusters können Sie Ausfallzeiten bei Steuerungsebeneupgrades vermeiden.
Sie haben die Möglichkeit, Ihren Cluster manuell mit der Cloud Console oder mit dem Google Cloud CLI zu aktualisieren. Nach dem Upgrade Ihres Clusters können Sie dessen Knoten aktualisieren. Bei Knoten, die mit der Google Cloud Console erstellt wurden, ist das automatische Upgrade standardmäßig aktiviert.
gcloud
Führen Sie den folgenden Befehl aus, um die verfügbaren Versionen für die Steuerungsebene Ihres Clusters anzuzeigen:
gcloud container get-server-config
Führen Sie den folgenden Befehl aus, um ein Upgrade auf die Standard-Clusterversion durchzuführen:
gcloud container clusters upgrade CLUSTER_NAME --master
Wenn Sie ein Upgrade auf eine bestimmte Version ausführen möchten, die nicht die Standardversion ist, geben Sie das Flag --cluster-version
wie im folgenden Befehl an:
gcloud container clusters upgrade CLUSTER_NAME --master \
--cluster-version VERSION
Ersetzen Sie VERSION
durch die Version, auf die Sie Ihren Cluster aktualisieren möchten. Sie können eine bestimmte Version verwenden, z. B. 1.18.17-gke.100
, oder einen Versionsalias wie latest
verwenden. Weitere Informationen finden Sie unter Clusterversion angeben.
Console
Führen Sie die folgenden Schritte aus, um die Steuerungsebene des Clusters manuell zu aktualisieren:
Rufen Sie in der Cloud Console die Seite Google Kubernetes Engine auf:
Klicken Sie auf den gewünschten Clusternamen.
Klicken Sie unter Clustergrundlagen neben Version auf edit Upgrade verfügbar.
Wählen Sie die gewünschte Version aus und klicken Sie dann auf Änderungen speichern.
Cluster-Downgrades
Ändern Sie die Version der Cluster-Steuerungsebene mit dem folgenden Befehl, um ein Downgrade des Clusters auf eine vorherige Patchversion durchzuführen:
gcloud container clusters upgrade CLUSTER_NAME \
--master --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 deaktivieren. Dieser Vorgang wird jedoch nicht empfohlen.
Knotenpools aktualisieren
Für die Knoten eines Clusters ist standardmäßig das automatische Upgrade aktiviert. Wir empfehlen, dies nicht zu deaktivieren.
Wenn für einen Knotenpool ein Upgrade durchgeführt wird, können Sie Einstellungen für Surge-Upgrades konfigurieren, um zu steuern, wie viele Knoten GKE gleichzeitig aktualisiert und wie das Upgrade Arbeitslasten beeinträchtigen wird. Standardmäßig aktualisiert GKE jeden Knoten einzeln.
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.
Das Upgrade ist erst abgeschlossen, wenn alle Knoten neu erstellt worden sind und der Cluster den gewünschten Status hat. Die aktualisierten Knoten werden bei der Registrierung auf der Steuerungsebene in GKE als planbar gekennzeichnet.
Neue Knoteninstanzen führen die gewünschte Kubernetes-Version aus sowie:
- Knoten-Image
- Docker-Daemon, falls zutreffend
kubelet
kube-proxy
Knotenpool manuell aktualisieren
Sie können die Version eines Knotenpools manuell auf die Version der Steuerungsebene oder auf eine frühere Version aktualisieren, die noch verfügbar und mit der Steuerungsebene kompatibel ist. Die Supportrichtlinie für Kubernetes-Versionen und Versionsinkompatibilität sorgt dafür, dass Steuerungsebenen mit Knoten kompatibel sind, die bis zu zwei Nebenversionen älter sind als die Steuerungsebene. Die Kubernetes-Steuerungsebenen 1.13 sind beispielsweise mit den Kubernetes-Knoten 1.11 kompatibel.
Wenn Sie einen Knotenpool manuell aktualisieren, entfernt GKE alleLabels, die Sie einzelnen Knoten mit kubectl
hinzugefügt haben.
Um dies zu vermeiden, können Sie stattdessen Labels auf Knotenpools anwenden (Vorschau).
Sie können Knotenpools mithilfe der Google Cloud Console oder der Google Cloud CLI manuell auf eine Version aktualisieren, die mit der Steuerungsebene kompatibel ist.
gcloud
Die folgenden Variablen werden in den Befehlen in diesem Abschnitt verwendet:
CLUSTER_NAME
ist der Name des Clusters des Knotenpools, der aktualisiert werden soll.NODE_POOL_NAME
ist der Name des Knotenpools, der aktualisiert werden soll.VERSION
ist die Kubernetes-Version, auf die die Knoten aktualisiert werden. Beispiel:--cluster-version=1.7.2
odercluster-version=latest
.
Knotenpool aktualisieren:
gcloud container clusters upgrade CLUSTER_NAME \
--node-pool=NODE_POOL_NAME
Wenn Sie für Knoten eine andere Version von GKE angeben möchten, verwenden Sie das optionale Flag --cluster-version
:
gcloud container clusters upgrade CLUSTER_NAME \
--node-pool=NODE_POOL_NAME \
--cluster-version VERSION
Weitere Informationen zum Festlegen von Versionen finden Sie unter Versionsverwaltung.
Weitere Informationen finden Sie in der Dokumentation zu gcloud container clusters upgrade
.
Console
So aktualisieren Sie einen Knotenpool mithilfe der Cloud Console:
Rufen Sie in der Cloud Console die Seite Google Kubernetes Engine auf:
Klicken Sie neben dem Cluster, den Sie bearbeiten möchten, auf more_vert Aktionen und dann auf edit Bearbeiten.
Klicken Sie auf der Seite Clusterdetails auf den Tab Knoten.
Klicken Sie im Bereich Knotenpools auf den Namen des Knotenpools, den Sie aktualisieren möchten.
Klicken Sie auf edit Bearbeiten.
Klicken Sie unter Knotenversion auf Ändern.
Wählen Sie die gewünschte Version aus der Drop-down-Liste Knotenversion aus und klicken Sie auf Ändern.
Knotenpools downgraden
Upgradestatus eines Knotenpools prüfen
Sie können den Status eines Upgrades mit gcloud beta container operations
prüfen.
So zeigen Sie eine Liste aller ausgeführten und abgeschlossenen Vorgänge im Cluster an:
gcloud beta container operations list
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 in folgenden Befehl eingeben:
gcloud beta container operations describe OPERATION_ID
Beispiel:
gcloud beta 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
Upgrade eines Knotenpools abbrechen
Sie können ein Upgrade jederzeit abbrechen. Dabei gilt:
- Knoten, die das Upgrade gestartet haben, schließen es auch ab.
- Knoten, die das Upgrade nicht gestartet haben, werden nicht aktualisiert.
- Knoten, die das Upgrade bereits erfolgreich abgeschlossen haben, sind davon nicht betroffen und werden nicht zurückgesetzt.
Die Vorgangs-ID des Upgrades rufen Sie mit dem folgenden Befehl ab:
gcloud container operations list
Führen Sie den folgenden Befehl aus, um das Upgrade abzubrechen:
gcloud beta container operations cancel OPERATION_ID
Weitere Informationen finden Sie in der Dokumentation zu gcloud container operations cancel
.
Upgrade eines Knotenpools rückgängig machen
Sie können für Knotenpools, deren Upgrade nicht korrekt ausgeführt wurde, ein Rollback durchführen, sodass wieder die vorherige Version von Kubernetes angewendet wird. Sie können für Knotenpools kein Rollback mehr durchführen, nachdem sie erfolgreich aktualisiert worden sind. Knoten, die kein Upgrade gestartet haben, sind davon nicht betroffen.
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
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, von dem aus der Knotenpool zurückgesetzt werden soll.
Weitere Informationen finden Sie in der Dokumentation zu gcloud container node-pools rollback
.
Surge-Upgradeparameter ändern
Mit Surge-Upgrades können Sie die Anzahl der Knoten, die GKE in einem Schritt aktualisiert, sowie den Umfang der Unterbrechung, die ein Upgrade bei Ihren Arbeitslasten verursacht, ändern.
Die Flags max-surge-upgrade
und max-unavailable-upgrade
sind für jeden Knotenpool definiert. Weitere Informationen zur Auswahl der richtigen Parameter finden Sie unter Optimale Surge-Konfiguration ermitteln.
Sie können diese Einstellungen ändern, wenn Sie einen Cluster oder Knotenpool erstellen oder aktualisieren.
Die folgenden Variablen werden in den unten aufgeführten Befehlen verwendet:
CLUSTER_NAME
: Der Name des Clusters für den Knotenpool.COMPUTE_ZONE
: Die Zone für den Cluster.NODE_POOL_NAME
ist der Name des Knotenpools.NUMBER_NODES
: Die Anzahl der Knoten im Knotenpool in jeder der Clusterzonen.SURGE_NODES
: Die Anzahl der zusätzlichen Knoten (Surge), die bei jedem Upgrade des Knotenpools erstellt werden.UNAVAILABLE_NODES
: Die Anzahl der Knoten, die bei jedem Upgrade des Knotenpools gleichzeitig nicht verfügbar sein können.
Cluster mit unterschiedlichen Surge-Parametern erstellen
Verwenden Sie die Flags max-surge-upgrade
und max-unavailable-upgrade
, um einen Cluster mit spezifischen Einstellungen für Surge-Upgrades zu erstellen.
gcloud container clusters create CLUSTER_NAME \ --max-surge-upgrade=SURGE_NODES --max-unavailable-upgrade=UNAVAILABLE_NODES
Cluster mit deaktiviertem Surge-Upgrade erstellen
Wenn Sie einen Cluster ohne Surge-Upgrades erstellen möchten, legen Sie den Wert für das Flag max-surge-upgrade
auf 0
fest.
gcloud container clusters create CLUSTER_NAME \ --max-surge-upgrade=0 --max-unavailable-upgrade=1
Knotenpool mit unterschiedlichen Surge-Parametern erstellen
Verwenden Sie die Flags max-surge-upgrade
und max-unavailable-upgrade
, um einen Knotenpool in einem vorhandenen Cluster mit spezifischen Einstellungen für Surge-Upgrades zu erstellen.
gcloud container node-pools create NODE_POOL_NAME \ --num-nodes=NUMBER_NODES --cluster=CLUSTER_NAME \ --max-surge-upgrade=SURGE_NODES --max-unavailable-upgrade=UNAVAILABLE_NODES
Surge-Upgrade für einen vorhandenen Knotenpool aktivieren oder deaktivieren
Verwenden Sie die Flags max-surge-upgrade
und max-unavailable-upgrade
, um die Upgradeeinstellungen eines vorhandenen Knotenpools zu aktualisieren. Wenn Sie max-surge-upgrade
auf einen größeren Wert als 0
festlegen, erstellt GKE Surge-Knoten. Wenn Sie max-surge-upgrade
auf 0
festlegen, erstellt GKE keine Surge-Knoten.
gcloud beta container node-pools update NODE_POOL_NAME \ --cluster=CLUSTER_NAME \ --max-surge-upgrade=SURGE_NODES --max-unavailable-upgrade=UNAVAILABLE_NODES
Surge-Upgrades in einem Knotenpool auf Aktivierung prüfen
Wenn Sie prüfen möchten, ob Surge-Upgrades für einen Knotenpool aktiviert sind, verwenden Sie gcloud
zum Beschreiben der Parameter des Clusters:
gcloud container node-pools describe NODE_POOL_NAME \ --cluster=CLUSTER_NAME
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
Knoten-CPU-Auslastung höher als erwartet
Möglicherweise stoßen Sie auf ein Problem, bei dem einige Knoten eine höhere CPU-Auslastung verwenden, als von den ausgeführten Pods erwartet.
Dieser Fehler kann auftreten, wenn auf dem Cluster oder den Knoten keine unterstützte Version ausgeführt wird. Lesen Sie die Versionshinweise, um sicherzustellen, dass die von Ihnen verwendeten Versionen verfügbar und unterstützt werden. Sie können auch den folgenden Befehl ausführen, um alle unterstützten Cluster- und Knotenversionen aufzulisten:
gcloud container get-server-config