Réparation des hôtes GPU

Avant de configurer la réparation lancée par l'utilisateur, identifiez un pool de noeuds GPU gérés admissible et un noeud de test contrôlé. Assurez-vous que les charges globales sur le noeud sélectionné peuvent être interrompues.

La réparation initiée par l'utilisateur nécessite un contrôle d'accès dans OCI IAM et Kubernetes RBAC. Dans OCI IAM, le principal de ressource de cluster OKE requiert des droits d'accès permettant d'appliquer la balise définie utilisée pour signaler la condition d'hôte à Compute. Dans Kubernetes, seul un opérateur de confiance doit pouvoir lancer la demande de réparation protégée. L'opérateur sécurisé requiert des droits d'accès RBAC Kubernetes standard pour mettre à jour la ressource Node cible et l'autorisation propre à OKE déléguée via ClusterRoleBinding.

Lorsque vous demandez une réparation lancée par l'utilisateur, OKE coordonne les actions suivantes :

1. Garantit qu'une seule demande de réparation est traitée à la fois.
2. Connectez le noeud de sorte que Kubernetes ne planifie pas de nouveaux pods dessus.
3. Tentatives de purge des charges globales à partir du noeud.
4. Signale la condition à Compute et met fin à l'instance concernée.
5. Restaure la capacité configurée du pool de noeuds gérés.

Pour configurer et tester la réparation initiée par l'utilisateur :

1. Vérifiez que le cluster est un cluster amélioré et qu'il exécute Kubernetes version 1.32 ou ultérieure. Vérifiez que le noeud est un noeud de processus actif GPU géré admissible. Vérifiez que le contrôleur de réparation de noeud géré par OKE et les CRD NodeHealthReport, oke-customer-node-repair-trigger ClusterRole et la stratégie d'admission et la liaison de protection des déclencheurs sont installés sur le cluster. Si une ressource gérée par OKE est manquante, contactez le support technique Oracle. Ne recréez pas de ressources gérées par OKE.

2. Avant d'utiliser la réparation en direct, ouvrez une demande d'assistance pour activer la gestion des pannes matérielles signalées par l'utilisateur pour votre location. Incluez la location, la région, l'OCID de cluster et le pool de noeuds GPU dans la demande.

3. Créez ou réutilisez la balise définie que le contrôleur de réparation de noeud utilise pour signaler la condition d'hôte au calcul.

   Créez ou réutilisez un espace de noms de balise nommé ComputeInstanceHostActions. Dans cet espace de noms, créez ou réutilisez une définition de clé de balise nommée CustomerReportedHostStatus. Ne créez pas de balise à format libre avec le même texte. Pour plus d'informations, reportez-vous à Création d'un espace de noms de balise et à Création d'une définition de clé de balises.

   Avant de mettre fin à l'instance d'origine, le contrôleur de réparation de noeud écrit la valeur unhealthy dans la balise définie par ComputeInstanceHostActions.CustomerReportedHostStatus sur l'instance.

4. Créez une stratégie OCI IAM qui accorde au principal de ressource de cluster OKE le droit d'accès de portée étroite pour appliquer la balise définie :

   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'}

   La propagation des modifications IAM peut prendre du temps. Attendez la propagation avant d'effectuer la validation destructive.

5. Déléguer le déclencheur de réparation initié par l'utilisateur protégé aux opérateurs de confiance.

   Créez une valeur ClusterRoleBinding qui lie un OCID de groupe OCI IAM sécurisé au fichier oke-customer-node-repair-trigger ClusterRole appartenant à OKE. Les opérateurs ont également besoin de droits d'accès RBAC Kubernetes standard pour mettre à jour la ressource Node cible.

   Créez un fichier nommé cir-trigger-operators.yaml avec le contenu suivant :

   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>

   Remplacez <trusted-oci-iam-group-ocid> par l'OCID du groupe OCI IAM qui contient les opérateurs sécurisés.

   Appliquez et vérifiez la liaison en saisissant ce qui suit :

   kubectl apply -f cir-trigger-operators.yaml

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

   Cette liaison n'accorde pas de droit d'accès général pour la mise à jour des ressources Node. Utilisez votre modèle d'autorisation Kubernetes existant pour n'accorder que les droits d'accès RBAC Kubernetes standard requis par les opérateurs sécurisés.

6. Créez une ressource personnalisée NodeRepairConfig de portée cluster qui ne se chevauche pas en mode de simulation.

   Sélectionnez les noeuds à l'aide d'une étiquette de pool de noeuds durable que vous gérez et qui est présente sur les noeuds de remplacement. Le libellé du sélecteur est défini par l'utilisateur. Configurez l'étiquette sur le pool de noeuds gérés prévu afin que les noeuds de remplacement le conservent.

   Un noeud doit correspondre à une seule ressource NodeRepairConfig. Les demandes sans configuration correspondante ou les configurations qui se chevauchent sont rejetées sans effets secondaires de réparation. Vous pouvez utiliser les mêmes configurations ou des configurations distinctes pour la réparation lancée par l'utilisateur et la récupération d'instance GPU. Si vous utilisez des configurations distinctes, n'incluez pas les mêmes noeuds dans plusieurs configurations ; sinon, la demande de réparation sera rejetée.

   L'exemple suivant démarre en mode d'exécution à sec, permet une réparation à la fois, définit le seuil de noeud en mauvais état sur 10 %, utilise un délai de grâce de purge de 60 minutes et désactive le comportement force après grâce :

   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

   Dans la section policy, dryRun et forceActionAfterGracePeriod sont des valeurs booléennes. evictionGracePeriodMinutes est un entier non négatif. maximumParallelNodeRepairs est un entier positif. maxUnhealthyNodeThreshold accepte un nombre de noeuds positif ou un pourcentage entre guillemets, tel que "10%".

   Commencez par dryRun: true. Après avoir validé la configuration, mettez à jour uniquement dryRun vers false pour l'opération en direct.

