Reparación de hosts de GPU

Antes de configurar la reparación iniciada por el usuario, identifique un pool de nodos de GPU gestionado elegible y un nodo de prueba controlado. Asegúrese de que se puedan interrumpir las cargas de trabajo en el nodo seleccionado.

La reparación iniciada por el usuario requiere control de acceso tanto en OCI IAM como en Kubernetes RBAC. En OCI IAM, la entidad de recurso de cluster de OKE necesita permiso para aplicar la etiqueta definida que se utiliza para informar la condición de host a Compute. En Kubernetes, solo un operador de confianza debe poder iniciar la solicitud de reparación protegida. El operador de confianza necesita permisos RBAC de Kubernetes estándar para actualizar el recurso Node de destino y la autorización específica de OKE delegada a través de ClusterRoleBinding.

Cuando solicita una reparación iniciada por el usuario, OKE coordina las siguientes acciones:

1. Garantiza que solo se procese una solicitud de reparación a la vez.
2. Conecta el nodo para que Kubernetes no programe nuevos pods en él.
3. Intenta vaciar cargas de trabajo del nodo.
4. Informa de la condición a Compute y finaliza la instancia afectada.
5. Restaura la capacidad configurada del pool de nodos gestionado.

Para configurar y probar la reparación iniciada por el usuario:

1. Verifique que el cluster sea un cluster mejorado y que esté ejecutando Kubernetes versión 1.32 o posterior. Verifique que el nodo sea un nodo de trabajador de GPU gestionado elegible. Verifique que el controlador de reparación de nodos gestionado por OKE y las CRD NodeHealthReport, oke-customer-node-repair-trigger ClusterRole y la política de admisión de protección de disparadores y el enlace estén instalados en el cluster. Si falta algún recurso gestionado por OKE, póngase en contacto con los Servicios de Soporte Oracle. No vuelva a crear los recursos gestionados por OKE.

2. Antes de utilizar la reparación en directo, abra una solicitud de soporte para permitir el manejo de fallos de hardware informados por el usuario para su arrendamiento. Incluya el arrendamiento, la región, el OCID del cluster y el pool de nodos de GPU en la solicitud.

3. Cree o reutilice la etiqueta definida que el controlador de reparación de nodos utiliza para informar la condición del host a Compute.

   Cree o reutilice un espacio de nombres de etiqueta denominado ComputeInstanceHostActions. En ese espacio de nombres, cree o reutilice una definición de clave de etiqueta denominada CustomerReportedHostStatus. No cree una etiqueta de formato libre con el mismo texto. Para obtener más información, consulte Creating a Tag Namespace y Creating a Tag Key Definition.

   Antes de terminar la instancia original, el controlador de reparación de nodos escribe el valor unhealthy en la etiqueta definida ComputeInstanceHostActions.CustomerReportedHostStatus en la instancia.

4. Cree una política de OCI IAM que otorgue a la entidad de recurso de cluster de OKE el permiso de ámbito limitado para aplicar la etiqueta definida:

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

   Los cambios de IAM pueden tardar en propagarse. Espere la propagación antes de realizar una validación destructiva.

5. Delegue el disparador de reparación iniciado por el usuario protegido a operadores de confianza.

   Cree un ClusterRoleBinding que enlace un OCID de grupo de OCI IAM de confianza al oke-customer-node-repair-trigger ClusterRole propiedad de OKE. Los operadores también necesitan permisos RBAC de Kubernetes estándar para actualizar el recurso Node de destino.

   Cree un archivo denominado cir-trigger-operators.yaml con el siguiente contenido:

   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>

   Sustituya <trusted-oci-iam-group-ocid> por el OCID del grupo de OCI IAM que contiene los operadores de confianza.

   Aplique y verifique el enlace introduciendo:

   kubectl apply -f cir-trigger-operators.yaml

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

   Este enlace no otorga permiso general para actualizar los recursos Node. Utilice su modelo de autorización de Kubernetes existente para otorgar solo los permisos de RBAC de Kubernetes estándar necesarios para los operadores de confianza.

6. Cree un recurso personalizado NodeRepairConfig de ámbito de cluster no solapado en modo de ejecución simulada.

   Seleccione nodos mediante una etiqueta duradera de agrupación de nodos que gestione y que esté presente en los nodos de sustitución. La etiqueta del selector está definida por el usuario. Configure la etiqueta en el pool de nodos gestionado deseado para que los nodos de sustitución la retengan.

   Un nodo debe coincidir exactamente con un recurso NodeRepairConfig. Las solicitudes sin configuración coincidente o con configuraciones superpuestas se rechazan sin efectos secundarios de reparación. Puede utilizar la misma configuración o configuraciones independientes para la reparación iniciada por el usuario y la recuperación de instancias de GPU. Si utiliza configuraciones independientes, no incluya los mismos nodos en varias configuraciones; de lo contrario, la solicitud de reparación se rechazará.

   El siguiente ejemplo comienza en modo de ejecución en seco, permite una reparación a la vez, establece el umbral de nodo no saludable en un 10%, utiliza un período de gracia de drenaje de 60 minutos y desactiva el comportamiento de fuerza después de la gracia:

   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

   En la sección policy, dryRun y forceActionAfterGracePeriod son valores booleanos. evictionGracePeriodMinutes es un entero no negativo. maximumParallelNodeRepairs es un entero positivo. maxUnhealthyNodeThreshold acepta un recuento de nodos positivo o un porcentaje entrecomillado, como "10%".

   Comience con dryRun: true. Después de validar la configuración, actualice solo dryRun a false para la operación activa.

