KI-optimierte GKE-Cluster verwalten

Auf dieser Seite erfahren Sie, wie Sie KI-optimierte GKE-Cluster (Google Kubernetes Engine) mit A4X Max-, A4X-, A4-, A3 Ultra-, A3 Mega- und A3 High-Maschinen (8 GPUs) verwalten, einschließlich der folgenden gängigen Ereignisse, die für GKE-Cluster und KI-Arbeitslasten relevant sind:

  • Hostwartung
  • Clusterupgrades
  • Fehlerhaften Host melden

Hostwartung für KI-Arbeitslasten verwalten

GKE-Knoten werden auf Compute Engine-Instanzen ausgeführt, auf denen regelmäßig Hostereignisse auftreten, die KI-Arbeitslasten beeinträchtigen können. Da Hostereignisse in der zugrunde liegendenGoogle Cloud -Infrastruktur auftreten, umgehen sie Wartungsfenster und -ausschlüsse von GKE. Bei den meisten Compute-Instanzen ist die Hostwartungsrichtlinie auf Live-Migration festgelegt, wodurch die Unterbrechung von Arbeitslasten minimiert wird. GPUs und TPUs unterstützen jedoch keine Live-Migration. Wenn diese Hostereignisse Ihre GKE-Knoten betreffen, auf denen KI-Arbeitslasten ausgeführt werden, muss GKE den Knoten und die auf dem Knoten ausgeführten Pods beenden. Wenn die Pods als Teil einer größeren Arbeitslast wie eines Jobs oder Deployments bereitgestellt werden, versucht GKE, die Pods auf dem betroffenen Knoten neu zu starten.

Weitere Informationen zum Verwalten der Hostwartung der zugrunde liegenden Compute-Instanzen finden Sie unter GKE-Knotenunterbrechungen für GPUs und TPUs verwalten.

Hostwartungsereignisse überwachen

Bei Clustern mit GKE-Version 1.31.1-gke.2008000 oder höher können Sie die geplante Startzeit des Hostwartungsereignisses so aufrufen. Die Startzeit wird durch Kubernetes-Knotenlabels auf dem entsprechenden GKE-Knoten für alle GPUs und TPUs dargestellt.

Weitere Informationen finden Sie unter Wartungsbenachrichtigungen überwachen.

Mit diesen Knotenlabels haben Sie folgende Möglichkeiten:

Host-Wartungsereignis manuell starten

Nachdem Compute Engine eine Benachrichtigung zu einem geplanten Wartungsereignis ausgegeben hat, können Sie die Wartung manuell zu einem Zeitpunkt starten, der zu Ihrem Zeitplan passt. Sie können beispielsweise festlegen, dass Wartungsarbeiten in Zeiten geringer Aktivität durchgeführt werden.

Wenn Sie ein Hostwartungsereignis nicht manuell starten, führt die Compute Engine die regelmäßige Wartung automatisch durch.

Folgen Sie der Anleitung zum manuellen Starten eines Host-Wartungsereignisses. Lesen Sie außerdem diesen Abschnitt weiter, um Folgendes zu erfahren:

Hostwartungsinformationen beim Planen von Arbeitslasten verwenden

Sie können die Wartungsinformationen, die über GKE-Knotenlabels bereitgestellt werden, zusammen mit Knotenaffinität und -antiaffinität verwenden, um Unterbrechungen Ihrer Arbeitslasten zu minimieren.

In den folgenden Abschnitten finden Sie Beispiele für die Verwendung dieser Informationen.

Pods auf Knoten planen, für die keine zukünftigen Wartungsereignisse geplant sind

Sie können GKE anweisen, Pods nur auf Knoten zu planen, für die keine zukünftigen Wartungsereignisse geplant sind, z. B. mit dem folgenden Snippet:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: DoesNotExist

Pods auf Knoten planen, für die nach einem bestimmten Datum eine Wartung geplant ist

Sie können GKE anweisen, Pods nur auf Knoten zu planen, für die nach einem bestimmten Datum eine Wartung geplant ist. Geben Sie dazu die Unix-Epoche an:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: Gt
            values:
            - 1733296000

GKE-Clusterupgrades für KI-Arbeitslasten verwalten

KI-Arbeitslasten sind anfällig für Störungen.

Während des Lebenszyklus eines GKE-Cluster müssen KI-Arbeitslasten auf Störungen sowohl der zugrunde liegenden Compute-Instanzen als auch des GKE-Cluster selbst vorbereitet sein:

