KI-optimierte GKE-Cluster verwalten

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

  • Hostwartung
  • Cluster upgrades
  • Fehlerhafte Hosts melden

Hostwartung für KI-Arbeitslasten verwalten

GKE-Knoten werden auf Compute Engine-Instanzen ausgeführt, bei denen regelmäßig Hostereignisse auftreten, die KI-Arbeitslasten stören können. Da Hostereignisse in der zugrunde liegenden Google Cloud Infrastruktur auftreten, umgehen sie GKE Wartungsfenster und -ausschlüsse. 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 beobachten

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

Mit diesen Knotenlabels können Sie Folgendes tun:

Hostwartungsereignis manuell starten

Nachdem Compute Engine eine Benachrichtigung über ein geplantes Wartungsereignis ausgegeben hat, können Sie die Wartung manuell zu einem Zeitpunkt starten, der zu Ihrem Zeitplan passt. Sie können beispielsweise Wartungsarbeiten in Zeiten mit geringerer Aktivität durchführen.

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

Folgen Sie der Anleitung unter Hostwartungsereignis manuell starten. Lesen Sie außerdem in diesem Abschnitt weiter, um Folgendes zu erfahren:

Informationen zur Hostwartung beim Planen von Arbeitslasten verwenden

Sie können die Wartungsinformationen, die über GKE-Knoten labels verfügbar gemacht 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 Wartungsarbeiten geplant sind

Sie können GKE anweisen, Pods nur auf Knoten zu planen, für die nach einem bestimmten Datum Wartungsarbeiten geplant sind, indem Sie die Unix-Epochenzeit angeben:

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

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

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

Mit Release-Versionen haben Sie Zugriff auf weitere Funktionen, einschließlich zusätzlicher Bereiche für Wartungsausschlüsse. Wir empfehlen den Bereich „Keine Nebenversions- oder Knotenupgrades“ für KI-Arbeitslasten.

Fehlerhafte Hosts über GKE melden

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

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 dem betroffenen GKE-Knoten ein fault-behavior-Knotenlabel zuweisen. Nachdem Sie das Knotenlabel auf einen bestimmten GKE-Knoten angewendet haben, führt GKE die folgenden Schritte aus:

  1. Arbeitslasten werden ordnungsgemäß vom Knoten entfernt.
  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 Host wieder hochgefahren wird. Bei Reservierungen, die den Alle Kapazitäten Reservierungsbetriebsmodus 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 Sie einen fehlerhaften Host melden können, muss Ihr GKE-Knoten die folgenden Anforderungen erfüllen:

  • Sie müssen mindestens die GKE-Patchversion 1.32.3-gke.1057001 verwenden.
  • Sie müssen einen der folgenden GPU-Maschinentypen verwenden: A4X Max, A4X, A4, A3 Ultra, A3 Mega und A3 High (8 GPUs).
  • Sie müssen Ihre GKE-Knoten auf einer Compute-Instanz ausführen, die an eine Reservierung gebunden ist.
  • Ihr 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 Alle Kapazitäten Reservierungsbetriebsmodus verwendet.

Fehlerhaften Host melden

So melden Sie einen fehlerhaften Host:

  1. Verwenden Sie die GKE-Tools zur Beobachtbarkeit, Ihre eigenen Monitoring-Tools oder Logs, um die GKE-Knoten zu identifizieren, bei denen Leistungsprobleme auftreten. Speichern Sie NODE_NAME.

  2. Melden Sie den Knoten mit dem folgenden Befehl als fehlerhaft. Sie können einen Grund und in 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 den entsprechenden Fehler grund. 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 in den Logs keine XID-Fehler angezeigt werden und keine der anderen üblichen Fehlermuster wie stille Datenbeschädigung erkannt werden.
      • SDC: Verwenden Sie diesen Wert für stille Datenbeschädigung, wenn Daten beschädigt sind, aber kein Systemabsturz auftritt. Diese Datenbeschädigung kann verursacht werden durch CPU-Fehler, Softwarefehler wie „Use-after-free“ oder Speicher überschreibungen, Kernelprobleme oder andere Fehler. Meistens wird dieser Begriff für hardwarebedingte Fehler verwendet.
      • 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 nicht sicher sind, welches Verhalten das Problem mit Ihrer Compute-Instanz verursacht. Das ist der Standard wert. Wir empfehlen jedoch, gegebenenfalls einen der anderen Werte anzugeben,
    • Passen Sie den annotations Block an die 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 Block „annotations“ 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 bei der Fehlerdiagnose zu helfen, und wird 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 Block annotations 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 den Cloud Customer Care, um Fehlerdetails anzugeben.
