Comprende cómo realizar el mantenimiento del host en GKE

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 interrupciones de la infraestructura queGoogle Cloud emite. Estos eventos automáticos pueden ocurrir para responder a decisiones de programación (eventos de interrupción) o actualizaciones 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 este documento, se explica qué significa la interrupción de nodos en GKE y cómo minimizar el impacto de la interrupción en tus nodos de GKE.

Para obtener detalles sobre la supervisión de las notificaciones y los eventos de mantenimiento, consulta Supervisa los eventos de mantenimiento.

Este documento se aplica a los siguientes tipos de máquinas:

Este documento está dirigido a los administradores y operadores de plataformas que administran el ciclo de vida de la infraestructura técnica 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 y tareas comunes del usuario 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, luego, interrumpe la infraestructura del clúster. Los eventos 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 que fallan varias verificaciones de estado.
    • HostError ocurre cuando un error de hardware o software en la máquina física hace que la VM se detenga.

  • Eventos de mantenimiento o actualización (MaintenanceEvent): Estos eventos ocurren cuando Google Cloud debe interrumpir una VM para realizar tareas de mantenimiento. Estos eventos 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): Estos eventos ocurren cuando Google Cloud debe 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 alojar una VM de mayor prioridad.
    • Desfragmentación: Se produce cuando GKE interrumpe una porción de TPU más pequeña para alojar una porción de TPU más grande. La desfragmentación solo se produce en los sectores de TPU.

Durante el ciclo de vida de un clúster de GKE de larga duración, los nodos pueden experimentar interrupciones periódicas en las cargas de trabajo. Cuando estas interrupciones afectan a los nodos de GKE que ejecutan tus cargas de trabajo, GKE debe reiniciar las cargas de trabajo en ejecución y el nodo subyacente.

Por qué los nodos que no admiten la migración en vivo 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 configurada para migrar 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, incluidos los siguientes tipos de máquinas:

  • Tipos de máquinas con GPU y TPU conectadas.
  • Tipos de máquinas H4D
  • El tipo de máquina c4a-highmem-96-metal.
  • Tipos de máquinas Z3 con más de 18 TiB de SSD Titanium conectadas.
  • Tipos de máquinas Z4D con más de 42 TiB de SSD Titanium conectada
  • Tipos de máquinas Z4M con más de 48 TiB de SSD Titanium conectada o cualquier instancia de Z4M que use Cloud RDMA.

Por ejemplo, cuando se produce 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 una porción de TPU que tiene cientos de VMs, todas esas VMs recibirán el mismo programa de eventos de mantenimiento.

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.

Administra eventos de mantenimiento

En el resto de este documento, se describe cómo administrar las interrupciones de MaintenanceEvent.

La administración de la interrupción de los nodos durante los eventos de mantenimiento del host sigue un flujo de trabajo de tres etapas:

  1. Detecta el mantenimiento programado del host: usa etiquetas de nodos de GKE, extremos de metadatos o registros.
  2. Actúa en función del mantenimiento detectado: Si se programa el mantenimiento, evalúa tu infraestructura y tus cargas de trabajo, y determina la mejor acción para tu caso de uso. Toma la medida adecuada, como permitir que el sistema controle el evento de mantenimiento de forma automática, iniciar el mantenimiento del host de forma manual o coordinar estrategias de mantenimiento.
  3. Verifica el resultado del evento de mantenimiento: Verifica que el evento de mantenimiento se haya iniciado correctamente, ya sea cuando Compute Engine lo inicia según lo programado o cuando lo inicias de forma manual.

Detecta el mantenimiento programado del host

Para supervisar y detectar los próximos eventos de mantenimiento, debes ver las notificaciones de GKE y Compute Engine.

Para obtener detalles sobre la supervisión de las notificaciones y los eventos de mantenimiento, consulta Supervisa los eventos de mantenimiento.

Actúa en función del mantenimiento detectado

