Administra clústeres de GKE optimizados para IA

En esta página, se muestra cómo administrar clústeres de Google Kubernetes Engine (GKE) optimizados para IA de máquinas A4X Max, A4X, A4, A3 Ultra, A3 Mega y A3 High (8 GPUs), incluidos los siguientes eventos comunes relevantes para los clústeres de GKE y las cargas de trabajo de IA:

• Mantenimiento de host
• Actualizaciones de clústeres
• Informes de hosts defectuosos

Administra el mantenimiento del host para cargas de trabajo de IA

Los nodos de GKE se ejecutan en instancias de Compute Engine que periódicamente experimentan eventos de host que pueden interrumpir las cargas de trabajo de IA. Como los eventos de host ocurren en la infraestructura subyacente Google Cloud , omiten los períodos y las exclusiones de mantenimiento de GKE . Si bien la mayoría de las instancias de procesamiento tienen su política de mantenimiento del host establecida en migración en vivo, lo que minimiza la interrupción de las cargas de trabajo, las GPUs y las TPUs no admiten la migración en vivo. Cuando estos eventos de host afectan a tus nodos de GKE que ejecutan cargas de trabajo de IA, GKE debe finalizar el nodo y los Pods que se ejecutan en él. Si los Pods se implementan como parte de una carga de trabajo más grande, como un trabajo o una implementación, GKE intenta reiniciar los Pods en el nodo afectado.

Para obtener más información sobre la administración del mantenimiento del host de las instancias de procesamiento subyacentes, consulta Administra la interrupción de nodos de GKE para GPU y TPU.

Supervisa los eventos de mantenimiento del host

En el caso de los clústeres que ejecutan la versión 1.31.1-gke.2008000 de GKE o una posterior, puedes ver la hora de inicio programada del evento de mantenimiento del host de la siguiente manera. La hora de inicio está representada por las etiquetas de nodo de Kubernetes en el nodo de GKE correspondiente para todas las GPUs y TPUs.

Para obtener más información, consulta Supervisa las notificaciones de mantenimiento.

Con estas etiquetas de nodo, puedes hacer lo siguiente:

• Inicia un evento de mantenimiento del host de forma manual.
• Usa la información del evento de mantenimiento del host mientras programas tus cargas de trabajo.

Inicia un evento de mantenimiento del host de forma manual.

Después de que Compute Engine emite una notificación sobre un evento de mantenimiento programado, puedes iniciar el mantenimiento de forma manual en un momento que se alinee con tu programación. Por ejemplo, puedes elegir realizar el mantenimiento durante períodos de actividad reducida.

Si no inicias un evento de mantenimiento del host de forma manual, Compute Engine completará automáticamente el mantenimiento programado con regularidad.

Sigue las instrucciones para iniciar un evento de mantenimiento del host de forma manual. Además, sigue leyendo esta sección para obtener más información sobre lo siguiente:

• Configura GKE para finalizar tus cargas de trabajo de forma ordenada
• Proceso de finalización ordenada
• Supervisa el progreso de una finalización ordenada activa

Usa la información de mantenimiento del host mientras programas tus cargas de trabajo

Puedes usar la información de mantenimiento que se muestra a través de las etiquetas de nodo de GKE junto con la afinidad y la antiafinidad de nodos para minimizar la interrupción de tus cargas de trabajo.

Consulta las siguientes secciones para ver ejemplos de cómo usar esta información.

Programa Pods en nodos que no tengan eventos de mantenimiento programados en el futuro

Puedes indicarle a GKE que solo programe Pods en nodos que no tengan eventos de mantenimiento programados en el futuro, como con el siguiente fragmento:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: DoesNotExist

Programa Pods en nodos que tengan mantenimiento programado después de una fecha determinada

Puedes indicarle a GKE que solo programe Pods en nodos que tengan mantenimiento programado después de una fecha determinada si proporcionas la hora de la época de Unix:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: Gt
            values:
            - 1733296000