7. Demandez une réparation par test en appliquant l'étiquette protégée oci.oraclecloud.com/customer-report-host-status=unhealthy au noeud sélectionné. Examinez NodeHealthReport et l'état du noeud associé. Une demande de test crée un enregistrement NodeHealthReport terminé, mais n'applique pas de cordon, de purge, de balise de calcul définie, d'interruption, de réinitialisation ou de remplacement au noeud.

8. Déclenchez une réparation en direct en appliquant l'étiquette de déclencheur protégé avec le remplacement en direct ponctuel oci.oraclecloud.com/node-repair-dry-run=false. Le remplacement actif n'est valide qu'avec un déclencheur actif et n'est échantillonné que lorsqu'un nouveau déclencheur est créé.

   Pour réessayer une demande de réparation lancée par l'utilisateur, enlevez et réappliquez le libellé oci.oraclecloud.com/customer-report-host-status=unhealthy. La réapplication de la même valeur de libellé ne démarre pas une autre demande. La suppression de l'étiquette n'annule pas une réparation active.

   Important
   
   Une réparation en direct lancée par l'utilisateur peut purger les charges globales et mettre fin à l'instance Compute d'origine. Draining utilise l'API d'expulsion Kubernetes et respecte les budgets de perturbation du pod. Les pods DaemonSet et les pods statiques sont ignorés. Si force-after-grace est activé, le contrôleur de réparation de noeud ne force pas la suppression des pods restants, mais l'action de l'hôte suivante peut toujours les interrompre.

9. Vérifiez la progression de l'action de réparation, la balise définie par Compute, la terminaison de l'instance d'origine, la restauration de la capacité du pool de noeuds gérés et la création d'un noeud de remplacement avec un nouvel UID et un nouvel OCID d'instance. Le fichier NodeHealthReport pour les instances arrêtées est conservé temporairement une fois le workflow terminé.

   Un résultat Deferred signifie que le workflow est temporairement bloqué. Un résultat Failed signifie que la tentative s'est arrêtée. Un résultat Superseded signifie qu'un workflow OKE de priorité supérieure a pris le relais. Un résultat Completed signifie qu'OKE a terminé le workflow de fin de contrat demandé. Cela ne signifie pas que la réparation physique est terminée ou que la capacité de remplacement est de Ready. Une fois le workflow terminé, vérifiez que le pool de noeuds gérés dispose de la capacité attendue et que le noeud de remplacement indique le statut d'intégrité actuel.

Pour la réparation initiée par l'utilisateur, la création d'un noeud de processus actif de remplacement dépend du rapprochement de pool de noeuds gérés et de la capacité de GPU disponible. Un workflow terminé ne confirme pas que l'erreur GPU sous-jacente a été corrigée.

Avant de configurer la récupération d'instance de GPU, identifiez un pool de noeuds de GPU géré admissible et vérifiez que ses charges globales peuvent être interrompues. La récupération d'instance de GPU peut cordonner et purger un noeud affecté avant de réinitialiser son instance.

Avant de configurer la récupération d'instance de GPU, créez les stratégies IAM requises par le module complémentaire GPU Health Monitoring pour surveiller les hôtes GPU :

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>

où :

• <dg-name> est le nom du groupe dynamique qui inclut les instances Compute pour les noeuds de processus actif GPU. Par exemple, en utilisant une règle telle que ALL {instance.compartment.id = '<compartment-ocid>'}. En appliquant des balises aux pools de noeuds, vous pouvez créer des règles plus restrictives, telles que :

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

  Pour plus d'informations, reportez-vous à Application de balises aux pools de noeuds.

• <compartment-ocid> est l'OCID du compartiment contenant les noeuds de processus actif GPU.

La récupération d'instance GPU est prise en charge uniquement sur les noeuds de processus actif GPU gérés éligibles à l'aide des formes GPU suivantes :

• 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

La disponibilité des formes de GPU varie selon les régions. Vérifiez que la forme de GPU sélectionnée est disponible dans la région où le cluster est exécuté.

La version d'agent Oracle Cloud 1.64.0 ou ultérieure est requise par le module d'extension de surveillance de GPU RDMA Compute et doit être installée sur les noeuds sélectionnés.

Lorsqu'OKE reçoit un signal d'intégrité GPU éligible, il coordonne les actions suivantes :

1. Garantit qu'une seule demande de récupération est traitée à la fois.
2. Connectez le noeud de sorte que Kubernetes ne planifie pas de nouveaux pods dessus.
3. Tentatives de purge des charges globales à partir du noeud.
4. Redémarre l'instance Compute concernée.

Pour configurer la récupération d'instance de GPU, procédez comme suit :