7. Solicite una reparación de ejecución simulada aplicando la etiqueta protegida oci.oraclecloud.com/customer-report-host-status=unhealthy al nodo seleccionado. Inspeccione NodeHealthReport y el estado del nodo relacionado. Una solicitud de ejecución simulada crea un registro NodeHealthReport completado, pero no acorta, drena, aplica la etiqueta definida de Compute, termina, reinicia ni reemplaza el nodo.

8. Disparar una reparación en directo mediante la aplicación de la etiqueta de disparador protegida junto con la sustitución en directo puntual oci.oraclecloud.com/node-repair-dry-run=false. La sustitución activa solo es válida con un disparador activo y se muestra solo cuando se crea un nuevo disparador.

   Para volver a intentar una solicitud de reparación iniciada por el usuario, elimine y vuelva a aplicar la etiqueta oci.oraclecloud.com/customer-report-host-status=unhealthy. Si se vuelve a aplicar el mismo valor de etiqueta, no se inicia otra solicitud. La eliminación de la etiqueta no cancela una reparación activa.

   Importante
   
   Una reparación activa iniciada por el usuario puede vaciar las cargas de trabajo y terminar la instancia informática original. Draining utiliza la API de desalojo de Kubernetes y respeta los presupuestos de interrupción de pod. Se omiten los pods DaemonSet y los pods estáticos. Si la opción force-after-grace está activada, el controlador de reparación de nodos no fuerza la supresión de los pods restantes, pero la acción posterior del host puede interrumpirlos.

9. Verifique el progreso de la acción de reparación, la etiqueta definida por Compute, la terminación de la instancia original, la restauración de la capacidad del pool de nodos gestionados y la creación de un nodo de sustitución con un nuevo UID y un OCID de instancia. El valor NodeHealthReport para las instancias terminadas se retiene temporalmente una vez finalizado el flujo de trabajo.

   Un resultado Deferred significa que el flujo de trabajo está bloqueado temporalmente. Un resultado Failed significa que el intento se detuvo. Un resultado Superseded significa que un flujo de trabajo de OKE de mayor prioridad asumió el control. Un resultado Completed significa que OKE finalizó el flujo de trabajo de terminación solicitado. No significa que la reparación física esté completa o que la capacidad de sustitución sea Ready. Cuando finalice el flujo de trabajo, verifique que el pool de nodos gestionado tenga la capacidad esperada y que el nodo de sustitución informe del estado actual en buen estado.

Para la reparación iniciada por el usuario, la creación de un nodo de trabajador de sustitución depende de la conciliación de nodos y agrupaciones gestionadas y de la capacidad de GPU disponible. Un flujo de trabajo completado no confirma que el fallo de GPU subyacente se haya corregido.

Antes de configurar la recuperación de instancias de GPU, identifique un pool de nodos de GPU gestionado elegible y confirme que sus cargas de trabajo se pueden interrumpir. La recuperación de instancias de GPU puede acordonar y drenar un nodo afectado antes de reiniciar su instancia.

Antes de configurar la recuperación de instancias de GPU, cree las políticas de IAM necesarias para que el complemento GPU Health Monitoring controle los hosts de 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>

donde:

• <dg-name> es el nombre del grupo dinámico que incluye las instancias informáticas para los nodos de trabajador de GPU. Por ejemplo, mediante una regla como ALL {instance.compartment.id = '<compartment-ocid>'}. Al aplicar etiquetas a pools de nodos, puede crear reglas más restrictivas, como:

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

  Para obtener más información, consulte Aplicación de etiquetas a pools de nodos.

• <compartment-ocid> es el OCID del compartimento que contiene los nodos de trabajador de GPU.

La recuperación de instancias de GPU solo está soportada en nodos de trabajador de GPU gestionados elegibles que utilizan las siguientes unidades de GPU:

• 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 disponibilidad de la unidad de GPU varía según la región. Confirme que la unidad de GPU seleccionada está disponible en la región donde se ejecuta el cluster.

El plugin Compute RDMA GPU Monitoring necesita la versión 1.64.0 o posterior del agente de Oracle Cloud y debe instalarse en los nodos seleccionados.

Cuando OKE recibe una señal de estado de GPU elegible, coordina las siguientes acciones:

1. Garantiza que solo se procese una solicitud de recuperación a la vez.
2. Conecta el nodo para que Kubernetes no programe nuevos pods en él.
3. Intenta vaciar cargas de trabajo del nodo.
4. Reinicia la instancia informática afectada.