Nachdem Sie einen fehlerhaften Host für einen Knoten gemeldet haben, variiert die Zeit, bis der Knoten neu gestartet wird, je nach Betriebsmodus der Reservierung, der in der Reservierung angegeben ist, die der Knoten verwendet. Um den Betriebsmodus einer Reservierung zu prüfen, sehen Sie sich das reservationOperationalMode Feld in der Reservierung an. In der folgenden Tabelle ist der Prozess für fehlerhafte Hosts für die beiden verfügbaren Betriebsmodi für Reservierungen zusammengefasst: Modus „Alle Kapazitäten“ und Verwalteter Modus.
Modus „Alle Kapazitäten“ (ALL_CAPACITY) Verwalteter Modus (HIGHLY_AVAILABLE_CAPACITY)
Unterstützte Maschinentypen A4X Max und A4X A4, A3 Ultra, A3 Mega und A3 High
Ratenbegrenzung für API-Aufrufe zum Melden fehlerhafter Hosts Es gelten keine Ratenbegrenzungen. Aufrufe der API können ratenbegrenzt sein.
Prozess zum Melden fehlerhafter Hosts

Wenn Sie einen fehlerhaften Host für einen Knoten melden, der im Modus „Alle Kapazitäten“ 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 auch, die laufenden Pods auf dem Knoten ordnungsgemäß zu entfernen. GKE respects the Pod Disruption Budgets (PDBs) and the spec.terminationGracePeriodSeconds field of your Pod manifests. Weitere Informationen finden Sie unter GKE so konfigurieren, dass Arbeitslasten ordnungsgemäß beendet werden.
  2. Fehlerhaften Host melden und reparieren: GKE meldet und repariert den fehlerhaften Host automatisch, indem die Compute Engine API aufgerufen wird. Dies führt zu einer Reihe von Vorgängen, die in der Regel 10 bis 12 Minuten dauern, um den fehlerhaften Host zu melden, und dann 3 bis 14 Tage oder manchmal sogar länger, um den Host zu reparieren.

  3. Instanz neu starten: Nachdem der Hostreparaturvorgang abgeschlossen ist (in der Regel 3 bis 14 Tage), geschieht eines der folgenden Dinge:

    • Wenn sich die Instanz im Status REPAIRING befindet und die Ressourcen verfügbar sind wenn die Reparatur abgeschlossen ist, startet Compute Engine die Instanz automatisch auf dem reparierten Host neu.
    • Andernfalls, wenn sich die Instanz im Status TERMINATED befindet oder wenn die Ressourcen nicht verfügbar sind, wenn die Reparatur abgeschlossen ist, bleibt der Instanzstatus oder ändert sich in TERMINATED. Sie müssen die Instanz manuell neu starten wenn sie ausgeführt werden soll. Der Neustart der Instanz kann jedoch fehlschlagen, wenn die Ressourcen nicht verfügbar sind, wenn Sie die Instanz neu starten. Das kann beispielsweise passieren, wenn andere Instanzen den reparierten Host bereits verwenden.

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 auch, die laufenden Pods auf dem Knoten ordnungsgemäß zu entfernen. GKE respects the Pod Disruption Budgets (PDBs) and the spec.terminationGracePeriodSeconds field of your Pod manifests. Weitere Informationen finden Sie unter GKE so konfigurieren, dass Arbeitslasten ordnungsgemäß beendet werden.
  2. Fehlerhaften Host melden und mit der Reparatur beginnen: GKE meldet und repariert den fehlerhaften Host automatisch, indem die Compute Engine API aufgerufen wird. Dies führt zu einer Reihe von Vorgängen, die in der Regel 10 bis 12 Minuten dauern, um den fehlerhaften Host zu melden, und dann 3 bis 14 Tage oder manchmal sogar länger, um den Host zu reparieren.

  3. Instanz migrieren und neu starten: Nachdem der Hostreparaturvorgang gestartet wurde (in der Regel 10 bis 12 Minuten), versucht Compute Engine, einen weiteren Host zu reservieren, um den gemeldeten fehlerhaften Host in Ihrer reservierten Kapazität zu ersetzen. Wenn Compute Engine einen fehlerfreien Host findet – wenn der fehlerhafte Host erfolgreich ersetzt wird oder andernfalls ein passender fehlerfreier Host in Ihrer reservierten Kapazität gefunden wird –, migriert Compute Engine die Instanz zu diesem Host. Der Neustart der Instanz erfolgt dann auf eine der folgenden Arten:

    • Wenn sich die Instanz im Status REPAIRING befindet und die Ressourcen verfügbar sind bevor oder wenn die Reparatur abgeschlossen ist, startet Compute Engine die Instanz automatisch auf einem fehlerfreien Host neu.
    • Andernfalls, wenn sich die Instanz im Status TERMINATED befindet oder wenn die Ressourcen nicht verfügbar sind, bevor oder wenn die Reparatur abgeschlossen ist, bleibt der Instanzstatus oder ändert sich in TERMINATED. Sie müssen die Instanz manuell neu starten wenn sie ausgeführt werden soll. Der Neustart der Instanz kann jedoch fehlschlagen, wenn die Ressourcen nicht verfügbar sind, wenn Sie die Instanz neu starten. Das kann beispielsweise passieren, wenn andere Instanzen den reparierten Host bereits verwenden.

