GPU-Hosts reparieren

Bevor Sie eine vom Benutzer initiierte Reparatur konfigurieren, identifizieren Sie einen berechtigten verwalteten GPU-Knotenpool und einen kontrollierten Testknoten. Stellen Sie sicher, dass Workloads auf dem ausgewählten Knoten unterbrochen werden können.

Für eine vom Benutzer initiierte Reparatur ist eine Zugriffskontrolle sowohl in OCI IAM als auch in Kubernetes RBAC erforderlich. In OCI IAM benötigt der Resource Principal des OKE-Clusters die Berechtigung, das definierte Tag anzuwenden, mit dem die Hostbedingung in Compute gemeldet wird. In Kubernetes sollte nur ein vertrauenswürdiger Operator die geschützte Reparaturanforderung initiieren können. Der vertrauenswürdige Operator erfordert Standard-Kubernetes-RBAC-Berechtigungen, um die Zielressource Node und die OKE-spezifische Autorisierung zu aktualisieren, die über eine ClusterRoleBinding delegiert wird.

Wenn Sie eine vom Benutzer initiierte Reparatur anfordern, koordiniert OKE die folgenden Aktionen:

1. Stellt sicher, dass jeweils nur eine Reparaturanforderung verarbeitet wird.
2. Verbindet den Knoten so, dass Kubernetes keine neuen Pods darauf plant.
3. Versuche, Workloads vom Knoten zu entfernen.
4. Meldet die Bedingung für Compute und beendet die betroffene Instanz.
5. Stellt die konfigurierte Kapazität des verwalteten Knotenpools wieder her.

So konfigurieren und testen Sie die vom Benutzer initiierte Reparatur:

1. Prüfen Sie, ob das Cluster ein erweitertes Cluster ist und Kubernetes-Version 1.32 oder höher ausführt. Prüfen Sie, ob der Knoten ein berechtigter verwalteter GPU-Worker-Knoten ist. Prüfen Sie, ob der OKE-verwaltete Node Repair Controller und die NodeHealthReport CRDs, oke-customer-node-repair-trigger ClusterRole sowie die Zulassungs-Policy und das Binding für den Triggerschutz im Cluster installiert sind. Wenn eine OKE-verwaltete Ressource fehlt, wenden Sie sich an Oracle Support. Erstellen Sie keine OKE-verwalteten Ressourcen neu.

2. Bevor Sie eine Live-Reparatur verwenden, öffnen Sie eine Supportanfrage, um die vom Benutzer gemeldete Hardwarefehlerbehandlung für Ihren Mandanten zu aktivieren. Nehmen Sie den Mandanten-, Regions-, Cluster-OCID- und GPU-Knotenpool in die Anforderung auf.

3. Erstellen Sie das definierte Tag, mit dem der Node Repair Controller die Hostbedingung für Compute meldet, oder verwenden Sie es erneut.

   Erstellen Sie einen Tag-Namespace mit dem Namen ComputeInstanceHostActions, oder verwenden Sie ihn erneut. Erstellen Sie in diesem Namespace eine Tagschlüsseldefinition namens CustomerReportedHostStatus, oder verwenden Sie sie erneut. Erstellen Sie kein Freiformtag mit demselben Text. Weitere Informationen finden Sie unter Tag-Namespace erstellen und Tagschlüsseldefinition erstellen.

   Vor dem Beenden der ursprünglichen Instanz schreibt der Node Repair Controller den Wert unhealthy in das definierte Tag ComputeInstanceHostActions.CustomerReportedHostStatus auf der Instanz.

4. Erstellen Sie eine OCI-IAM-Policy, die dem Ressourcen-Principal des OKE-Clusters die uneingeschränkte Berechtigung zum Anwenden des definierten Tags erteilt:

   Allow any-user to use tag-namespace in tenancy where all {request.principal.type = 'cluster', request.principal.id = '<cluster-ocid>', target.tag-namespace.name = 'ComputeInstanceHostActions'}

   Die Propagierung von IAM-Änderungen kann einige Zeit dauern. Warten Sie auf Propagierung, bevor Sie eine destruktive Validierung durchführen.

