Manuelles Upgrade eines Clusters oder Knotenpools

Standardmäßig werden Cluster und Knotenpools von Google Kubernetes Engine automatisch von Google aktualisiert. 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.

Hinweis zur Terminologie: Die Steuerungsebene eines Controllers (Master) und seine Knoten müssen nicht unbedingt die gleiche Version haben. In diesem Thema werden Clusterupgrade und Upgrade der Steuerungsebene austauschbar verwendet, aber von Knotenupgrades unterschieden.

Neue GKE-Versionen werden regelmäßig angekündigt. Informationen zu den verfügbaren Versionen erhalten Sie unter Versionsverwaltung und Upgrades. 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.
Aktivieren Sie Google Kubernetes Engine API
• Prüfen Sie, ob das Cloud SDK installiert ist.

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

Hinweis: Sie können diese Standardeinstellungen in gcloud-Befehlen mit den Flags --project, --zone und --region überschreiben.

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 Compute-Standardzone fest:

  gcloud config set compute/zone compute-zone

• Wenn Sie mit regionalen Clustern arbeiten, legen Sie die Standardregion für Compute Engine fest:

  gcloud config set compute/region compute-region

• Aktualisieren Sie gcloud auf die neueste Version:

  gcloud components update

Hinweis: Sie können diese Standardeinstellungen in gcloud-Befehlen mit den Flags --project, --zone und --region überschreiben.

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.

Clusterupgrade

Die Steuerungsebene und Knoten eines Clusters werden separat aktualisiert.

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

Vom Downgrade eines Clusters wird abgeraten. Knoten können auf eine Patch-Version herabgestuft werden, die älter als die Clusterversion ist. Das Downgrade eines Clusters von einer Nebenversion auf eine andere Nebenversion ist nicht möglich. Wenn in einem Cluster beispielsweise GKE 1.11.5 ausgeführt wird, können Sie ein Downgrade auf 1.11.4 durchführen, sofern die Version noch verfügbar ist. Ein Downgrade auf 1.10.9 ist jedoch nicht möglich. Sie erhalten in diesem Fall in etwa folgende Fehlermeldung:

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

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 Versionsverwaltung und Upgrades.

Sie können jederzeit ein manuelles Upgrade ausführen, wenn eine neue Version zur Verfügung steht.

Manuelles Upgrade der Steuerungsebene

Hinweis: Sie können ein Upgrade für Ihren Cluster jeweils nur auf die folgende Nebenversion ausführen. Beispielsweise ist ein Upgrade für einen Cluster von Version 1.12.x auf 1.13.x, aber nicht direkt von 1.11.x auf 1.13.x möglich. Weitere Informationen finden Sie unter Versionsverwaltung und Upgrades.

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

Lassen Sie zuerst die verfügbaren Versionen mit dem folgenden Befehl anzeigen, um die Version der Cluster-Steuerungsebene zu aktualisieren:

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 durchführen möchten, die nicht die Standardversion ist, führen Sie den folgenden Befehl aus:

gcloud container clusters upgrade cluster-name \
  --master --cluster-version cluster-version

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

Console

Führen Sie die folgenden Schritte aus, um die Steuerungsebene des Clusters manuell zu aktualisieren:

1. Rufen Sie in der Google Cloud Console das Menü von Google Kubernetes Engine auf.

   Zum Google Kubernetes Engine-Menü

2. Wählen Sie den gewünschten Cluster aus.

3. Klicken Sie neben Masterversion auf den Link Upgrade verfügbar.

4. Wählen Sie die gewünschte Version aus und klicken Sie dann auf Ändern.

5. Klicken Sie oben auf dem Bildschirm auf den Pfeil, um zur Seite "Clusterübersicht" zurückzukehren.

Cluster-Downgrades

Hinweis: Bevor Sie ein Downgrade für einen Cluster ausführen, sollten Sie sich mit den damit verbundenen Einschränkungen vertraut machen.

Ä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 downgrade-version

Automatische Upgrades von Clustern deaktivieren

Automatische Upgrades von Clustern können nicht deaktiviert werden. Obwohl es nicht empfohlen wird, können Sie aber das automatische Upgrade von Knoten deaktivieren.

Upgrade für Knoten ausführen

Für die Knoten eines Clusters ist standardmäßig das automatische Upgrade aktiviert. Wir empfehlen, dies nicht zu deaktivieren.

Wenn ein Knotenpool aktualisiert wird, führt GKE das Upgrade für jeden Knoten nacheinander aus.

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. Der Knoten wird dann in der neuen Version, aber mit dem gleichen Namen wie zuvor neu erstellt. Dies ist mit anderen Ereignissen vergleichbar, bei denen der Knoten neu erstellt wird, z. B. beim Aktivieren oder Deaktivieren eines Features im Knotenpool.