Para configurar la recuperación de instancias de GPU:

1. Verifique que el cluster esté ejecutando Kubernetes versión 1.32 o posterior. Verifique que el nodo sea un nodo de trabajador de GPU gestionado elegible. Verifique que el controlador de reparación de nodos gestionado por OKE y las CRD NodeHealthReport estén instaladas en el cluster y verifique que el complemento de supervisión del estado de la GPU esté disponible para el cluster.

2. Verifique que el complemento GPU Health Monitoring tenga una opción ACTIVE para la versión de Kubernetes que se ejecuta en el cluster introduciendo:

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

   Al instalar el complemento, instale la última opción ACTIVE en lugar de anclar una versión. La versión instalada debe ser v1.1.0 o posterior.

3. Instale el complemento de supervisión del estado de la GPU gestionado por OKE escribiendo:

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

   El comando instala la última versión disponible del complemento para el cluster.

   Las claves de configuración del complemento soportadas son nodeSelectors, tolerations y rollingUpdate. El valor rollingUpdate controla el comportamiento de actualización sucesiva por maxSurge y maxUnavailable, utilizando el formato JSON en texto sin formato.

4. Cree un recurso GpuHealthMonitoringConfig para activar la supervisión del estado de la GPU para los nodos de trabajador de la GPU seleccionados. La configuración requiere spec.enabled y un selector de nodos que no esté vacío.

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

   Guarde la configuración como gpu-health-monitoring.yaml y aplíquela introduciendo:

   kubectl apply -f gpu-health-monitoring.yaml

   El campo spec.enabled activa o desactiva la supervisión de los nodos seleccionados. El campo spec.nodeSelector selecciona los nodos de GPU en los que se ejecutan el plugin Compute RDMA GPU Monitoring y el supervisor de fallos de GPU.

   Evite crear varios recursos GpuHealthMonitoringConfig activados cuyos selectores coincidan con el mismo nodo. Las políticas superpuestas se rechazan con una condición Ready que tiene status definido en False y reason definido en MultipleMatchingPolicies.

5. Verifique la configuración de supervisión del estado de la GPU en los nodos seleccionados.

   El controlador publica la condición de nodo oci.oraclecloud.com/GpuHealthMonitoringConfigured. El valor True indica que el plugin Compute RDMA GPU Monitoring se ha configurado como activado. Un valor de False indica que se ha configurado como desactivado. Un valor de Unknown indica que actualmente no se puede confiar en el estado configurado.

   El supervisor de fallos de GPU publica la condición de nodo oci.oraclecloud.com/GpuHealthMonitoringUnavailable. El valor True indica que uno o más archivos de resultado de estado de GPU necesarios no están disponibles. Las posibles causas incluyen una versión obsoleta de Oracle Cloud Agent, una unidad no soportada, un plugin desactivado o en mal estado o una configuración incorrecta. El valor False indica que los archivos de resultados necesarios están presentes.

6. Cree un recurso personalizado NodeRepairConfig de ámbito de cluster no solapado en modo de ejecución simulada.

   Seleccione nodos mediante una etiqueta duradera de agrupación de nodos que gestione. La etiqueta del selector está definida por el usuario.

   Un nodo debe coincidir exactamente con un recurso NodeRepairConfig. Las solicitudes sin configuración coincidente o con configuraciones superpuestas se rechazan sin efectos secundarios de reparación. Puede utilizar la misma configuración o configuraciones independientes para la reparación iniciada por el usuario y la recuperación de instancias de GPU. Si utiliza configuraciones independientes, no incluya los mismos nodos en varias configuraciones; de lo contrario, la solicitud de reparación se rechazará.

   El siguiente ejemplo comienza en modo de ejecución en seco, permite una reparación a la vez, establece el umbral de nodo no saludable en un 10%, utiliza un período de gracia de drenaje de 60 minutos y desactiva el comportamiento de fuerza después de la gracia:

   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

   En la sección policy, dryRun, forceActionAfterGracePeriod y pauseBeforeRepair son valores booleanos. evictionGracePeriodMinutes es un entero no negativo. maximumParallelNodeRepairs es un entero positivo. maxUnhealthyNodeThreshold acepta un recuento de nodos positivo o un porcentaje entrecomillado, como "10%".

   Comience con dryRun: true y pauseBeforeRepair: true. Si se define pauseBeforeRepair en true, podrá inspeccionar la reparación seleccionada antes de que OKE inicie las acciones de interrupción. La pausa también se aplica durante la ejecución en seco. Cuando pauseBeforeRepair está definido en true, debe continuar la simulación en pausa antes de que se pueda completar.

   Después de validar la configuración, actualice solo dryRun a false para la operación activa.

   Tenga en cuenta que la recuperación de instancias de GPU está controlada por señales de estado. No aplique la etiqueta de reparación iniciada por el usuario oci.oraclecloud.com/customer-report-host-status=unhealthy para la recuperación de instancias de GPU.