Wir empfehlen, den Cluster in einer Release-Version registriert zu lassen. GKE-Cluster sind standardmäßig in der Release-Version „Regular“ registriert. Weitere Informationen zu den Vorteilen von Release-Versionen finden Sie im Vergleich zwischen Clustern, die in einer Release-Version registriert sind, und Clustern, die nicht registriert sind.

Mit Release-Versionen erhalten Sie Zugriff auf weitere Funktionen, einschließlich zusätzlicher Wartungsausschlussbereiche. Für KI-Arbeitslasten empfehlen wir den Bereich „Keine Nebenversions- oder Knotenupgrades“.

Fehlerhafte Hosts über GKE melden

In diesem Abschnitt wird beschrieben, wie Sie über GKE einen fehlerhaften Host melden können, auf dem Compute-Instanzen mit dem reservierungsgebundenen Bereitstellungsmodell bereitgestellt wurden. Wenn Sie einen fehlerhaften Host für einen Knoten melden möchten, der mit dem Bereitstellungsmodell „Flex-Start“ (Vorabversion) bereitgestellt wurde, wenden Sie sich stattdessen an Ihr Account-Management-Team.

Wenn Sie GPU-Speicher- oder Xid-Fehler auf einem Knoten feststellen und prüfen möchten, ob manuelle Wiederherstellungsmaßnahmen wie das Auslösen eines Neustarts des Gastbetriebssystems (kubectl label nodes <NODE_NAME> cloud.google.com/perform-reboot=true) das Problem beheben können, bevor Sie den Host als fehlerhaft melden, lesen Sie den Abschnitt Xid-Nachrichten prüfen.

Ein Host ist ein einzelner physischer Server im Rechenzentrum, auf dem eine Compute-Instanz ausgeführt wird, die Ihren GKE-Knoten hostet. Sie können fehlerhafte Hosts melden, indem Sie das Knotenlabel fault-behavior auf den betroffenen GKE-Knoten anwenden. Nachdem Sie das Knotenlabel auf einen bestimmten GKE-Knoten angewendet haben, führt GKE die folgenden Schritte aus:

  1. Entfernt Arbeitslasten ordnungsgemäß aus dem Knoten.
  2. Verhindert, dass neue Pods auf dem Knoten geplant werden.
  3. Ruft die API auf der Compute-Instanz auf, um den Host als fehlerhaft zu markieren.
  4. Wartet, bis die Compute-Instanz auf einem fehlerfreien Hostcomputer wieder hochgefahren ist. Bei Reservierungen, die den Betriebsmodus Gesamte Kapazität verwenden, stellt Compute Engine die Compute-Instanz nach Abschluss des Reparaturvorgangs auf demselben Knoten wieder her.
  5. Entfernt die Markierung und das Label fault-behavior vom Knoten.

Danach ist der Knoten wieder bereit, Arbeitslasten zu verarbeiten.

Voraussetzungen

Damit ein fehlerhafter Host gemeldet werden kann, muss Ihr GKE-Knoten die folgenden Anforderungen erfüllen:

  • Sie müssen die GKE-Patchversion 1.32.3-gke.1057001 oder höher ausführen.
  • Sie müssen einen der folgenden GPU-Maschinentypen ausführen: A4X Max, A4X, A4, A3 Ultra, A3 Mega und A3 High (8 GPUs).
  • Ihre GKE-Knoten müssen auf einer Compute-Instanz ausgeführt werden, die reservierungsgebunden ist.
  • Der GKE-Knoten muss den Status RUNNING haben. Wenn Sie versuchen, einen fehlerhaften Host zu melden, nachdem Sie die Compute-Instanz gelöscht haben, wird eine Fehlermeldung zurückgegeben und der Hostcomputer wird nicht als fehlerhaft markiert.
  • Die Anzahl der Aufrufe dieser API pro Reservierung und Monat kann basierend auf einer Bewertung des Zustands Ihrer Blöcke begrenzt werden. Ratenbegrenzungen gelten nicht, wenn Ihre Reservierung den Betriebsmodus Gesamte Kapazität verwendet.

Fehlerhaften Host melden