Hinweis: Während der automatischen oder manuellen Aktualisierung werden PodDisruptionBudgets (PDBs) für maximal eine Stunde berücksichtigt. Wenn Pods, die auf einem Knoten ausgeführt werden, nicht innerhalb einer Stunde auf neuen Knoten geplant werden können, wird das Upgrade unabhängig davon trotzdem ausgeführt.
Weitere Informationen über die Folgen der Beendigung von Knoten im Allgemeinen finden Sie im Thema zu Pods.

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

Manuelles Upgrade eines Knotens ausführen

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.

Hinweis: 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 gewünschten Version erstellen und die Arbeitslast migrieren. Nach der Migration können Sie den alten Knotenpool löschen.

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

gcloud

Mit dem folgenden Befehl wird ein Upgrade Ihrer Knoten auf die Version durchgeführt, die auf Ihrer Steuerungsebene ausgeführt wird:

gcloud container clusters upgrade cluster-name \
  --node-pool=node-pool-name

wobei cluster-name der Name des Clusters ist, der aktualisiert werden soll.

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 cluster-version

Dabei ist cluster-version die Kubernetes-Version, auf die ein Upgrade der Knoten vorgenommen werden soll. Beispiel: --cluster-version=1.7.2oder cluster-version=latest

Weitere Informationen zum Festlegen von Versionen finden Sie unter Versionsverwaltung und Upgrades.

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

Console

So aktualisieren Sie einen Knotenpool mithilfe der Cloud Console:

1. Rufen Sie in der Cloud Console das Kubernetes Engine-Menü auf.

   Zum Google Kubernetes Engine-Menü

2. Klicken Sie auf die Schaltfläche "Bearbeiten" (Stiftsymbol) des Clusters.

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

4. Klicken Sie auf Bearbeiten.

5. Klicken Sie neben Knotenversion auf den Link Ändern.

6. Wählen Sie die gewünschte Version aus und klicken Sie dann auf Ändern.

7. Klicken Sie auf Speichern.

Hinweis: Es kann einige Minuten dauern, bis die Knotenversion geändert wird.

Downgrade von Knoten ausführen

Für einen Knotenpool kann kein Downgrade ausgeführt werden. Erstellen Sie stattdessen mit der gewünschten Version einen neuen Knotenpool und migrieren Sie Ihre Arbeitslasten dorthin. Knoten, für die das automatische Upgrade aktiviert ist, werden auf die Steuerungsebenenversion aktualisiert.

Status der Knotenaktualisierung prüfen

Beta

Dieses Produkt oder Feature unterliegt den Nutzungsbedingungen des Pre-GA-Angebots in den Nutzungsbedingungen der Google Cloud Platform. Pre-GA-Produkte und -Features werden eventuell nur eingeschränkt unterstützt. Änderungen an Pre-GA-Produkten und -Features sind möglicherweise nicht mit anderen Pre-GA--Versionen kompatibel. Weitere Informationen finden Sie unter Beschreibungen der Startphase.

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

Hinweis: Wenn Sie Befehle des Typs gcloud beta verwenden möchten, müssen Sie gcloud für die Verwendung der v1beta1 API konfigurieren.

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

Knotenupgrade abbrechen

Beta — gcloud container operations

Dieses Feature unterliegt den Nutzungsbedingungen des Pre-GA-Angebots in den Nutzungsbedingungen der Google Cloud Platform. Pre-GA-Features werden eventuell nur eingeschränkt unterstützt. Änderungen an diesen Features sind möglicherweise nicht mit anderen Pre-GA-Versionen kompatibel. Weitere Informationen finden Sie unter Beschreibungen der Startphase.

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.

Knotenupgrade 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, dessen Upgrade rückgängig gemacht werden soll.
• cluster-name ist der Name des Clusters, von dem aus ein Rollback für den Knotenpool durchgeführt 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.

Hinweis: Alle neuen Knotenpools sind automatisch zur Verwendung von Surge-Upgrades konfiguriert. maxSurge=1 maxUnavailable=0 Wie Sie Ihre Konfiguration optimieren, erfahren 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 ist der Name des Clusters für den Knotenpool.
• compute-zone ist die Zone für den Cluster.
• node-pool-name ist der Name des Knotenpools.
• number-nodes ist die Anzahl der Knoten im Knotenpool in jeder Zone des Clusters.
• surge-nodes ist die Anzahl der zusätzlichen Knoten, die bei jedem Upgrade des Knotenpools erstellt werden.
• unavailable-nodes ist 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

Hinweis: Für die Neuerstellung von Knoten sind keine zusätzlichen Compute Engine-Ressourcen erforderlich. Für Surge-Upgrades hingegen benötigen Sie zusätzliche Ressourcen. Die Ressourcenzuweisung unterliegt einem Compute Engine-Kontingent. Je nach Konfiguration kann dieses Kontingent die Anzahl der parallelen Upgrades begrenzen oder sogar dazu führen, dass das Upgrade fehlschlägt.

Weitere Informationen zu Kontingenten finden Sie unter Knotenupgrades und -kontingente.

Nächste Schritte

• Mehr zu Clusterarchitektur
• Mehr über Releasekanäle erfahren