Manuelles Upgrade eines Clusters oder Knotenpools

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:

Mit den folgenden Methoden können Sie die gcloud-Einstellungen festlegen:

  • Verwenden Sie gcloud init, wenn Sie die Standardeinstellungen ansehen möchten.
  • Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region individuell festzulegen.

gcloud init verwenden

Wenn Sie die Fehlermeldung One of [--zone, --region] must be supplied: Please specify location erhalten, führen Sie diesen Abschnitt aus.

  1. 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
  2. Folgen Sie der Anleitung, um gcloud zur Verwendung Ihres Google Cloud-Kontos zu autorisieren.
  3. Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene aus.
  4. Wählen Sie ein Google Cloud-Projekt aus.
  5. Wählen Sie eine Compute Engine-Standardzone für zonale Cluster oder eine Region für regionale oder Autopilot-Cluster aus.

gcloud config verwenden

  • Legen Sie Ihre standardmäßige Projekt-ID fest: 
    gcloud config set project PROJECT_ID
  • Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Standardzone für Compute Engine fest: 
    gcloud config set compute/zone COMPUTE_ZONE
  • Wenn Sie mit Autopilot oder regionalen Clustern arbeiten, legen Sie die Compute-Standardregion fest: 
    gcloud config set compute/region COMPUTE_REGION
  • Aktualisieren Sie gcloud auf die neueste Version:
    gcloud components update

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.

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

Bekannte Probleme

Wenn Anthos Service Mesh oder OSS Istio in Ihrem Cluster installiert ist, werden die Nutzerknoten je nach PodDisruptionBudget-Einstellungen für die Istio-Komponenten möglicherweise nach wiederholten Versuchen nicht auf die Version der Steuerungsebene aktualisiert. Zur Vermeidung diese Problems empfehlen wir, die minReplicas-Einstellung für das horizontale Pod-Autoscaling vor dem Upgrade von 1 auf 2 für die Komponenten im Namespace istio-system zu erhöhen. Dadurch wird immer eine Instanz der ASM-Steuerungsebene ausgeführt.

Wenn Sie Anthos Service Mesh 1.5 (oder höher) oder OSS Istio 1.5 (oder höher) verwenden:

kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istiod -p '{"spec":{"minReplicas": 2}}' --type=merge

Wenn Sie Anthos Service Mesh 1.4.x oder OSS Istio 1.4.x verwenden:

kubectl patch hpa -n istio-system istio-galley -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istio-nodeagent -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istio-pilot -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istio-sidecar-injector -p '{"spec":{"minReplicas": 2}}' --type=merge

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.

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 gcloud-Befehlszeilentool 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:

  1. Rufen Sie in der Cloud Console die Seite Google Kubernetes Engine auf:

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie auf den gewünschten Clusternamen.

  3. Klicken Sie unter Clustergrundlagen neben Version auf Upgrade verfügbar.

  4. 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:

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 alle Labels, die Sie einzelnen Knoten mit kubectl hinzugefügt haben. Dies können Sie vermeiden, wenn Sie stattdessen Labels auf Knotenpools anwenden (Vorschau).

Sie können Ihre Knotenpools mithilfe der Google Cloud Console oder mit dem gcloud-Befehlszeilentool manuell auf eine Version aktualisieren, die mit der Steuerungsebene kompatibel ist.

gcloud

Führen Sie zum Aktualisieren aller Knoten auf die Version der Steuerungsebene den Befehl gcloud container clusters upgrade aus:

gcloud container clusters upgrade CLUSTER_NAME

Ersetzen Sie CLUSTER_NAME durch den Namen des zu aktualisierenden Clusters.

Wenn Sie einen bestimmten Knotenpool aktualisieren möchten, geben Sie das Flag --node-pool an:

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

Ersetzen Sie VERSION durch die Kubernetes-Version, auf die die Knoten aktualisiert werden. Beispiel: --cluster-version=1.7.2 oder cluster-version=latest.

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:

Führen Sie die folgenden Schritte aus, um einen Knotenpool zu aktualisieren:

  1. Rufen Sie in der Cloud Console die Seite Google Kubernetes Engine auf:

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie neben dem Cluster, den Sie bearbeiten möchten, auf Aktionen und dann auf Bearbeiten.

  3. Klicken Sie auf der Seite Clusterdetails auf den Tab Knoten.

  4. Klicken Sie im Bereich Knotenpools auf den Namen des Knotenpools, den Sie aktualisieren möchten.

  5. Klicken Sie auf  Bearbeiten.

  6. Klicken Sie unter Knotenversion auf Ändern.

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

  1. Die Vorgangs-ID des Upgrades rufen Sie mit dem folgenden Befehl ab:

    gcloud container operations list

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

Nächste Schritte