GKE-Knotenunterbrechungen für GPUs und TPUs verwalten

Auf dieser Seite erfahren Sie, wie Sie Störungsereignisse auf GKE-Knoten (Google Kubernetes Engine) mit Arbeitslasten für künstliche Intelligenz (KI) oder maschinelles Lernen (ML) verstehen, konfigurieren und überwachen. Dazu gehören:

Während des Lebenszyklus eines lang laufenden GKE-Clusters kommt es aufgrund von automatischen Wartungsereignissen, die von Google Cloud für die Compute Engine-Ressourcen ausgegeben werden, die der GKE-Infrastruktur zugrunde liegen, zu regelmäßigen Störungen bei Arbeitslasten. Wenn diese Störungen Ihre GKE-Knoten betreffen, auf denen KI/ML-Arbeitslasten ausgeführt werden, muss GKE sowohl die laufenden Arbeitslasten als auch den zugrunde liegenden Knoten neu starten.

Warum GPUs und TPUs eine Störungsverwaltung erfordern

Ihre GKE-Cluster verwalten den Lebenszyklus der GKE-Knoten. Diese Knoten werden auf Compute Engine-VMs bereitgestellt. Bei Compute Engine-VMs treten regelmäßig Hostereignisse auf, die durch verschiedene Gründe verursacht werden, z. B. Hardware- oder Softwareupdates, Wartung und Hardwarefehler. Hostereignisse werden für die zugrunde liegende Google Cloud-Infrastruktur ausgegeben und GKE-Wartungsrichtlinien und -ausschlüsse umgehen.

Bei den meisten Compute Engine-VMs ist dieHostwartungsrichtlinie auf Live-Migration festgelegt. Das bedeutet, dass laufende Arbeitslasten nur selten oder gar nicht unterbrochen werden. Bestimmte VM-Klassen unterstützen jedoch keine Live-Migration, einschließlich VMs mit angehängten GPUs und TPUs, auf denen Ihre KI‑/ML-Arbeitslasten ausgeführt werden. Darüber hinaus kann GKE On-Demand-TPUs mithilfe von vorzeitigem Beenden neu starten, sodass GKE aus Gründen der Defragmentierung größere TPUs bereitstellen kann.

Wenn ein Hostereignis eintritt, beendet GKE den Knoten und seine Pods. Wenn die Pods als Teil einer größeren Arbeitslast wie eines Jobs oder Deployments bereitgestellt werden, startet GKE die Pods auf dem betroffenen Knoten neu. Es liegt an Ihnen oder den Frameworks, die Sie zum Verwalten der Arbeitslasten oder Jobs verwenden, angemessen auf die Störung zu reagieren. So können Sie beispielsweise den Status Ihres KI-Trainingsjobs speichern, um Datenverluste zu reduzieren.

Prozess der ordnungsgemäßen Beendigung

Der folgende Workflow zeigt, wie GKE die ordnungsgemäße Knotenbeendigung ausführt, nachdem von Compute Engine eine Störung ausgegeben wurde:

  1. Compute Engine gibt den aktualisierten Wert TERMINATE_ON_HOST_MAINTENANCE für den VM-Metadatenschlüssel maintenance-event aus.

  2. Innerhalb von 60 Sekunden geschieht Folgendes:

    1. Die Systemkomponenten wenden das folgende neue Knotenlabel auf true an, um anzuzeigen, dass die Wartung läuft: cloud.google.com/active-node-maintenance

    2. GKE wendet die Knotenmarkierung an, um zu verhindern, dass neue Pods auf dem Knoten geplant werden: cloud.google.com/impending-node-termination:NoSchedule. Wir empfehlen, Arbeitslasten so zu ändern, dass sie diese Markierung aufgrund der bekannten Beendigung tolerieren.

  3. Die Komponente maintenance-handler beginnt, Pods in der Reihenfolge der Arbeitslast-Pods und dann der System-Pods zu entfernen (z. B. kube-system).

  4. GKE sendet ein Shutdown-Signal-SIGTERM, um eine Benachrichtigung über die Ausführung von Arbeitslast-Pods auf dem Knoten eines bevorstehenden Herunterfahrens zu senden. Pods können mit dieser Benachrichtigung alle laufenden Aufgaben durchführen. GKE unternimmt alles, um diese Pods ordnungsgemäß zu beenden.

