Hostwartung in GKE

Während des Lebenszyklus eines lang laufenden GKE-Cluster kommt es aufgrund von Infrastrukturunterbrechungen, die vonCloud de Confiance by S3NS ausgegeben werden, zu regelmäßigen Störungen bei Arbeitslasten. Diese automatischen Ereignisse können als Reaktion auf Planungsentscheidungen (Preemption-Ereignisse) oder Knotenaktualisierungen auftreten, einschließlich automatischer GKE-Knotenupgrades (Wartungsereignisse) oder der Behebung erkannter Probleme (Beendigungsereignisse).

In diesem Dokument wird erläutert, was Knotenunterbrechungen in GKE bedeuten und wie Sie die Auswirkungen von Unterbrechungen auf Ihre GKE-Knoten minimieren können.

Weitere Informationen zum Monitoring von Wartungsbenachrichtigungen und -ereignissen finden Sie unter Wartungsereignisse überwachen.

Dieses Dokument gilt für die folgenden Maschinentypen:

Dieses Dokument richtet sich an Plattformadministratoren und ‑betreiber, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Cloud de Confiance by S3NS -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Was bedeutet Infrastrukturunterbrechung in der GKE?

Ihre GKE-Cluster verwalten den Lebenszyklus der GKE-Knoten. Diese Knoten werden auf Compute Engine-VMs bereitgestellt, die regelmäßig die folgenden Unterbrechungen aufweisen:

  • Behebung erkannter Probleme (TerminationEvent): Diese Ereignisse treten auf, weil Cloud de Confiance by S3NS ein Problem erkennt und Ihre Clusterinfrastruktur unterbricht. TerminationEvent-Ereignisse unterstützen kein ordnungsgemäßes Herunterfahren. TerminationEvent-Ereignisse werden durch die folgenden Probleme ausgelöst:

    • Eine automatische Reparatur erfolgt, wenn die GKE einen Knoten nach wiederholten fehlgeschlagenen Systemdiagnosen repariert.
    • HostError tritt auf, wenn ein Hardware- oder Softwarefehler auf der physischen Maschine dazu führt, dass die VM beendet wird.

  • Wartungs- oder Upgrade-Ereignisse (MaintenanceEvent): Diese Ereignisse treten auf, wenn Cloud de Confiance by S3NS eine VM unterbrechen muss, um Wartungsarbeiten durchzuführen. Diese Ereignisse werden durch die folgenden Wartungsaufgaben ausgelöst:

    • Wartungsereignisse treten auf, wenn Cloud de Confiance by S3NS den zugrunde liegenden Host aktualisiert.
    • Knotenupdates, einschließlich automatischer Knotenupgrades, erfolgen, wenn GKE die Konfiguration des Knotens aktualisiert, z. B. die GKE-Version.

    Weitere Informationen dazu, wie Sie und GKE Änderungen während des Lebenszyklus eines Clusters verwalten, finden Sie unter Arten von Änderungen.

  • Reaktion auf Planungsentscheidungen (PreemptionEvent): Diese Ereignisse treten auf, wenn Cloud de Confiance by S3NS VMs vorzeitig beenden muss, um Kapazität für Ressourcen mit höherer Priorität bereitzustellen. PreemptionEvent-Ereignisse können Folgendes sein:

    • Entfernung: Tritt auf, wenn eine auf Abruf bereitgestellte oder Spot-Infrastruktur vorzeitig beendet wird, um eine VM mit höherer Priorität zu berücksichtigen.
    • Defragmentierung: Tritt auf, wenn GKE ein kleineres TPU-Slice vorzeitig beendet, um ein größeres TPU-Slice aufzunehmen. Die Defragmentierung erfolgt nur auf TPU-Slices.

Während des Lebenszyklus eines lang laufenden GKE-Cluster kann es bei den Knoten zu regelmäßigen Störungen bei Arbeitslasten kommen. Wenn diese Störungen die GKE-Knoten betreffen, auf denen Ihre Arbeitslasten ausgeführt werden, muss GKE sowohl die laufenden Arbeitslasten als auch den zugrunde liegenden Knoten neu starten.