1. Vérifiez que le cluster exécute Kubernetes version 1.32 ou ultérieure. Vérifiez que le noeud est un noeud de processus actif GPU géré admissible. Vérifiez que le contrôleur de réparation de noeud géré par OKE et les CRD NodeHealthReport sont installés sur le cluster et que l'extension GPU Health Monitoring est disponible pour le cluster.

2. Vérifiez que le module complémentaire GPU Health Monitoring dispose d'une option ACTIVE pour la version de Kubernetes exécutée sur le cluster en saisissant ce qui suit :

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

   Lorsque vous installez le module, installez la dernière option ACTIVE au lieu d'épingler une version. La version installée doit être v1.1.0 ou ultérieure.

3. Installez le module complémentaire GPU Health Monitoring géré par OKE en saisissant ce qui suit :

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

   La commande installe la dernière version disponible du module complémentaire pour le cluster.

   Les clés de configuration d'extension prises en charge sont nodeSelectors, tolerations et rollingUpdate. La valeur rollingUpdate contrôle le comportement de mise à jour non simultanée par maxSurge et maxUnavailable, en utilisant le format JSON en texte brut.

4. Créez une ressource GpuHealthMonitoringConfig pour activer la surveillance de l'état des GPU pour les noeuds de processus actif GPU sélectionnés. La configuration requiert spec.enabled et un sélecteur de noeud non vide.

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

   Enregistrez la configuration sous le nom gpu-health-monitoring.yaml et appliquez-la en saisissant la commande suivante :

   kubectl apply -f gpu-health-monitoring.yaml

   Le champ spec.enabled active ou désactive la surveillance pour les noeuds sélectionnés. Le champ spec.nodeSelector sélectionne les noeuds de GPU sur lesquels le plug-in de surveillance de GPU RDMA Compute et le détecteur de pannes GPU sont exécutés.

   Evitez de créer plusieurs ressources GpuHealthMonitoringConfig activées dont les sélecteurs correspondent au même noeud. Les stratégies se chevauchant sont rejetées avec une condition Ready dont status est défini sur False et reason sur MultipleMatchingPolicies.

5. Vérifiez la configuration de surveillance de l'état des GPU sur les noeuds sélectionnés.

   Le contrôleur publie la condition de noeud oci.oraclecloud.com/GpuHealthMonitoringConfigured. La valeur True indique que le module d'extension de surveillance de GPU RDMA Compute a été configuré comme activé. La valeur False indique qu'elle a été configurée comme désactivée. La valeur Unknown indique que l'état configuré ne peut pas être approuvé actuellement.

   Le détecteur de pannes de GPU publie la condition de noeud oci.oraclecloud.com/GpuHealthMonitoringUnavailable. La valeur True indique qu'un ou plusieurs fichiers de résultat d'intégrité GPU requis ne sont pas disponibles. Causes possibles : version obsolète de l'agent Oracle Cloud, forme non prise en charge, module d'extension désactivé ou en mauvais état, ou configuration incorrecte. La valeur False indique que les fichiers de résultats requis sont présents.

6. Créez une ressource personnalisée NodeRepairConfig de portée cluster qui ne se chevauche pas en mode de simulation.

   Sélectionnez des noeuds à l'aide d'une étiquette de pool de noeuds durable que vous gérez. Le libellé du sélecteur est défini par l'utilisateur.

   Un noeud doit correspondre à une seule ressource NodeRepairConfig. Les demandes sans configuration correspondante ou les configurations qui se chevauchent sont rejetées sans effets secondaires de réparation. Vous pouvez utiliser les mêmes configurations ou des configurations distinctes pour la réparation lancée par l'utilisateur et la récupération d'instance GPU. Si vous utilisez des configurations distinctes, n'incluez pas les mêmes noeuds dans plusieurs configurations ; sinon, la demande de réparation sera rejetée.

   L'exemple suivant démarre en mode d'exécution à sec, permet une réparation à la fois, définit le seuil de noeud en mauvais état sur 10 %, utilise un délai de grâce de purge de 60 minutes et désactive le comportement force après grâce :

   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
       pauseBeforeRepair: true

   Dans la section policy, dryRun, forceActionAfterGracePeriod et pauseBeforeRepair sont des valeurs booléennes. evictionGracePeriodMinutes est un entier non négatif. maximumParallelNodeRepairs est un entier positif. maxUnhealthyNodeThreshold accepte un nombre de noeuds positif ou un pourcentage entre guillemets, tel que "10%".

   Commencez par dryRun: true et pauseBeforeRepair: true. La définition de pauseBeforeRepair sur true vous permet d'inspecter la réparation sélectionnée avant qu'OKE ne commence les actions perturbatrices. La pause s'applique également pendant la course à sec. Lorsque pauseBeforeRepair est défini sur true, vous devez poursuivre la simulation mise en pause avant de pouvoir la terminer.

   Après avoir validé la configuration, mettez à jour uniquement dryRun vers false pour l'opération en direct.

   La récupération d'instance de GPU est régie par le signal d'état. N'appliquez pas le libellé de réparation oci.oraclecloud.com/customer-report-host-status=unhealthy lancé par l'utilisateur pour la récupération d'instance de GPU.