7. Verifique que se informe una señal de estado de GPU elegible para el nodo.

   Un nodo es elegible para el reinicio automatizado solo cuando se cumplen todas las condiciones siguientes:

   • La condición de nodo oci.oraclecloud.com/GpuHealthMonitoringFaultDetected es True.
   • NodeHealthReport contiene una entrada en status.signals.clusterHealthCheck[].
   • La señal tiene un id no vacío.
   • La señal tiene action=REBOOT. El valor es no sensible a mayúsculas/minúsculas.
   • La señal tiene un valor firstObservedAt no nulo.
   • La señal tiene un valor lastObservedAt no nulo, lo que indica que la señal está activa.
   • La señal ha permanecido activa durante al menos 10 minutos.
   • Las reglas de reintento y enfriamiento del controlador de reparación de nodos permiten otro intento. El tiempo de reutilización de reinicio repetido es de 60 minutos.
   • El valor de ejecución simulada efectivo es false para un reinicio real.
   • Los límites de admisión e interrupción posteriores pasan.

   Las señales con action=CUSTOMER_ACTION_REQUIRED no disparan un reinicio automático. Si ve una de estas señales, revise las condiciones de nodo y NodeHealthReport, investigue el problema de estado de la GPU informado y póngase en contacto con Soporte si necesita ayuda para resolverlo.

8. Active la reparación en directo en el recurso NodeRepairConfig.

   La recuperación de instancias de GPU comienza solo después de que la señal elegible se haya mantenido activa durante al menos 10 minutos, y el tiempo de reutilización de reinicio repetido es de 60 minutos. El comportamiento de drenaje sigue la política de reparación especificada en el recurso NodeRepairConfig coincidente. Draining utiliza la API de desalojo de Kubernetes y respeta los presupuestos de interrupción de pod. El tiempo necesario para completar la recuperación de la instancia de GPU puede variar en función de la configuración de interrupción de la carga de trabajo, el comportamiento de vaciado de nodos y el estado de la instancia de Compute.

9. Verifique que la recuperación de la instancia de GPU se ha realizado correctamente.

   Confirme que NodeHealthReport muestra una acción Reboot en modo activo y que tiene un estado de terminal Completed. Confirme que la instancia informática tiene el estado Running, que el nodo de Kubernetes es Ready y que el resultado de estado de la GPU actual ya no informa el fallo.

10. Revise el resultado de estado de la GPU después de que se complete el flujo de trabajo.

    Si el resultado de estado de la GPU aún informa el mismo fallo después del reinicio o vuelve a informar el fallo, el fallo no se ha resuelto. Un flujo de trabajo de recuperación completado no significa que se haya corregido el fallo subyacente de la GPU. La recuperación de instancias de GPU utiliza reglas de recuperación para evitar bucles de reinicio inmediato. Una vez que el resultado de estado de la GPU deja de informar el fallo, un resultado de estado de la GPU posterior que informe un nuevo fallo puede hacer que el nodo sea elegible para otra reparación.

Antes de configurar la reparación de eventos de mantenimiento, identifique los nodos de trabajador de GPU con hardware dedicado elegibles y confirme que las cargas de trabajo en los nodos seleccionados se puedan interrumpir. La reparación de eventos de mantenimiento puede acordonar y drenar un nodo afectado antes de que OKE realice la acción de cálculo correspondiente.

La reparación de eventos de mantenimiento está soportada para nodos de trabajador de GPU con hardware dedicado elegibles, incluidos los nodos gestionados y los nodos autogestionados. El cluster debe ser un cluster mejorado y debe ejecutar Kubernetes versión 1.32 o posterior. La reparación de eventos de mantenimiento no se aplica a nodos virtuales ni nodos de trabajador que no sean de hardware dedicado.

La reparación de eventos de mantenimiento utiliza la supervisión de estado de GPU para identificar fallos de GPU o RDMA locales de nodo en unidades de GPU. OKE correlaciona la señal de fallo local con un evento de mantenimiento de OCI Compute para la misma instancia de Compute. Si el nodo está seleccionado exactamente por un recurso NodeRepairConfig coincidente y la política de reparación permite la reparación, OKE coordina el flujo de trabajo de reparación.

Antes de configurar la reparación de eventos de mantenimiento, cree las políticas de IAM necesarias para que el complemento GPU Health Monitoring controle los hosts de 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>

donde:

• <dg-name> es el nombre del grupo dinámico que incluye las instancias informáticas para los nodos de trabajador de GPU. Por ejemplo, mediante una regla como ALL {instance.compartment.id = '<compartment-ocid>'}. Al aplicar etiquetas a pools de nodos, puede crear reglas más restrictivas, como:

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

  Para obtener más información, consulte Aplicación de etiquetas a pools de nodos.

• <compartment-ocid> es el OCID del compartimento que contiene los nodos de trabajador de GPU.

Cree también una política que permita a la entidad de recurso de cluster de OKE utilizar eventos de mantenimiento de instancias en el compartimento que contiene las instancias de nodo de trabajador de GPU y sus eventos de mantenimiento:

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

Para restringir el acceso a un cluster específico, utilice una política como:

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

donde:

• <worker-compartment-ocid> es el OCID del compartimento que contiene las instancias de nodo de trabajador de GPU y sus eventos de mantenimiento.
• <cluster-ocid> es el OCID del cluster.

La reparación de eventos de mantenimiento admite las siguientes acciones de eventos de mantenimiento de Compute:

• STOP: OKE coordina un evento de mantenimiento que no termina. Se espera que la misma instancia informática y el mismo nodo de Kubernetes vuelvan al servicio después de procesar el evento de mantenimiento.
• TERMINATE: OKE coordina la terminación de la instancia informática afectada. Para los pools de nodos gestionados, la sustitución depende de la gestión de la capacidad de los pools de nodos gestionados y de la capacidad de GPU disponible. En el caso de los nodos autogestionados, OKE no sustituye automáticamente el nodo después de la terminación. Aprovisione y una un nodo de sustitución mediante el proceso de gestión de nodos que normalmente se utiliza para los nodos autogestionados (consulte Trabajar con nodos autogestionados).

El plugin Compute RDMA GPU Monitoring necesita la versión 1.64.0 o posterior del agente de Oracle Cloud y debe instalarse en los nodos seleccionados.

Cuando OKE admite una solicitud de reparación de eventos de mantenimiento, coordina las siguientes acciones:

1. Garantiza que solo se procese una solicitud de reparación a la vez.
2. Correlación de la señal de fallo de GPU o RDMA local con un evento de mantenimiento de Compute para la misma instancia.
3. Registra la información de reparación en NodeHealthReport.
4. Conecta el nodo para que Kubernetes no programe nuevos pods en él.
5. Intenta vaciar cargas de trabajo del nodo.
6. Realiza el flujo de trabajo del evento de mantenimiento STOP o TERMINATE aplicable.

Para configurar la reparación de eventos de mantenimiento:

1. Verifique que el cluster sea un cluster mejorado y que esté ejecutando Kubernetes versión 1.32 o posterior. Verifique que el nodo sea un nodo de trabajador de GPU con hardware dedicado elegible, ya sea un nodo gestionado o un nodo autogestionado.

   Verifique que el controlador de reparación de nodos gestionado por OKE y las CRD NodeHealthReport estén instaladas en el cluster y verifique que el complemento de supervisión del estado de la GPU esté disponible para el cluster. Si falta algún recurso gestionado por OKE, póngase en contacto con los Servicios de Soporte Oracle. No vuelva a crear los recursos gestionados por OKE.

2. Instale y configure el complemento Supervisión de estado de GPU para los nodos de trabajador de GPU seleccionados.

   La reparación de eventos de mantenimiento requiere que se active la supervisión de estado de GPU en los nodos de trabajador de GPU seleccionados para que OKE pueda correlacionar una señal de fallo de GPU o RDMA local con un evento de mantenimiento de Compute.

   Verifique que el complemento GPU Health Monitoring tenga una opción ACTIVE para la versión de Kubernetes que se ejecuta en el cluster introduciendo:

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

   Instale el complemento de supervisión del estado de la GPU gestionado por OKE escribiendo:

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

   Cree un recurso GpuHealthMonitoringConfig para activar la supervisión del estado de la GPU para los nodos de trabajador de la GPU seleccionados. La configuración requiere spec.enabled y un selector de nodos que no esté vacío.

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

   Guarde la configuración como gpu-health-monitoring.yaml y aplíquela introduciendo:

   kubectl apply -f gpu-health-monitoring.yaml

   El campo spec.enabled activa o desactiva la supervisión de los nodos seleccionados. El campo spec.nodeSelector selecciona los nodos de GPU en los que se ejecutan el plugin Compute RDMA GPU Monitoring y el supervisor de fallos de GPU.

   Evite crear varios recursos GpuHealthMonitoringConfig activados cuyos selectores coincidan con el mismo nodo. Las políticas superpuestas se rechazan con una condición Ready que tiene status definido en False y reason definido en MultipleMatchingPolicies.

   Verifique la configuración de supervisión del estado de la GPU en los nodos seleccionados. El controlador publica la condición de nodo oci.oraclecloud.com/GpuHealthMonitoringConfigured. El supervisor de fallos de GPU publica la condición de nodo oci.oraclecloud.com/GpuHealthMonitoringUnavailable.