Warum Knoten, die keine Live-Migration unterstützen, eine Unterbrechungsverwaltung erfordern

Bei den meisten Compute Engine-VMs ist die Hostwartungsrichtlinie auf Live-Migration festgelegt. Das bedeutet, dass laufende Arbeitslasten in der Regel nur selten oder gar nicht unterbrochen werden. Bestimmte VM-Klassen unterstützen jedoch keine Live-Migration, einschließlich der folgenden Maschinentypen:

  • Maschinentypen mit angehängten GPUs und TPUs.
  • H4D-Maschinentypen.
  • Der Maschinentyp c4a-highmem-96-metal.
  • C4D-Bare-Metal-Maschinentypen (c4d-standard-384-metal, c4d-highcpu-384-metal und c4d-highmem-384-metal).
  • Z3-Maschinentypen mit mehr als 18 TiB angehängter Titanium-SSD.
  • Z4D-Maschinentypen mit mehr als 42 TiB angehängter Titanium SSD.
  • Z4M-Maschinentypen mit mehr als 48 TiB angehängter Titanium-SSD oder Z4M-Instanzen, die Cloud RDMA verwenden.

Wenn beispielsweise ein Host-Ereignis für die VM innerhalb eines TPU-Slice auftritt, wird das gesamte Slice unterbrochen und dann neu geplant, da alle Wartungsereignisse auf Slice-Ebene koordiniert werden. Wenn Sie also ein TPU-Slice mit Hunderten von VMs erstellen, erhalten alle diese VMs denselben Zeitplan für Wartungsereignisse.

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.

Wartungsereignisse verwalten

Im weiteren Verlauf dieses Dokuments wird beschrieben, wie Sie MaintenanceEvent-Unterbrechungen verwalten.

Die Verwaltung von Knotenunterbrechungen während Hostwartungsereignissen erfolgt in drei Phasen:

  1. Geplante Hostwartung erkennen: Verwenden Sie GKE-Knotenlabels, Metadatenendpunkte oder Logs.
  2. Auf erkannte Wartung reagieren: Wenn eine Wartung geplant ist, bewerten Sie Ihre Infrastruktur und Arbeitslasten und bestimmen Sie die beste Maßnahme für Ihren Anwendungsfall. Ergreifen Sie die entsprechenden Maßnahmen, z. B. das System das Wartungsereignis automatisch verarbeiten lassen, die Hostwartung manuell starten oder Wartungsstrategien orchestrieren.
  3. Ergebnis des Wartungsereignisses prüfen: Prüfen Sie, ob das Wartungsereignis korrekt gestartet wurde, entweder wenn die Compute Engine das Wartungsereignis planmäßig startet oder wenn Sie es manuell starten.

Geplante Hostwartung erkennen

Wenn Sie anstehende Wartungsereignisse im Blick behalten und erkennen möchten, müssen Sie die Benachrichtigungen von GKE und Compute Engine im Auge behalten.

Weitere Informationen zum Monitoring von Wartungsbenachrichtigungen und -ereignissen finden Sie unter Wartungsereignisse überwachen.

Auf erkannte Wartung reagieren

