Hostwartung für Knoten durchführen, auf denen Trainings- und Inferenzarbeitslasten ausgeführt werden

In diesem Dokument wird erläutert, wie Sie die Hostwartung der zugrunde liegenden Compute Engine-Instanzen für Knoten in GKE-Clustern (Google Kubernetes Engine) durchführen. Sie müssen diese Wartung nur für bestimmte Arten von Compute Engine-Instanzen aktiv verwalten, die nicht live migriert werden, einschließlich Instanzen mit GPUs und TPUs. Die in diesem Dokument beschriebenen Strategien eignen sich gut für Trainings- und Inferenzarbeitslasten. Wenn Sie die Hostwartung nur für einen einzelnen Knoten manuell durchführen müssen oder Ihre Arbeitslasten eine automatische Hostwartung tolerieren, lesen Sie den Abschnitt Hostwartung in GKE durchführen.

Mit diesen Strategien wird die Hostwartung für Knotengruppen durchgeführt und optional GKE-Clusterupgrades initiiert.

Verwenden Sie die parallele Strategie für die Knoten von Arbeitslasten, bei denen Sie eine einzige Ausfallzeit haben können, z. B. für die Knoten von Trainingsarbeitslasten. Verwenden Sie die Rolling-Strategie für die Knoten von Arbeitslasten, bei denen Sie Batches von Ausfallzeiten haben können, während die Verfügbarkeit der meisten Ressourcen aufrechterhalten wird, z. B. für die Knoten von Inferenzarbeitslasten.

Parallele Strategie zum Aktualisieren der Knoten von Trainingsarbeitslasten verwenden

Bei dieser Strategie werden Änderungen gleichzeitig für eine Gruppe von Knoten vorgenommen, die Beschleuniger verwenden. Sie können diese Strategie für Trainingsarbeitslasten verwenden. Sie können sie auch für andere Arten von Arbeitslasten verwenden, bei denen die am wenigsten störende Methode zum Vornehmen von Änderungen darin besteht, ein einzelnes Zeitfenster mit vollständiger Ausfallzeit für alle Knoten in der Gruppe und die darauf ausgeführten Arbeitslasten zu haben.

Die Strategie umfasst die folgenden allgemeinen Schritte:

  1. Arbeitslasten beenden: Wählen Sie die Knotenpools aus und beenden Sie entweder die darauf ausgeführten Arbeitslasten oder verschieben Sie die Arbeitslasten auf andere Knoten, die verfügbar bleiben.
  2. Hostwartung auslösen: Wenden Sie das Wartungslabel gleichzeitig auf alle ausgewählten Knoten an und warten Sie, bis der Vorgang auf allen Knoten abgeschlossen ist.
  3. GKE-Version aktualisieren: Ändern Sie die GKE-Version der Knoten.
  4. Arbeitslasten neu starten: Starten Sie Ihre Arbeitslasten neu, nachdem alle Hostwartungen und -upgrades abgeschlossen sind.

Die bereitgestellten Anleitungen nehmen Änderungen für einen einzelnen Knotenpool vor. Sie können die Schritte jedoch anpassen, um Änderungen für mehrere Knotenpools gleichzeitig vorzunehmen. Bevor Sie mit diesen Schritten beginnen, sollten Sie sicherstellen, dass Sie mindestens ein paar Stunden Zeit haben, in denen diese Arbeitslast nicht auf diesen Knoten ausgeführt werden muss.

Um Unterbrechungen zu minimieren und gleichzeitig wichtige Änderungen sowohl für die zugrunde liegenden Compute Engine-Instanzen als auch für die GKE-Knoten zu erhalten, sollten Sie diese Ausfallzeit nutzen, um sowohl die Hostwartung als auch die GKE-Versionsupgrades durchzuführen. Wenn Sie die Version Ihrer GKE-Knoten nicht aktualisieren möchten, können Sie jedoch nur eine Hostwartung durchführen.

Hinweise