Die maintenance-event-Benachrichtigungen werden ausgegeben, wenn die zugrunde liegende Compute Engine-VM eines GKE-Knotens ein störendes Hostereignis erleidet, das zur Beendigung des Knotens führt. In diesem Fall aktualisiert die Compute Engine den maintenance-event-Metadatenschlüssel. Das Benachrichtigungsfenster für die erweiterte Wartungseinstellung vor der Beendigung des Knotens sieht so aus:

  • GPU: 60 Minuten.
  • TPU: 5 Minuten.

Anschließend wird der Knoten beendet und ein Ersatzknoten zugewiesen. GKE löscht die Labels und Markierungen, wenn der Vorgang abgeschlossen ist. Führen Sie die Schritte im Abschnitt GKE für eine ordnungsgemäße Beendigung Ihrer Arbeitslasten konfigurieren aus, um das Beendigungsfenster für Ihre Arbeitslasten mit GPUs oder TPUs zu erhöhen.

Arbeitslaststörungen in GKE beheben

Um GKE-Beendigungsereignisse zu verwalten und Störungen bei Arbeitslasten in Ihren Clustern zu reduzieren, überwacht GKE diese Benachrichtigungen für Sie und führt folgende Aktionen aus:

  • GKE benachrichtigt Ihre Arbeitslasten vor einem bevorstehenden Herunterfahren: Wenn ein GKE-Knoten für ein Hostwartungsereignis beendet werden muss, sendet GKE ein SIGTERM-Signal an ausgeführte Pods auf den Knoten am Anfang des erweiterten Mitteilungszeitraums. Betriebssystemsignale wie SIGTERM können von den meisten Standardbibliotheken nativ verarbeitet werden, z. B. von Python und Go. Zu den Frameworks, die SIGTERM erfassen können, gehören MaxText, Pax und JAX mit Orbax.
  • GKE beendet Ihre Arbeitslasten ordnungsgemäß: Sie können GKE so konfigurieren, dass Ihre Arbeitslasten ordnungsgemäß beendet werden, und zwar mit einem Kulanzzeitraum für die Beendigung von Pods. Pods können auf das SIGTERM-Signal reagieren, um laufende Aufgaben zu beenden und jede von Ihnen definierte Beendigungsaktion auszuführen, z. B. das Speichern eines Trainingsstatus. Während der ordnungsgemäßen Beendigung unternimmt GKE alles, um die Pods ordnungsgemäß zu beenden und die in Ihrer Anwendung definierten Bereinigungsprozesse oder die Beendigungsaktion auszuführen. Dazu werden beispielsweise Arbeitslastdaten gespeichert, um Datenverluste zu reduzieren, oder ein Trainingsstatus gespeichert.

GKE so konfigurieren, dass Arbeitslasten ordnungsgemäß beendet werden

In diesem Abschnitt konfigurieren Sie GKE, um den Anwendungslebenszyklus zu verwalten und Störungen Ihrer Arbeitslast zu minimieren. Wenn Sie keinen Kulanzzeitraum konfigurieren, wird standardmäßig ein Kulanzzeitraum von 30 Sekunden verwendet.

GKE unternimmt alles, um diese Pods ordnungsgemäß zu beenden und die von Ihnen definierte Beendigungsaktion auszuführen, z. B. das Speichern eines Trainingsstatus. GKE sendet zu Beginn des Kulanzzeitraums ein SIGTERM-Signal an Pods. Wenn Pods nicht bis zum Ende des Kulanzzeitraums beendet werden, sendet GKE ein weiteres SIGKILL-Signal an alle Prozesse, die noch in einem Container im Pod ausgeführt werden.

Folgen Sie der Anleitung für GPUs oder TPUs, um den ordnungsgemäßen Beendigungszeitraum für Arbeitslasten zu konfigurieren.

GPU

Legen Sie in Ihrem Pod-Manifest das Feld spec.terminationGracePeriodSeconds auf einen Wert von maximal 3.600 Sekunden (60 Minuten) fest. Wenn Sie beispielsweise eine Benachrichtigungszeit von 10 Minuten erhalten möchten, legen Sie in Ihrem Pod-Manifest das Feld spec.terminationGracePeriodSeconds so auf 600 Sekunden fest:

    spec:
      terminationGracePeriodSeconds: 600