7. Vérifiez qu'un signal d'intégrité GPU admissible est signalé pour le noeud.

   Un noeud peut être réinitialisé automatiquement uniquement lorsque toutes les conditions suivantes sont remplies :

   • La condition de noeud oci.oraclecloud.com/GpuHealthMonitoringFaultDetected est True.
   • NodeHealthReport contient une entrée sous status.signals.clusterHealthCheck[].
   • Le signal a un id non vide.
   • Le signal a action=REBOOT. La valeur n'est pas sensible à la casse.
   • Le signal a une valeur firstObservedAt non NULL.
   • Le signal a une valeur lastObservedAt non NULL, indiquant que le signal est actif.
   • Le signal est resté actif pendant au moins 10 minutes.
   • Les règles de relance et de ralentissement du contrôleur de réparation de noeud permettent une autre tentative. Le temps de recharge de la réinitialisation est de 60 minutes.
   • La valeur d'exécution à sec effective est false pour une réinitialisation réelle.
   • Les limites d'admission et de perturbation subséquentes sont dépassées.

   Les signaux avec action=CUSTOMER_ACTION_REQUIRED ne déclenchent pas de redémarrage automatique. Si l'un de ces signaux s'affiche, examinez les conditions NodeHealthReport et de noeud, examinez le problème d'intégrité du GPU signalé et contactez le support technique si vous avez besoin d'aide pour le résoudre.

8. Activez la réparation en direct dans la ressource NodeRepairConfig.

   La récupération d'instance de GPU ne démarre qu'une fois que le signal éligible est resté actif pendant au moins 10 minutes et que le temps de recharge du redémarrage répété est de 60 minutes. Le comportement de purge suit la stratégie de réparation indiquée dans la ressource NodeRepairConfig correspondante. Draining utilise l'API d'expulsion Kubernetes et respecte les budgets de perturbation du pod. Le temps nécessaire à la récupération de l'instance de GPU peut varier en fonction des paramètres d'interruption de charge globale, du comportement de purge des noeuds et de l'état de l'instance de calcul.

9. Vérifiez que la récupération de l'instance GPU s'est terminée avec succès.

   Vérifiez que NodeHealthReport affiche une action Reboot en mode direct et que son statut de terminal est Completed. Vérifiez que l'instance Compute est à l'état Running, que le noeud Kubernetes est Ready et que le résultat d'état du GPU en cours ne signale plus l'erreur.

10. Vérifiez le résultat de l'état du GPU une fois le workflow terminé.

    Si le résultat d'intégrité du GPU signale toujours la même panne après la réinitialisation ou signale à nouveau la panne, celle-ci n'a pas été résolue. Un workflow de récupération terminé ne signifie pas que l'erreur GPU sous-jacente a été corrigée. La récupération d'instance GPU utilise des règles de ralentissement pour empêcher les boucles de redémarrage immédiates. Une fois que le résultat d'intégrité du GPU cesse de signaler l'erreur, un résultat d'intégrité du GPU ultérieur qui signale une nouvelle erreur peut rendre le noeud éligible pour une autre réparation.

Avant de configurer la réparation des événements de maintenance, identifiez les noeuds de processus actif GPU Bare Metal éligibles et vérifiez que les charges globales sur les noeuds sélectionnés peuvent être interrompues. La réparation d'événement de maintenance peut cordonner et vider un noeud affecté avant qu'OKE n'exécute l'action Compute applicable.

La réparation des événements de maintenance est prise en charge pour les noeuds de processus actif GPU Bare Metal éligibles, y compris les noeuds gérés et les noeuds autogérés. Le cluster doit être un cluster amélioré et doit exécuter Kubernetes version 1.32 ou ultérieure. La réparation d'événement de maintenance ne s'applique pas aux noeuds virtuels ou aux noeuds de processus actif non Bare Metal.

La réparation des événements de maintenance utilise GPU Health Monitoring pour identifier les pannes de GPU ou RDMA noeud-local sur les formes GPU. OKE met en corrélation le signal de panne local avec un événement de maintenance OCI Compute pour la même instance Compute. Si le noeud est sélectionné par une seule ressource NodeRepairConfig correspondante et que la stratégie de réparation autorise la réparation, OKE coordonne le workflow de réparation.

Avant de configurer la réparation d'événement de maintenance, créez les stratégies IAM requises par le module complémentaire GPU Health Monitoring pour surveiller les hôtes GPU :

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>

où :

• <dg-name> est le nom du groupe dynamique qui inclut les instances Compute pour les noeuds de processus actif GPU. Par exemple, en utilisant une règle telle que ALL {instance.compartment.id = '<compartment-ocid>'}. En appliquant des balises aux pools de noeuds, vous pouvez créer des règles plus restrictives, telles que :

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

  Pour plus d'informations, reportez-vous à Application de balises aux pools de noeuds.

• <compartment-ocid> est l'OCID du compartiment contenant les noeuds de processus actif GPU.

Créez également une stratégie qui permet au principal de ressource de cluster OKE d'utiliser les événements de maintenance d'instance dans le compartiment contenant les instances de noeud de processus actif GPU et leurs événements de maintenance :

Allow any-user to use instance-maintenance-events in compartment id <worker-compartment-ocid> where request.principal.type = 'cluster'

Pour restreindre l'accès à un cluster spécifique, utilisez une stratégie telle que :