5. Delegieren Sie den geschützten vom Benutzer initiierten Reparatur-Trigger an vertrauenswürdige Operatoren.

   Erstellen Sie eine ClusterRoleBinding, die eine vertrauenswürdige OCI-IAM-Gruppen-OCID an die OKE-eigene oke-customer-node-repair-trigger ClusterRole bindet. Operatoren benötigen auch Standard-Kubernetes-RBAC-Berechtigungen, um die Node-Zielressource zu aktualisieren.

   Erstellen Sie eine Datei namens cir-trigger-operators.yaml mit dem folgenden Inhalt:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: oke-node-repair-trigger-operators
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: oke-customer-node-repair-trigger
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: <trusted-oci-iam-group-ocid>

   Ersetzen Sie <trusted-oci-iam-group-ocid> durch die OCID der OCI-IAM-Gruppe, die die vertrauenswürdigen Operatoren enthält.

   Wenden Sie das Binding an, und prüfen Sie es, indem Sie Folgendes eingeben:

   kubectl apply -f cir-trigger-operators.yaml

   kubectl get clusterrolebinding \
     oke-node-repair-trigger-operators \
     -o yaml

   Dieses Binding erteilt keine allgemeine Berechtigung zum Aktualisieren von Node-Ressourcen. Verwenden Sie Ihr vorhandenes Kubernetes-Autorisierungsmodell, um nur die standardmäßigen Kubernetes-RBAC-Berechtigungen zu erteilen, die von den vertrauenswürdigen Operatoren benötigt werden.

6. Erstellen Sie eine benutzerdefinierte NodeRepairConfig-Ressource mit nicht überlappendem Clusterbereich im Dry-Run-Modus.

   Wählen Sie Knoten mithilfe eines dauerhaften Node Pool-Labels, das Sie verwalten und auf Ersatzknoten vorhanden ist. Das Selektorlabel ist benutzerdefiniert. Konfigurieren Sie das Label im beabsichtigten verwalteten Knotenpool, sodass Ersatzknoten es beibehalten.

   Ein Knoten muss genau einer NodeRepairConfig-Ressource entsprechen. Anforderungen ohne übereinstimmende Konfiguration oder sich überschneidende Konfigurationen werden ohne Reparaturnebenwirkungen abgelehnt. Sie können dieselben oder separate Konfigurationen für vom Benutzer initiierte Reparatur- und GPU-Instanz-Recovery verwenden. Wenn Sie separate Konfigurationen verwenden, nehmen Sie nicht dieselben Knoten in mehreren Konfigurationen auf. Andernfalls wird die Reparaturanforderung abgelehnt.

   Das folgende Beispiel beginnt im Trockenlaufmodus, ermöglicht eine Reparatur nach der anderen, setzt den Schwellenwert für fehlerhafte Knoten auf 10%, verwendet eine Ablauffrist von 60 Minuten und deaktiviert das Verhalten nach der Schärfe:

   apiVersion: oci.oraclecloud.com/v1beta1
   kind: NodeRepairConfig
   metadata:
     name: gpu-node-repair
   spec:
     nodeSelector:
       matchLabels:
         example.com/gpu-repair: "enabled"
     policy:
       dryRun: true
       evictionGracePeriodMinutes: 60
       forceActionAfterGracePeriod: false
       maxUnhealthyNodeThreshold: "10%"
       maximumParallelNodeRepairs: 1

   Im Abschnitt policy sind dryRun und forceActionAfterGracePeriod boolesche Werte. evictionGracePeriodMinutes ist eine nicht negative Ganzzahl. maximumParallelNodeRepairs ist eine positive Ganzzahl. maxUnhealthyNodeThreshold akzeptiert eine positive Knotenanzahl oder einen in Anführungszeichen stehenden Prozentsatz, wie "10%".

   Beginnen Sie mit dryRun: true. Nachdem Sie die Konfiguration validiert haben, aktualisieren Sie nur dryRun für Livevorgänge in false.

