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

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:

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í:

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

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 de 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

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:

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

    Reemplaza lo siguiente:

    • NODE_NAME: el nombre del nodo defectuoso.
    • FAULT_REASON: 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 de 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 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 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 limiten las llamadas a la API.
Proceso de informes de hosts defectuosos

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 marca el 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.
  2. 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.

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

  1. Expulsa Pods: Después de que se aplica la etiqueta al nodo defectuoso, GKE marca el 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.
  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 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.

  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 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 trasladarse a un host nuevo.
  • Error: No se pudo realizar la llamada a la API por motivos que incluyen 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

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

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?