Beachten Sie Folgendes, bevor Sie beginnen:

  • Arbeitslasten nicht noch einmal bereitstellen: Um unnötige Verzögerungen aufgrund von PodDisruptionBudgets zu vermeiden, sollten Sie Arbeitslasten erst dann noch einmal bereitstellen, wenn Sie alle Schritte abgeschlossen haben.
  • Unterbrechungen einplanen: Sorgen Sie dafür, dass Ihre Arbeitslasten für einen bestimmten Zeitraum unterbrochen werden können. Diese Schritte dauern mehrere Stunden, hauptsächlich aufgrund der Zeit, die für die Hostwartung erforderlich ist.

Updates für alle Knoten gleichzeitig ausführen

Führen Sie die folgenden Schritte aus, um eine Hostwartung und optional GKE-Versionsupgrades durchzuführen:

  1. Arbeitslasten vorbereiten: Beenden Sie Ihre Arbeitslasten oder sorgen Sie dafür, dass ein aktueller Snapshot oder Prüfpunkt erstellt wurde.

  2. Hostwartung starten und überwachen:

    • Unterblöcke aus Reservierungen, die die gruppierte Wartungsplanung verwenden: Lösen Sie die Wartung für Reservierungen, Reservierungsblöcke oder Reservierungsunterblöcke mit dem entsprechenden Unterbefehl gcloud compute reservations aus. Mit dem folgenden Befehl wird beispielsweise die Wartung für einen Unterblock gestartet:

      gcloud compute reservations sub-blocks perform-maintenance RESERVATION_NAME \
    --block-name=BLOCK_NAME \
    --sub-block-name=SUB_BLOCK_NAME \
    --zone=ZONE

      Ersetzen Sie Folgendes:

      • RESERVATION_NAME: der Name der Reservierung.
      • BLOCK_NAME: der Name des Reservierungsblocks.
      • SUB_BLOCK_NAME: der Name des Reservierungsunterblocks.
      • ZONE: die Zone, in der die Reservierung vorhanden ist.

      Compute Engine beginnt gleichzeitig mit dem Entleeren und Aktualisieren aller Instanzen im Unterblock. Dieser Vorgang kann einige Stunden dauern.

      Prüfen Sie zur Überwachung den Status der Wartung, indem Sie das Metadatenfeld upcomingGroupMaintenance in den Reservierungsressourcen prüfen. Weitere Informationen finden Sie unter Wartungsstatus ansehen.

    • Instanzen, die eine unabhängige Wartungsplanung verwenden: Lösen Sie die Wartung für On-Demand-Instanzen oder für Reservierungen aus, die keine Unterblöcke verwenden, indem Sie das Label cloud.google.com/perform-maintenance=true auf die Knoten in Ihrem Knotenpool anwenden:

      kubectl label nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME cloud.google.com/perform-maintenance=true --overwrite

      Compute Engine beginnt gleichzeitig mit dem Ausgleich und der Aktualisierung der zugrunde liegenden Instanzen. Dieser Vorgang kann einige Stunden dauern. Weitere Informationen finden Sie unter Prozess der ordnungsgemäßen Beendigung.

      Prüfen Sie die Knoten, um den Status der Wartung zu überwachen. GKE entfernt das Wartungslabel, wenn die Wartung abgeschlossen ist, sofern es angewendet wurde. Wenn die Wartung abgeschlossen ist, finden Sie in Cloud Logging ein Log mit der folgenden Meldung:

      Maintenance window has completed for this instance. All maintenance
notifications on the instance have been removed.

  3. Optional: Version der GKE-Knoten aktualisieren: Folgen Sie der Anleitung zum Aktualisieren der GKE-Version der Knoten.

Rollierende Strategie zum Aktualisieren der Knoten von Inferenzarbeitslasten verwenden

Diese Strategie beschreibt einen manuellen Ansatz zur Wartung von GKE-Knoten, auf denen Inferenzarbeitslasten ausgeführt werden. Dabei werden Knoten in Batches aktualisiert, um die Dienstverfügbarkeit aufrechtzuerhalten. Diese Methode eignet sich am besten für Arbeitslasten, bei denen ein bestimmter Prozentsatz der Replikate vorübergehend offline sein kann.