Wir empfehlen, einen Kulanzzeitraum für die Kündigung festzulegen, der lang genug ist, damit alle laufenden Aufgaben innerhalb des Benachrichtigungszeitraums abgeschlossen werden können.

TPU

Legen Sie im Pod-Manifest das Feld spec.terminationGracePeriodSeconds auf 300 Sekunden (fünf Minuten) fest, um die maximale Zeit für die Ausführung der Bereinigungsprozesse zuzuweisen. Beispiele:

    spec:
      terminationGracePeriodSeconds: 300

Wir empfehlen, einen Kulanzzeitraum für die Kündigung festzulegen, der lang genug ist, damit alle laufenden Aufgaben innerhalb des Benachrichtigungszeitraums abgeschlossen werden können.

Wenn Ihre Arbeitslast ein ML-Framework wie MaxText, Pax oder JAX mit Orbax verwendet, können die Arbeitslasten das -Signal erfassen und einen Prüfpunktprozess initiieren. Weitere Informationen finden Sie unter TPU-Autoprüfpunkt.

Fortschritt einer aktiven ordnungsgemäßen Beendigung beobachten

In GKE-Clustern mit der Steuerungsebene, auf der 1.29.1-gke.1425000 oder höher ausgeführt wird, stellt GKE eine Komponente auf Knotenebene namens gpu-maintenance-handler bereit. Diese Komponente wird auf allen GPU- und TPU-Knoten zusammen mit einer entsprechenden Komponente der Steuerungsebene ausgeführt. Diese Komponenten haben folgende Funktionen:

  • Verarbeiten Sie Ereignisse vom Typ „Ordnungsgemäße Beendigung“.
  • Reagieren Sie auf bevorstehende Störungsereignisse auf der GKE-VM, indem Sie ein SIGTERM-Signal an die laufenden Arbeitslasten eines Knotens weiterleiten. Diese Störungen werden als Pod-Bereinigung- und Löschanfragen protokolliert.

GKE fügt Knoten mit dem Status „Bevorstehendes Herunterfahren“ ein Label und eine Markierung hinzu. GKE überwacht Benachrichtigungen zu Hostereignissen wie Wartung mithilfe der Systemkomponente maintenance-handler, die auf jedem GPU- und TPU-Knoten ausgeführt wird.

GKE protokolliert die folgenden Ereignisse für die ordnungsgemäße Beendigung:

Wenn GKE die ordnungsgemäße Beendigung abgeschlossen hat, werden die Labels und Markierungen gelöscht.

Wenn Sie den Status einer aktiven ordnungsgemäßen Beendigung aufgrund einer Störung überwachen möchten, können Sie die gpu-maintenance-handler-Logs über die Console oder das Google Cloud CLI aufrufen.

gcloud

  1. Führen Sie den folgenden Befehl aus, um die Namen der Knoten und Pods zu ermitteln, auf denen Instanzen von gpu-maintenance-handler ausgeführt werden:

    kubectl get pods -l name=maintenance-handler -A -o wide

    Jede Zeile der Ausgabe enthält den Knotennamen, den Podnamen und den Status.

  2. Logs prüfen:

    kubectl logs -n=kube-system MAINTENANCE_HANDLER_POD_NAME

    Ersetzen Sie MAINTENANCE_HANDLER_POD_NAME durch den Namen der Handler-Instanz.

    Wenn ein Wartungsereignis erkannt wird, zeichnet der Pod eine Nachricht auf, wendet die Labels an und die Auslagerungen beginnen.

  3. Prüfen Sie die Knotenlabels und ‑markierungen:

    kubectl describe node NODE_NAME

    Ersetzen Sie NODE_NAME durch den Namen des Pods, den Sie sich ansehen möchten.

    Die Ausgabe enthält eine Liste der zu beobachtenden Knotenlabels und ‑markierungen.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

    Zum Log-Explorer

  2. Geben Sie im Feld Abfrage die folgende Abfrage ein:

    resource.type="k8s_container"
resource.labels.namespace_name="kube-system"
resource.labels.container_name="maintenance-handler"
resource.labels.cluster_name="CLUSTER_NAME"

    Ersetzen Sie CLUSTER_NAME: Der Name Ihres Clusters.

Nächste Schritte