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

   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.

   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.
   • Pasan las barandillas de admisión y interrupción posteriores.

   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.

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.

   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 informática, la etiqueta definida por Compute que se utiliza para la reparación iniciada por el usuario 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. 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.

   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.