Die Strategie umfasst die folgenden allgemeinen Schritte:

  1. Knoten identifizieren und zusammenfassen: Wählen Sie die zu aktualisierenden Knotenpools aus. Gruppieren Sie die Knoten in Batches, deren Größe der Fehlertoleranz Ihrer Arbeitslast entspricht.
  2. Batches durchlaufen: Wenden Sie für jeden Batch das Wartungslabel an und überwachen Sie den Batch von Knoten, bis das Label entfernt wird.
  3. GKE-Version aktualisieren: Nachdem alle Batches die Hostwartung abgeschlossen haben, ändern Sie die Version der GKE-Knoten.

Hinweise

Beachten Sie Folgendes, bevor Sie beginnen:

  • Bereitstellung verstehen: Für den Erfolg sind detaillierte Kenntnisse über die Verteilung Ihrer Arbeitslasten, die Platzierung von Replikaten und die fehlerhaften Domains erforderlich. Achten Sie darauf, dass Sie während des gesamten Prozesses eine ausreichende Bereitstellungskapazität aufrechterhalten.
  • Batchgrößen planen: Knoten in Batches aktualisieren. Die Größe der einzelnen Batches wird durch die Fehlertoleranz Ihrer Arbeitslast bestimmt. Zu berücksichtigende Faktoren:
    • Die Anzahl der Replikate pro Bereitstellungsmodell.
    • Die Verteilung von Replikaten auf Knoten und fehlerhafte Domains.
    • Mit PodDisruptionBudgets können Sie die maximale Anzahl von Pods erzwingen, die gleichzeitig ausfallen.
    • Empfehlung: Um die Verwaltung zu vereinfachen, sollten Sie verschiedene Knotenpools für verschiedene Replikatsätze verwenden. So können Sie Fehlerdomains auf Knotenpoolebene isolieren.
  • Zeitliche Einschränkungen berechnen: Berücksichtigen Sie die folgenden zeitlichen Faktoren:
    • Es kann mehrere Stunden dauern, bis der Hostwartungsschritt für jeden Batch abgeschlossen ist.
    • Berechnen Sie die Mindest-Batchgröße, damit alle Wartungsarbeiten innerhalb der erforderlichen Fristen abgeschlossen werden:
      1. MAINTENANCE_BLOCKS = floor(HOURS_TO_MAINTENANCE / 4) (wobei HOURS_TO_MAINTENANCE die insgesamt verfügbare Zeit ist).
      2. MIN_PER_BATCH = TOTAL_NODE_COUNT / MAINTENANCE_BLOCKS
    • Die ausgewählte Batchgröße muss mindestens MIN_PER_BATCH betragen.
  • Bestimmte Arbeitslasttypen prüfen: Berücksichtigen Sie Folgendes für die jeweiligen Konfigurationstypen:
    • Mixture of Experts (MoE): Achten Sie darauf, dass Ihre Batching-Strategie die erforderliche Mindestanzahl von Replikaten für jedes Modell beibehält.
    • Disaggregierte Bereitstellung: Achten Sie darauf, dass Sie alle Replikate, die an der disaggregierten Einrichtung beteiligt sind, beim Planen von Batches im Blick behalten.
    • Knotenpools mit mehreren Hosts (TPU, MNNVL): Bei diesen Konfigurationen wird wahrscheinlich ein ganzer Knotenpool auf einmal heruntergefahren. Planen Sie Ihre fehlerhaften Domains entsprechend über mehrere Knotenpools hinweg.

Rolling Updates in Batches durchführen

Wenn Sie rollierende Hostwartungsupdates durchführen möchten, können Sie Ihre Kapazität aus Reservierungen, die eine gruppierte Wartungsplanung verwenden, in Batches von einem oder mehreren Unterblöcken aktualisieren. Alternativ können Sie bestimmte Knotensätze im Cluster mit unabhängiger Wartungsplanung nach Namen aktualisieren.

Wählen Sie die geeignete Strategie für Ihre Ressourcen aus:

Reservierungen in Batches von Unterblöcken aktualisieren