So melden Sie einen fehlerhaften Host:

  1. Verwenden Sie die GKE-Beobachtbarkeitstools, Ihre eigenen Monitoring-Tools oder Logs, um die GKE-Knoten mit Leistungsproblemen zu identifizieren. Speichern Sie die NODE_NAME.

  2. Melden Sie den Knoten mit dem folgenden Befehl als fehlerhaft. Sie können einen Grund und bei späteren Versionen eine Beschreibung angeben:

      kubectl patch node NODE_NAME --type merge -p '{
    "metadata": {
      "labels": {
        "cloud.google.com/fault-behavior": "FAULT_REASON"
      },
      "annotations": {
        "cloud.google.com/fault-description": "FAULT_DESCRIPTION"
      }
    }
  }'

    Ändern Sie den Befehl so:

    • Ersetzen Sie NODE_NAME durch den Namen des fehlerhaften Knotens.
    • Ersetzen Sie FAULT_REASON durch die entsprechende Fehlerursache. Verwenden Sie dazu einen oder mehrere der folgenden Werte:
      • PERFORMANCE: Verwenden Sie diesen Wert, wenn GPUs auf einer Compute-Instanz langsamer als andere GPUs im Cluster sind und Sie keine XID-Fehler in den Logs sehen und keine der anderen üblichen Fehler wie unbemerkte Datenbeschädigung erkannt werden.
      • SDC: Verwenden Sie diesen Wert für eine unbemerkte Datenbeschädigung, wenn Sie eine Datenbeschädigung, aber keinen Systemabsturz feststellen. Diese Datenbeschädigung kann durch CPU-Fehler, Softwarefehler wie Use-After-Free oder Memory Stomping, Kernel-Probleme oder andere Fehler verursacht werden. Meistens wird dieser Begriff verwendet, um auf hardwarebedingte Fehler zu verweisen.
      • XID: Verwenden Sie diesen Wert, wenn Sie einen nicht behebbaren GPU-Fehler mit einer XID für eine Compute-Instanz identifiziert haben.
      • unspecified: Verwenden Sie diesen Wert, wenn Sie sich nicht sicher sind, welches Verhalten das Problem mit Ihrer Compute-Instanz verursacht. Das ist der Standardwert. Wir empfehlen jedoch, einen der anderen Werte anzugeben, falls zutreffend.
    • Passen Sie den Block annotations basierend auf der Version der Steuerungsebene Ihres GKE-Clusters an:
      • 1.35.6-gke.1017000 oder höher oder 1.36.0-gke.3251000 oder höher: Behalten Sie den Annotationsblock bei und ersetzen Sie FAULT_DESCRIPTION durch eine Textbeschreibung des beobachteten Fehlers. Dazu können der XID-Fehlercode, Symptome oder Zeitstempel gehören. Diese Beschreibung wird an Compute Engine weitergeleitet, um die Reparaturdiagnose zu unterstützen, und nach Abschluss des Vorgangs automatisch vom Knoten entfernt. Beispiel: GPU XID 48 observed on device nvidia0 at 2026-06-10T10:30:00Z.
      • Frühere Versionen: Entfernen Sie den gesamten annotations-Block aus dem Befehl. Das Feld fault-description wird in diesen Versionen nicht an Compute Engine weitergeleitet und nicht automatisch vom Knoten entfernt. Wenden Sie sich stattdessen an Ihr Account-Management-Team oder an den Cloud Customer Care, um Details zum Fehler anzugeben.
Nachdem Sie einen fehlerhaften Host für einen Knoten gemeldet haben, variiert die Zeit, zu der der Knoten neu gestartet wird, je nach dem Betriebsmodus der Reservierung, der in der Reservierung angegeben ist, die der Knoten verwendet. Wenn Sie den Betriebsmodus einer Reservierung prüfen möchten, rufen Sie das Feld reservationOperationalMode in der Reservierung auf. In der folgenden Tabelle ist der Prozess für fehlerhafte Hosts für die beiden verfügbaren Betriebsmodi für Reservierungen zusammengefasst: Modus für die gesamte Kapazität und verwalteter Modus.
Modus „Gesamte Kapazität“ (ALL_CAPACITY) Verwalteter Modus (HIGHLY_AVAILABLE_CAPACITY)
Unterstützte Maschinentypen A4X Max und A4X A4, A3 Ultra, A3 Mega und A3 High (8 GPUs)
Ratenbegrenzung für die API zum Melden fehlerhafter Hosts Es gelten keine Ratenbegrenzungen. API-Aufrufe können einer Ratenbegrenzung unterliegen.
Prozess zum Melden fehlerhafter Hosts