Si ves una notificación de mantenimiento programado para uno o más nodos de tu clúster, usa el siguiente árbol de decisión para determinar la mejor manera de controlar la interrupción:

  1. Mantenimiento automático: Permite que Compute Engine inicie el evento de mantenimiento según lo programado. Tus VMs se migrarán en vivo automáticamente en segundo plano con interrupciones mínimas o nulas.

    1. Si la VM host admite la migración en vivo, te recomendamos que permitas que el evento de mantenimiento se produzca automáticamente.
    2. Si tus cargas de trabajo se ejecutan en nodos flexibles inactivos, puedes optimizar los tiempos de mantenimiento de forma automática configurando el mantenimiento oportunista. Esto activa las actualizaciones necesarias solo durante los períodos de inactividad natural.

  2. Inicia un evento de mantenimiento del host de forma manual: Evalúa las siguientes preguntas para determinar la mejor manera de controlar la interrupción de forma manual:

    1. ¿Los nodos afectados son VMs individuales o aisladas?

      • Sí (ejecuto una VM única o aislada):
        • Si no necesitas controles de tiempo precisos, permite que Compute Engine inicie el evento de mantenimiento según lo programado (automático predeterminado).
        • Si necesitas evitar la interrupción inesperada, inicia de forma manual el evento de mantenimiento del host en el nodo individual en un momento conveniente, por ejemplo, durante períodos de tráfico menor.
      • No (ejecuto un grupo de nodos de aceleradores): elige una de las opciones en el siguiente paso.

    2. Elige una de las siguientes opciones según tu caso de uso:

      • Si tu grupo de aceleradores ejecuta tareas de entrenamiento de IA/AA acopladas, implementa la estrategia paralela. Guarda el estado de entrenamiento en un punto de control, cierra el grupo de forma correcta y realiza actualizaciones de host y de clúster de GKE de forma simultánea antes de reiniciar.

      • Si tu grupo de aceleradores ejecuta extremos de inferencia o entrega de IA/AA de alta disponibilidad: implementa la estrategia progresiva. Coordina el mantenimiento programado del host y las actualizaciones de versión en lotes progresivos dentro de los límites de tu zona o grupo, con réplicas activas para proteger los ANS.

Inicia un evento de mantenimiento del host de forma manual en VMs individuales o aisladas

Puedes iniciar de forma manual el mantenimiento reprogramable cuando se ajuste a tu programa, como durante los períodos de baja actividad. Para ello, aplica la etiqueta cloud.google.com/perform-maintenance=true si se cumplen las siguientes condiciones:

  • Compute Engine emite una notificación sobre un evento de mantenimiento programado.
  • El evento de mantenimiento de Compute Engine subyacente se puede reprogramar. Para verificar si el evento se puede reprogramar, busca la notificación can_reschedule=TRUE en los metadatos del evento. Si el evento no se puede reprogramar, configurar la etiqueta cloud.google.com/perform-maintenance=true no tiene efecto, y el mantenimiento se realiza en el horario programado originalmente.

Si se cumplen las condiciones anteriores, en un nodo del grupo de nodos, establece la etiqueta de nodo cloud.google.com/perform-maintenance como true. Por ejemplo:

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

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

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

Verifica el resultado del evento de mantenimiento

Después de detectar un próximo evento de mantenimiento y decidir el mejor curso de acción, puedes verificar el resultado del evento de mantenimiento.

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

Cuando se inicia el evento de mantenimiento, un nodo puede cerrarse una o más veces con un tiempo de notificación breve antes de su finalización inminente. En estos casos, GKE hace todo lo posible 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 detecta y controla el evento de mantenimiento del host programado, ya sea que lo actives de forma manual o permitas que GKE continúe automáticamente.

La siguiente métrica del sistema de GKE informa la cantidad 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 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 por 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}]))

Parámetros de configuración avanzados para minimizar las interrupciones