7. Fordern Sie eine Trockenlaufreparatur an, indem Sie das geschützte Label oci.oraclecloud.com/customer-report-host-status=unhealthy auf den ausgewählten Knoten anwenden. Prüfen Sie NodeHealthReport und den zugehörigen Knotenstatus. Eine Dry-Run-Anforderung erstellt einen abgeschlossenen NodeHealthReport-Datensatz, jedoch nicht Cordon, Drain, Anwenden des Compute-definierten Tags, Beenden, Neustarten oder Ersetzen des Knotens.

8. Lösen Sie eine Live-Reparatur aus, indem Sie das geschützte Triggerlabel zusammen mit dem One-Shot-Live-Override oci.oraclecloud.com/node-repair-dry-run=false anwenden. Die Live-Überschreibung ist nur mit einem aktiven Trigger gültig und wird nur abgetastet, wenn ein neuer Trigger erstellt wird.

   Um eine vom Benutzer initiierte Reparaturanforderung zu wiederholen, entfernen Sie das Label oci.oraclecloud.com/customer-report-host-status=unhealthy, und wenden Sie es erneut an. Wenn Sie denselben Etikettenwert erneut anwenden, wird keine weitere Anforderung gestartet. Durch das Entfernen des Labels wird eine aktive Reparatur nicht abgebrochen.

   Wichtig
   
   Eine vom Benutzer initiierte Livereparatur kann Workloads entladen und die ursprüngliche Compute-Instanz beenden. Draining verwendet die Kubernetes Eviction-API und würdigt Podunterbrechungsbudgets. DaemonSet-Pods und statische Pods werden übersprungen. Wenn "Force-after-Grace" aktiviert ist, erzwingt der Node Repair Controller das Löschen der verbleibenden Pods nicht. Die nachfolgende Hostaktion kann sie jedoch weiterhin unterbrechen.

9. Prüfen Sie den Fortschritt der Reparaturaktion, das definierte Compute-Tag, das Beenden der ursprünglichen Instanz, die Wiederherstellung der Kapazität des Managed Node Pools und die Erstellung eines Ersatzknotens mit einer neuen UID und Instanz-OCID. Die NodeHealthReport für beendete Instanzen wird vorübergehend beibehalten, nachdem der Workflow abgeschlossen ist.

   Ein Deferred-Ergebnis bedeutet, dass der Workflow vorübergehend blockiert wird. Ein Failed-Ergebnis bedeutet, dass der Versuch gestoppt wurde. Ein Superseded-Ergebnis bedeutet, dass ein OKE-Workflow mit höherer Priorität übernommen wurde. Ein Completed-Ergebnis bedeutet, dass OKE den angeforderten Beendigungsworkflow beendet hat. Dies bedeutet nicht, dass die physische Reparatur abgeschlossen ist oder dass die Austauschkapazität Ready ist. Prüfen Sie nach Abschluss des Workflows, ob der verwaltete Knotenpool die erwartete Kapazität aufweist und ob der Ersatzknoten den aktuellen fehlerfreien Status meldet.

Bei einer vom Benutzer initiierten Reparatur hängt die Erstellung eines Ersatz-Worker-Knotens von der Abstimmung zwischen verwaltetem Knoten und Pool und der verfügbaren GPU-Kapazität ab. Ein abgeschlossener Workflow bestätigt nicht, dass der zugrunde liegende GPU-Fehler korrigiert wurde.

Bevor Sie das GPU-Instanz-Recovery konfigurieren, identifizieren Sie einen berechtigten verwalteten GPU-Knotenpool, und bestätigen Sie, dass seine Workloads unterbrochen werden können. GPU-Instanz-Recovery kann einen betroffenen Knoten verschlüsseln und entladen, bevor die Instanz neu gestartet wird.

Erstellen Sie vor dem Konfigurieren des GPU-Instanz-Recoverys die IAM-Policys, die vom GPU-Zustandsmonitoring-Add-on zum Überwachen von GPU-Hosts erforderlich sind:

Allow dynamic-group <dg-name> to manage instance-family in compartment id <compartment-ocid>

Allow dynamic-group <dg-name> to read instance-agent-plugins in compartment id <compartment-ocid>

Hierbei gilt:

• <dg-name> ist der Name der dynamischen Gruppe, die Compute-Instanzen für die GPU-Worker-Knoten enthält. Beispiel: Verwenden Sie eine Regel wie ALL {instance.compartment.id = '<compartment-ocid>'}. Durch das Anwenden von Tags auf Knotenpools können Sie restriktivere Regeln erstellen, wie:

  ALL {
    instance.compartment.id = 'ocid1.compartment.oc1..examplecompartment',
    tag.Operations.Workload.value = 'gpu-monitoring',
    tag.Operations.Environment.value = 'prod'
  }

  Weitere Informationen finden Sie unter Tags auf Knotenpools anwenden.

• <compartment-ocid> ist die OCID des Compartments, das die GPU-Worker-Knoten enthält.

GPU-Instanzwiederherstellung wird nur auf berechtigten verwalteten GPU-Worker-Knoten unterstützt, die folgende GPU-Ausprägungen verwenden:

• BM.GPU.A10.4
• BM.GPU.A100-v2.8
• BM.GPU.B200.8
• BM.GPU.B300.8
• BM.GPU.B300.HS.8
• BM.GPU.B4.8
• BM.GPU.GB200-v2.4
• BM.GPU.GB200-v3.4
• BM.GPU.GB200.4
• BM.GPU.GB300.4
• BM.GPU.H100.8
• BM.GPU.H100T.8
• BM.GPU.H200-NC.8
• BM.GPU.H200.8
• BM.GPU.L40S-NC.4
• BM.GPU.L40S.4
• BM.GPU.MI300X.8
• BM.GPU.MI355X-v1.8
• BM.GPU.MI355X.8

Die Verfügbarkeit der GPU-Ausprägung variiert je nach Region. Stellen Sie sicher, dass die ausgewählte GPU-Ausprägung in der Region verfügbar ist, in der das Cluster ausgeführt wird.

Oracle Cloud Agent Version 1.64.0 oder höher ist für das Compute RDMA GPU Monitoring-Plug-in erforderlich und muss auf den ausgewählten Knoten installiert werden.

Wenn OKE ein zulässiges GPU-Zustandssignal empfängt, koordiniert es die folgenden Aktionen:

1. Stellt sicher, dass jeweils nur eine Recovery-Anforderung verarbeitet wird.
2. Verbindet den Knoten so, dass Kubernetes keine neuen Pods darauf plant.
3. Versuche, Workloads vom Knoten zu entfernen.
4. Startet die betroffene Compute-Instanz neu.

So konfigurieren Sie das GPU-Instanz-Recovery:

1. Prüfen Sie, ob auf dem Cluster Kubernetes-Version 1.32 oder höher ausgeführt wird. Prüfen Sie, ob der Knoten ein berechtigter verwalteter GPU-Worker-Knoten ist. Prüfen Sie, ob der OKE-verwaltete Node Repair Controller und die NodeHealthReport-CRDs im Cluster installiert sind, und prüfen Sie, ob das GPU-Zustandsmonitoring-Add-on für das Cluster verfügbar ist.

2. Prüfen Sie, ob das GPU-Zustandsmonitoring-Add-on eine Option ACTIVE für die im Cluster ausgeführte Kubernetes-Version enthält, indem Sie Folgendes eingeben:

   oci ce addon-option list \
     --kubernetes-version <version> \
     --addon-name GpuHealthMonitoring

   Wenn Sie das Add-on installieren, installieren Sie die neueste Option ACTIVE, anstatt eine Version anzuheften. Die installierte Version muss v1.1.0 oder höher sein.