Allow any-user to use instance-maintenance-events in compartment id <worker-compartment-ocid> where all {request.principal.type = 'cluster', request.principal.id = '<cluster-ocid>'}

où :

• <worker-compartment-ocid> est l'OCID du compartiment contenant les instances de noeud de processus actif GPU et leurs événements de maintenance.
• <cluster-ocid> est l'OCID du cluster.

La réparation d'événement de maintenance prend en charge les actions d'événement de maintenance Compute suivantes :

• STOP : OKE coordonne un événement de maintenance sans fin. Une fois l'événement de maintenance traité, l'instance Compute et le noeud Kubernetes doivent être remis en service.
• TERMINATE : OKE coordonne la terminaison de l'instance Compute concernée. Pour les pools de noeuds gérés, le remplacement dépend de la gestion de la capacité de pool de noeuds gérés et de la capacité de GPU disponible. Pour les noeuds autogérés, OKE ne remplace pas automatiquement le noeud après l'interruption. Provisionner et joindre un noeud de remplacement à l'aide du processus de gestion des noeuds que vous utilisez normalement pour les noeuds autogérés (reportez-vous à Utilisation de noeuds autogérés).

La version d'agent Oracle Cloud 1.64.0 ou ultérieure est requise par le module d'extension de surveillance de GPU RDMA Compute et doit être installée sur les noeuds sélectionnés.

Lorsqu'OKE admet une demande de réparation d'événement de maintenance, il coordonne les actions suivantes :

1. Garantit qu'une seule demande de réparation est traitée à la fois.
2. Corrige le signal de panne de GPU ou RDMA local avec un événement de maintenance Compute pour la même instance.
3. Enregistre les informations de réparation dans un fichier NodeHealthReport.
4. Connectez le noeud de sorte que Kubernetes ne planifie pas de nouveaux pods dessus.
5. Tentatives de purge des charges globales à partir du noeud.
6. Exécute le workflow d'événement de maintenance STOP ou TERMINATE applicable.

Pour configurer la réparation d'événement de maintenance :

1. Vérifiez que le cluster est un cluster amélioré et qu'il exécute Kubernetes version 1.32 ou ultérieure. Vérifiez que le noeud est un noeud de processus actif GPU Bare Metal éligible, qu'il s'agisse d'un noeud géré ou d'un noeud autogéré.

   Vérifiez que le contrôleur de réparation de noeud géré par OKE et les CRD NodeHealthReport sont installés sur le cluster et que l'extension GPU Health Monitoring est disponible pour le cluster. Si une ressource gérée par OKE est manquante, contactez le support technique Oracle. Ne recréez pas de ressources gérées par OKE.

2. Installez et configurez l'extension GPU Health Monitoring pour les noeuds de processus actif GPU sélectionnés.

   La réparation d'événement de maintenance nécessite que GPU Health Monitoring soit activé sur les noeuds de processus actif GPU sélectionnés afin qu'OKE puisse mettre en corrélation un signal de panne GPU ou RDMA local avec un événement de maintenance Compute.

   Vérifiez que l'extension GPU Health Monitoring dispose d'une option ACTIVE pour la version de Kubernetes exécutée sur le cluster en saisissant la commande suivante :

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

   Installez le module complémentaire GPU Health Monitoring géré par OKE en saisissant ce qui suit :

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

   Créez une ressource GpuHealthMonitoringConfig pour activer la surveillance de l'état des GPU pour les noeuds de processus actif GPU sélectionnés. La configuration requiert spec.enabled et un sélecteur de noeud non vide.

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

   Enregistrez la configuration sous le nom gpu-health-monitoring.yaml et appliquez-la en saisissant la commande suivante :

   kubectl apply -f gpu-health-monitoring.yaml

   Le champ spec.enabled active ou désactive la surveillance pour les noeuds sélectionnés. Le champ spec.nodeSelector sélectionne les noeuds de GPU sur lesquels le plug-in de surveillance de GPU RDMA Compute et le détecteur de pannes GPU sont exécutés.

   Evitez de créer plusieurs ressources GpuHealthMonitoringConfig activées dont les sélecteurs correspondent au même noeud. Les stratégies se chevauchant sont rejetées avec une condition Ready dont status est défini sur False et reason sur MultipleMatchingPolicies.

   Vérifiez la configuration de surveillance de l'état des GPU sur les noeuds sélectionnés. Le contrôleur publie la condition de noeud oci.oraclecloud.com/GpuHealthMonitoringConfigured. Le détecteur de pannes de GPU publie la condition de noeud oci.oraclecloud.com/GpuHealthMonitoringUnavailable.