3. Cree un recurso personalizado NodeRepairConfig de ámbito de cluster no solapado en modo de ejecución simulada.

   Seleccione nodos mediante una etiqueta duradera que gestione y que esté presente en los nodos de trabajador de GPU previstos. Para los pools de nodos gestionados, configure la etiqueta en el pool de nodos para que los nodos de sustitución la retengan. Para los nodos autogestionados, asegúrese de que la etiqueta se aplique de manera coherente a los nodos previstos.

   Un nodo debe coincidir exactamente con un recurso NodeRepairConfig. Las solicitudes sin configuración coincidente o con configuraciones superpuestas se rechazan sin efectos secundarios de reparación. No cree configuraciones superpuestas para la reparación iniciada por el usuario, la recuperación de instancias de GPU y la reparación de eventos de mantenimiento.

   El siguiente ejemplo comienza en modo de ejecución en seco, permite una reparación a la vez, establece el umbral de nodo no saludable en un 10%, utiliza un período de gracia de drenaje de 60 minutos y desactiva el comportamiento de fuerza después de la gracia:

   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

   En la sección policy, dryRun, forceActionAfterGracePeriod y pauseBeforeRepair son valores booleanos. evictionGracePeriodMinutes es un entero no negativo. maximumParallelNodeRepairs es un entero positivo. maxUnhealthyNodeThreshold acepta un recuento de nodos positivo o un porcentaje entrecomillado, como "10%".

   Comience con dryRun: true y pauseBeforeRepair: true. Si se define pauseBeforeRepair en true, podrá inspeccionar la reparación seleccionada antes de que OKE inicie las acciones de interrupción. La pausa también se aplica durante la ejecución en seco. Cuando pauseBeforeRepair está definido en true, debe continuar la simulación en pausa antes de que se pueda completar.

4. Verifique el comportamiento de ejecución simulada.

   En el modo de ejecución simulada, OKE evalúa el nodo seleccionado, la política de reparación coincidente, el evento de mantenimiento correlacionado y la acción de evento de mantenimiento propuesto. El modo de ejecución en seco no debe acordonar, drenar, detener, terminar ni reemplazar el nodo.

   Inspeccione NodeHealthReport para ver el evento de mantenimiento correlacionado y el resultado del flujo de trabajo. El OCID del evento de mantenimiento se muestra en status.signals.maintenanceEvent[].maintenanceEventId. La acción correlacionada se muestra en status.signals.maintenanceEvent[].action. El estado del ciclo de vida del evento Compute se muestra en status.signals.maintenanceEvent[].maintenanceLifecycleState.

   Para verificar el intento de reparación seleccionado, revise status.repair.selectedSignalIds, status.repair.repairAction, status.repair.dryRun, status.repair.terminalState y status.lastRepairAttempt. Una simulación de ejecución en seco exitosa registra Completed con dryRun: true. La finalización de ejecución en seco no prueba que una acción de drenaje o cálculo real se realice correctamente.

5. Active la reparación activa controlada actualizando el recurso NodeRepairConfig coincidente.

   Para la operación activa, actualice solo los campos de política deseados, como cambiar dryRun de true a false. El cambio de dryRun no reproduce un intento de reparación ya admitido. El cambio del recurso NodeRepairConfig no vuelve a evaluar una señal de evento de mantenimiento existente ni altera un intento de reparación ya admitido. La política actualizada se aplica a la siguiente señal de evento de mantenimiento distinta.

   No edite los recursos NodeHealthReport ni cambie las condiciones Node internas para forzar un reintento.

   Importante
   
   Una reparación de evento de mantenimiento activo puede vaciar las cargas de trabajo y parar o terminar la instancia informática afectada. Draining utiliza la API de expulsión de Kubernetes y respeta los presupuestos de interrupción de pod. Se omiten los pods DaemonSet y los pods estáticos. Si la opción force-after-grace está activada, el controlador de reparación de nodos no fuerza la supresión de los pods restantes, pero la acción de cálculo posterior aún puede interrumpirlos.

6. Si la reparación se pausa antes de la acción Compute, inspeccione las condiciones de nodo y NodeHealthReport. La condición de nodo oci.oraclecloud.com/NodeAutoRepairPaused=True indica una reparación en pausa.

   Para continuar con la reparación en pausa, introduzca:

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

   Para cancelar la reparación en pausa, introduzca:

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

   El controlador de reparación de nodo consume la etiqueta de respuesta y borra la condición de pausa. Cuando continúa una reparación en pausa, OKE vuelve a comprobar la política de reparación y los límites de interrupción antes de continuar.

   La cancelación de una reparación en pausa solo detiene el intento de reparación de OKE. No cancela, reprograma ni elimina el evento de mantenimiento de Compute subyacente. OKE registra Cancelled para el intento de reparación y borra la condición de pausa y la etiqueta de respuesta. OKE sigue realizando un seguimiento del evento de mantenimiento de Compute y es posible que la condición MaintenanceEventDetected permanezca presente. La cancelación del intento de reparación de OKE no impide que Compute procese el mantenimiento según su propio programa.

7. Para una reparación de evento de mantenimiento STOP, verifique que el flujo de trabajo del evento de mantenimiento se complete y que el mismo nodo vuelva a estar en servicio.

   En una reparación correcta de STOP que no termina, el nombre Node de Kubernetes, el UID Node de Kubernetes y el OCID de la instancia informática siguen siendo los mismos.

   Confirme que NodeHealthReport registra repairAction: STOP y no es una ejecución en seco. Confirme que status.lastRepairAttempt registra result: Completed y un registro de hora completedAt. Confirme que el Node original sea Ready y programable, con identidades sin cambios.

