KI-optimierte GKE-Cluster verwalten

Auf dieser Seite wird beschrieben, wie Sie KI-optimierte Google Kubernetes Engine-Cluster (GKE) mit A4X Max-, A4X-, A4-, A3 Ultra-, A3 Mega- und A3 High-Maschinen (8 GPUs) verwalten. Dazu gehören die folgenden häufigen Ereignisse, die für GKE-Cluster und KI-Arbeitslasten relevant sind:

  • Hostwartung
  • Clusterupgrades
  • Fehlerhafte Hosts melden

Hostwartung für KI-Arbeitslasten verwalten

GKE-Knoten werden auf Compute Engine-Instanzen ausgeführt, die regelmäßig Hostereignisse durchlaufen, die KI-Arbeitslasten stören können. Da Hostereignisse in der zugrunde liegendenGoogle Cloud -Infrastruktur auftreten, werden GKE-Wartungsfenster und -ausschlüsse umgangen. Bei den meisten Compute-Instanzen ist die Hostwartungsrichtlinie auf Live-Migration festgelegt, wodurch Unterbrechungen von Arbeitslasten minimiert werden. 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 im Blick behalten.

Mit diesen Knotenlabels haben Sie folgende Möglichkeiten:

Host-Wartungsereignis manuell starten

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

Wenn Sie kein Host-Wartungsereignis manuell starten, führt Compute Engine die regelmäßig geplante Wartung automatisch durch.

Folgen Sie der Anleitung zum manuellen Starten eines Host-Wartungsereignisses. Lesen Sie in diesem Abschnitt weiter, um Folgendes zu erfahren:

Informationen zur Hostwartung beim Planen von Arbeitslasten verwenden

Sie können die Wartungsinformationen, die über GKE-Knotenlabels angezeigt 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 geplanten Wartungsereignisse anstehen, 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 Wartungsarbeiten geplant sind. Geben Sie dazu die Unix-Epochenzeit an:

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

GKE-Cluster-Upgrades für KI-Arbeitslasten verwalten

KI-Arbeitslasten reagieren empfindlich auf Unterbrechungen.

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, dass Ihr Cluster in einer Release-Version registriert bleibt. GKE-Cluster sind standardmäßig in der Release-Version „Regular“ registriert. Weitere Informationen zu den Vorteilen von Release-Versionen finden Sie unter Vergleich von Clustern, die in einer Release-Version registriert sind und nicht.

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 an Ihr Kontoteam.

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 das Knotenlabel fault-behavior zuweisen. 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 wird. Bei Reservierungen, die den Betriebsmodus „Alle Kapazitäten“ verwenden, stellt Compute Engine die Compute-Instanz nach Abschluss der Reparatur auf demselben Knoten wieder her.
  5. Entfernt die Markierung und das Label fault-behavior vom Knoten.

Danach kann der Knoten wieder Arbeitslasten 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 ausführen.
  • Sie müssen einen der folgenden GPU-Maschinentypen verwenden: 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.
  • 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 begrenzt werden, basierend auf einer Bewertung des Zustands Ihrer Blöcke. Ratenbeschränkungen gelten nicht, wenn für Ihre Reservierung der Betriebsmodus für Reservierungen mit voller Kapazität verwendet wird.

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. Speichere die NODE_NAME.

  2. Melden Sie den Knoten als fehlerhaft:

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

    Ersetzen Sie Folgendes:

    • NODE_NAME: Der Name des fehlerhaften Knotens.
    • FAULT_REASON: Der entsprechende Fehlergrund 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, 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 die stille Datenbeschädigung, wenn Sie 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. Dieser Begriff wird meistens für hardwarebedingte Defekte verwendet.
      • XID: Verwenden Sie diesen Wert, wenn Sie einen nicht behebaren GPU-Fehler mit einer XID für eine Compute-Instanz festgestellt haben.
      • unspecified: Verwenden Sie diesen Wert, wenn Sie nicht sicher sind, welches Verhalten das Problem mit Ihrer Compute-Instanz verursacht. Das ist der Standardwert. Wir empfehlen jedoch, gegebenenfalls einen der anderen Werte anzugeben.
