Administra la interrupción de nodos de GKE para GPU y TPU

En esta página, encontrarás ayuda para comprender, configurar y supervisar los eventos de interrupción que pueden ocurrir en los nodos de Google Kubernetes Engine (GKE) que ejecutan cargas de trabajo de inteligencia artificial (IA) o de aprendizaje automático (AA), incluidas las siguientes:

Durante el ciclo de vida de un clúster de GKE de larga duración, se producen interrupciones periódicas en las cargas de trabajo debido a los eventos de mantenimiento automático que emite Google Cloud para los recursos de Compute Engine subyacentes a la infraestructura de GKE. Cuando estas interrupciones afectan a tus nodos de GKE que ejecutan cargas de trabajo de IA/AA, GKE debe reiniciar las cargas de trabajo en ejecución y el nodo subyacente.

Por qué las GPU y las TPU requieren administración de interrupciones

Tus clústeres de GKE administran el ciclo de vida de los nodos de GKE. Estos nodos se aprovisionan en VMs de Compute Engine. Las VMs de Compute Engine experimentan eventos de host de forma periódica, que se deben a una variedad de razones, como actualizaciones de hardware o software, mantenimiento y fallas de hardware. Los eventos de host se emiten para la infraestructura subyacente de Google Cloud y evitan las políticas y exclusiones de mantenimiento de GKE.

La mayoría de las VMs de Compute Engine, con algunas excepciones, tienen su política de mantenimiento del host configurada para migrar en vivo, lo que significa que hay poca o ninguna interrupción de las cargas de trabajo en ejecución. Sin embargo, ciertas clases de VMs no admiten la migración en vivo, incluidas las VMs con GPU y TPU conectadas en las que se ejecutan tus cargas de trabajo de IA/AA. Además, GKE también puede reiniciar las TPU a pedido mediante la interrupción, lo que permite que GKE aprovisione TPU más grandes, debido a motivos de desfragmentación.

Cuando se produce un evento de host, GKE finaliza el nodo y sus Pods. Si los pods se implementan como parte de una carga de trabajo más grande, como un trabajo o una implementación, GKE reinicia los pods en el nodo afectado. Depende de ti o de los frameworks que uses para controlar las cargas de trabajo o los trabajos reaccionar de manera adecuada a la interrupción. Por ejemplo, puedes guardar el estado de tu trabajo de entrenamiento de IA para reducir la pérdida de datos.

Proceso de finalización ordenada

En el siguiente flujo de trabajo, se muestra cómo GKE ejecuta la terminación ordenada del nodo después de que Compute Engine emite una interrupción:

  1. Compute Engine emite un valor actualizado de TERMINATE_ON_HOST_MAINTENANCE para la clave metadatos de VM maintenance-event.

  2. En un plazo de 60 segundos, ocurre lo siguiente:

    1. Los componentes del sistema aplican el siguiente conjunto de etiquetas de nodo nuevo en true para indicar que el mantenimiento está en proceso: cloud.google.com/active-node-maintenance

    2. GKE aplica el taint de nodo para evitar que se programen Pods nuevos en el nodo: cloud.google.com/impending-node-termination:NoSchedule. Te recomendamos que modifiques las cargas de trabajo para tolerar este taint debido a la terminación conocida que se produce.

  3. El componente maintenance-handler comienza a expulsar Pods en orden de Pods de carga de trabajo primero y, luego, los Pods del sistema (por ejemplo, kube-system).

  4. GKE envía una señal de cierre SIGTERM para alertar a los Pods de carga de trabajo en ejecución en el nodo de un cierre inminente. Los Pods pueden usar esta alerta para finalizar cualquier tarea en curso. GKE hace su mejor esfuerzo para finalizar estos Pods de forma correcta.

Las notificaciones maintenance-event ocurren cuando la VM de Compute Engine subyacente de un nodo de GKE se somete a un evento de host disruptivo que genera la finalización del nodo. Cuando esto ocurre, Compute Engine actualiza la clave de metadatos maintenance-event. El período de notificación de mantenimiento avanzado antes de que finalice el nodo es el siguiente:

  • GPU: 60 minutos.
  • TPU: 5 minutos

Luego, se produce la terminación del nodo y se asigna un nodo de reemplazo. GKE borra las etiquetas y los taints cuando finaliza el proceso. Para aumentar el período de finalización de tus cargas de trabajo con GPU o TPU, completa los pasos de la sección Configura GKE para finalizar tus cargas de trabajo de forma correcta.

Controla las interrupciones de las cargas de trabajo en GKE

Para administrar los eventos de finalización de GKE y reducir las interrupciones en las cargas de trabajo en tus clústeres, GKE supervisa estas notificaciones por ti y hará lo siguiente:

  • GKE notifica a tus cargas de trabajo con anticipación sobre un cierre inminente: Cuando un nodo de GKE debe detenerse debido a un evento de mantenimiento del host, GKE envía una señal SIGTERM a los Pods en ejecución en el nodo al comienzo del período de aviso anticipado. Las señales del SO, como SIGTERM, pueden manejarse de forma nativa en la mayoría de las bibliotecas estándar, por ejemplo, Python y Go. Los frameworks que pueden capturar SIGTERM incluyen MaxText, Pax y JAX con Orbax.
  • GKE finaliza correctamente tus cargas de trabajo: puedes configurar GKE para finalizar de forma correcta tus cargas de trabajo con un período de gracia de finalización de Pods. Los Pods pueden reaccionar a la señal SIGTERM para finalizar las tareas en curso y ejecutar cualquier acción de finalización que definas, como guardar un estado de entrenamiento. Durante la finalización ordenada, GKE hace su mejor esfuerzo para finalizar los Pods de manera correcta y ejecutar procesos de limpieza o la acción de finalización que definiste en tu aplicación, por ejemplo, almacenar los datos de la carga de trabajo para reducir la pérdida de datos o guardar un estado de entrenamiento.

