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
  • Cómo informar un host defectuoso

Administra el mantenimiento del host para las cargas de trabajo de IA

Los nodos de GKE se ejecutan en instancias de Compute Engine que experimentan periódicamente eventos del host que pueden interrumpir las cargas de trabajo de IA. Dado que los eventos del host ocurren en la infraestructura subyacente deGoogle Cloud , omiten las exclusiones y los períodos 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 GPU y las TPU no admiten la migración en vivo. Cuando estos eventos del 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 Job o una Deployment, GKE intentará 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 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 se representa con etiquetas de nodos de Kubernetes en el nodo de GKE correspondiente para todas las GPU y TPU.

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

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 cronograma. Por ejemplo, puedes optar por realizar el mantenimiento durante los períodos de menor actividad.

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 aprender lo siguiente:

Usa la información de mantenimiento del host cuando programes 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 anti-afinidad 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 futuros

Puedes indicarle a GKE que solo programe Pods en nodos que no tengan eventos de mantenimiento programados futuros, 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 programado un mantenimiento 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. Para ello, proporciona la hora de Unix en formato de época:

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 las interrupciones tanto en las instancias de procesamiento subyacentes como en el propio 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 los que no están inscritos en un canal de versiones.

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

Cómo informar hosts defectuosos a través de GKE

En esta sección, se describe cómo, a través de GKE, puedes informar sobre 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), comunícate con tu equipo de cuentas.

Un host es un solo servidor físico en el centro de datos que ejecuta una instancia de procesamiento que aloja tu nodo de GKE. Puedes informar sobre hosts defectuosos aplicando 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 se vuelva a iniciar la instancia de procesamiento en una máquina host en buen estado. En el caso de las reservas que usan el modo operativo de reserva de toda la capacidad, Compute Engine restablece 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 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 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 mostrará un mensaje de error y la máquina anfitrión no se marcará como defectuosa.
  • Es posible que se aplique un límite de frecuencia a 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 toda la capacidad.

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

  2. Informa que el nodo está defectuoso:

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

    Reemplaza lo siguiente:

    • NODE_NAME: Es el nombre del nodo defectuoso.
    • FAULT_REASON: El motivo de error adecuado con uno o más de los siguientes valores:
      • PERFORMANCE: Usa este valor si las GPUs de una instancia de procesamiento tienen un rendimiento más lento que otras GPUs 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 el daño silencioso de los datos.
      • 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 la corrupción de memoria, problemas del kernel o cualquier otro defecto. Por lo general, este término se usa para referirse a defectos inducidos por el hardware.
      • XID: Usa este valor si identificaste un error irrecuperable de la GPU con un XID para una instancia de procesamiento.
      • unspecified: Usa este valor si no sabes 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.
Después de informar que un host de un nodo está defectuoso, el momento en 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 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 host defectuoso No se aplican límites de frecuencia. Es posible que las llamadas a la API tengan una tasa limitada.
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:

  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 correctamente 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 detalles, consulta Configura GKE para finalizar tus cargas de trabajo de forma ordenada.
  2. Informa y repara 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, por lo general, tarda 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 ocasiones, en reparar el host.

  3. Reinicia la instancia: Después de que la operación de reparación del host se complete (por lo general, de 3 a 14 días), ocurrirá una de las siguientes situaciones:

    • Si la instancia está en el 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 el 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 no hay recursos disponibles cuando lo hagas. Por ejemplo, esto puede ocurrir si otras instancias ya están usando el host reparado.

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

  1. Expulsa los 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 correctamente 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 detalles, consulta Configura GKE para finalizar tus cargas de trabajo de forma ordenada.
  2. 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, por lo general, tarda 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 ocasiones, en reparar el host.

  3. 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 que informaste 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 de una de las siguientes maneras:

    • Si la instancia está en el estado REPAIRING y los recursos están disponibles antes de que se complete la reparación o cuando esta se completa, 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 de que se complete la reparación o cuando se complete, el estado de la instancia permanecerá en TERMINATED o cambiará 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 no hay recursos disponibles cuando lo haces. Por ejemplo, esto puede ocurrir si otras instancias ya están usando 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 desalojar los Pods del nodo afectado.
  • OperationRUNNING: Se está ejecutando la operación para informar que el host está defectuoso.
  • OperationDone: Se informó que el host subyacente tiene fallas y el nodo de GKE está listo para trasladarse a un host nuevo.
  • Error: La llamada a la API falló por motivos que incluyen uno de los requisitos descritos en la sección anterior.

También puedes ver la etiqueta del nodo cloud.google.com/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 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

En caso de errores de la API, GKE establece la etiqueta del nodo en cloud.google.com/report-and-replace-status=ERROR. GKE borra los taints del nodo y quita la etiqueta cloud.google.com/fault-behavior del nodo.

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.

Para volver a intentar la operación en caso de errores transitorios, como límites de frecuencia, vuelve a aplicar la etiqueta cloud.google.com/fault-behavior al nodo.

¿Qué sigue?