3. Installieren Sie das OKE-verwaltete GPU-Zustandsüberwachungs-Add-on, indem Sie Folgendes eingeben:

   oci ce cluster install-addon \
     --addon-name GpuHealthMonitoring \
     --cluster-id $CLUSTER_ID \
     --region $REGION

   Der Befehl installiert die neueste verfügbare Version des Add-ons für das Cluster.

   Die unterstützten Add-on-Konfigurationsschlüssel sind nodeSelectors, tolerations und rollingUpdate. Der Wert rollingUpdate steuert das rollierende Aktualisierungsverhalten nach maxSurge und maxUnavailable, wobei das JSON-Format im Nur-Text-Format verwendet wird.

4. Erstellen Sie eine GpuHealthMonitoringConfig-Ressource, um das GPU-Zustandsmonitoring für die ausgewählten GPU-Worker-Knoten zu aktivieren. Für die Konfiguration sind spec.enabled und ein nicht leerer Knotenselektor erforderlich.

   apiVersion: oci.oraclecloud.com/v1beta1
   kind: GpuHealthMonitoringConfig
   metadata:
     name: gpu-health-monitoring
   spec:
     enabled: true
     nodeSelector:
       matchLabels:
         nvidia.com/gpu.present: "true"

   Speichern Sie die Konfiguration unter gpu-health-monitoring.yaml, und wenden Sie sie an, indem Sie Folgendes eingeben:

   kubectl apply -f gpu-health-monitoring.yaml

   Das Feld spec.enabled aktiviert oder deaktiviert das Monitoring für die ausgewählten Knoten. Im Feld spec.nodeSelector werden die GPU-Knoten ausgewählt, auf denen das Compute RDMA GPU Monitoring-Plug-in und der GPU Fault Monitor ausgeführt werden.

   Vermeiden Sie das Erstellen mehrerer aktivierter GpuHealthMonitoringConfig-Ressourcen, deren Selektoren mit demselben Knoten übereinstimmen. Überschneidende Policys werden abgelehnt, wenn die Bedingung Ready status auf False und reason auf MultipleMatchingPolicies gesetzt ist.

5. Prüfen Sie die GPU-Zustandsmonitoringkonfiguration auf den ausgewählten Knoten.

   Der Controller veröffentlicht die Knotenbedingung oci.oraclecloud.com/GpuHealthMonitoringConfigured. Der Wert True gibt an, dass das Compute RDMA GPU Monitoring-Plug-in als aktiviert konfiguriert wurde. Der Wert False gibt an, dass er als deaktiviert konfiguriert wurde. Der Wert Unknown gibt an, dass der konfigurierte Status derzeit nicht vertrauenswürdig ist.

   Der GPU-Faultmonitor veröffentlicht die Knotenbedingung oci.oraclecloud.com/GpuHealthMonitoringUnavailable. Der Wert True gibt an, dass mindestens eine erforderliche GPU-Zustandsergebnisdatei nicht verfügbar ist. Mögliche Ursachen sind eine veraltete Oracle Cloud Agent-Version, eine nicht unterstützte Ausprägung, ein deaktiviertes oder fehlerhaftes Plug-in oder eine falsche Konfiguration. Der Wert False gibt an, dass die erforderlichen Ergebnisdateien vorhanden sind.