Führen Sie die folgenden Schritte aus, um eine rollierende Hostwartung für Kapazitätsreservierungen in Batches von Unterblöcken durchzuführen:

  1. Reservierungen für die Wartung identifizieren: Identifizieren Sie den Namen der Kapazitätsreservierung und die Reservierungsblöcke oder Reservierungsunterblöcke, die vom GKE-Cluster verwendet werden. Führen Sie dazu eine Suche mit GKE-Knotenlabels und dem Befehl gcloud compute reservations aus:

    1. Listen Sie den Reservierungsnamen und die IDs der physischen Block- und Unterblocktopologie der Knoten in Ihrem Knotenpool auf:

      kubectl get nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME \
    -o custom-columns='NAME:.metadata.name,RESERVATION:.metadata.labels.cloud\.google\.com/reservation-name,BLOCK_ID:.metadata.labels.cloud\.google\.com/gce-topology-block,SUBBLOCK_ID:.metadata.labels.cloud\.google\.com/gce-topology-subblock'

      Ersetzen Sie NODE_POOL_NAME durch den Namen des Knotenpools.

      Notieren Sie sich die Ausgabewerte: den Reservierungsnamen (z. B. nvidia-gb300-m7kp2xq9vd4j1), die Block-ID (z. B. 3f2a8c9b1d4e0756f8a2b3c1d9e4f0a5) und die Unterblock-ID (z. B. e7b91f4a3c2d58069e1a4b7f3d2c8056).

    2. Um den Ressourcennamen des Reservierungsblocks zu ermitteln, fragen Sie die Liste der Compute Engine-Reservierungsblöcke mit dem Reservierungsnamen ab und filtern Sie nach der Block-ID:

      gcloud compute reservations blocks list RESERVATION_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --filter="physicalTopology.block=BLOCK_ID"

      Ersetzen Sie Folgendes:

      • RESERVATION_NAME: der Name der Reservierung.
      • ZONE: die Zone, in der die Reservierung vorhanden ist.
      • PROJECT_ID: die Projekt-ID, in der die Reservierung vorhanden ist.
      • BLOCK_ID: die Block-ID, die aus den Knotenlabels abgerufen wurde.

      Notieren Sie sich den Namen des Blocks aus der Ausgabe.

    3. Wenn Sie den Ressourcennamen des Reservierungsunterblocks ermitteln möchten, fragen Sie die Liste der Reservierungsunterblöcke mit dem Reservierungsnamen und dem Blocknamen ab und filtern Sie nach der Unterblock-ID:

      gcloud compute reservations sub-blocks list RESERVATION_NAME \
    --block-name=BLOCK_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --filter="physicalTopology.subBlock=SUBBLOCK_ID"

      Ersetzen Sie Folgendes:

      • RESERVATION_NAME: der Name der Reservierung.
      • BLOCK_NAME: der Ressourcenname des Reservierungsblocks.
      • ZONE: die Zone, in der die Reservierung vorhanden ist.
      • PROJECT_ID: die Projekt-ID, in der die Reservierung vorhanden ist.
      • SUBBLOCK_ID: die Unterblock-ID, die aus den Knotenlabels abgerufen wurde.

      In der Ausgabe werden Details zum übereinstimmenden Reservierungsunterblock angezeigt, einschließlich des Ressourcennamens.

  2. Reservierungen in Batches aufteilen: Teilen Sie die identifizierten Unterblöcke der Kapazitätsreservierung in gleich große Batches auf. Bestimmen Sie die Batchgröße anhand der Formel, die im Listenelement Zeitliche Einschränkungen berechnen im vorherigen Abschnitt Überlegungen vor dem Start beschrieben wird. Jeder Batch entspricht einem oder mehreren Reservierungsunterblöcken und muss mindestens die Größe eines Unterblocks haben.

  3. Hostwartung durchführen: Führen Sie für jeden Batch die folgenden Schritte aus:

    1. Wählen Sie eine Gruppe von Reservierungsunterblöcken aus und lösen Sie die Hostwartung aus. Sie können die Wartung für Ihre Reservierungen, Reservierungsblöcke oder Reservierungsunterblöcke auslösen. Bei Maschinentypen wie A4X, A4X Max, TPU v6e und TPU7x müssen Sie die Wartung auf diese Weise auslösen. Die Wartung wird in Gruppen von Unterblöcken durchgeführt. Führen Sie den Befehl gcloud compute reservations sub-blocks perform-maintenance aus:

      gcloud compute reservations sub-blocks perform-maintenance RESERVATION_NAME \
    --block-name=BLOCK_NAME \
    --sub-block-name=SUB_BLOCK_NAME \
    --zone=ZONE

      Ersetzen Sie Folgendes:

      • RESERVATION_NAME: der Name der Reservierung.
      • BLOCK_NAME: der Name des Reservierungsblocks.
      • SUB_BLOCK_NAME: der Name des Reservierungsunterblocks.
      • ZONE: die Zone, in der die Reservierung vorhanden ist.

      Compute Engine beginnt gleichzeitig mit dem Entleeren und Aktualisieren aller Instanzen im Unterblock. Dieser Vorgang kann einige Stunden dauern.

    2. Überwachen Sie den Status der Wartung, indem Sie den Status der Wartung im Metadatenfeld upcomingGroupMaintenance in den Reservierungsressourcen prüfen. Weitere Informationen finden Sie unter Wartungsstatus der Reservierung ansehen.

    3. Wiederholen Sie die vorherigen Schritte für alle verbleibenden Batches, bis Sie die Hostwartung für alle Batches abgeschlossen haben.

  4. Optional: Version der GKE-Knoten aktualisieren: Führen Sie diesen Schritt erst aus, nachdem die Hostwartung für alle Reservierungsunterblöcke abgeschlossen ist. So vermeiden Sie Szenarien, in denen die GKE-Knoten auf Hosts bereitgestellt werden, für die die Wartung noch nicht abgeschlossen ist. Folgen Sie der Anleitung zum Aktualisieren der GKE-Version der Knoten.