En esta sección, se describen herramientas adicionales para configurar tu clúster y tus cargas de trabajo con el objetivo de minimizar las interrupciones.

Habilita el manejo de interrupciones

apiVersion: v1
kind: ConfigMap
metadata:
  name: gke-disruption-handling
  namespace: kube-system
data:
  maintenance-experience.yaml: |
    gracefulTermination: true

Para habilitar el manejo de interrupciones, crea un archivo llamado maintenance-config.yaml con este ConfigMap. Aplica el ConfigMap al clúster con el siguiente comando:

kubectl apply -f my-configmap.yaml

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, este será de 30 segundos de forma predeterminada.

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 antes de que finalice el 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 (segundos) en el campo spec.terminationGracePeriodSeconds del manifiesto del 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 cierre SIGTERM y, luego, iniciar un proceso de creación de puntos de control. Para obtener más información, consulta Autocheckpoint de TPU.

Proceso de finalización ordenada

Cuando comienza un evento de mantenimiento iniciado de forma manual, 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 de los nodos cuando hay un cierre inminente de estos:

  1. En un plazo de 60 segundos, ocurrirá lo siguiente:
    1. Los componentes del sistema aplican la etiqueta de nodo cloud.google.com/active-node-maintenance establecida en ONGOING para indicar que se están deteniendo las cargas de trabajo.
    2. GKE aplica el taint de nodo para evitar que se programen Pods nuevos en el nodo. La tacha 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 finalización conocida que se produce.
  2. El componente maintenance-handler comienza a expulsar Pods. Primero, expulsa 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 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.
  4. Una vez que finaliza la expulsión, GKE actualiza el valor de la etiqueta cloud.google.com/active-node-maintenance a terminating para indicar que el nodo está listo para finalizar.

Después, 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 Inicia un evento de mantenimiento del host de forma manual.

Verifica el progreso de una finalización ordenada activa

Puedes filtrar los registros de GKE por 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 el cloud.google.com/active-node-maintenance en ONGOING cuando se detienen las cargas de trabajo y en terminating cuando las cargas de trabajo finalizan 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 detecte 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 puedes 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 consumen aceleradores) antes de que se active el mantenimiento. El valor representa la duración en segundos, con hasta nueve dígitos fraccionarios, 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, en 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 anteriores 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 de hosts de Compute Engine es distinto de los períodos de mantenimiento de GKE, que determinan cuándo puede ocurrir el mantenimiento de clúster de GKE y se configuran por separado.

Configuración de ejemplo para el mantenimiento oportunista

Considera el siguiente ejemplo: Tienes un grupo de nodos con cuatro nodos y la configuración de mantenimiento oportunista se establece en --opportunistic-maintenance=node-idle-time=600s,window=2419200s,min-nodes=3. En este caso, 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 estuvo inactivo durante 60 segundos. Este nodo no estuvo inactivo durante el tiempo suficiente, por lo que se omite.
  • node3 estuvo inactivo durante 600 segundos. Este nodo cumple con el requisito de inactividad.
  • node4 estuvo inactivo durante 600 segundos. Este nodo cumple con el requisito de inactividad.

Tanto node3 como node4 cumplen con el requisito de inactividad. Sin embargo, solo uno de estos nodos activará el mantenimiento oportunista porque el valor de la opción min-nodes se establece 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 quieres 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, ya que 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 de la configuración min-nodes-per-pool debe ser 0 porque estos grupos de nodos son atómicos.
  • La versión mínima de GKE compatible es la 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 respectivas. También puedes inhabilitar la función de forma manual en nodos específicos con cloud.google.com/opportunistic-disable=true.
  • En casos excepcionales, el mantenimiento puede tardar más tiempo en finalizar en un nodo. Los clientes que usen esta función podrían experimentar menos nodos disponibles, hasta el valor del parámetro de configuración min-nodes-per-pool, durante un período.

¿Qué sigue?