3. Créez une ressource personnalisée NodeRepairConfig de portée cluster qui ne se chevauche pas en mode de simulation.

   Sélectionnez des noeuds à l'aide d'un libellé durable que vous gérez et qui est présent sur les noeuds de processus actif GPU prévus. Pour les pools de noeuds gérés, configurez l'étiquette sur le pool de noeuds afin que les noeuds de remplacement le conservent. Pour les noeuds autogérés, assurez-vous que l'étiquette est appliquée de manière cohérente aux noeuds voulus.

   Un noeud doit correspondre à une seule ressource NodeRepairConfig. Les demandes sans configuration correspondante ou les configurations qui se chevauchent sont rejetées sans effets secondaires de réparation. Ne créez pas de configurations qui se chevauchent pour la réparation lancée par l'utilisateur, la récupération d'instance de GPU et la réparation d'événement de maintenance.

   L'exemple suivant démarre en mode d'exécution à sec, permet une réparation à la fois, définit le seuil de noeud en mauvais état sur 10 %, utilise un délai de grâce de purge de 60 minutes et désactive le comportement force après grâce :

   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
       pauseBeforeRepair: true

   Dans la section policy, dryRun, forceActionAfterGracePeriod et pauseBeforeRepair sont des valeurs booléennes. evictionGracePeriodMinutes est un entier non négatif. maximumParallelNodeRepairs est un entier positif. maxUnhealthyNodeThreshold accepte un nombre de noeuds positif ou un pourcentage entre guillemets, tel que "10%".

   Commencez par dryRun: true et pauseBeforeRepair: true. La définition de pauseBeforeRepair sur true vous permet d'inspecter la réparation sélectionnée avant qu'OKE ne commence les actions perturbatrices. La pause s'applique également pendant la course à sec. Lorsque pauseBeforeRepair est défini sur true, vous devez poursuivre la simulation mise en pause avant de pouvoir la terminer.

4. Vérifiez le comportement de la simulation.

   En mode test, OKE évalue le noeud sélectionné, la stratégie de réparation correspondante, l'événement de maintenance corrélé et l'action d'événement de maintenance proposée. Le mode d'exécution à sec ne doit pas être cordon, drainer, arrêter, interrompre ou remplacer le nœud.

   Examinez le fichier NodeHealthReport pour connaître l'événement de maintenance et le résultat de workflow corrélés. L'OCID d'événement de maintenance est affiché dans status.signals.maintenanceEvent[].maintenanceEventId. L'action corrélée est affichée dans status.signals.maintenanceEvent[].action. L'état de cycle de vie de l'événement Compute est indiqué dans status.signals.maintenanceEvent[].maintenanceLifecycleState.

   Pour vérifier la tentative de réparation sélectionnée, consultez status.repair.selectedSignalIds, status.repair.repairAction, status.repair.dryRun, status.repair.terminalState et status.lastRepairAttempt. Une simulation à sec réussie enregistre Completed avec dryRun: true. La fin de l'exécution à sec ne prouve pas qu'une action de purge ou de calcul réelle réussira.

5. Activez la réparation en direct contrôlée en mettant à jour la ressource NodeRepairConfig correspondante.

   Pour l'opération en direct, mettez à jour uniquement les champs de stratégie prévus, tels que la modification de dryRun de true à false. La modification de dryRun ne réexécute pas une tentative de réparation déjà admise. La modification de la ressource NodeRepairConfig ne réévalue pas un signal d'événement de maintenance existant ni ne modifie une tentative de réparation déjà admise. La stratégie mise à jour s'applique au prochain signal d'événement de maintenance distinct.

   Ne modifiez pas les ressources NodeHealthReport ou ne basculez pas les conditions Node internes pour forcer une nouvelle tentative.

   Important
   
   Une réparation d'événement de maintenance en direct peut purger les charges globales et arrêter ou mettre fin à l'instance Compute concernée. Draining utilise l'API d'expulsion Kubernetes et respecte les budgets de perturbation du pod. Les pods DaemonSet et les pods statiques sont ignorés. Si force-after-grace est activé, le contrôleur de réparation de noeud ne force pas la suppression des pods restants, mais l'action de calcul suivante peut toujours les interrompre.

6. Si la réparation est interrompue avant l'action Compute, examinez les conditions NodeHealthReport et de noeud. Une réparation mise en pause est indiquée par la condition de noeud oci.oraclecloud.com/NodeAutoRepairPaused=True.

   Pour poursuivre la réparation suspendue, saisissez :

   kubectl label node <node-name> oci.oraclecloud.com/node-repair-paused-response=continue --overwrite

   Pour annuler la réparation mise en pause, saisissez :

   kubectl label node <node-name> oci.oraclecloud.com/node-repair-paused-response=cancel --overwrite

   Le contrôleur de réparation de noeud consomme l'étiquette de réponse et efface la condition de pause. Lorsque vous continuez une réparation mise en pause, OKE vérifie à nouveau la stratégie de réparation et les limites d'interruption avant de continuer.

   L'annulation d'une réparation mise en pause arrête uniquement la tentative de réparation OKE. Il n'annule, ne reprogramme ni n'enlève l'événement de maintenance Compute sous-jacent. OKE enregistre Cancelled pour la tentative de réparation et efface la condition de pause et le libellé de réponse. OKE continue de suivre l'événement de maintenance Compute et la condition MaintenanceEventDetected peut rester présente. L'annulation de la tentative de réparation OKE n'empêche pas Compute de traiter la maintenance selon sa propre programmation.

7. Pour une réparation d'événement de maintenance STOP, vérifiez que le workflow d'événement de maintenance se termine et que le même noeud revient au service.

   Dans le cadre d'une réparation STOP sans fin réussie, le nom Node de Kubernetes, l'UID Node de Kubernetes et l'OCID d'instance Compute restent identiques.

   Confirmez que NodeHealthReport enregistre repairAction: STOP et qu'il ne s'agit pas d'une exécution à sec. Vérifiez que status.lastRepairAttempt enregistre result: Completed et un horodatage completedAt. Vérifiez que le fichier Node d'origine est Ready et qu'il peut être programmé, avec des identités inchangées.