Administra las actualizaciones de clúster de GKE para cargas de trabajo de IA

Las cargas de trabajo de IA son sensibles a las interrupciones.

Durante el ciclo de vida de un clúster de GKE, las cargas de trabajo de IA deben prepararse para la interrupción de las instancias de procesamiento subyacentes, así como del clúster de GKE en sí:

• Mantenimiento de host: Para administrar el mantenimiento del host de las instancias de procesamiento subyacentes, consulta Administra la interrupción de nodos de GKE para GPU y TPU. Esto también se describe en las secciones anteriores.
• Actualizaciones de clústeres: Para administrar la interrupción de las actualizaciones de clústeres, puedes usar las siguientes herramientas:
  • Períodos de mantenimiento: Programa cuándo GKE puede realizar actualizaciones de clústeres y otros tipos de operaciones de clústeres.
  • Exclusiones de mantenimiento: Evita las actualizaciones de clústeres y otros tipos de operaciones de clústeres durante un período específico.

Te recomendamos que mantengas tu clúster inscrito en un canal de versiones. De forma predeterminada, los clústeres de GKE están inscritos en el canal de versiones Regular. Para obtener más información sobre los beneficios de los canales de versiones, consulta la Comparación entre clústeres inscritos y no inscritos en un canal de versiones.

Con los canales de versiones, obtienes acceso a más funciones, incluidos los alcances de exclusión de mantenimiento adicionales maintenance exclusion scopes. Recomendamos el alcance "Sin actualizaciones secundarias ni de nodos" para las cargas de trabajo de IA.

Informa hosts defectuosos a través de GKE

En esta sección, se describe cómo puedes informar, a través de GKE, un host defectuoso que tiene instancias de procesamiento aprovisionadas con el modelo de aprovisionamiento vinculado a la reserva. Si deseas informar un host defectuoso para un nodo que se aprovisionó con el modelo de aprovisionamiento de inicio flexible (vista previa), entonces comunícate con tu equipo de cuentas.

Precaución: Informar un host defectuoso es una acción desestabilizadora que detiene tu VM. Antes de informar un host, investiga minuciosamente tu entorno con herramientas como el analizador de estado del clúster (CHS) para identificar la causa raíz del problema. Solo informa el host como defectuoso si no tienes alternativas para resolver el problema.

Un host es una sola máquina de servidor física en el centro de datos que ejecuta una instancia de procesamiento que aloja tu nodo de GKE. Puedes informar hosts defectuosos si aplicas una etiqueta de nodo fault-behavior al nodo de GKE afectado. Después de aplicar la etiqueta de nodo a un nodo de GKE en particular, GKE realiza los siguientes pasos:

1. Expulsa las cargas de trabajo del nodo de forma ordenada.
2. Evita que se programen Pods nuevos en el nodo.
3. Llama a la API en la instancia de procesamiento para marcar el host como defectuoso.
4. Espera a que la instancia de procesamiento vuelva a estar en funcionamiento en una máquina host en buen estado. En el caso de las reservas que usan el modo operativo de reserva All Capacity, Compute Engine vuelve a colocar la instancia de procesamiento en el mismo nodo después de que se completa la operación de reparación.
5. Quita el taint y la etiqueta fault-behavior del nodo.

Después de esto, el nodo estará listo para volver a entregar cargas de trabajo.

Requisitos

Para informar un host defectuoso, tu nodo de GKE debe cumplir con los siguientes requisitos:

• Debes ejecutar la versión del parche 1.32.3-gke.1057001 de GKE o una posterior.
• Debes ejecutar uno de los siguientes tipos de máquinas con GPU: A4X Max, A4X, A4, A3 Ultra, A3 Mega y A3 High (8 GPUs).
• Debes ejecutar tus nodos de GKE en una instancia de procesamiento que esté vinculada a la reserva.
• Tu nodo de GKE debe estar en estado RUNNING. Si intentas informar un host defectuoso después de borrar la instancia de procesamiento, se muestra un mensaje de error y la máquina anfitrión no se marcará como defectuosa.
• Es posible que se limite la cantidad de llamadas a esta API por reserva por mes en función de una evaluación del estado de tus bloques. Los límites de frecuencia no se aplican si tu reserva usa el modo operativo de reservaAll Capacity.