Configura GKE para finalizar tus cargas de trabajo de forma ordenada

En esta sección, configurarás GKE para administrar el ciclo de vida de la aplicación y minimizar las interrupciones en la carga de trabajo. Si no configuras un período de gracia, el período de gracia se establece de forma predeterminada en 30 segundos.

GKE hace su mejor esfuerzo para finalizar estos Pods de forma correcta y ejecutar la acción de finalización que definiste, por ejemplo, guardar un estado de entrenamiento. GKE envía señales SIGTERM a los Pods al comienzo del período de gracia. Si los Pods no salen al final del período de gracia, GKE envía una señal de seguimiento SIGKILL a todos los procesos que aún se ejecutan en cualquier contenedor del Pod.

Para configurar el período de finalización ordenada de las cargas de trabajo, sigue las instrucciones para GPU o TPU.

GPU

En el manifiesto de tu Pod, establece el campo spec.terminationGracePeriodSeconds en un valor de hasta 3,600 segundos (60 minutos). Por ejemplo, para obtener un tiempo de notificación de 10 minutos, en el manifiesto de tu Pod, configura el campo spec.terminationGracePeriodSeconds en 600 segundos de la siguiente manera:

    spec:
      terminationGracePeriodSeconds: 600

Te recomendamos que establezcas un período de gracia de finalización que sea lo suficientemente extenso como para que cualquier tarea en curso finalice en el período de notificación.

TPU

Para asignar el tiempo máximo para realizar tus procesos de limpieza, establece el campo spec.terminationGracePeriodSeconds en 300 segundos (cinco minutos) en el manifiesto de tu Pod. Por ejemplo:

    spec:
      terminationGracePeriodSeconds: 300

Te recomendamos que establezcas un período de gracia de finalización que sea lo suficientemente extenso como para que cualquier tarea en curso finalice en el período de notificación.

Si tu carga de trabajo usa un framework de AA, como MaxText, Pax o JAX con Orbax, las cargas de trabajo pueden capturar la señal SIGTERM de cierre y, luego, iniciar un proceso de punto de control. Para obtener más información, consulta Punto de control automático de TPU.

Supervisa el progreso de una finalización ordenada activa

En los clústeres de GKE con el plano de control que ejecuta 1.29.1-gke.1425000 o una versión posterior, GKE implementa un componente a nivel de nodo llamado gpu-maintenance-handler. Este componente se ejecuta en todos los nodos de GPU y TPU junto con un componente del plano de control correspondiente. Estos componentes hacen lo siguiente:

  • Procesa eventos de finalización ordenada
  • Reenvía una señal SIGTERM a las cargas de trabajo en ejecución de un nodo para responder a eventos de interrupción inminentes en la VM de GKE. Estas interrupciones se registran como solicitudes de expulsión de pods y de eliminación.

GKE agrega una etiqueta y un taint a los nodos con estado de cierre inminente. GKE supervisa las notificaciones de eventos del host, como el mantenimiento, mediante el componente del sistema maintenance-handler que se ejecuta en cada nodo de GPU y TPU.

GKE registra los siguientes eventos de finalización ordenada:

Cuando GKE finaliza la finalización ordenada, se borran las etiquetas y los taints.

Para supervisar el estado de una finalización ordenada activa causada por una interrupción, puedes ver los registros de gpu-maintenance-handler mediante la consola o Google Cloud CLI.

gcloud

  1. Ubica los nombres de los nodos y los Pods que ejecutan instancias de gpu-maintenance-handler mediante la ejecución del siguiente comando:

    kubectl get pods -l name=maintenance-handler -A -o wide

    Cada fila del resultado incluye el nombre del nodo, el nombre del pod y el estado.

  2. Verifica los registros:

    kubectl logs -n=kube-system MAINTENANCE_HANDLER_POD_NAME

    Reemplaza MAINTENANCE_HANDLER_POD_NAME por el nombre de la instancia del controlador.

    Si se detecta un evento de mantenimiento, el Pod registra un mensaje, aplica las etiquetas y comienzan las expulsiones.

  3. Verifica las etiquetas y los taints de nodo:

    kubectl describe node NODE_NAME

    Reemplaza NODE_NAME por el nombre del nodo que deseas ver.

    El resultado muestra la lista de etiquetas y taints de nodos para supervisar.

Console

  1. Ve al Explorador de registros en la consola de Google Cloud:

    Ir al Explorador de registros

  2. En el campo Consulta, ingresa la siguiente consulta:

    resource.type="k8s_container"
resource.labels.namespace_name="kube-system"
resource.labels.container_name="maintenance-handler"
resource.labels.cluster_name="CLUSTER_NAME"

    Reemplaza CLUSTER_NAME: Es el nombre de tu clúster.

¿Qué sigue?