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

Durante el ciclo de vida de un clúster de GKE de ejecución prolongada, se producen interrupciones periódicas en las cargas de trabajo debido a interrupciones de la infraestructura que generanGoogle Cloud problemas. Estos eventos automáticos pueden ocurrir en respuesta a decisiones de programación (eventos de preferencia), actualizaciones del plano de control o de nodos, que incluyen actualizaciones automáticas de nodos de GKE (eventos de mantenimiento) o corrección de problemas detectados (eventos de finalización).

En esta página, se explica qué significa la interrupción de nodos en GKE, cómo supervisar las notificaciones de mantenimiento y cómo minimizar el impacto de las interrupciones en tus nodos de GKE con GPUs y TPUs adjuntas.

Este documento está dirigido a los administradores y operadores de la plataforma que administran el ciclo de vida de la infraestructura tecnológica subyacente. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles de usuario y tareas comunes de GKE.

¿Qué significa interrupción de la infraestructura en GKE?

Tus clústeres de GKE administran el ciclo de vida de los nodos de GKE. Estos nodos se aprovisionan en VMs de Compute Engine, que experimentan periódicamente las siguientes interrupciones:

  • Corrección de problemas detectados (TerminationEvent): Estos eventos ocurren porque Google Cloud detecta un problema y detiene la infraestructura del clúster. Los eventos de TerminationEvent no admiten el cierre ordenado. Los eventos TerminationEvent se activan por los siguientes problemas:

    • La reparación automática se produce cuando GKE repara un nodo después de varias verificaciones de estado fallidas.
    • HostError se produce cuando un error de hardware o software en la máquina física hace que se detenga la VM.

  • Eventos de mantenimiento o actualización (MaintenanceEvent): Estos eventos ocurren cuando Google Cloud necesita interrumpir una VM para realizar tareas de mantenimiento. Los eventos MaintenanceEvent se activan con las siguientes tareas de mantenimiento:

    Para obtener más información sobre cómo tú y GKE administran los cambios durante el ciclo de vida de un clúster, consulta Tipos de cambios.

  • Respuesta a las decisiones de programación (PreemptionEvent): Se producen cuandoGoogle Cloud necesita interrumpir las VMs para que haya capacidad disponible para los recursos de mayor prioridad. Los eventos de PreemptionEvent pueden ser cualquiera de los siguientes:

    • Expulsión: Se produce cuando la infraestructura interrumpible o Spot se interrumpe para dar lugar a una VM de mayor prioridad.
    • La desfragmentación se produce cuando GKE interrumpe una porción de TPU más pequeña para admitir una porción de TPU más grande. La desfragmentación solo se produce en las porciones de TPU.

Durante el ciclo de vida de un clúster de GKE de larga duración, es posible que los nodos experimenten interrupciones periódicas en las cargas de trabajo de entrenamiento o de servicio. Cuando estas interrupciones afectan a tus nodos de GKE que ejecutan cargas de trabajo de IA/AA, GKE debe reiniciar tanto las cargas de trabajo en ejecución como el nodo subyacente.

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

La mayoría de las VMs de Compute Engine, con algunas excepciones, tienen su política de mantenimiento del host establecida en migración en vivo, lo que significa que las cargas de trabajo en ejecución suelen experimentar poca o ninguna interrupción. Sin embargo, ciertas clases de VMs no admiten la migración en vivo, incluidas las VMs con GPUs y TPUs conectadas. Cuando ocurre un evento de host en la VM dentro de una porción de TPU, se interrumpe toda la porción y, luego, se reprograma, ya que todos los eventos de mantenimiento se coordinan a nivel de la porción. Por lo tanto, si creas un segmento de TPU que tiene cientos de VMs, todas esas VMs recibirán el mismo programa de eventos de mantenimiento.

Cuando se produce un evento del 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 Job o una Deployment, GKE reinicia los Pods en el nodo afectado.

Depende de ti o de los frameworks que uses controlar la configuración de la carga de trabajo para reaccionar de forma adecuada a los eventos de mantenimiento. Por ejemplo, puedes guardar el estado de tu trabajo de entrenamiento de IA para reducir la pérdida de datos.

Para administrar las interrupciones en las cargas de trabajo de AA/IA, puedes hacer lo siguiente:

Supervisa las interrupciones de nodos