Cómo informar un host defectuoso

Nota: Los datos del SSD local se borrarán cuando se invoque correctamente la API, ya que la instancia de procesamiento mueve los hosts. Te recomendamos que hagas una copia de seguridad de los datos del SSD local antes de informar un nodo defectuoso a través de GKE.

Para informar un host defectuoso, haz lo siguiente:

1. Usa las herramientas de observabilidad de GKE, tus propias herramientas de supervisión o los registros para identificar los nodos de GKE que tienen problemas de rendimiento. Guarda el NODE_NAME.

2. Informa el nodo como defectuoso con el siguiente comando. Puedes proporcionar un motivo y, con versiones posteriores, una descripción:

   Importante: Después de informar un host como defectuoso, no envíes solicitudes adicionales hasta que se complete la operación. GKE rechaza las solicitudes adicionales mientras la operación está en curso.

     kubectl patch node NODE_NAME --type merge -p '{
       "metadata": {
         "labels": {
           "cloud.google.com/fault-behavior": "FAULT_REASON"
         },
         "annotations": {
           "cloud.google.com/fault-description": "FAULT_DESCRIPTION"
         }
       }
     }'
   

   Modifica el comando de la siguiente manera:

   • Reemplaza NODE_NAME por el nombre del nodo defectuoso.
   • Reemplaza FAULT_REASON por el motivo de falla adecuado con uno o más de los siguientes valores:
     • PERFORMANCE: Usa este valor si las GPUs de una instancia de procesamiento funcionan más lento que otras GPUs del clúster y no ves ningún error XID en los registros, y no se detecta ninguno de los otros patrones de falla habituales, como la corrupción silenciosa de datos.
     • SDC: Usa este valor para la corrupción silenciosa de datos si ves corrupción de datos, pero no falla del sistema. Esta corrupción de datos puede deberse a defectos de la CPU, errores de software, como el uso después de la liberación o el pisoteo de la memoria, problemas del kernel o cualquier otro defecto. Por lo general, este término se usa para hacer referencia a defectos inducidos por hardware.
     • XID: Usa este valor si identificaste un error de GPU irrecuperable con un XID para una instancia de procesamiento.
     • unspecified: Usa este valor si no estás seguro de qué comportamiento causa el problema con tu instancia de procesamiento. Este es el valor predeterminado. Sin embargo, te recomendamos que especifiques uno de los otros valores, si corresponde.
   • Ajusta el bloque annotations según la versión del plano de control de tu clúster de GKE:
     • 1.35.6-gke.1017000 o posterior, o 1.36.0-gke.3251000 o posterior: Conserva el bloque de anotaciones y reemplaza FAULT_DESCRIPTION por una descripción de texto de la falla observada. Esto puede incluir el código de error XID, los síntomas o las marcas de tiempo. Esta descripción se reenvía a Compute Engine para ayudar con los diagnósticos de reparación y se quita automáticamente del nodo después de que se completa la operación. Por ejemplo: GPU XID 48 observed on device nvidia0 at 2026-06-10T10:30:00Z.
     • Versiones anteriores: Quita todo el bloque annotations de el comando. El campo fault-description no se reenvía a Compute Engine en estas versiones y no se quita automáticamente del nodo. En su lugar, comunícate con tu equipo de cuentas o con Atención al cliente de Cloud para proporcionar detalles de la falla.

Después de informar un host defectuoso para un nodo, el momento en que se reinicia el nodo varía según el modo operativo de reserva que se especifica en la reserva que usa el nodo. Para verificar el modo operativo de reserva de una reserva, consulta el campo reservationOperationalMode en la reserva. En la siguiente tabla, se resume el proceso de host defectuoso para los dos modos operativos de reserva disponibles: modo All Capacity y modo administrado.

	Modo All Capacity (ALL_CAPACITY)	Modo administrado (HIGHLY_AVAILABLE_CAPACITY)