8. Para una reparación de evento de mantenimiento TERMINATE, verifique que la reparación en directo coincide con el evento de mantenimiento y la instancia informática previstos, que la instancia original ha terminado y que se ha eliminado el Node de Kubernetes original.

   Para los pools de nodos gestionados, confirme que la capacidad de sustitución esté disponible cuando la capacidad de GPU, los límites de servicio y las cuotas de compartimento permitan la sustitución. Para los nodos autogestionados, aprovisione y únase a un nodo de sustitución mediante el proceso de gestión de nodos que normalmente se utiliza para los nodos autogestionados (consulte Trabajo con nodos autogestionados).

   Un resultado Completed indica que OKE completó el flujo de trabajo de terminación. No confirma que la reparación del host físico se haya completado, que la capacidad de sustitución esté lista o que las cargas de trabajo se hayan recuperado.

Un flujo de trabajo de reparación de eventos de mantenimiento completado no confirma que se haya corregido el fallo subyacente de GPU o RDMA, que se haya completado la reparación del host físico, que la capacidad de sustitución esté lista o que las cargas de trabajo se hayan recuperado. Una vez completado el flujo de trabajo, verifique las señales de estado actuales del nodo, la preparación del nodo, la capacidad esperada y el estado de la aplicación.

Utilice los recursos de Kubernetes y las herramientas de supervisión de Kubernetes estándar para inspeccionar NodeHealthReport, las condiciones del nodo, las cargas de trabajo afectadas y el flujo de trabajo de reparación.

Para supervisar un flujo de trabajo de reparación de host de GPU:

1. Inspeccione el nodo de trabajador afectado y NodeHealthReport antes, durante y después de la reparación.

   Revise NodeHealthReport para ver la solicitud de reparación, el progreso de la reparación, la acción, el modo activo o de ejecución en seco y el resultado del flujo de trabajo. Revise el recurso Node de Kubernetes afectado para ver las etiquetas y condiciones de los nodos. Revise los eventos de Kubernetes para conocer la actividad reciente de reparación y nodo. Para la recuperación de instancias de GPU, compruebe las condiciones GpuHealthMonitoringConfigured, GpuHealthMonitoringUnavailable y GpuHealthMonitoringFaultDetected en el recurso Node de Kubernetes afectado. Para la reparación de eventos de mantenimiento, compruebe la señal de estado de GPU o RDMA, el evento de mantenimiento de Compute correlacionado y el estado de reparación del evento de mantenimiento registrado en NodeHealthReport.

   Tratar los recursos propiedad del controlador como de solo lectura. No cree ni edite acciones generadas ni recursos propiedad del controlador.

2. Revise el estado de reparación admitido y el estado del nodo.

   Utilice NodeHealthReport para revisar la política de reparación, el valor efectivo de ejecución en seco, el resultado de admisión, el resultado terminal y el último intento de reparación. Utilice el recurso Node de Kubernetes afectado para revisar las condiciones del nodo. Cuando corresponda, verifique el estado del ciclo de vida de la instancia de Compute, la etiqueta definida de Compute utilizada para la reparación iniciada por el usuario, los detalles del evento de mantenimiento para la reparación del evento de mantenimiento y si la capacidad de sustitución está lista.

   No se base en permisos internos, IDs de petición, rutas de archivos, intervalos de sondeo ni fases intermedias de workflow como indicadores de estado.

3. Para la reparación iniciada por el usuario, investigue las solicitudes rechazadas, la reparación diferida, la reparación fallida y la reparación sustituida.

   Se puede rechazar una solicitud cuando ningún recurso NodeRepairConfig coincide con el nodo o cuando se aplica más de una configuración.

   Utilice el resultado NodeHealthReport para decidir qué investigar:

   • Si NodeHealthReport muestra AdmissionRejected, verifique el recurso NodeRepairConfig, la autorización de disparadores y la configuración de etiquetas.
   • Si NodeHealthReport muestra Deferred, espere a que se borre la condición de bloqueo o ajuste la capacidad si la capacidad de sustitución no está disponible.
   • Si NodeHealthReport muestra Failed, inspeccione NodeHealthReport, Kubernetes Events, los presupuestos de interrupción del pod, la política de IAM, la etiqueta definida por Compute y el estado de la instancia de Compute.
   • Si NodeHealthReport muestra Superseded, siga el flujo de trabajo de OKE que se hizo cargo de la reparación.
   • Si NodeHealthReport muestra Completed, verifique que la instancia original se ha terminado y que la capacidad de sustitución está lista.

