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 de hosts para cargas de trabajo de IA

Los nodos de GKE se ejecutan en instancias de Compute Engine que experimentan eventos de host de forma periódica, lo que puede interrumpir las cargas de trabajo de IA. Debido a que los eventos de host ocurren en la infraestructura subyacente deGoogle Cloud , omiten los períodos de mantenimiento y las exclusiones de GKE. Si bien la mayoría de las instancias de procesamiento tienen su política de mantenimiento del host configurada como migración en vivo, lo que minimiza la interrupción de las cargas de trabajo, las GPU y las TPU 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 objeto Job o Deployment, GKE intenta reiniciar los Pods en el nodo afectado.

Para obtener más información sobre cómo administrar el 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 o una posterior de GKE, puedes ver la hora de inicio programada del evento de mantenimiento del host de la siguiente manera. La hora de inicio se representa con etiquetas de nodo de Kubernetes en el nodo de GKE correspondiente para todas las GPU y TPU.

Para obtener más detalles, 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

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 programa. 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:

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 antiafinidad de nodos para minimizar las interrupciones en 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 para el futuro

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

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

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

Puedes indicarle a GKE que solo programe Pods en nodos que tengan un mantenimiento programado después de una fecha determinada proporcionando el tiempo 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 estar preparadas para la interrupción de las instancias de procesamiento subyacentes y del clúster de GKE:

Te recomendamos que mantengas tu clúster inscrito en un canal de versiones. De forma predeterminada, los clústeres de GKE se inscriben 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 los clústeres inscritos y no inscritos en un canal de versiones.

Con los canales de versiones, obtienes acceso a más funciones, incluidos ámbitos de exclusión de mantenimiento adicionales. Recomendamos el permiso "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, a través de GKE, puedes informar 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 (versión preliminar), comunícate con tu equipo de cuentas.

Si observas errores de memoria de GPU o Xid en un nodo y deseas verificar si las medidas de recuperación manual, como activar un reinicio del SO invitado (kubectl label nodes <NODE_NAME> cloud.google.com/perform-reboot=true), pueden resolver el problema antes de informar que el host tiene errores, consulta Revisa los mensajes de Xid.

Un host es una sola máquina de servidor físico en el centro de datos que ejecuta una instancia de procesamiento que aloja tu nodo de GKE. Para informar sobre hosts defectuosos, aplica 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 correcta.
  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 se vuelva a activar en una máquina host en buen estado. En el caso de las reservas que usan el modo operativo de reserva de capacidad total, Compute Engine recupera 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 de GKE 1.32.3-gke.1057001 o una posterior.
  • Debes ejecutar uno de los siguientes tipos de máquinas de GPU: A4X Max, A4X, A4, A3 Ultra, A3 Mega y A3 High (8 GPU).
  • Debes ejecutar tus nodos de GKE en una instancia de procesamiento que esté vinculada a una 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 devolverá 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 y por mes según una evaluación del estado de tus bloques. Los límites de frecuencia no se aplican si tu reserva usa el modo operativo de reserva de capacidad total.

Cómo informar un host defectuoso

Para informar un host defectuoso, sigue estos pasos:

  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 archivo NODE_NAME.

  2. Informa que el nodo tiene fallas con el siguiente comando. Puedes proporcionar un motivo y, con las versiones posteriores, una descripción:

      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 error adecuado con uno o más de los siguientes valores:
      • PERFORMANCE: Usa este valor si las GPU de una instancia de procesamiento tienen un rendimiento más lento que otras GPU del clúster y no ves ningún error de XID en los registros, y no se detecta ninguno de los otros patrones de falla habituales, como la corrupción de datos silenciosa.
      • SDC: Usa este valor para la corrupción silenciosa de datos, si ves corrupción de datos, pero no una falla del sistema. Esta corrupción de datos puede deberse a defectos de la CPU, errores de software, como el uso después de liberar o el pisoteo de memoria, problemas del kernel o algún otro defecto. En la mayoría de los casos, este término se usa para referirse a defectos inducidos por el 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 tienes certeza de qué comportamiento está causando 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 de XID, los síntomas o las marcas de tiempo. Esta descripción se reenvía a Compute Engine para ayudar con el diagnóstico 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 del 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 el equido de Atención al cliente de Cloud para proporcionar detalles de la falla.
Después de informar un host defectuoso para un nodo, el tiempo en el que se reinicia el nodo varía según el modo operativo de la reserva que se especifica en la reserva que usa el nodo. Para verificar el modo operativo 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 de capacidad total 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 (8 GPUs)
Límite de frecuencia de la API de informes de hosts defectuosos No se aplican límites de frecuencia. Es posible que las llamadas a la API tengan un límite de frecuencia.
Proceso de informe de host defectuoso