Wenn Sie einen fehlerhaften Host für einen Knoten melden, der im Modus „Gesamte Kapazität“ ausgeführt wird, geschieht Folgendes:

  1. Pods entfernen: Nachdem das Label auf den fehlerhaften Knoten angewendet wurde, markiert GKE den Knoten, um die Planung neuer Pods zu blockieren. GKE beginnt außerdem damit, die laufenden Pods auf dem Knoten ordnungsgemäß zu entfernen. GKE berücksichtigt die Budgets für Pod-Störungen (Pod Disruption Budgets, PDBs) und das Feld spec.terminationGracePeriodSeconds Ihrer Pod-Manifeste. Weitere Informationen finden Sie unter GKE so konfigurieren, dass Arbeitslasten ordnungsgemäß beendet werden.
  2. Fehlerhaften Host melden und reparieren: GKE ruft die Compute Engine API auf, um den fehlerhaften Host zu melden und zu reparieren. Diese Abfolge von Vorgängen dauert in der Regel 10 bis 12 Minuten, um den fehlerhaften Host zu melden, und 3 bis 14 Tage oder manchmal sogar länger, um den Host zu reparieren.

  3. Knoten neu starten: Nach Abschluss der Hostreparatur geschieht Folgendes:

    • Wenn sich der Knoten im Status REPAIRING befindet und die Ressourcen nach Abschluss der Reparatur verfügbar sind, startet Compute Engine den Knoten automatisch auf dem reparierten Host neu.
    • Wenn sich der Knoten im Status TERMINATED befindet oder wenn nach Abschluss der Reparatur keine Ressourcen verfügbar sind, bleibt der Knotenstatus im Status TERMINATED oder ändert sich in diesen. Sie müssen den Knoten manuell neu starten, wenn Sie ihn ausführen möchten. Wenn jedoch beim Neustart des Knotens keine Ressourcen verfügbar sind, z. B. weil andere Compute-Instanzen bereits den reparierten Host verwenden, kann der Neustart fehlschlagen.

Wenn Sie einen fehlerhaften Host für einen Knoten melden, der im verwalteten Modus ausgeführt wird, geschieht Folgendes:

  1. Pods entfernen: Nachdem das Label auf den fehlerhaften Knoten angewendet wurde, markiert GKE den Knoten, um die Planung neuer Pods zu blockieren. GKE beginnt außerdem damit, die auf dem Knoten ausgeführten Pods ordnungsgemäß zu entfernen. GKE berücksichtigt die Budgets für Pod-Störungen (Pod Disruption Budgets, PDBs) und das Feld spec.terminationGracePeriodSeconds Ihrer Pod-Manifeste. Weitere Informationen finden Sie unter GKE so konfigurieren, dass Arbeitslasten ordnungsgemäß beendet werden.

  2. Fehlerhaften Host melden und reparieren: GKE ruft die Compute Engine API auf, um den fehlerhaften Host zu melden und zu reparieren. Diese Abfolge von Vorgängen dauert in der Regel 10 bis 12 Minuten, bis der fehlerhafte Host gemeldet wird.

    Das Verhalten des Knotens beim Start des Hostreparaturvorgangs variiert je nach Maschinenserie:

    • A4 und A3 Ultra: GKE versucht, den Knoten per Live-Migration auf einen anderen Host zu migrieren. Wenn Sie nicht genügend reservierte Kapazität haben oder in der Zone des Knotens keine Kapazität verfügbar ist, wird der Knoten beendet.
    • A3 Mega und A3 High: GKE beendet den Knoten und startet ihn auf einem fehlerfreien Host neu.

    Die Reparatur des ursprünglichen fehlerhaften Hosts kann 3 bis 14 Tage oder manchmal sogar länger dauern.

  3. Knoten migrieren oder neu starten: Nach dem Start des Hostreparaturvorgangs versucht Compute Engine, einen fehlerfreien Host zu reservieren, um den gemeldeten fehlerhaften Host in Ihrer reservierten Kapazität zu ersetzen. Wenn Compute Engine einen Ersatzhost findet, geschieht Folgendes:

    • A4 und A3 Ultra: Wenn der Knoten im vorherigen Schritt live migriert wurde, wird er auf dem Ersatzhost weiter ausgeführt. Wenn der Knoten beendet wurde, wird er auf dem Ersatzhost neu gestartet.
    • A3 Mega und A3 High: Der Knoten wird auf dem Ersatzhost neu gestartet.

    Wenn Compute Engine nicht sofort einen Ersatzhost finden kann, wird der Knoten so neu gestartet:

    • Wenn sich der Knoten im Status REPAIRING befindet und Ressourcen vor oder nach Abschluss der Reparatur verfügbar sind, startet Compute Engine den Knoten automatisch auf einem fehlerfreien Host neu.
    • Wenn sich der Knoten im Status TERMINATED befindet oder Ressourcen vor oder nach Abschluss der Reparatur nicht verfügbar sind, bleibt der Knotenstatus im Status TERMINATED oder ändert sich in diesen. Sie müssen den Knoten manuell neu starten, wenn Sie ihn ausführen möchten.

    Im Gegensatz zum Modus „Gesamte Kapazität“ müssen Sie nicht warten, bis der ursprüngliche fehlerhafte Host repariert ist, bevor Ihre Arbeitslast fortgesetzt werden kann.

