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 haben Sie folgende Möglichkeiten:

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 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 den Vergleich zwischen Clustern, die in einer Release-Version registriert sind und solchen, die es nicht sind.

Mit Release-Versionen haben Sie Zugriff auf weitere Funktionen, einschließlich zusätzlicher Wartungsausschluss bereiche. 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, 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 Bereitstellungsmodell mit flexibler Startzeit (Vorschau) bereitgestellt wurde, dann wenden Sie sich stattdessen an Ihr Account-Management-Team.

Wenn Sie GPU-Arbeitsspeicher- 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 Xid Meldungen 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 dem betroffenen GKE-Knoten ein Knotenlabel fault-behavior 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 all capacity 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 die GKE-Patchversion 1.32.3-gke.1057001 oder höher 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 aufgrund einer Bewertung des Zustands Ihrer Blöcke begrenzt sein. Ratenbegrenzungen gelten nicht, wenn Ihre Reservierung den all capacity 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 mit einem oder mehreren 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 Fehlermuster wie stille Datenbeschädigung erkannt werden.
      • SDC: Verwenden Sie diesen Wert für stille Datenbeschädigung, wenn Sie Daten Beschädigung, aber keinen Systemabsturz feststellen. 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 verwendet, um hardwarebedingte Fehler zu bezeichnen.
      • XID: Verwenden Sie diesen Wert, wenn Sie einen nicht wiederherstellbaren 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. Dies ist der Standard Wert. Wir empfehlen jedoch, gegebenenfalls einen der anderen Werte anzugeben,
    • Passen Sie den annotations Block an die Steuerungsebene-Version 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 Cloud Customer Care, um Fehlerdetails anzugeben.
Nachdem Sie einen fehlerhaften Host für einen Knoten gemeldet haben, variiert der Zeitpunkt, zu dem der Knoten neu gestartet wird, je nach Betriebsmodus der Reservierung, der in der Reservierung angegeben ist, die der Knoten verwendet. Um den Betriebsmodus der Reservierung für eine 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 der Reservierung zusammengefasst: all capacity mode und managed mode.
Modus „All capacity“ (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 die API 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 „All capacity“ 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 TERMINATED oder ändert sich in diesen Status. Sie müssen die Instanz manuell neu starten wenn sie ausgeführt werden soll. Der Neustart der Instanz kann jedoch fehlschlagen, wenn die Ressourcen beim Neustart der Instanz nicht verfügbar sind. 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 ein anderer 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 TERMINATED oder ändert sich in diesen Status. Sie müssen die Instanz manuell neu starten wenn sie ausgeführt werden soll. Der Neustart der Instanz kann jedoch fehlschlagen, wenn die Ressourcen beim Neustart der Instanz nicht verfügbar sind. 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. Informationen zum Fehler finden Sie unter Fehlerbehebung bei API-Fehlern beim Melden fehlerhafter Hosts. Informationen zur Wiederherstellung finden Sie unter Fehler beim Melden und Ersetzen beheben.
  • Error: Der API-Aufruf ist fehlgeschlagen, weil die Anfrage eine der Anforderungen nicht erfüllt hat, die im vorherigen Abschnitt beschrieben wurden.

Sie können auch das Knotenlabel node.gke.io/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,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. Außerdem wendet GKE in Version 1.35.6-gke.1256000 oder höher oder 1.36.0-gke.4060000 oder höher die Markierung cloud.google.com/report-and-replace-failed:NoSchedule auf den Knoten an. Diese Markierung verhindert, dass neue Pods auf dem Knoten geplant werden, sodass 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 fehlerhafter Hosts finden Sie unter Vorgänge zum Melden fehlerhafter 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. Diese Markierung sorgt dafür, dass der Knoten isoliert bleibt, sodass keine neuen Arbeitslasten darauf geplant werden, während der zugrunde liegende Host möglicherweise noch fehlerhaft ist.

Auf die Markierung für Fehler prüfen

Führen Sie den folgenden Befehl aus, um zu prüfen, ob ein Knoten die Markierung für Fehler beim Melden und Ersetzen hat:

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

Nach einem Fehler beim Melden und Ersetzen wiederherstellen

So führen Sie eine Wiederherstellung nach einem Fehler beim Melden und Ersetzen durch:

  • 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 Sie ihn wieder in Betrieb nehmen möchten:

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

Nächste Schritte