La siguiente métrica del sistema de GKE informa el recuento de interrupciones de un nodo de GKE desde la última muestra (la métrica se muestrea cada 60 segundos):

  • kubernetes.io/node/interruption_count

Los campos interruption_type (como TerminationEvent, MaintenanceEvent o PreemptionEvent) y interruption_reason (como HostError, Eviction o AutoRepair) pueden ayudar a proporcionar el motivo por el que se interrumpió un nodo.

Para obtener un desglose de las interrupciones y sus causas en los nodos de TPU de los clústeres de tu proyecto, usa la siguiente consulta de PromQL:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

Para ver solo los eventos de mantenimiento del host, actualiza la consulta para filtrar el valor HW/SW Maintenance para el interruption_reason. Usa la siguiente consulta de PromQL:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

Para ver el recuento de interrupciones agregado por grupo de nodos, usa la siguiente consulta de PromQL:

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

Supervisa las notificaciones de mantenimiento

Compute Engine emite notificaciones cuando se programan eventos del host disruptivos para los nodos y sus VMs subyacentes, y cuando estos eventos se activan. Las notificaciones incluyen información sobre la hora de inicio planificada, el tipo de evento y otros detalles.

En la versión 1.31.1-gke.2008000 y posteriores de GKE, puedes supervisar los próximos eventos de mantenimiento, incluidos los eventos que se describen en esta sección.

Se programó un mantenimiento próximo, pero no está activo

Antes de que una VM con GPUs o TPUs adjuntas tenga un evento de mantenimiento programado, Compute Engine envía notificaciones a todas sus VMs. Estas notificaciones informan el inicio del período de mantenimiento. Cuando la VM programa un mantenimiento próximo, pero no activo, GKE agrega scheduled-maintenance-time a la etiqueta del nodo.

Para consultar estas notificaciones a nivel del nodo, ejecuta el siguiente comando:

kubectl get nodes -l cloud.google.com/scheduled-maintenance-time \
    -L cloud.google.com/scheduled-maintenance-time

El resultado es similar a este:

NAME                         STATUS    SCHEDULED-MAINTENANCE-TIME
<gke-accelerator-node-name>  Ready     1733083200
<gke-accelerator-node-name>  Ready     1733083200
[...]

La columna SCHEDULED-MAINTENANCE-TIME representa los segundos, que se muestran en formato de hora de época Unix.

Para consultar estas notificaciones a nivel de los metadatos del nodo, verifica las instancias para ver si hay una notificación de evento de mantenimiento.

En el caso de las familias de máquinas optimizadas para aceleradores que admiten el mantenimiento avanzado, puedes acceder al extremo upcoming-maintenance que proporciona información sobre los eventos de mantenimiento programados y los que ya comenzaron.

Minimiza el impacto de las interrupciones

Compute Engine envía notificaciones sobre los próximos eventos de mantenimiento y programa una ventana de mantenimiento. Entre la hora de la notificación y la hora de inicio del período de mantenimiento, puedes decidir entre las siguientes opciones:

  • Inicia manualmente un evento de mantenimiento del host.
  • Permite que Compute Engine inicie el evento de mantenimiento según lo programado.

Inicia manualmente un evento de mantenimiento del host

Cuando 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 operativo, por ejemplo, durante períodos de actividad reducida.

En un nodo del grupo de nodos, establece la etiqueta de nodo cloud.google.com/perform-maintenance en true. Por ejemplo:

kubectl label nodes <node-name> cloud.google.com/perform-maintenance=true

Si inicias un evento de mantenimiento, GKE ejecuta las siguientes operaciones:

  1. Aplica un taint al nodo.
  2. Desaloja los Pods de forma ordenada.
  3. Solicita a Compute Engine que inicie el evento de mantenimiento de inmediato, en lugar de esperar la hora programada.

Compute Engine inicia el evento de mantenimiento según lo programado

Si no inicias un evento de mantenimiento del host, Compute Engine iniciará el evento de mantenimiento programado por su cuenta. A partir de la versión 1.33 de GKE, el nodo no se marca como dañado y los Pods no se expulsan cuando comienza el período de mantenimiento.

Cuando comienza el evento de mantenimiento, es posible que un nodo se apague una o varias veces con un breve tiempo de notificación antes de su finalización inminente. En estos casos, GKE hace su mejor esfuerzo para finalizar las cargas de trabajo y desalojar los Pods de forma correcta.

Comienza el mantenimiento programado

