In diesem Dokument wird erläutert, wie Sie die Hostwartung der zugrunde liegenden Compute Engine-Instanzen für Knoten in Google Kubernetes Engine-Clustern (GKE) durchführen. Sie müssen diese Wartung nur für bestimmte Arten von Compute Engine-Instanzen aktiv verwalten, die nicht live migriert werden, einschließlich Instanzen mit GPUs und TPUs. Die in diesem Dokument beschriebenen Strategien eignen sich gut für Trainings- und Inferenzarbeitslasten. Wenn Sie die Hostwartung nur manuell für einen einzelnen Knoten durchführen müssen oder Ihre Arbeitslasten die automatische Host wartung tolerieren können, lesen Sie den Artikel Hostwartung in GKE durchführen.
Mit diesen Strategien wird die Hostwartung für Knotengruppen durchgeführt und optional werden GKE-Cluster-Upgrades initiiert.
Verwenden Sie die parallele Strategie für die Knoten von Arbeitslasten, bei denen es eine einzige Ausfallzeit geben kann, z. B. für die Knoten von Trainingsarbeitslasten. Verwenden Sie die Rolling-Strategie für die Knoten von Arbeitslasten, bei denen es zu Ausfallzeiten in Batches kommen kann, während die Verfügbarkeit der meisten Ressourcen erhalten bleibt, z. B. für die Knoten von Inferenzarbeitslasten.
Parallele Strategie zum Aktualisieren der Knoten von Trainingsarbeitslasten verwenden
Bei dieser Strategie werden Änderungen gleichzeitig für eine Gruppe von Knoten vorgenommen, die Beschleuniger verwenden. Sie können diese Strategie für Trainingsarbeitslasten verwenden. Alternativ können Sie sie für andere Arten von Arbeitslasten verwenden, bei denen die am wenigsten störende Methode zum Ausführen von Änderungen ein einzelnes Fenster mit vollständiger Ausfallzeit für alle Knoten in der Gruppe und die darauf ausgeführten Arbeitslasten ist.
Die Strategie umfasst die folgenden allgemeinen Schritte:
- Arbeitslasten beenden: Wählen Sie die Knotenpools aus und beenden Sie entweder die darauf ausgeführten Arbeitslasten oder verschieben Sie sie zu anderen Knoten, die weiterhin verfügbar sind.
- Hostwartung auslösen: Wenden Sie das Wartungslabel gleichzeitig auf alle ausgewählten Knoten an und warten Sie, bis der Vorgang auf allen Knoten abgeschlossen ist.
- GKE-Version aktualisieren: Ändern Sie die GKE Version der Knoten.
- Arbeitslasten neu starten: Starten Sie nach Abschluss aller Hostwartungs- und Upgradevorgänge Ihre Arbeitslasten neu.
Die bereitgestellten Anleitungen führen Änderungen für einen einzelnen Knotenpool durch. Sie können die Schritte jedoch so anpassen, dass Änderungen für mehrere Knotenpools gleichzeitig durchgeführt werden. Achten Sie darauf, dass Sie vor Beginn dieser Schritte mindestens einige Stunden Zeit haben, in denen diese Arbeitslast nicht auf diesen Knoten ausgeführt werden muss.
Um Unterbrechungen zu minimieren, während kritische Änderungen sowohl für die zugrunde liegenden Compute Engine-Instanzen als auch für die GKE-Knoten vorgenommen werden, nutzen Sie diese Ausfallzeit, um sowohl die Hostwartung als auch die GKE-Versionsupgrades durchzuführen. Sie können jedoch nur die Hostwartung durchführen, wenn Sie die Version Ihrer GKE-Knoten nicht aktualisieren möchten.
Hinweise
Lesen Sie zuerst die folgenden Hinweise:
- Arbeitslasten nicht neu bereitstellen: Um unnötige Verzögerungen aufgrund von PodDisruptionBudgets, zu vermeiden, stellen Sie keine Arbeitslasten neu bereit, bis Sie alle Schritte ausgeführt haben.
- Unterbrechung einplanen: Achten Sie darauf, dass Ihre Arbeitslasten für einen bestimmten Zeitraum unterbrochen werden können. Die Ausführung dieser Schritte dauert mehrere Stunden, hauptsächlich aufgrund der Zeit, die für die Hostwartung erforderlich ist.
Updates für alle Knoten gleichzeitig durchführen
Führen Sie die folgenden Schritte aus, um die Hostwartung und optional GKE-Versionsupgrades durchzuführen:
- Arbeitslasten vorbereiten: Beenden Sie Ihre Arbeitslasten oder sorgen Sie dafür, dass sie einen aktuellen Snapshot oder Prüfpunkt haben.
Hostwartung starten: Wenden Sie das Wartungslabel auf alle Knoten in dem ausgewählten Knotenpool an:
kubectl label nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME cloud.google.com/perform-maintenance=true --overwriteCompute Engine beginnt gleichzeitig mit dem Leeren und Aktualisieren der zugrunde liegenden Instanzen. Dieser Vorgang kann einige Stunden dauern. Weitere Informationen finden Sie unter Prozess der ordnungsgemäßen Beendigung.
Status der Hostwartung beobachten: GKE entfernt das Wartungslabel, wenn die Wartung abgeschlossen ist. Nach Abschluss der Wartung finden Sie in Cloud Logging ein Log mit der folgenden Meldung:
Maintenance window has completed for this instance. All maintenance notifications on the instance have been removed.
Rolling-Strategie zum Aktualisieren der Knoten von Inferenzarbeitslasten verwenden
Diese Strategie beschreibt einen manuellen Ansatz zur Durchführung der Wartung auf GKE-Knoten, auf denen Inferenzarbeitslasten ausgeführt werden. Dabei werden Knoten in Batches aktualisiert, um die Dienstverfügbarkeit aufrechtzuerhalten. Diese Methode eignet sich am besten für Arbeitslasten, bei denen ein bestimmter Prozentsatz der Replikate vorübergehend offline sein kann.
Die Strategie umfasst die folgenden allgemeinen Schritte:
- Knoten identifizieren und in Batches aufteilen: Wählen Sie die Knotenpools aus, die aktualisiert werden sollen. Gruppieren Sie die Knoten in Batches, deren Größe von der Fehlertoleranz Ihrer Arbeitslast abhängt.
- Batches durchlaufen: Wenden Sie für jeden Batch das Wartungslabel an und beobachten Sie den Batch von Knoten, bis das Label entfernt wird.
- GKE-Version aktualisieren: Nachdem alle Batches die Host wartung abgeschlossen haben, ändern Sie die Version der GKE-Knoten.
Hinweise
Lesen Sie zuerst die folgenden Hinweise:
- Bereitstellung verstehen: Für den Erfolg sind detaillierte Kenntnisse von Ihrer Arbeitslastverteilung, Replikaplatzierung und Fehlerdomains erforderlich. Achten Sie darauf, dass während des gesamten Vorgangs ausreichend Serving-Kapazität vorhanden ist.
- Batchgrößen planen: Aktualisieren Sie Knoten in Batches. Die Größe der einzelnen Batches wird durch die Fehlertoleranz Ihrer Arbeitslast bestimmt. Berücksichtigen Sie dabei folgende Faktoren:
- Anzahl der Replikate pro Serving-Modell.
- Verteilung der Replikate auf Knoten und Fehlerdomains.
- PodDisruptionBudgets können helfen, die maximale Anzahl von Pods zu erzwingen, die gleichzeitig nicht verfügbar sind.
- Empfehlung: Um die Verwaltung zu vereinfachen, können Sie verschiedene Knotenpools für verschiedene Replikagruppen verwenden. So lassen sich Fehlerdomains auf Knotenpoolebene isolieren.
- Zeitbeschränkungen berechnen: Berücksichtigen Sie die folgenden Zeitfaktoren:
- Für jeden Batch kann es mehrere Stunden dauern, bis der Schritt zur Hostwartung abgeschlossen ist.
- Berechnen Sie die Mindestbatchgröße, damit die gesamte Wartung innerhalb der erforderlichen Fristen abgeschlossen wird:
MAINTENANCE_BLOCKS = floor(HOURS_TO_MAINTENANCE / 4)(wobeiHOURS_TO_MAINTENANCEdie insgesamt verfügbare Zeit ist).MIN_PER_BATCH = TOTAL_NODE_COUNT / MAINTENANCE_BLOCKS
- Die ausgewählte Batchgröße muss gleich oder größer als
MIN_PER_BATCHsein.
- Bestimmte Arbeitslasttypen prüfen: Berücksichtigen Sie Folgendes für die
jeweiligen Konfigurationstypen:
- Mixture of Experts (MOE): Achten Sie darauf, dass mit Ihrer Batching-Strategie die mindestens erforderliche Anzahl von Replikaten für jedes Modell beibehalten wird.
- Disaggregated Serving: Achten Sie darauf, dass Sie bei der Planung von Batches alle Replikate berücksichtigen, die in der disaggregierten Einrichtung verwendet werden.
- Multi-Host-Knotenpools (TPU, MNNVL): Bei diesen Konfigurationen werden Sie wahrscheinlich jeweils ganze Knotenpools herunterfahren. Planen Sie Ihre Fehlerdomains entsprechend auf mehrere Knotenpools auf.
Rolling Updates in Batches durchführen
Führen Sie die folgenden Schritte aus, um Rolling Updates durchzuführen:
Knoten für die Wartung identifizieren: Identifizieren Sie alle Knoten, auf denen Sie die Wartung durchführen möchten, und speichern Sie diese Liste. Verwenden Sie eine der folgenden Methoden, um Knoten zu identifizieren, oder wählen Sie sie manuell aus:
Alle Knoten im Cluster abrufen, die Beschleuniger (TPUs oder GPUs) verwenden:
kubectl get nodes -o json | jq -r '.items[] | select(.spec.taints[]? | select(.key=="nvidia.com/gpu" or .key=="google.com/tpu")) | .metadata.name'Alle Knoten in einem bestimmten Knotenpool abrufen:
kubectl get nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME --no-headers -o custom-columns=":metadata.name"Ersetzen Sie
NODE_POOL_NAMEdurch den Namen des Knotenpools.Alle Knoten mit einem bestimmten Label abrufen:
kubectl get nodes -l LABEL -o jsonpath='{.items[*].metadata.name}'Ersetzen Sie
LABELdurch das Knotenlabel.
Knoten in Batches aufteilen: Teilen Sie die identifizierten Knoten in gleich große Batches auf. Bestimmen Sie die Batchgröße anhand der Formel, die im Listenelement Zeitbeschränkungen berechnen im vorherigen Abschnitt Hinweise vor Beginn beschrieben ist.
Hostwartung durchführen: Führen Sie für jeden Batch die folgenden Schritte aus:
Wählen Sie einen Batch von Knoten aus und wenden Sie das Wartungslabel an:
kubectl label nodes LIST_OF_NODES_IN_BATCH cloud.google.com/perform-maintenance=true --overwriteErsetzen Sie
LIST_OF_NODES_IN_BATCHdurch eine durch Leerzeichen getrennte Liste von Knoten aus dem Batch. Beispiel:node-1 node-2 node-3.Beobachten Sie den Status der Hostwartung. GKE entfernt das Wartungslabel, wenn die Wartung abgeschlossen ist. Nach Abschluss der Wartung finden Sie in Logging ein Log mit der folgenden Meldung:
Maintenance window has completed for this instance. All maintenance notifications on the instance have been removed.Wiederholen Sie die beiden vorherigen Schritte für jeden verbleibenden Batch, bis Sie die Hostwartung für alle Batches abgeschlossen haben.
Optional: Version der GKE-Knoten aktualisieren: Führen Sie diesen Schritt erst aus, nachdem die Hostwartung für alle Knoten abgeschlossen ist. So vermeiden Sie Szenarien, in denen die GKE-Knoten auf Hosts bereitgestellt werden, bei denen die Wartung noch nicht abgeschlossen ist. Eine Anleitung finden Sie im folgenden Abschnitt.
GKE-Version der Knoten aktualisieren
Berücksichtigen Sie die Anzahl der Knoten, die Sie gleichzeitig aktualisieren möchten. Mit der parallelen Strategie haben Sie die Hostwartung für den gesamten Knotenpool oder mehrere Knotenpools gleichzeitig durchgeführt. Mit der Rolling-Strategie haben Sie die Hostwartung in Batches durchgeführt. Bestimmen Sie anhand der Größe der Knotengruppen, welche Upgrademethode Sie verwenden möchten:
- Parallele Strategie: Wenn Ihre Knotenpools jeweils 20 oder weniger Knoten pro Zone haben, verwenden Sie Surge-Upgrades. Wenn Ihre Knotenpools jeweils mehr als 20 Knoten pro Zone haben, löschen Sie die Knotenpools und erstellen Sie sie neu.
- Rolling-Strategie: Wenn Ihre Batches 20 oder weniger Knoten pro Zone und Knoten pool haben, verwenden Sie Surge-Upgrades. Wenn Ihre Batches mehr als 20 Knoten pro Zone und Knotenpool haben, löschen Sie die Knoten und erstellen Sie sie neu.
Surge-Upgrades verwenden
Konfigurieren Sie Surge- Upgrades, mit der
maxUnavailableEinstellung, um festzulegen, wie viele Knoten in einem Knotenpool gleichzeitig pro Zone nicht verfügbar sein können. Wenn Sie beispielsweise 18 Knoten in einer Zone in einem Knotenpool haben, setzen Sie den Wert des FeldsmaxUnavailableauf18.Diese Einstellung funktioniert am besten, wenn Sie Kapazität aus einer Reservierung verwenden, in der Sie keine überschüssige Kapazität haben. Weitere Informationen dazu, warum Sie diese Einstellung verwenden sollten, finden Sie unter Upgrade in einer ressourcenknappen Umgebung.
Führen Sie mit dem folgenden Befehl ein Upgrade des Knotenpools durch. Wenn Sie mehrere Knotenpools aktualisieren möchten, führen Sie diesen Befehl für jeden Knotenpool aus:
gcloud container clusters upgrade CLUSTER_NAME \ --node-pool NODE_POOL_NAME \ --cluster-version VERSION \ --location CONTROL_PLANE_LOCATION \ --quietErsetzen Sie Folgendes:
CLUSTER_NAME: Der Name Ihres Clusters.NODE_POOL_NAME: Der Name des Knotenpools.VERSION: Ein empfohlenes Ziel für das automatische Upgrade für den Knotenpool. Weitere Informationen finden Sie unter Informationen zu Upgrades für Knotenpools von Standard-Clustern abrufen. Wenn Ihr Cluster kein empfohlenes Ziel für das automatische Upgrade hat, prüfen Sie die neuesten Versionsupdates Einträge in den GKE-Versionshinweisen.CONTROL_PLANE_LOCATION: Der Standort der Steuerungsebene Ihres Clusters.
Knoten löschen und neu erstellen
Löschen Sie den Knotenpool und erstellen Sie ihn mit der neueren Version neu:
Löschen Sie den Knotenpool:
gcloud container node-pools delete NODE_POOL_NAME \ --cluster CLUSTER_NAME \ --location CONTROL_PLANE_LOCATIONErstellen Sie den Knotenpool neu und übergeben Sie die neue Version mit dem Flag
--cluster-version. Übergeben Sie das empfohlene Ziel für das automatische Upgrade für den Knotenpool. Weitere Informationen finden Sie unter Informationen zu Upgrades für Knotenpools von Standard-Clustern abrufen. Wenn Ihr Cluster kein empfohlenes Ziel für das automatische Upgrade hat, prüfen Sie die neuesten Einträge unter Versionsupdates in den GKE-Versionshinweisen.