6. Erstellen Sie eine benutzerdefinierte NodeRepairConfig-Ressource mit nicht überlappendem Clusterbereich im Dry-Run-Modus.

   Wählen Sie Knoten mithilfe eines dauerhaften Node Pool-Labels aus, das Sie verwalten. Das Selektorlabel ist benutzerdefiniert.

   Ein Knoten muss genau einer NodeRepairConfig-Ressource entsprechen. Anforderungen ohne übereinstimmende Konfiguration oder sich überschneidende Konfigurationen werden ohne Reparaturnebenwirkungen abgelehnt. Sie können dieselben oder separate Konfigurationen für vom Benutzer initiierte Reparatur- und GPU-Instanz-Recovery verwenden. Wenn Sie separate Konfigurationen verwenden, nehmen Sie nicht dieselben Knoten in mehreren Konfigurationen auf. Andernfalls wird die Reparaturanforderung abgelehnt.

   Das folgende Beispiel beginnt im Trockenlaufmodus, ermöglicht eine Reparatur nach der anderen, setzt den Schwellenwert für fehlerhafte Knoten auf 10%, verwendet eine Ablauffrist von 60 Minuten und deaktiviert das Verhalten nach der Schärfe:

   apiVersion: oci.oraclecloud.com/v1beta1
   kind: NodeRepairConfig
   metadata:
     name: gpu-node-repair
   spec:
     nodeSelector:
       matchLabels:
         example.com/gpu-repair: "enabled"
     policy:
       dryRun: true
       evictionGracePeriodMinutes: 60
       forceActionAfterGracePeriod: false
       maxUnhealthyNodeThreshold: "10%"
       maximumParallelNodeRepairs: 1

   Im Abschnitt policy sind dryRun und forceActionAfterGracePeriod boolesche Werte. evictionGracePeriodMinutes ist eine nicht negative Ganzzahl. maximumParallelNodeRepairs ist eine positive Ganzzahl. maxUnhealthyNodeThreshold akzeptiert eine positive Knotenanzahl oder einen in Anführungszeichen stehenden Prozentsatz, wie "10%".

   Beginnen Sie mit dryRun: true. Nachdem Sie die Konfiguration validiert haben, aktualisieren Sie nur dryRun für Livevorgänge in false.

   Beachten Sie, dass das GPU-Instanz-Recovery funktionsgesteuert ist. Wenden Sie das vom Benutzer initiierte Reparaturlabel oci.oraclecloud.com/customer-report-host-status=unhealthy nicht für das GPU-Instanz-Recovery an.

7. Prüfen Sie, ob ein zulässiges GPU-Zustandssignal für den Knoten gemeldet wird.

   Ein Knoten kann nur dann automatisch neu gestartet werden, wenn alle der folgenden Bedingungen erfüllt sind:

   • Die Knotenbedingung oci.oraclecloud.com/GpuHealthMonitoringFaultDetected ist True.
   • Die NodeHealthReport enthält einen Eintrag unter status.signals.clusterHealthCheck[].
   • Das Signal hat eine nicht leere id.
   • Das Signal hat action=REBOOT. Beim Wert wird Groß-/Kleinschreibung nicht beachtet.
   • Das Signal hat einen Wert ungleich Null firstObservedAt.
   • Das Signal hat einen Wert ungleich Null lastObservedAt, der angibt, dass das Signal aktiv ist.
   • Das Signal bleibt mindestens 10 Minuten aktiv.
   • Wiederholungs- und Cooldown-Regeln des Node Repair Controllers erlauben einen weiteren Versuch. Die Wiederholungsabklingzeit für den Neustart beträgt 60 Minuten.
   • Der effektive Trockenlaufwert ist false für einen tatsächlichen Neustart.
   • Nachträgliche Eintritts- und Störungsschienen passieren.

   Signale mit action=CUSTOMER_ACTION_REQUIRED lösen keinen automatischen Neustart aus. Wenn eines dieser Signale angezeigt wird, prüfen Sie die NodeHealthReport- und Knotenbedingungen, untersuchen Sie das gemeldete GPU-Zustandsproblem, und wenden Sie sich an den Support, wenn Sie Hilfe bei der Lösung benötigen.

8. Aktivieren Sie die Livereparatur in der Ressource NodeRepairConfig.

   Die Wiederherstellung der GPU-Instanz beginnt erst, nachdem das berechtigte Signal mindestens 10 Minuten aktiv geblieben ist und die Wiederholungsabklingzeit für den Neustart 60 Minuten beträgt. Das Drain-Verhalten folgt der Reparatur-Policy, die in der übereinstimmenden NodeRepairConfig-Ressource angegeben ist. Draining verwendet die Kubernetes Eviction-API und würdigt Podunterbrechungsbudgets. Die für den Abschluss des GPU-Instanz-Recoverys erforderliche Zeit kann variieren, abhängig von Workload-Unterbrechungseinstellungen, dem Verhalten bei der Knotenentladung und dem Status der Compute-Instanz.