Wenn Sie eine Benachrichtigung über anstehende geplante Wartungsarbeiten für einen oder mehrere Knoten in Ihrem Cluster sehen, können Sie anhand des folgenden Entscheidungsbaums die beste Vorgehensweise für die Unterbrechung ermitteln:

  1. Automatische Wartung: Compute Engine startet das Wartungsereignis planmäßig. Ihre VMs werden automatisch im Hintergrund mit minimaler oder keiner Unterbrechung migriert.

    1. Wenn die Host-VM die Live-Migration unterstützt, empfehlen wir, das Wartungsereignis automatisch ausführen zu lassen.
    2. Wenn Ihre Arbeitslasten auf inaktiven flexiblen Knoten ausgeführt werden, können Sie den Zeitpunkt der Wartung automatisch optimieren, indem Sie die opportunistische Wartung konfigurieren. Dadurch werden erforderliche Updates nur während natürlicher Leerlaufzeiten ausgelöst.

  2. Hostwartungsereignis manuell starten: Beantworten Sie die folgenden Fragen, um die beste Methode für den manuellen Umgang mit der Unterbrechung zu ermitteln:

    1. Sind die betroffenen Knoten einzelne oder isolierte VMs?

      • Ja (Ich führe eine einzelne oder isolierte VM aus):
        • Wenn Sie keine genauen Zeitsteuerungen benötigen, lassen Sie Compute Engine das Wartungsereignis nach Zeitplan starten (Standardeinstellung: automatisch).
        • Wenn Sie unerwartete Preemptions vermeiden möchten, starten Sie das Host-Wartungsereignis auf dem einzelnen Knoten manuell zu einem geeigneten Zeitpunkt, z. B. während eines Zeitfensters mit geringem Traffic.
      • Nein (Ich führe einen Knotenpool von Beschleunigern aus): Wählen Sie im nächsten Schritt eine der Optionen aus.

    2. Wählen Sie je nach Anwendungsfall eine der folgenden Optionen aus:

      • Wenn in Ihrem Beschleunigerpool gekoppelte KI-/ML-Trainingsaufgaben ausgeführt werden: Implementieren Sie die parallele Strategie. Speichern Sie den Trainingsstatus in einem Prüfpunkt, fahren Sie den Pool ordnungsgemäß herunter und führen Sie Hostupdates und GKE-Clusterupgrades gleichzeitig durch, bevor Sie neu starten.

      • Wenn Ihr Beschleunigerpool hochverfügbare KI-/ML-Bereitstellungs- oder Inferenzendpunkte ausführt: Implementieren Sie die rollierende Strategie. Koordinieren Sie geplante Hostwartungen und Versionsupgrades in rollierenden Batches innerhalb Ihrer Zonen- oder Poolgrenzen und verwenden Sie aktive Replikate, um SLAs zu schützen.

Hostwartungsereignis auf einzelnen oder isolierten VMs manuell starten

Sie können verschiebbare Wartungen manuell starten, wenn es in Ihren Zeitplan passt, z. B. in Zeiten geringer Aktivität. Wenden Sie dazu das Label cloud.google.com/perform-maintenance=true an, wenn die folgenden Bedingungen erfüllt sind:

  • Compute Engine gibt eine Benachrichtigung zu einem geplanten Wartungsereignis aus.
  • Das zugrunde liegende Compute Engine-Wartungsereignis kann verschoben werden. Wenn Sie prüfen möchten, ob das Ereignis verschoben werden kann, suchen Sie in den Ereignismetadaten nach der Benachrichtigung can_reschedule=TRUE. Wenn das Ereignis nicht verschoben werden kann, hat das Festlegen des Labels cloud.google.com/perform-maintenance=true keine Auswirkungen und die Wartung erfolgt zum ursprünglich geplanten Zeitpunkt.

Wenn die oben genannten Bedingungen erfüllt sind, legen Sie auf einem Knoten im Knotenpool das Knotenlabel cloud.google.com/perform-maintenance auf true fest. Beispiel:

kubectl label nodes <node-name> cloud.google.com/perform-maintenance=true

Wenn Sie ein Wartungsereignis starten, führt GKE die folgenden Vorgänge aus:

  1. Markiert den Knoten.
  2. Pods werden ordnungsgemäß entfernt.
  3. Fordert Compute Engine auf, das Wartungsereignis sofort zu starten, anstatt auf die geplante Zeit zu warten.

Ergebnis des Wartungsereignisses prüfen

Nachdem Sie ein anstehendes Wartungsereignis erkannt und die beste Vorgehensweise festgelegt haben, können Sie das Ergebnis des Wartungsereignisses prüfen.

Compute Engine startet das Wartungsereignis planmäßig.