Tipos de máquina admitidos	A4X Max y A4X	A4, A3 Ultra, A3 Mega y A3 High
Límite de frecuencia de la API de informes de hosts defectuosos	No se aplican límites de frecuencia.	Es posible que se limite la frecuencia de las llamadas a la API.
Proceso de informe de host defectuoso	Cuando informas un host defectuoso para un nodo que se ejecuta en el modo All Capacity, sucede lo siguiente: Expulsa Pods: Después de que se aplica la etiqueta al nodo defectuoso, GKE aplica un taint al nodo para bloquear la programación de Pods nuevos. GKE también comienza a expulsar de forma ordenada los Pods en ejecución en el nodo. GKE respects the Pod Disruption Budgets (PDBs) and the spec.terminationGracePeriodSeconds field of your Pod manifests. Para obtener más detalles, consulta Configura GKE para finalizar tus cargas de trabajo de forma ordenada. Informa y repara el host defectuoso: GKE informa automáticamente y repara el host defectuoso llamando a la API de Compute Engine, lo que genera una secuencia de operaciones que suele tardar entre 10 y 12 minutos en informar el host defectuoso y, luego, puede tardar entre 3 y 14 días, o incluso más, en reparar el host. Reinicia la instancia: Después de que se completa la operación de reparación del host (por lo general, entre 3 y 14 días), sucede una de las siguientes acciones: Si la instancia está en estado REPAIRING y los recursos están disponibles cuando se completa la reparación, Compute Engine reinicia automáticamente la instancia en el host reparado. De lo contrario, si la instancia está en estado TERMINATED o si los recursos no están disponibles cuando se completa la reparación, el estado de la instancia permanece en TERMINATED o cambia a ese estado. Debes reiniciar la instancia de forma manual cuando quieras que se ejecute. Sin embargo, es posible que no se pueda reiniciar la instancia si los recursos no están disponibles cuando la reinicias. Por ejemplo, esto puede suceder si otras instancias ya usan el host reparado.	Cuando informas un host defectuoso para un nodo que se ejecuta en el modo administrado, sucede lo siguiente: Expulsa Pods: Después de que se aplica la etiqueta al nodo defectuoso, GKE aplica un taint al nodo para bloquear la programación de Pods nuevos. GKE también comienza a expulsar de forma ordenada los Pods en ejecución en el nodo. GKE respects the Pod Disruption Budgets (PDBs) and the spec.terminationGracePeriodSeconds field of your Pod manifests. Para obtener más detalles, consulta Configura GKE para finalizar tus cargas de trabajo de forma ordenada. Informa y comienza a reparar el host defectuoso: GKE informa y repara automáticamente el host defectuoso llamando a la API de Compute Engine, lo que genera una secuencia de operaciones que suele tardar entre 10 y 12 minutos en informar el host defectuoso y, luego, puede tardar entre 3 y 14 días, o incluso más, en reparar el host. Migra y reinicia la instancia: Después de que comienza la operación de reparación del host (por lo general, entre 10 y 12 minutos), Compute Engine intenta reservar un host más para reemplazar el host defectuoso informado en tu capacidad reservada. Si Compute Engine encuentra un host en buen estado (si reemplaza correctamente el host defectuoso o encuentra un host en buen estado coincidente en tu capacidad reservada), Compute Engine migra la instancia a ese host. Luego, el reinicio de la instancia se realiza a través de una de las siguientes opciones: Si la instancia está en estado REPAIRING y los recursos están disponibles antes o cuando se completa la reparación, Compute Engine reinicia automáticamente la instancia en un host en buen estado. De lo contrario, si la instancia está en estado TERMINATED o si los recursos no están disponibles antes o cuando se completa la reparación, el estado de la instancia permanece en TERMINATED o cambia a ese estado. Debes reiniciar la instancia de forma manual cuando quieras que se ejecute. Sin embargo, es posible que no se pueda reiniciar la instancia si los recursos no están disponibles cuando la reinicias. Por ejemplo, esto puede suceder si otras instancias ya usan el host reparado.