Fortschritt des Vorgangs beobachten

Sie können den Fortschritt des GKE-Vorgangs mit dem Knotenlabel cloud.google.com/report-and-replace-status auf Ihrem GKE-Knoten beobachten. Dieses Label hat einen der folgenden Werte:

  • 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 zu einem neuen Host verschoben werden.
  • OperationFAILED: Die API auf der Compute-Instanz ist aufgrund von Kontingentlimits oder anderen Infrastrukturproblemen fehlgeschlagen. Weitere Informationen finden Sie unter Fehler bei der API zum Melden fehlerhafter Hosts beheben. GKE entfernt das Knotenlabel cloud.google.com/fault-behavior und löscht die Knotenmarkierungen. Sie können das Label noch einmal anwenden, um den Vorgang zu wiederholen.
  • Error: Der API-Aufruf zum Melden des fehlerhaften Hosts ist fehlgeschlagen, weil die Anfrage eine der Anforderungen nicht erfüllt hat, die im vorherigen Abschnitt beschrieben sind.

Sie können auch das Knotenlabel cloud.google.com/report-and-replace-operation aufrufen, um die Compute Engine-Vorgangs-ID zu sehen und den Status des Vorgangs zu beobachten.

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

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

Wenn ein API-Aufruffehler auftritt, setzt GKE das Knotenlabel auf cloud.google.com/report-and-replace-status=ERROR. Wenn die API auf der Compute-Instanz fehlschlägt, setzt GKE das Knotenlabel auf cloud.google.com/report-and-replace-status=OperationFAILED. In beiden Fällen löscht GKE die Knotenmarkierungen und entfernt das Knotenlabel cloud.google.com/fault-behavior.

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

Um den Vorgang bei vorübergehenden Fehlern wie Ratenbegrenzungen zu wiederholen, wenden Sie das Label cloud.google.com/fault-behavior noch einmal auf den Knoten an.

Nächste Schritte