Wenn das Wartungsereignis beginnt, wird ein Knoten möglicherweise ein- oder mehrmals heruntergefahren. Vor dem Herunterfahren wird eine kurze Benachrichtigung angezeigt. In diesen Fällen unternimmt GKE alles, um Arbeitslasten zu beenden und Pods ordnungsgemäß zu entfernen.

Geplante Wartung beginnt

Wenn die geplante Wartung beginnt, aktualisiert Compute Engine die Metadaten im Verzeichnis http://metadata.google.internal/computeMetadata/v1/instance/attributes/. Compute Engine aktualisiert die Metadatenlabels so:

  • Legt maintenance-event auf TERMINATE_ON_HOST_MAINTENANCE fest.
  • In upcoming-maintenance wird maintenance_status auf ONGOING gesetzt.

GKE erkennt und verarbeitet das geplante Hostwartungsereignis, unabhängig davon, ob Sie es manuell auslösen oder GKE automatisch fortfahren lassen.

Der folgende GKE-Systemmesswert gibt die Anzahl der Unterbrechungen für einen GKE-Knoten seit der letzten Stichprobe an (der Messwert wird alle 60 Sekunden abgerufen):

  • kubernetes.io/node/interruption_count

Die Felder interruption_type (z. B. TerminationEvent, MaintenanceEvent oder PreemptionEvent) und interruption_reason (z. B. HostError, Eviction oder AutoRepair) können den Grund für die Unterbrechung eines Knotens angeben.

Verwenden Sie die folgende PromQL-Abfrage, um eine Aufschlüsselung der Unterbrechungen und ihrer Ursachen in TPU-Knoten in den Clustern Ihres Projekts zu erhalten:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

Wenn Sie nur die Hostwartungsereignisse sehen möchten, aktualisieren Sie die Abfrage, um den Wert HW/SW Maintenance für interruption_reason zu filtern. Verwenden Sie die folgende PromQL-Abfrage:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

Verwenden Sie die folgende PromQL-Abfrage, um die Anzahl der Unterbrechungen nach Knotenpool aggregiert aufzurufen:

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

Erweiterte Konfigurationen zur Minimierung von Unterbrechungen

In diesem Abschnitt werden zusätzliche Tools zum Konfigurieren Ihres Clusters und Ihrer Arbeitslasten beschrieben, um Unterbrechungen zu minimieren.

Unterbrechungsbehandlung aktivieren

apiVersion: v1
kind: ConfigMap
metadata:
  name: gke-disruption-handling
  namespace: kube-system
data:
  maintenance-experience.yaml: |
    gracefulTermination: true

Wenn Sie die Unterbrechungsbehandlung aktivieren möchten, erstellen Sie eine Datei mit dem Namen maintenance-config.yaml mit dieser ConfigMap. Wenden Sie die ConfigMap mit dem folgenden Befehl auf den Cluster an:

kubectl apply -f my-configmap.yaml

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.

Wenn Sie den Kulanzzeitraum für die Beendigung konfigurieren möchten, legen Sie den Kulanzzeitraum für die Beendigung (in Sekunden) im Feld spec.terminationGracePeriodSeconds Ihres Pod-Manifests 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. Wenn Ihre Arbeitslast ein ML-Framework wie MaxText, Pax oder JAX mit Orbax verwendet, können die Arbeitslasten das SIGTERM-Signal erfassen und einen Prüfpunktprozess initiieren. Weitere Informationen finden Sie unter TPU-Autocheckpoint.

Prozess der ordnungsgemäßen Beendigung

Wenn ein manuell gestartetes Wartungsereignis beginnt, signalisiert Compute Engine das bevorstehende Herunterfahren der Maschine, indem der Metadatenschlüssel maintenance-event aktualisiert wird. GKE startet die ordnungsgemäße Beendigung.