Fortschritt des Vorgangs überwachen

Sie können den Fortschritt des GKE-Vorgangs mithilfe des Knotenlabels cloud.google.com/report-and-replace-status auf Ihrem GKE-Knoten überwachen, das einen der folgenden Werte hat:

  • PodsEvicted: GKE hat die Pods vom betroffenen Knoten entfernt.
  • OperationRUNNING: Der Vorgang zum Melden des fehlerhaften Hosts wird ausgeführt.
  • OperationDONE: Der zugrunde liegende Host wurde als fehlerhaft gemeldet und der GKE-Knoten kann auf einen neuen Host verschoben werden.
  • OperationFAILED: Die API auf der Compute-Instanz ist aufgrund von Kontingentlimits oder anderen Infrastrukturproblemen fehlgeschlagen. Informationen zum Fehler finden Sie unter Fehler bei der Meldung fehlerhafter Host-APIs beheben. Informationen zur Wiederherstellung finden Sie unter Fehler beim Melden und Ersetzen beheben.
  • Error: Der API-Aufruf ist fehlgeschlagen, weil die Anfrage eine der im vorherigen Abschnitt beschriebenen Anforderungen nicht erfüllt hat.

Sie können sich auch das Knotenlabel node.gke.io/report-and-replace-operation ansehen, um die Compute Engine-Vorgangs-ID aufzurufen und den Status des Vorgangs zu überwachen.

Sie können beide Knotenlabels mit dem folgenden Befehl aufrufen:

  kubectl get nodes NODE_NAME \
  -L cloud.google.com/report-and-replace-status,node.gke.io/report-and-replace-operation

Wenn ein API-Fehler auftritt, setzt GKE das Knotenlabel cloud.google.com/report-and-replace-status auf Error. Wenn ein Vorgangsfehler auftritt, setzt GKE das Label auf OperationFAILED. In beiden Fällen entfernt GKE das Knotenlabel cloud.google.com/fault-behavior. In GKE-Version 1.35.6-gke.1256000 oder höher oder 1.36.0-gke.4060000 oder höher wendet GKE außerdem eine cloud.google.com/report-and-replace-failed:NoSchedule-Markierung auf den Knoten an. Diese Markierung verhindert, dass neue Pods auf dem Knoten geplant werden. So wird sichergestellt, dass Arbeitslasten nicht auf einem Knoten mit einem potenziell fehlerhaften Host platziert werden. Weitere Informationen finden Sie unter Fehler beim Melden und Ersetzen beheben.

Informationen zum Verfolgen des detaillierten Status eines Vorgangs zum Melden eines fehlerhaften Hosts finden Sie unter Vorgänge zum Melden eines fehlerhaften Hosts prüfen.

Fehler beim Melden und Ersetzen beheben

Wenn ein Vorgang zum Melden und Ersetzen fehlschlägt, wendet GKE die Markierung cloud.google.com/report-and-replace-failed:NoSchedule auf den betroffenen Knoten an. Durch diese Markierung bleibt der Knoten gesperrt, sodass keine neuen Arbeitslasten darauf geplant werden, während der zugrunde liegende Host möglicherweise noch fehlerhaft ist.

Auf Fehler-Taint prüfen

Führen Sie den folgenden Befehl aus, um zu prüfen, ob ein Knoten die Markierung „report-and-replace“ hat:

  kubectl describe node NODE_NAME | grep "report-and-replace-failed"

Nach einem Fehler beim Melden und Ersetzen wiederherstellen

So beheben Sie einen Fehler beim Melden und Ersetzen:

  • Wiederholen Sie den Vorgang, indem Sie das Label cloud.google.com/fault-behavior noch einmal auf den Knoten anwenden. Wenn der Wiederholungsversuch erfolgreich ist, entfernt GKE die Markierung cloud.google.com/report-and-replace-failed:NoSchedule automatisch:

      kubectl label node NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON

  • Entfernen Sie die Markierung manuell, wenn Sie festgestellt haben, dass der Knoten fehlerfrei ist, oder wenn Sie ihn wieder in Betrieb nehmen möchten:

      kubectl taint nodes NODE_NAME cloud.google.com/report-and-replace-failed:NoSchedule-

Nächste Schritte