8. Pour une réparation d'événement de maintenance TERMINATE, vérifiez que la réparation en direct correspond à l'événement de maintenance prévu et à l'instance Compute, que l'instance d'origine est interrompue et que la plate-forme Kubernetes d'origine Node est enlevée.

   Pour les pools de noeuds gérés, vérifiez que la capacité de remplacement devient disponible lorsque la capacité de GPU, les limites de service et les quotas de compartiment autorisent le remplacement. Pour les noeuds autogérés, provisionnez et joignez un noeud de remplacement à l'aide du processus de gestion des noeuds que vous utilisez normalement pour les noeuds autogérés (reportez-vous à Utilisation de noeuds autogérés).

   Un résultat Completed indique qu'OKE a terminé le workflow de fin de contrat. Elle ne confirme pas que la réparation de l'hôte physique est terminée, que la capacité de remplacement est prête ou que les charges globales ont été récupérées.

Un workflow de réparation d'événement de maintenance terminé ne confirme pas que la panne GPU ou RDMA sous-jacente a été corrigée, que la réparation de l'hôte physique est terminée, que la capacité de remplacement est prête ou que les charges de travail ont été récupérées. Une fois le workflow terminé, vérifiez les signaux d'état en cours du noeud, sa préparation, sa capacité attendue et l'état de l'application.

Utilisez les ressources Kubernetes et les outils de surveillance Kubernetes standard pour inspecter le workflow de réparation, les conditions de noeud, les charges globales affectées et NodeHealthReport.

Pour surveiller un workflow de réparation d'hôte GPU :

1. Examinez NodeHealthReport et le noeud de processus actif concerné avant, pendant et après la réparation.

   Consultez NodeHealthReport pour la demande de réparation, l'avancement de la réparation, l'action, le mode d'exécution à sec ou en direct et le résultat du workflow. Consultez la ressource Node Kubernetes affectée pour connaître les conditions et les libellés de noeud. Consultez les événements Kubernetes pour connaître l'activité de réparation et de noeud récente. Pour la récupération d'instance de GPU, vérifiez les conditions GpuHealthMonitoringConfigured, GpuHealthMonitoringUnavailable et GpuHealthMonitoringFaultDetected sur la ressource Node Kubernetes affectée. Pour la réparation des événements de maintenance, vérifiez le signal d'intégrité GPU ou RDMA, l'événement de maintenance Compute corrélé et le statut de réparation des événements de maintenance enregistré dans NodeHealthReport.

   Traitez les ressources appartenant au contrôleur en lecture seule. Ne créez ni ne modifiez les actions générées ou les ressources appartenant au contrôleur.

2. Vérifiez le statut de réparation et l'état du noeud pris en charge.

   Utilisez NodeHealthReport pour passer en revue la stratégie de réparation, la valeur d'exécution à sec effective, le résultat d'admission, le résultat final et la dernière tentative de réparation. Utilisez la ressource Node Kubernetes affectée pour vérifier les conditions de noeud. Le cas échéant, vérifiez l'état de cycle de vie de l'instance Compute, la balise définie Compute utilisée pour la réparation lancée par l'utilisateur, les détails de l'événement de maintenance pour la réparation de l'événement de maintenance et si la capacité de remplacement est prête.

   Ne vous fiez pas aux baux internes, aux ID de demande, aux chemins de fichier, aux intervalles d'interrogation ou aux phases de workflow intermédiaires en tant qu'indicateurs d'état.

3. Pour la réparation lancée par l'utilisateur, examinez les demandes rejetées, la réparation différée, l'échec de la réparation et la réparation remplacée.

   Une demande peut être rejetée lorsqu'aucune ressource NodeRepairConfig ne correspond au noeud ou lorsque plusieurs configurations s'appliquent.

   Utilisez le résultat NodeHealthReport pour décider des éléments à examiner :

   • Si NodeHealthReport affiche AdmissionRejected, vérifiez la ressource NodeRepairConfig, l'autorisation de déclencheur et la configuration d'étiquette.
   • Si NodeHealthReport affiche Deferred, attendez que la condition de blocage disparaisse ou ajustez la capacité si la capacité de remplacement n'est pas disponible.
   • Si NodeHealthReport affiche Failed, examinez NodeHealthReport, les événements Kubernetes, les budgets d'interruption de pod, la stratégie IAM, la balise définie Compute et l'état de l'instance Compute.
   • Si NodeHealthReport affiche Superseded, suivez le workflow OKE qui a repris la réparation.
   • Si NodeHealthReport affiche Completed, vérifiez que l'instance d'origine a pris fin et que la capacité de remplacement est prête.