Der folgende Workflow zeigt, wie GKE die ordnungsgemäße Knotenbeendigung ausführt, wenn ein Knoten heruntergefahren wird:

  1. Innerhalb von 60 Sekunden geschieht Folgendes:
    1. Die Systemkomponenten wenden das Knotenlabel cloud.google.com/active-node-maintenance auf ONGOING an, um anzuzeigen, dass Arbeitslasten beendet werden.
    2. GKE wendet die Knotenmarkierung an, um zu verhindern, dass neue Pods auf dem Knoten geplant werden. Die Markierung hat den Schlüssel cloud.google.com/impending-node-termination:NoSchedule. Wir empfehlen, Ihre Arbeitslasten nicht so zu ändern, dass sie diese Markierung aufgrund der bekannten Beendigung tolerieren.
  2. Die Komponente „maintenance-handler“ beginnt, Pods zu entfernen. Dabei werden zuerst Arbeitslast-Pods und dann System-Pods (z. B. kube-system) entfernt.
  3. GKE sendet ein SIGTERM-Shutdown-Signal an Arbeitslast-Pods, die auf dem Knoten ausgeführt werden, um sie über ein bevorstehendes Herunterfahren zu benachrichtigen. Pods können mit dieser Benachrichtigung alle laufenden Aufgaben durchführen. GKE unternimmt alles, um diese Pods ordnungsgemäß zu beenden.
  4. Nach Abschluss der Bereinigung aktualisiert GKE den Wert des Labels cloud.google.com/active-node-maintenance auf terminating, um anzugeben, dass der Knoten beendet werden kann.

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 Host-Wartungsereignis manuell starten aus, um das Beendigungsfenster für Ihre Arbeitslasten mit GPUs oder TPUs zu erhöhen.

Fortschritt einer aktiven ordnungsgemäßen Beendigung prüfen

Sie können die GKE-Logs nach den folgenden Ereignissen für die ordnungsgemäße Beendigung filtern:

  • Wenn die VM eine Störung aufgrund einer bevorstehenden Knotenbeendigung erkennt, z. B. ein Compute Engine-Hostwartungsereignis, setzt GKE den cloud.google.com/active-node-maintenance auf ONGOING, wenn Arbeitslasten beendet werden, und auf terminating, wenn die Arbeitslasten abgeschlossen sind und der Knoten beendet werden kann.
  • Wenn die Planung neuer Arbeitslasten eingeschränkt wird, wendet GKE die Markierung cloud.google.com/impending-node-termination:NoSchedule an.

Unterbrechungen laufender Arbeitslasten durch opportunistische Wartung minimieren

Sie können die Unterbrechung laufender Arbeitslasten minimieren, indem Sie die Wartung automatisch auslösen, wenn GKE erkennt, dass Knoten mit GPUs oder TPUs inaktiv sind. Erstellen Sie einen neuen Knotenpool, um diese Funktion zu aktivieren. Sie können die opportunistische Wartung für einen vorhandenen Knotenpool nicht aktivieren.

Neuen Knotenpool mit opportunistischer Wartung erstellen

Der folgende Befehl zeigt, wie Sie einen Knotenpool mit aktivierter opportunistischer Wartung erstellen können:

gcloud beta container node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --accelerator ACCELERATOR_ARG \
    --machine-type MACHINE_TYPE \
    --num-nodes NODE_COUNT \
    --zone ZONE \
    --project=PROJECT_ID \
    --opportunistic-maintenance=node-idle-time=NODE_IDLE_TIME,min-nodes=MIN_NODES,window=WINDOW

Ersetzen Sie die folgenden Werte:

  • NODE_POOL_NAME: der Name Ihres GKE-Knotenpools.
  • CLUSTER_NAME : der Name Ihres GKE-Clusters.
  • NODE_IDLE_TIME : Die Zeit, die ein Knoten inaktiv bleiben kann (d. h. es werden keine Arbeitslasten ausgeführt, die Beschleuniger verbrauchen), bevor eine Wartung ausgelöst wird. Der Wert stellt die Dauer in Sekunden mit bis zu neun Nachkommastellen dar und endet mit dem Zeichen s, z. B. 80000s.
  • MIN_NODES : die Mindestanzahl von Knoten, die in einem Knotenpool verfügbar sein müssen. Mit dieser Option wird die Wartung blockiert, wenn die Anzahl der laufenden Knoten dadurch unter diesen Wert fällt, z. B. 10.
  • WINDOW : das Zeitfenster in Sekunden, in dem die opportunistische Wartung ausgeführt werden kann. Der Wert endet mit einem s-Zeichen. Ein Wert von 14 Tagen oder 1209600s bedeutet beispielsweise, dass die opportunistische Wartung nur in den zwei Wochen vor dem geplanten Wartungsdatum ausgeführt werden kann. Ein Wert von 28 Tagen oder 2419200s ermöglicht es, die opportunistische Wartung jederzeit während des geplanten Wartungsfensters auszuführen. Dieses Fenster für die Compute Engine-Hostwartung unterscheidet sich von GKE-Wartungsfenstern, die festlegen, wann die GKE-Clusterwartung erfolgen kann, und separat konfiguriert werden.