Cuando comienza el mantenimiento programado, Compute Engine actualiza los metadatos en el directorio http://metadata.google.internal/computeMetadata/v1/instance/attributes/. Compute Engine actualiza las etiquetas de metadatos de la siguiente manera:

  • Establece maintenance-event en TERMINATE_ON_HOST_MAINTENANCE.
  • En upcoming-maintenance, establece maintenance_status en ONGOING.

GKE controla un evento de mantenimiento del host programado, según si lo activas de forma manual o permites que GKE proceda automáticamente.

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 tu aplicación y minimizar la interrupción de tu carga de trabajo. Si no configuras un período de gracia, el valor predeterminado es de 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 una señal 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 un indicador SIGKILL de seguimiento a todos los procesos que aún se ejecutan en cualquier contenedor del Pod.

Para configurar el período de finalización correcta, establece el período de gracia de finalización (en segundos) en el campo spec.terminationGracePeriodSeconds del manifiesto de tu Pod. Por ejemplo, para obtener un tiempo de notificación de 10 minutos, configura el campo spec.terminationGracePeriodSeconds en el manifiesto de tu Pod 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. Si tu carga de trabajo usa un framework de AA, como MaxText, Pax o JAX con Orbax, las cargas de trabajo pueden capturar el indicador de apagado SIGTERM y, luego, iniciar un proceso de creación de puntos de control. Para obtener más información, consulta TPU Autocheckpoint.

Proceso de finalización ordenada

Cuando comienza un evento de mantenimiento iniciado manualmente, Compute Engine indica el cierre inminente de la máquina actualizando la clave de metadatos maintenance-event. GKE inicia la finalización ordenada.

En el siguiente flujo de trabajo, se muestra cómo GKE ejecuta la finalización correcta del nodo cuando se acerca el cierre del nodo:

  1. En un plazo de 60 segundos, ocurre lo siguiente:
    1. Los componentes del sistema aplican el conjunto de etiquetas de nodo cloud.google.com/active-node-maintenance a ONGOING para indicar que se están deteniendo las cargas de trabajo.
    2. GKE aplica el taint del nodo para evitar que se programen Pods nuevos en él. El taint tiene la clave cloud.google.com/impending-node-termination:NoSchedule. Te recomendamos que no modifiques tus cargas de trabajo para tolerar este taint debido a la terminación conocida que se produce.
  2. El componente maintenance-handler comienza a desalojar Pods. Primero, desalojará los Pods de carga de trabajo y, luego, los Pods del sistema (por ejemplo, kube-system).
  3. GKE envía una señal de cierre SIGTERM a los Pods de carga de trabajo que se ejecutan en el nodo para alertarlos sobre 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.
  4. Una vez que finaliza el desalojo, GKE actualiza el valor de la etiqueta cloud.google.com/active-node-maintenance a terminating para indicar que el nodo está listo para finalizar.

Luego, se produce la finalizació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 Cómo iniciar manualmente un evento de mantenimiento del host.

Supervisa el progreso de una finalización ordenada activa

Puedes filtrar los registros de GKE según los siguientes eventos de finalización correcta:

  • Cuando la VM detecta una interrupción debido a una finalización inminente del nodo, como un evento de mantenimiento del host de Compute Engine, GKE establece cloud.google.com/active-node-maintenance en ONGOING cuando se detienen las cargas de trabajo y en terminating cuando finalizan las cargas de trabajo y el nodo está listo para finalizar.
  • Cuando se restringe la programación de cargas de trabajo nuevas, GKE aplica el taint cloud.google.com/impending-node-termination:NoSchedule.

Minimiza la interrupción de las cargas de trabajo en ejecución con el mantenimiento oportunista

Puedes minimizar la interrupción de las cargas de trabajo en ejecución activando automáticamente el mantenimiento cuando GKE detecta que los nodos con GPU o TPU están inactivos. Para habilitar esta función, crea un grupo de nodos nuevo. No puedes habilitar el mantenimiento oportunista en un grupo de nodos existente.

Crea un grupo de nodos nuevo con mantenimiento oportunista

En el siguiente comando, se muestra cómo crear un grupo de nodos con el mantenimiento oportunista habilitado:

gcloud beta container node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --accelerator ACCELERATOR_ARG \
    --machine-type MACHINE_TYPE \
    --num-nodes NODE_COUNT \
    --zone ZONE \
    --project=PROJECT_ID \
    --opportunistic-maintenance=node-idle-time=NODE_IDLE_TIME,min-nodes=MIN_NODES,window=WINDOW

