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 que Cloud de Confiance by S3NS 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).

Este documento te ayuda a comprender qué significa la interrupción de nodos en GKE y a minimizar el impacto de la interrupción en tus nodos de GKE.

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

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

Este documento está destinado a 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 Cloud de Confiance by S3NS contenido de, consulta Roles y tareas comunes del usuario de GKE.

¿Qué significa la 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 Cloud de Confiance by S3NS detecta un problema e interrumpe la infraestructura de tu clúster. Los eventos TerminationEvent no admiten el cierre correcto. Los eventos TerminationEvent se activan por los siguientes problemas:

    • La reparación automática ocurre cuando GKE repara un nodo después de verificaciones de estado fallidas repetidas.
    • 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 Cloud de Confiance by S3NS debe interrumpir una VM para realizar el 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 Cloud de Confiance by S3NS debe interrumpir las VMs para que la capacidad esté disponible para los recursos de mayor prioridad. Los eventos PreemptionEvent pueden ser cualquiera de los siguientes:

    • Expulsión: Ocurre cuando se interrumpe la infraestructura interrumpible o Spot para alojar una VM de mayor prioridad.
    • Desfragmentación: Ocurre 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 ocurre en porciones 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 la 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 GPU conectadas y TPU, los tipos de máquinas Z3 con más de 18 TiB de SSD, los tipos de máquinas H4D y el tipo de máquina dec4a-highmem-96-metal máquina. Por ejemplo, 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 vuelve a programar porque 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 la misma programación de eventos de mantenimiento.

Cuando ocurre 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 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 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 sobre el mantenimiento detectado: Si se programa el mantenimiento, evalúa tu infraestructura y cargas de trabajo, y determina la mejor acción para tu caso de uso. Realiza la acción 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 inicia el evento de mantenimiento según la programación 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 notificaciones y eventos de mantenimiento, consulta Supervisa eventos de mantenimiento.

Actúa sobre el mantenimiento detectado

Si ves una notificación de mantenimiento programado próximo 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 la programación. Tus VMs se migrarán en vivo automáticamente en segundo plano con interrupciones mínimas o nulas.

    1. Si la VM del host admite la migración en vivo, te recomendamos que permitas que el evento de mantenimiento se produzca de forma automática.
    2. Si tus cargas de trabajo se ejecutan en nodos flexibles inactivos, puedes optimizar el tiempo de mantenimiento de forma automática configurando el mantenimiento oportunista. Esto activa las actualizaciones necesarias solo durante los períodos de tiempo 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 únicas 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 la programación (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 del 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 del host y del clúster de GKE de forma simultánea antes de reiniciar.

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

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

Puedes iniciar el mantenimiento reprogramable de forma manual cuando se ajuste a tu programación, por ejemplo, durante 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 subyacente de Compute Engine se puede reprogramar. Para verificar si el evento se puede reprogramar, busca la notificación can_reschedule=TRUEen los metadatos del evento. Si el evento no se puede reprogramar, configurar la etiqueta cloud.google.com/perform-maintenance=true no tiene ningún 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 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. Daña el nodo.
  2. Expulsa los Pods de forma correcta.
  3. Solicita a Compute Engine que inicie el evento de mantenimiento de inmediato, en lugar de esperar el horario programado.

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 la programación

Cuando comienza el evento de mantenimiento, un nodo puede apagarse una o más 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 expulsar 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 programado del host, 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 el recuento de interrupciones para 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 HW/SW Maintenance valor 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}]))

Configuraciones avanzadas para minimizar las interrupciones

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

Habilita el control de interrupciones

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

Para habilitar el control 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, 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 una señal 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, establece 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 la señal SIGTERM de apagado e iniciar un proceso de punto de control. Para obtener más información, consulta Autocheckpoint de TPU.

Proceso de finalización correcta

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

En el siguiente flujo de trabajo, se muestra cómo GKE ejecuta la finalización correcta de nodos cuando hay un cierre de nodos inminente:

  1. En un plazo de 60 segundos, ocurre 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 detienen las cargas de trabajo.
    2. GKE aplica el taint de nodo para evitar que se programen Pods nuevos en el nodo. 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 de controlador de mantenimiento 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 apagado 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.

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

Verifica el progreso de una finalización correcta 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 de nodo inminente, 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 restringen las cargas de trabajo nuevas para que no se programen, 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 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 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 s carácter, 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 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 se establece 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 ha estado inactivo durante el tiempo suficiente, por lo que se omite.
  • 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 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 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 con el 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 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 admitida de GKE es 1.33.3-gke.1118000.
  • Solo se admite el mantenimiento planificado que incluye la can_reschedule=TRUE notificación.
  • 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 en finalizar en un nodo. Los clientes que usan esta función pueden experimentar menos nodos disponibles, hasta el valor de la configuración min-nodes-per-pool, durante un período.

¿Qué sigue?