Supervisa el progreso de la operación

Puedes supervisar el progreso de la operación de GKE con la etiqueta de nodo cloud.google.com/report-and-replace-status en tu nodo de GKE, que tiene uno de los siguientes valores:

• PodsEvicted: GKE terminó de expulsar los Pods del nodo afectado.
• OperationRUNNING: Se está ejecutando la operación para informar el host defectuoso.
• OperationDONE: Se informó que el host subyacente está defectuoso y el nodo de GKE está listo para moverse a un host nuevo.
• OperationFAILED: La API de la instancia de procesamiento falló debido a los límites de cuota o a otros problemas de infraestructura. Para comprender el error, consulta Soluciona problemas de errores de la API de informes de hosts defectuosos. Para obtener información sobre cómo recuperarte, consulta Controla las fallas de informes y reemplazos.
• Error: La llamada a la API falló porque la solicitud no cumplió con uno de los requisitos descritos en la sección anterior.

También puedes ver la etiqueta de nodo cloud.google.com/report-and-replace-operation para ver el ID de operación de Compute Engine y supervisar el estado de la operación.

Puedes ver ambas etiquetas de nodo con el siguiente comando:

  kubectl get nodes NODE_NAME \
  -L cloud.google.com/report-and-replace-status,cloud.google.com/report-and-replace-operation

Si se produce un error de API, GKE establece la etiqueta de nodo cloud.google.com/report-and-replace-status en Error. Si se produce una falla en la operación, GKE establece la etiqueta en OperationFAILED. En ambos casos, GKE quita la etiqueta de nodo cloud.google.com/fault-behavior. Además, en la versión 1.35.6-gke.1256000 de GKE o posterior, o en la versión 1.36.0-gke.4060000 o posterior, GKE aplica un taint cloud.google.com/report-and-replace-failed:NoSchedule al nodo. Este taint evita que se programen Pods nuevos en el nodo, lo que garantiza que las cargas de trabajo no se coloquen en un nodo con un host potencialmente defectuoso. Para obtener más información, consulta Controla las fallas de informes y reemplazos.

Para obtener información sobre cómo hacer un seguimiento del estado detallado de una operación de informe de host defectuoso, consulta Revisa las operaciones de informe de host defectuoso.

Controla las fallas de informes y reemplazos

Cuando falla una operación de informe y reemplazo, GKE aplica el taint cloud.google.com/report-and-replace-failed:NoSchedule al nodo afectado. Este taint mantiene el nodo acordonado para que no se programen cargas de trabajo nuevas en él mientras el host subyacente aún pueda estar defectuoso.

Verifica el taint de falla

Para verificar si un nodo tiene el taint de falla de informe y reemplazo, ejecuta el siguiente comando:

  kubectl describe node NODE_NAME | grep "report-and-replace-failed"

Recupérate de una falla de informe y reemplazo

Para recuperarte de una falla de informe y reemplazo, realiza una de las siguientes acciones:

• Vuelve a intentar la operación si vuelves a aplicar la etiqueta cloud.google.com/fault-behavior al nodo. Si el reintento se realiza correctamente, GKE quita automáticamente el taint cloud.google.com/report-and-replace-failed:NoSchedule:

    kubectl label node NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON
  

• Quita el taint de forma manual si determinaste que el nodo está en buen estado o si deseas volver a ponerlo en servicio:

    kubectl taint nodes NODE_NAME cloud.google.com/report-and-replace-failed:NoSchedule-
  

¿Qué sigue?

• Obtén información para programar cargas de trabajo de GKE con la programación consciente de la topología.

• Obtén información para optimizar las redes de clústeres con NCCL/gIB.

• Obtén información para solucionar problemas de errores de la API de informes de hosts defectuosos.