4. Para la recuperación de instancias de GPU, investigue la configuración de supervisión del estado de la GPU, los resultados de estado no disponibles, las señales de reinicio, las señales que requieren acción, los drenajes incompletos, los reinicios completados con un fallo continuo y las señales continuas que no disparan reinicios repetidos.

   Utilice condiciones de nodo, señales de estado de GPU y el resultado NodeHealthReport para decidir qué investigar:

   • Si la condición del nodo GpuHealthMonitoringConfigured es False o Unknown, verifique la configuración del agente de Oracle Cloud y la configuración del complemento GpuHealthMonitoring.
   • Si la condición del nodo GpuHealthMonitoringUnavailable es True, verifique que la unidad de GPU esté soportada, que Oracle Cloud Agent versión 1.64.0 o posterior esté instalada, que el plugin Compute RDMA GPU Monitoring esté activado y que el complemento GPU Health Monitoring esté instalado y configurado.
   • Si una señal de estado de GPU activa tiene action=REBOOT, supervise NodeHealthReport para el flujo de trabajo de recuperación de instancias de GPU.
   • Si una señal de estado de GPU tiene action=CUSTOMER_ACTION_REQUIRED, investigue el problema de estado de GPU informado. Esta señal no activa un reinicio automatizado.
   • Si NodeHealthReport muestra un vaciado incompleto o una reparación fallida, inspeccione los eventos de Kubernetes, los presupuestos de interrupción del pod, el estado de la carga de trabajo y las condiciones del nodo.
   • Si se completó el reinicio, pero el resultado de estado de la GPU aún informa el fallo, investigue el fallo en curso.
   • Si la misma señal continúa después del reinicio, la recuperación de la instancia de GPU no reinicia inmediatamente el nodo de nuevo. Las reglas de enfriamiento evitan los bucles de reinicio inmediato.

5. Para la reparación de eventos de mantenimiento, investigue la configuración de GPU Health Monitoring, las señales de fallo locales de GPU o RDMA, los eventos de mantenimiento de Compute correlacionados, los recursos NodeRepairConfig coincidentes, las reparaciones en pausa, los drenajes incompletos y el resultado del flujo de trabajo STOP o TERMINATE.

   Para la reparación de eventos de mantenimiento, revise las condiciones de nodo oci.oraclecloud.com/MaintenanceEventDetected y oci.oraclecloud.com/NodeAutoRepairPaused. En NodeHealthReport, revise el OCID del evento de mantenimiento, la acción, los códigos de fallo, el estado del ciclo de vida de mantenimiento, el ID de reparación, los ID de señal seleccionados, la acción de reparación, el valor de ejecución en seco, el estado de admisión, los detalles de rechazo, el estado de terminal y el último intento de reparación.

   Utilice las condiciones del nodo, la información del evento de mantenimiento y el resultado NodeHealthReport para decidir qué investigar:

   • Si un fallo local de GPU o RDMA no inicia la reparación del evento de mantenimiento, verifique GPU Health Monitoring, Oracle Cloud Agent, la unidad de nodo de trabajador de GPU y las señales de estado registradas en NodeHealthReport. Confirme que existe un evento de mantenimiento de Compute coincidente para la misma instancia.
   • Si no se admite la reparación de eventos de mantenimiento, confirme que exactamente un NodeRepairConfig seleccione el nodo y que la política de reparación y los límites de interrupción permitan la reparación. Inspeccione el resultado de admisión NodeHealthReport.
   • Si la reparación está en pausa, inspeccione las condiciones de nodo y NodeHealthReport y, a continuación, utilice el mecanismo de respuesta soportado para continuar o cancelar la reparación.
   • Si se completa una reparación de STOP pero el nodo no es programable, compruebe la preparación del nodo, el estado del cordón, el estado del ciclo de vida del evento de mantenimiento de Compute, las señales de estado actuales y los eventos de Kubernetes.
   • Si se completa una reparación de TERMINATE, pero la capacidad esperada no está disponible, compruebe la capacidad de la unidad de GPU, los límites de servicio, las cuotas de compartimento y el estado del pool de nodos. Para los nodos autogestionados, aprovisione y únase a un nodo de sustitución mediante el proceso de gestión de nodos que normalmente se utiliza para los nodos autogestionados (consulte Trabajo con nodos autogestionados).

   Los resultados de reparación relevantes de OKE incluyen Completed, Failed, Cancelled, Superseded y AdmissionRejected. Un estado Deferred representa un bloqueo temporal, no un resultado terminal. Los valores del ciclo de vida de mantenimiento de recursos informáticos son independientes de los resultados de reparación de OKE.

6. Antes de abrir una solicitud de servicio, recopile la información necesaria para investigar el flujo de trabajo de reparación.

   Incluya el OCID del arrendamiento, el OCID del cluster, la región, la versión de Kubernetes, la versión del complemento de supervisión del estado de la GPU, la versión del agente de Oracle Cloud, el nombre del nodo de trabajador afectado, el OCID de la instancia informática, los recursos NodeHealthReport y NodeRepairConfig relevantes, las etiquetas y condiciones de los nodos, los eventos de Kubernetes, el presupuesto de interrupción del pod y el estado de la carga de trabajo, los registros de hora y los resultados actuales del estado de la GPU. Para la reparación de eventos de mantenimiento, también incluya el OCID del evento de mantenimiento de Compute, la acción del evento de mantenimiento, los códigos de fallo, el estado del ciclo de vida del evento de mantenimiento y cualquier detalle de evento de mantenimiento disponible de Compute.

   No modifique los CRD propiedad de OKE, los recursos del controlador, los objetos de admisión, las acciones generadas ni los recursos de coordinación.