Beispielkonfiguration für opportunistische Wartung

Dazu ein Beispiel: Sie haben einen Knotenpool mit vier Knoten und die opportunistische Wartungskonfiguration ist auf --opportunistic-maintenance=node-idle-time=600s,window=2419200s,min-nodes=3 festgelegt. In diesem Szenario geschieht Folgendes:

  • Auf node1 wird eine GPU-Arbeitslast ausgeführt. Dieser Knoten ist nicht inaktiv und wird daher übersprungen.
  • node2 ist seit 60 Sekunden inaktiv. Dieser Knoten war nicht lange genug inaktiv und wird daher übersprungen.
  • node3 ist seit 600 Sekunden inaktiv. Dieser Knoten erfüllt die Anforderung für den inaktiven Zustand.
  • node4 ist seit 600 Sekunden inaktiv. Dieser Knoten erfüllt die Anforderung für den inaktiven Zustand.

Sowohl node3 als auch node4 erfüllen die Anforderung für den inaktiven Zustand. Allerdings wird nur einer dieser Knoten eine opportunistische Wartung auslösen, da der Wert der Option min-nodes auf 3 festgelegt ist.

Konfiguration und Status von Knoten mit opportunistischer Wartung prüfen

Prüfen Sie mit dem folgenden Befehl, ob die opportunistische Wartung für einen Knoten konfiguriert ist:

kubectl describe node NODE_NAME | grep node.gke.io/opportunistic-config

Ersetzen Sie NODE_NAME durch den Namen des Knotens, den Sie prüfen möchten.

Prüfen Sie, ob ein mit opportunistischer Wartung konfigurierter Knoten gewartet wird:

kubectl describe node NODE_NAME | grep node.gke.io/maintenance-state

Wenn der Knoten durch eine opportunistische Wartung ausgelöst wird, wird in der Annotation maintenance-state der Wert opportunistic-triggered als true angezeigt.

Beschränkungen

Beachten Sie die folgenden Einschränkungen der opportunistischen Wartung:

  • Diese Funktion kann nur mit GPU- und TPU-Knotenpools verwendet werden.
  • Die opportunistische Wartung ist nicht mit Cluster Autoscaler kompatibel, da Cluster Autoscaler inaktive Knoten bereits herunterskaliert.
  • Für TPU-Knotenpools mit mehreren Hosts sollte der Wert der Einstellung min-nodes-per-pool 0 sein, da diese Knotenpools atomar sind.
  • Die niedrigste unterstützte GKE-Version ist 1.33.3-gke.1118000.
  • Es werden nur geplante Wartungen unterstützt, die die Benachrichtigung can_reschedule=TRUE enthalten.
  • Wenn Sie diese Funktion deaktivieren möchten, müssen Sie den Knotenpool ohne die entsprechenden Flags neu erstellen. Alternativ können Sie die Funktion auf bestimmten Knoten mit cloud.google.com/opportunistic-disable=true manuell deaktivieren.
  • In seltenen Fällen kann die Wartung eines Knotens länger dauern. Kunden, die diese Funktion verwenden, haben möglicherweise für einen bestimmten Zeitraum weniger verfügbare Knoten, bis hin zum Wert der Einstellung min-nodes-per-pool.

Nächste Schritte