4. Pour la récupération d'instance de GPU, examinez la configuration de surveillance de l'état du GPU, les résultats d'état indisponibles, les signaux de réinitialisation, les signaux nécessitant une action, les drains incomplets, les réinitialisations terminées avec une panne en cours et les signaux continus qui ne déclenchent pas de réinitialisations répétées.

   Utilisez les conditions de noeud, les signaux d'état de GPU et le résultat NodeHealthReport pour déterminer les éléments à examiner :

   • Si la condition de noeud GpuHealthMonitoringConfigured est False ou Unknown, vérifiez la configuration de l'agent Oracle Cloud et la configuration de l'extension GpuHealthMonitoring.
   • Si la condition de noeud GpuHealthMonitoringUnavailable est True, vérifiez que la forme de GPU est prise en charge, que l'agent Oracle Cloud version 1.64.0 ou ultérieure est installé, que le module d'extension de surveillance de GPU Compute RDMA est activé et que l'extension de surveillance de l'état de GPU est installée et configurée.
   • Si un signal d'état de GPU actif a action=REBOOT, surveillez NodeHealthReport pour le workflow de récupération d'instance de GPU.
   • Si le signal d'intégrité d'un GPU est action=CUSTOMER_ACTION_REQUIRED, recherchez le problème d'intégrité du GPU signalé. Ce signal ne déclenche pas de redémarrage automatique.
   • Si NodeHealthReport indique une purge incomplète ou une réparation ayant échoué, examinez les événements Kubernetes, les budgets d'interruption de pod, l'état de charge globale et les conditions de noeud.
   • Si la réinitialisation est terminée mais que le résultat de l'intégrité du GPU signale toujours la panne, examinez la panne en cours.
   • Si le même signal continue après la réinitialisation, la récupération d'instance de GPU ne redémarre pas immédiatement le noeud. Les règles de refroidissement empêchent les boucles de réinitialisation immédiates.

5. Pour la réparation des événements de maintenance, examinez la configuration de GPU Health Monitoring, les signaux de panne de GPU ou RDMA locaux, les événements de maintenance Compute corrélés, les ressources NodeRepairConfig correspondantes, les réparations en pause, les vidages incomplets et le résultat du workflow STOP ou TERMINATE.

   Pour la réparation des événements de maintenance, passez en revue les conditions des noeuds oci.oraclecloud.com/MaintenanceEventDetected et oci.oraclecloud.com/NodeAutoRepairPaused. Dans le fichier NodeHealthReport, vérifiez l'OCID d'événement de maintenance, l'action, les codes d'erreur, l'état du cycle de vie de maintenance, l'ID de réparation, les ID de signal sélectionnés, l'action de réparation, la valeur d'exécution à sec, l'état d'admission, les détails de rejet, l'état terminal et la dernière tentative de réparation.

   Utilisez les conditions de noeud, les informations sur les événements de maintenance et le résultat NodeHealthReport pour déterminer les éléments à examiner :

   • Si une panne de GPU ou RDMA locale ne démarre pas la réparation d'événement de maintenance, vérifiez GPU Health Monitoring, l'agent Oracle Cloud, la forme du noeud de processus actif GPU et les signaux d'état enregistrés dans NodeHealthReport. Vérifiez qu'un événement de maintenance Compute correspondant existe pour la même instance.
   • Si la réparation d'événement de maintenance n'est pas admise, vérifiez qu'un seul élément NodeRepairConfig sélectionne le noeud et que la stratégie de réparation et les limites d'interruption permettent la réparation. Examinez le résultat d'admission NodeHealthReport.
   • Si la réparation est suspendue, examinez les conditions NodeHealthReport et de noeud, puis utilisez le mécanisme de réponse pris en charge pour poursuivre ou annuler la réparation.
   • Si une réparation STOP est terminée mais que le noeud n'est pas planifiable, vérifiez la préparation du noeud, l'état du cordon, l'état du cycle de vie des événements de maintenance Compute, les signaux d'état en cours et les événements Kubernetes.
   • Si une réparation TERMINATE est terminée mais que la capacité attendue n'est pas disponible, vérifiez la capacité de la forme de GPU, les limites de service, les quotas de compartiment et l'état du pool de noeuds. Pour les noeuds autogérés, provisionnez et joignez un noeud de remplacement à l'aide du processus de gestion des noeuds que vous utilisez normalement pour les noeuds autogérés (reportez-vous à Utilisation de noeuds autogérés).

   Les résultats de réparation OKE pertinents incluent Completed, Failed, Cancelled, Superseded et AdmissionRejected. Un état Deferred représente un blocage temporaire et non un résultat final. Les valeurs de cycle de vie de maintenance de calcul sont distinctes des résultats de réparation OKE.

6. Avant d'ouvrir une demande d'assistance, collectez les informations nécessaires pour examiner le workflow de réparation.

   Incluez l'OCID de location, l'OCID de cluster, la région, la version de Kubernetes, la version d'extension GPU Health Monitoring, la version d'agent Oracle Cloud, le nom de noeud de processus actif affecté, l'OCID d'instance de calcul, les ressources NodeHealthReport et NodeRepairConfig pertinentes, les libellés et conditions de noeud, les événements Kubernetes, le budget et l'état de charge globale des interruptions de pod, les horodatages et les résultats d'état de GPU en cours. Pour la réparation des événements de maintenance, incluez également l'OCID d'événement de maintenance Compute, l'action d'événement de maintenance, les codes d'erreur, l'état du cycle de vie des événements de maintenance et tous les détails d'événement de maintenance disponibles à partir de Compute.

   Ne modifiez pas les CRD, les ressources de contrôleur, les objets d'admission, les actions générées ou les ressources de coordination appartenant à OKE.