Cuando informas un host defectuoso para un nodo que se ejecuta en el modo All Capacity, ocurre lo siguiente:

  1. 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 desalojar de forma correcta los Pods en ejecución en el nodo. GKE respeta los presupuestos de interrupción de Pods (PDB) y el campo spec.terminationGracePeriodSeconds de los manifiestos de tus Pods. Para obtener más información, consulta Configura GKE para finalizar tus cargas de trabajo de forma ordenada.
  2. Informa y repara el host defectuoso: GKE llama a la API de Compute Engine para informar y reparar el host defectuoso. Esta secuencia de operaciones suele tardar entre 10 y 12 minutos en informar el host defectuoso y de 3 a 14 días, o incluso más, en repararlo.

  3. Reiniciar el nodo: Después de que se completa la operación de reparación del host, ocurre una de las siguientes situaciones:

    • Si el nodo está en el estado REPAIRING y los recursos están disponibles cuando se completa la reparación, Compute Engine reinicia automáticamente el nodo en el host reparado.
    • De lo contrario, si el nodo está en el estado TERMINATED o si los recursos no están disponibles cuando se completa la reparación, el estado del nodo permanece en TERMINATED o cambia a ese estado. Debes reiniciar el nodo de forma manual cuando quieras que se ejecute. Sin embargo, si los recursos no están disponibles cuando reinicias el nodo (por ejemplo, si otras instancias de procesamiento ya están usando el host reparado), es posible que el reinicio falle.

Cuando informas un host defectuoso para un nodo que se ejecuta en modo administrado, sucede lo siguiente:

  1. 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 correcta los Pods en ejecución en el nodo. GKE respeta los presupuestos de interrupción de Pods (PDB) y el campo spec.terminationGracePeriodSeconds de los manifiestos de tus Pods. Para obtener más información, consulta Configura GKE para finalizar tus cargas de trabajo de forma ordenada.

  2. Informa y comienza a reparar el host defectuoso: GKE llama a la API de Compute Engine para informar y reparar el host defectuoso. Esta secuencia de operaciones suele tardar entre 10 y 12 minutos en informar el host defectuoso.

    El comportamiento del nodo cuando se inicia la operación de reparación del host varía según la serie de máquinas:

    • A4 y A3 Ultra: GKE intenta migrar en vivo el nodo a un host diferente. Si no tienes suficiente capacidad reservada o la capacidad no está disponible en la zona del nodo, este se detiene.
    • A3 Mega y A3 High: GKE detiene el nodo y lo reinicia en un host en buen estado.

    La reparación del host defectuoso original puede tardar entre 3 y 14 días, o incluso más en ocasiones.

  3. Migra o reinicia el nodo: Después de que se inicia la operación de reparación del host, Compute Engine intenta reservar un host en buen estado para reemplazar el host defectuoso informado en tu capacidad reservada. Si Compute Engine encuentra un host de reemplazo, sucede lo siguiente:

    • A4 y A3 Ultra: Si el nodo se migró en vivo en el paso anterior, seguirá ejecutándose en el host de reemplazo. Si el nodo se detuvo, se reinicia en el host de reemplazo.
    • A3 Mega y A3 High: El nodo se reinicia en el host de reemplazo.

    Si Compute Engine no puede encontrar un host de reemplazo de inmediato, el nodo se reinicia de la siguiente manera:

    • Si el nodo está en el estado REPAIRING y los recursos están disponibles antes o cuando se completa la reparación, Compute Engine reinicia automáticamente el nodo en un host en buen estado.
    • De lo contrario, si el nodo está en el estado TERMINATED o si los recursos no están disponibles antes o cuando se completa la reparación, el estado del nodo permanece en TERMINATED o cambia a ese estado. Debes reiniciar el nodo de forma manual cuando quieras que se ejecute.

    A diferencia del modo All Capacity, no es necesario que esperes a que se repare el host defectuoso original para que se reanude la carga de trabajo.

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 Pods del nodo afectado.
  • OperationRUNNING: Se está ejecutando la operación para informar el host con errores.
  • OperationDONE: Se informó que el host subyacente tiene fallas y el nodo de GKE está listo para trasladarse a un host nuevo.
  • OperationFAILED: La API en la instancia de procesamiento falló debido a límites de cuota u otros problemas de infraestructura. Para comprender el error, consulta Soluciona problemas de errores de la API de informe de host defectuoso. 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 node.gke.io/report-and-replace-operation para ver el ID de la operación de Compute Engine y supervisar el estado de la operación.

Puedes ver estas dos etiquetas de nodo con el siguiente comando:

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

Si se produce un error de la API, GKE establece la etiqueta de nodo cloud.google.com/report-and-replace-status en Error. Si se produce un error 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 o posterior, o 1.36.0-gke.4060000 o posterior, GKE aplica un reproche 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 Cómo controlar 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 informe y reemplazo

Cuando falla una operación de informe y reemplazo, GKE aplica el reproche 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 puede tener fallas.

Verifica la taint de falla

Para verificar si un nodo tiene la tacha de falla de informar y reemplazar, ejecuta el siguiente comando:

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

Cómo recuperarse 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 aplicando de nuevo 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 la tacha de forma manual si determinaste que el nodo está en buen estado o si quieres volver a ponerlo en servicio:

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

¿Qué sigue?