Reemplaza los siguientes valores:

  • NODE_POOL_NAME: Es el nombre de tu grupo de nodos de GKE.
  • CLUSTER_NAME : Es el nombre del clúster de GKE.
  • NODE_IDLE_TIME : Es la cantidad de tiempo que un nodo puede permanecer inactivo (es decir, no se ejecutan cargas de trabajo que consuman aceleradores) antes de que se active el mantenimiento. El valor representa la duración en segundos, con hasta nueve dígitos decimales, y termina con el carácter s, por ejemplo: 80000s.
  • MIN_NODES : Es la cantidad mínima de nodos que deben estar disponibles en un grupo de nodos. Esta opción bloquea el mantenimiento si hace que la cantidad de nodos en ejecución sea inferior a este valor, por ejemplo, 10.
  • WINDOW : Es el período, en segundos, durante el que se puede ejecutar el mantenimiento oportunista. El valor termina con un carácter s. Por ejemplo, un valor de 14 días, o 1209600s, implica que el mantenimiento oportunista solo se puede ejecutar en las dos semanas previas a la fecha de mantenimiento programada. Un valor de 28 días, o 2419200s, permite que el mantenimiento oportunista se ejecute en cualquier momento durante el período de mantenimiento programado. Este período para el mantenimiento del host de Compute Engine es distinto de los períodos de mantenimiento de GKE, que determinan cuándo puede ocurrir el mantenimiento del clúster de GKE y se configuran por separado.

Ejemplo de configuración para el mantenimiento oportunista

Considera el siguiente ejemplo: Tienes un grupo de nodos con cuatro nodos y la configuración de mantenimiento oportunista está establecida en --opportunistic-maintenance=node-idle-time=600s,window=2419200s,min-nodes=3. En esta situación, ocurre lo siguiente:

  • node1 tiene una carga de trabajo de GPU en ejecución. Este nodo no está inactivo, por lo que se omite.
  • node2 ha estado inactivo durante 60 segundos. Este nodo no estuvo inactivo durante el tiempo suficiente, por lo que se omitió.
  • node3 ha estado inactivo durante 600 segundos. Este nodo cumple con el requisito de inactividad.
  • node4 ha estado inactivo durante 600 segundos. Este nodo cumple con el requisito de inactividad.

Tanto node3 como node4 satisfacen el requisito de inactividad. Sin embargo, solo uno de estos nodos activará el mantenimiento oportunista porque el valor de la opción min-nodes está establecido en 3.

Verifica la configuración y el estado de los nodos con mantenimiento oportunista

Ejecuta el siguiente comando para verificar si el mantenimiento oportunista está configurado para un nodo:

kubectl describe node NODE_NAME | grep node.gke.io/opportunistic-config

Reemplaza NODE_NAME por el nombre del nodo que deseas verificar.

Verifica si un nodo configurado con mantenimiento oportunista está en mantenimiento:

kubectl describe node NODE_NAME | grep node.gke.io/maintenance-state

Si el nodo se activa por mantenimiento oportunista, la anotación maintenance-state muestra opportunistic-triggered como true.

Limitaciones

Ten en cuenta las siguientes limitaciones del mantenimiento oportunista:

  • Esta función solo se puede usar con grupos de nodos de GPU y TPU.
  • El mantenimiento oportunista no es compatible con el ajuste de escala automático del clúster porque el escalador automático del clúster ya reduce la escala verticalmente de los nodos inactivos.
  • Para los grupos de nodo TPU de varios hosts, el valor del parámetro de configuración min-nodes-per-pool debe ser 0 porque estos grupos de nodos son atómicos.
  • La versión mínima compatible de GKE es 1.33.3-gke.1118000.
  • Solo se admite el mantenimiento planificado que incluye la notificación can_reschedule=TRUE.
  • Para inhabilitar esta función, debes volver a crear el grupo de nodos sin las marcas correspondientes. También puedes inhabilitar la función manualmente en nodos específicos con cloud.google.com/opportunistic-disable=true.
  • En casos excepcionales, el mantenimiento puede tardar más en finalizar en un nodo. Es posible que los clientes que usen esta función experimenten una menor cantidad de nodos disponibles, hasta el valor del parámetro de configuración min-nodes-per-pool, durante un período.

¿Qué sigue?