Nachdem Sie einen fehlerhaften Host für einen Knoten gemeldet haben, variiert die Zeit, zu der der Knoten neu gestartet wird, je nach -Reservierungsbetriebsmodus, der in der Reservierung angegeben ist, die der Knoten verwendet. Rufen Sie das Feld reservationOperationalMode in der Reservierung auf, um den Betriebsmodus einer Reservierung zu prüfen. In der folgenden Tabelle ist der fehlerhafte Hostprozess für die beiden verfügbaren Betriebsmodi für Reservierungen zusammengefasst: Modus mit voller 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
Ratenbegrenzung für die API für fehlerhafte Hostberichte Es gelten keine Ratenbegrenzungen. API-Aufrufe können begrenzt werden.
Prozess zum Melden fehlerhafter Hosts

Wenn Sie einen fehlerhaften Host für einen Knoten melden, der im Modus „Alle Kapazitäten“ ausgeführt wird, passiert Folgendes:

  1. Pods entfernen: Nachdem das Label auf den fehlerhaften Knoten angewendet wurde, markiert GKE den Knoten, um die Planung neuer Pods zu verhindern. GKE beginnt auch, 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 meldet und repariert den fehlerhaften Host automatisch, indem die Compute Engine API aufgerufen wird. Dies führt zu einer Folge von Vorgängen, die in der Regel 10 bis 12 Minuten dauert, um den fehlerhaften Host zu melden. Die Reparatur des Hosts kann dann 3 bis 14 Tage oder manchmal auch länger dauern.

  3. Instanz neu starten: Nachdem der Hostreparaturvorgang abgeschlossen wurde (in der Regel 3–14 Tage), tritt einer der folgenden Fälle ein:

    • 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.
    • Wenn die Instanz den Status TERMINATED hat oder Ressourcen nicht verfügbar sind, wenn die Reparatur abgeschlossen ist, bleibt der Instanzstatus bei TERMINATED 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 beim Neustart der Instanz keine Ressourcen 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, passiert 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 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 meldet und repariert den fehlerhaften Host automatisch, indem die Compute Engine API aufgerufen wird. Dies führt zu einer Folge von Vorgängen, die in der Regel 10 bis 12 Minuten dauert, um den fehlerhaften Host zu melden, und dann 3 bis 14 Tage oder manchmal auch länger dauern kann, um den Host zu reparieren.

  3. Instanz migrieren und neu starten: Nachdem der Hostreparaturvorgang gestartet wurde (in der Regel nach 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 Compute Engine auf andere Weise einen passenden fehlerfreien Host in Ihrer reservierten Kapazität findet –, migriert Compute Engine die Instanz zu diesem Host. Das Neustarten der Instanz erfolgt dann auf eine der folgenden Arten:

    • Wenn sich die Instanz im Status REPAIRING befindet und Ressourcen vor oder während der Reparatur verfügbar sind, startet Compute Engine die Instanz automatisch auf einem fehlerfreien Host neu.
    • Andernfalls, wenn sich die Instanz im Status TERMINATED befindet oder Ressourcen vor oder nach Abschluss der Reparatur nicht verfügbar sind, bleibt der Instanzstatus TERMINATED 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 beim Neustart der Instanz keine Ressourcen verfügbar sind. Das kann beispielsweise passieren, wenn andere Instanzen den reparierten Host bereits verwenden.

Vorgangsfortschritt überwachen

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

  • PodsEvicted: GKE hat das Entfernen von Pods vom betroffenen Knoten abgeschlossen.
  • 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.
  • Error: Der API-Aufruf ist fehlgeschlagen, unter anderem aus einem der Gründe, die im vorherigen Abschnitt beschrieben werden.

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 überwachen.

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

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

Bei API-Fehlern legt GKE das Knotenlabel cloud.google.com/report-and-replace-status=ERROR fest. GKE entfernt die Knotenmarkierungen und das Knotenlabel cloud.google.com/fault-behavior.

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

Wenn Sie den Vorgang bei vorübergehenden Fehlern wie Ratenbegrenzungen noch einmal versuchen möchten, wenden Sie das Label cloud.google.com/fault-behavior noch einmal auf den Knoten an.

Nächste Schritte