9. Prüfen Sie, ob das GPU-Instanz-Recovery erfolgreich abgeschlossen wurde.

   Stellen Sie sicher, dass NodeHealthReport eine Reboot-Aktion im Livemodus anzeigt und den Terminalstatus Completed aufweist. Stellen Sie sicher, dass sich die Compute-Instanz im Status Running befindet, der Kubernetes-Knoten Ready lautet und das aktuelle GPU-Zustandsergebnis den Fault nicht mehr meldet.

10. Prüfen Sie das GPU-Zustandsergebnis nach Abschluss des Workflows.

    Wenn das GPU-Zustandsergebnis nach dem Neustart immer noch denselben Fehler meldet oder den Fehler erneut meldet, wurde der Fehler nicht behoben. Ein abgeschlossener Recovery-Workflow bedeutet nicht, dass der zugrunde liegende GPU-Fehler korrigiert wurde. Bei der GPU-Instanzwiederherstellung werden Cooldown-Regeln verwendet, um sofortige Neustartschleifen zu verhindern. Nachdem das GPU-Zustandsergebnis den Fault nicht mehr meldet, kann ein späteres GPU-Zustandsergebnis, das einen neuen Fault meldet, den Knoten für eine andere Reparatur qualifizieren.

Verwenden Sie Kubernetes-Ressourcen und standardmäßige Kubernetes-Überwachungstools, um die NodeHealthReport, Knotenbedingungen, betroffenen Workloads und den Reparaturworkflow zu prüfen.

So überwachen Sie einen GPU-Hostreparaturworkflow:

1. Prüfen Sie die NodeHealthReport und den betroffenen Worker-Knoten vor, während und nach der Reparatur.

   Prüfen Sie die NodeHealthReport auf die Reparaturanforderung, den Reparaturfortschritt, die Aktion, den Trockenlauf- oder Livemodus sowie das Workflowergebnis. Prüfen Sie die betroffene Kubernetes-Ressource Node auf Knotenlabels und -bedingungen. Prüfen Sie Kubernetes-Ereignisse auf aktuelle Knoten- und Reparaturaktivitäten. Prüfen Sie beim GPU-Instanz-Recovery die Bedingungen GpuHealthMonitoringConfigured, GpuHealthMonitoringUnavailable und GpuHealthMonitoringFaultDetected in der betroffenen Kubernetes-Ressource Node.

   Controller-eigene Ressourcen als schreibgeschützt behandeln. Erstellen oder bearbeiten Sie keine generierten Aktionen oder Controller-Ressourcen.

2. Prüfen Sie den unterstützten Reparaturstatus und Knotenstatus.

   Verwenden Sie die NodeHealthReport, um die Reparatur-Policy, den effektiven Trockenlaufwert, das Zulassungsergebnis, das Endergebnis und den letzten Reparaturversuch zu prüfen. Mit der betroffenen Kubernetes-Ressource Node können Sie Knotenbedingungen prüfen. Prüfen Sie gegebenenfalls den Lebenszyklusstatus der Compute-Instanz, das Compute-definierte Tag, das für eine vom Benutzer initiierte Reparatur verwendet wird, und ob die Austauschkapazität bereit ist.

   Verlassen Sie sich nicht als Statusindikatoren auf interne Leasings, Anforderungs-IDs, Dateipfade, Polling-Intervalle oder Zwischenworkflowphasen.