Knoten im Batch aktualisieren

So führen Sie eine rollierende Hostwartung für On-Demand-Instanzen oder Reservierungen aus, die keine Unterblöcke in Batches unterstützen:

  1. Knoten für die Wartung identifizieren: Identifizieren Sie alle Knoten, für die Sie eine Wartung durchführen möchten, und speichern Sie diese Liste. Verwenden Sie eine der folgenden Methoden, um Knoten zu identifizieren, oder wählen Sie sie manuell aus:

    • Rufen Sie alle Knoten im Cluster ab, die Beschleuniger (TPUs oder GPUs) verwenden:

      kubectl get nodes -o json | jq -r '.items[] | select(.spec.taints[]? | select(.key=="nvidia.com/gpu" or .key=="google.com/tpu")) | .metadata.name'

    • Alle Knoten in einem bestimmten Knotenpool abrufen:

      kubectl get nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME --no-headers -o custom-columns=":metadata.name"

      Ersetzen Sie NODE_POOL_NAME durch den Namen des Knotenpools.

    • Alle Knoten mit einem bestimmten Label abrufen:

      kubectl get nodes -l LABEL -o jsonpath='{.items[*].metadata.name}'

      Ersetzen Sie LABEL durch das Knotenlabel.

  2. Knoten in Batches aufteilen: Teilen Sie die identifizierten Knoten in gleich große Batches auf. Bestimmen Sie die Batchgröße anhand der Formel, die im Listenelement Zeitliche Einschränkungen berechnen im vorherigen Abschnitt Überlegungen vor dem Start beschrieben wird.

  3. Hostwartung durchführen: Führen Sie für jeden Batch die folgenden Schritte aus:

    1. Wählen Sie eine Gruppe von Knoten aus und lösen Sie die Wartung auf der Instanzebene mit der instances API aus, indem Sie das Wartungslabel anwenden:

      kubectl label nodes LIST_OF_NODES_IN_BATCH cloud.google.com/perform-maintenance=true --overwrite

      Ersetzen Sie LIST_OF_NODES_IN_BATCH durch eine durch Leerzeichen getrennte Liste von Knoten aus dem Batch. Beispiel: node-1 node-2 node-3

      Compute Engine beginnt gleichzeitig mit dem Ausgleich und der Aktualisierung der zugrunde liegenden Instanzen. Dieser Vorgang kann einige Stunden dauern. Weitere Informationen finden Sie unter Prozess der ordnungsgemäßen Beendigung.

    2. Überwachen Sie den Status der Hostwartung. GKE entfernt das Wartungslabel, wenn die Wartung abgeschlossen ist, sofern es angewendet wurde. Wenn die Wartung abgeschlossen ist, finden Sie in Logging ein Log mit der folgenden Meldung:

      Maintenance window has completed for this instance. All maintenance