3. Untersuchen Sie abgelehnte Anforderungen, verzögerte Reparaturen, fehlgeschlagene Reparaturen und ersetzte Reparaturen, um vom Benutzer initiierte Reparaturen durchzuführen.

   Eine Anforderung kann abgelehnt werden, wenn keine NodeRepairConfig-Ressource mit dem Knoten übereinstimmt oder wenn mehrere Konfigurationen angewendet werden.

   Verwenden Sie das Ergebnis NodeHealthReport, um zu entscheiden, was untersucht werden soll:

   • Wenn in NodeHealthReport AdmissionRejected angezeigt wird, prüfen Sie die Ressource NodeRepairConfig, die Triggerautorisierung und die Labelkonfiguration.
   • Wenn NodeHealthReport Deferred anzeigt, warten Sie, bis die Blockierungsbedingung gelöscht wird, oder passen Sie die Kapazität an, wenn die Ersatzkapazität nicht verfügbar ist.
   • Wenn in NodeHealthReport Failed angezeigt wird, prüfen Sie NodeHealthReport, Kubernetes-Ereignisse, Budgets für Podunterbrechungen, IAM-Policy, definiertes Compute-Tag und Compute-Instanzstatus.
   • Wenn in NodeHealthReport Superseded angezeigt wird, befolgen Sie den OKE-Workflow, der die Reparatur übernommen hat.
   • Wenn in NodeHealthReport Completed angezeigt wird, prüfen Sie, ob die ursprüngliche Instanz beendet wurde und ob die Ersatzkapazität bereit ist.

4. Untersuchen Sie bei der GPU-Instanzwiederherstellung die Konfiguration der GPU-Zustandsüberwachung, nicht verfügbare Zustandsergebnisse, Neustartsignale, Signale, die eine Aktion erfordern, unvollständige Drains, abgeschlossene Neustarts mit einem laufenden Fehler und fortlaufende Signale, die keinen wiederholten Neustart auslösen.

   Verwenden Sie Knotenbedingungen, GPU-Zustandssignale und das Ergebnis NodeHealthReport, um zu entscheiden, was untersucht werden soll:

   • Wenn die Knotenbedingung GpuHealthMonitoringConfigured False oder Unknown lautet, prüfen Sie die Oracle Cloud Agent-Konfiguration und die Add-on-Konfiguration GpuHealthMonitoring.
   • Wenn die Knotenbedingung GpuHealthMonitoringUnavailable True lautet, prüfen Sie, ob die GPU-Ausprägung unterstützt wird, Oracle Cloud Agent Version 1.64.0 oder höher installiert ist, das Compute RDMA GPU Monitoring-Plug-in aktiviert ist und das GPU Health Monitoring-Add-on installiert und konfiguriert ist.
   • Wenn ein aktives GPU-Zustandssignal action=REBOOT aufweist, überwachen Sie NodeHealthReport für den GPU-Instanz-Recovery-Workflow.
   • Wenn ein GPU-Zustandssignal action=CUSTOMER_ACTION_REQUIRED aufweist, untersuchen Sie das gemeldete GPU-Zustandsproblem. Dieses Signal löst keinen automatischen Neustart aus.
   • Wenn die NodeHealthReport eine unvollständige Drain- oder nicht erfolgreiche Reparatur anzeigt, prüfen Sie Kubernetes-Ereignisse, Podunterbrechungsbudgets, Workload-Status und Knotenbedingungen.
   • Wenn der Neustart abgeschlossen ist, das GPU-Zustandsergebnis den Fehler jedoch weiterhin meldet, untersuchen Sie den laufenden Fehler.
   • Wenn das gleiche Signal nach dem Neustart fortgesetzt wird, startet das GPU-Instanz-Recovery den Knoten nicht sofort neu. Cooldown-Regeln verhindern sofortige Neustartschleifen.

5. Sammeln Sie vor dem Öffnen einer Serviceanfrage die Informationen, die zum Untersuchen des Reparaturworkflows erforderlich sind.

   Schließen Sie Mandanten-OCID, Cluster-OCID, Region, Kubernetes-Version, GPU-Zustandsmonitoring-Add-on-Version, Oracle Cloud Agent-Version, betroffenen Worker-Knotennamen, Compute-Instanz-OCID, relevante NodeHealthReport- und NodeRepairConfig-Ressourcen, Knotenlabels und -bedingungen, Kubernetes-Ereignisse, Podunterbrechungsbudget und Workload-Status, Zeitstempel und aktuelle GPU-Zustandsergebnisse ein.

   Ändern Sie keine CRDs, Controllerressourcen, Zulassungsobjekte, generierten Aktionen oder Koordinierungsressourcen im Besitz von OKE.