notifications on the instance have been removed.

    3. Wiederholen Sie die vorherigen Schritte für jeden verbleibenden Batch, bis Sie die Hostwartung für alle Batches abgeschlossen haben.

  4. Optional: Version der GKE-Knoten aktualisieren: Führen Sie diesen Schritt erst aus, wenn die Hostwartung für alle Knoten abgeschlossen ist. So vermeiden Sie, dass die GKE-Knoten auf Hosts bereitgestellt werden, für die die Wartung noch nicht abgeschlossen ist. Folgen Sie der Anleitung zum Aktualisieren der GKE-Version der Knoten.

GKE-Version der Knoten aktualisieren

Berücksichtigen Sie die Anzahl der Knoten, die Sie gleichzeitig aktualisieren möchten. Mit der parallelen Strategie haben Sie die Hostwartung für den gesamten Knotenpool oder mehrere Knotenpools gleichzeitig durchgeführt. Bei der rollierenden Strategie haben Sie die Hostwartung in Batches durchgeführt. Bestimmen Sie anhand der Größe der Knotengruppen, welche Upgrademethode Sie verwenden möchten:

  • Parallele Strategie: Wenn Ihre Knotenpools jeweils maximal 100 Knoten pro Zone haben, verwenden Sie Surge-Upgrades. Wenn Ihre Knotenpools jeweils mehr als 100 Knoten pro Zone haben, löschen Sie die Knotenpools und erstellen Sie sie neu.
  • Rolling-Strategie: Wenn Ihre Batches 100 Knoten pro Zone, pro Knotenpool oder weniger haben, verwenden Sie Surge-Upgrades. Wenn Ihre Batches mehr als 100 Knoten pro Zone und Knotenpool enthalten, löschen Sie die Knoten und erstellen Sie sie neu.

Surge-Upgrades verwenden

  1. Konfigurieren Sie Surge-Upgrades mit der Einstellung maxUnavailable, um festzulegen, wie viele Knoten pro Zone in einem Knotenpool gleichzeitig nicht verfügbar sein dürfen. Wenn Sie beispielsweise 18 Knoten in einer Zone in einem Knotenpool haben, setzen Sie den Wert des Felds maxUnavailable auf 18.

    Diese Einstellung funktioniert am besten, wenn Sie Kapazität aus einer Reservierung verwenden, in der Sie keine überschüssige Kapazität haben. Weitere Informationen dazu, warum Sie diese Einstellung verwenden sollten, finden Sie unter Upgrade in einer ressourcenknappen Umgebung.

  2. Führen Sie den folgenden Befehl aus, um ein Upgrade des Knotenpools durchzuführen. Wenn Sie mehrere Knotenpools aktualisieren möchten, führen Sie diesen Befehl für jeden Knotenpool aus:

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

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • NODE_POOL_NAME ist der Name des Knotenpools.
    • VERSION: ein empfohlenes Ziel für das automatische Upgrade des Knotenpools. Weitere Informationen finden Sie unter Upgrade-Informationen für Standard-Clusterknotenpools abrufen. Wenn Ihr Cluster kein empfohlenes Ziel für automatische Upgrades hat, prüfen Sie die neuesten Einträge unter Versionsupdates in den GKE-Versionshinweisen.
    • CONTROL_PLANE_LOCATION: Der Standort der Steuerungsebene Ihres Clusters.

Knoten löschen und neu erstellen

Löschen Sie den Knotenpool und erstellen Sie ihn mit der neueren Version neu:

  1. Löschen Sie den Knotenpool:

    gcloud container node-pools delete NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location CONTROL_PLANE_LOCATION

  2. Erstellen Sie den Knotenpool neu und übergeben Sie die neue Version mit dem Flag --cluster-version. Übergeben Sie das empfohlene Ziel für automatische Upgrades für den Knotenpool. Weitere Informationen finden Sie unter Upgrade-Informationen für Standard-Clusterknotenpools abrufen. Wenn Ihr Cluster kein empfohlenes Ziel für automatische Upgrades hat, prüfen Sie die neuesten Einträge unter Versionsupdates in den GKE-Versionshinweisen.