Realiza el mantenimiento del host para los nodos que ejecutan cargas de trabajo de entrenamiento y de inferencia

En este documento, se explica cómo realizar el mantenimiento del host de las instancias de Compute Engine subyacentes para los nodos de los clústeres de Google Kubernetes Engine (GKE). Solo necesitas administrar de forma activa este mantenimiento para ciertos tipos de instancias de Compute Engine que no realizan la migración en vivo, incluidas las instancias con GPU y TPU. Las estrategias que se describen en este documento funcionan bien para las cargas de trabajo de entrenamiento y de inferencia. Si solo necesitas realizar el mantenimiento del host de forma manual para un nodo individual o si tus cargas de trabajo pueden tolerar el mantenimiento automático del host consulta Comprende cómo realizar el mantenimiento del host en GKE.

Estas estrategias realizan el mantenimiento del host para grupos de nodos y, de manera opcional, inician las actualizaciones del clúster de GKE.

Usa la estrategia paralela para los nodos de las cargas de trabajo en los que puedes tener un solo período de inactividad, como los nodos de las cargas de trabajo de entrenamiento. Usa la estrategia progresiva para los nodos de las cargas de trabajo en los que puedes tener lotes de tiempo de inactividad mientras mantienes la disponibilidad de la mayoría de los recursos, como los nodos de las cargas de trabajo de inferencia.

Usa una estrategia paralela para actualizar los nodos de las cargas de trabajo de entrenamiento

Esta estrategia realiza cambios de forma simultánea para un grupo de nodos que usan aceleradores. Puedes usar esta estrategia para las cargas de trabajo de entrenamiento. O bien, puedes usarla para otros tipos de cargas de trabajo en las que el método menos disruptivo para realizar cambios es tener una sola ventana de tiempo de inactividad completa para todos los nodos del grupo y las cargas de trabajo que se ejecutan en ellos.

La estrategia sigue estos pasos de alto nivel:

  1. Detén las cargas de trabajo: selecciona los grupos de nodos y detén las cargas de trabajo que se ejecutan en ellos o mueve las cargas de trabajo a otros nodos que permanezcan disponibles.
  2. Activa el mantenimiento del host: aplica la etiqueta de mantenimiento a todos los nodos seleccionados al mismo tiempo y espera a que se complete el proceso en todos los nodos.
  3. Actualiza la versión de GKE: cambia la versión de GKE de los nodos.
  4. Reinicia las cargas de trabajo: después de que finalicen todas las actualizaciones y el mantenimiento del host, reinicia tus cargas de trabajo.

Las instrucciones proporcionadas realizan cambios para un solo grupo de nodos. Sin embargo, puedes adaptar los pasos para realizar cambios en varios grupos de nodos al mismo tiempo. Asegúrate de que, antes de comenzar con estos pasos, tengas al menos unas horas en las que esta carga de trabajo no necesite ejecutarse en estos nodos.

Para minimizar la interrupción mientras recibes cambios críticos para las instancias de Compute Engine subyacentes y los nodos de GKE, usa este período de inactividad para realizar el mantenimiento del host y las actualizaciones de la versión de GKE. Sin embargo, puedes realizar solo el mantenimiento del host si no deseas actualizar la versión de tus nodos de GKE.

Consideraciones antes de comenzar

Revisa las siguientes consideraciones antes de comenzar:

  • Evita volver a implementar cargas de trabajo: para evitar demoras innecesarias debido a PodDisruptionBudgets, no vuelvas a implementar ninguna carga de trabajo hasta que hayas completado todos los pasos.
  • Planifica la interrupción: asegúrate de que tus cargas de trabajo puedan interrumpirse durante un período. Estos pasos tardan varias horas en completarse, principalmente debido al tiempo requerido para el mantenimiento del host.

Realiza actualizaciones para todos los nodos de forma simultánea

Para realizar el mantenimiento del host y, de manera opcional, las actualizaciones de la versión de GKE, completa los siguientes pasos:

  1. Prepara tus cargas de trabajo: detén tus cargas de trabajo o asegúrate de que hayan tomado una instantánea o un punto de control recientes.

  2. Inicia y supervisa el mantenimiento del host:

    • Subbloques de reservas que usan la programación de mantenimiento agrupada: activa el mantenimiento en las reservas, los bloques de reservas o los subbloques de reservas con el subcomando gcloud compute reservations correspondiente. Por ejemplo, el siguiente comando inicia el mantenimiento de un subbloque:

      gcloud compute reservations sub-blocks perform-maintenance RESERVATION_NAME \
    --block-name=BLOCK_NAME \
    --sub-block-name=SUB_BLOCK_NAME \
    --zone=ZONE

      Reemplaza lo siguiente:

      • RESERVATION_NAME: el nombre de la reserva.
      • BLOCK_NAME: el nombre del bloque de reserva.
      • SUB_BLOCK_NAME: el nombre del subbloque de reserva.
      • ZONE: la zona en la que existe la reserva.

      Compute Engine comienza a desviar y actualizar cualquier instancia en el subbloque de forma simultánea. Este proceso puede tardar algunas horas.

      Para supervisar, consulta el estado del mantenimiento. Para ello, verifica el campo de metadatos upcomingGroupMaintenance en los recursos de reserva. Para obtener más información, consulta Consulta el estado del mantenimiento.

    • Instancias que usan la programación de mantenimiento independiente: activa el mantenimiento para las instancias de procesamiento según demanda o para las reservas que no usan subbloques. Para ello, aplica la etiqueta cloud.google.com/perform-maintenance=true a los nodos de tu grupo de nodos:

      kubectl label nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME cloud.google.com/perform-maintenance=true --overwrite

      Compute Engine comienza a desviar y actualizar las instancias subyacentes de forma simultánea. Este proceso puede tardar algunas horas. Para obtener más información, consulta Proceso de finalización ordenada.

      Para supervisar el estado del mantenimiento, verifica los nodos. GKE quita la etiqueta de mantenimiento cuando se completa el mantenimiento, si se aplicó. Cuando finaliza el mantenimiento, puedes encontrar un registro con el siguiente mensaje en Cloud Logging:

      Maintenance window has completed for this instance. All maintenance
notifications on the instance have been removed.

  3. Opcional: Actualiza la versión de los nodos de GKE: sigue las instrucciones para actualizar la versión de GKE de los nodos.

Usa una estrategia progresiva para actualizar los nodos de las cargas de trabajo de inferencia

Esta estrategia describe un enfoque manual para realizar el mantenimiento en los nodos de GKE que ejecutan cargas de trabajo de inferencia. Implica actualizar los nodos en lotes para mantener la disponibilidad del servicio. Este método es más adecuado para las cargas de trabajo que pueden tolerar que un cierto porcentaje de réplicas estén sin conexión de forma temporal.

La estrategia sigue estos pasos de alto nivel:

  1. Identifica y agrupa los nodos: elige los grupos de nodos que deseas actualizar. Agrupa los nodos en lotes dimensionados según la tolerancia a fallas de tu carga de trabajo.
  2. Itera a través de los lotes: para cada lote, aplica la etiqueta de mantenimiento y supervisa el lote de nodos hasta que se quite la etiqueta.
  3. Actualiza la versión de GKE: después de que todos los lotes completen el mantenimiento del host, cambia la versión de los nodos de GKE.

Consideraciones antes de comenzar

Revisa las siguientes consideraciones antes de comenzar:

  • Comprende tu implementación: el éxito requiere un conocimiento detallado de la distribución de tu carga de trabajo, la ubicación de las réplicas y los dominios con fallas. Asegúrate de mantener una capacidad de entrega suficiente durante todo el proceso.
  • Planifica los tamaños de los lotes: actualiza los nodos en lotes. El tamaño de cada lote está determinado por la tolerancia a fallas de tu carga de trabajo. Entre los factores que debes tener en cuenta, se incluyen los siguientes:
    • La cantidad de réplicas por modelo de entrega
    • La distribución de réplicas en nodos y dominios con fallas
    • PodDisruptionBudgets puede ayudar a aplicar la cantidad máxima de Pods que están inactivos de forma simultánea.
    • Recomendación: Para simplificar la administración, considera dedicar diferentes grupos de nodos a diferentes conjuntos de réplicas, lo que te permite aislar los dominios con fallas a nivel del grupo de nodos.
  • Calcula las restricciones de tiempo: ten en cuenta los siguientes factores de tiempo:
    • Cada lote puede tardar varias horas en completar el paso de mantenimiento del host.
    • Calcula el tamaño mínimo del lote para asegurarte de que todo el mantenimiento finalice dentro de los plazos requeridos:
      1. MAINTENANCE_BLOCKS = floor(HOURS_TO_MAINTENANCE / 4) (donde HOURS_TO_MAINTENANCE es el tiempo total disponible).
      2. MIN_PER_BATCH = TOTAL_NODE_COUNT / MAINTENANCE_BLOCKS
    • El tamaño del lote que elijas debe ser igual o mayor que MIN_PER_BATCH.
  • Revisa tipos de cargas de trabajo específicos: ten en cuenta lo siguiente para los tipos de configuración respectivos:
    • Mezcla de expertos (MOE): asegúrate de que tu estrategia de procesamiento por lotes mantenga la cantidad mínima requerida de réplicas para cada modelo.
    • Entrega desagregada: asegúrate de hacer un seguimiento de todas las réplicas involucradas en la configuración desagregada cuando planifiques lotes.
    • Grupos de nodos de varios hosts (TPU, MNNVL): para estas configuraciones, es probable que quites un grupo de nodos completo a la vez. Planifica tus dominios con fallas en varios grupos de nodos según corresponda.

Realiza actualizaciones progresivas en lotes

Para realizar actualizaciones progresivas de mantenimiento del host, puedes actualizar tu capacidad de las reservas que usan la programación de mantenimiento agrupada en lotes de uno o más subbloques, o puedes actualizar conjuntos específicos de nodos en el clúster por nombre con la programación de mantenimiento independiente.

Elige la estrategia adecuada para tus recursos:

Actualiza las reservas en lotes de subbloques

Para realizar el mantenimiento progresivo del host para las reservas de capacidad en lotes de subbloques, completa los siguientes pasos:

  1. Identifica las reservas para el mantenimiento: identifica el nombre de la reserva de capacidad y los bloques de reserva o los subbloques de reserva que usa el clúster de GKE. Para ello, realiza una búsqueda con las etiquetas de nodo de GKE y el gcloud compute reservations comando:

    1. Enumera el nombre de la reserva y los IDs de la topología física de bloques y subbloques de los nodos de tu grupo de nodos:

      kubectl get nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME \
    -o custom-columns='NAME:.metadata.name,RESERVATION:.metadata.labels.cloud\.google\.com/reservation-name,BLOCK_ID:.metadata.labels.cloud\.google\.com/gce-topology-block,SUBBLOCK_ID:.metadata.labels.cloud\.google\.com/gce-topology-subblock'

      Reemplaza NODE_POOL_NAME por el nombre del grupo de nodos.

      Ten en cuenta los valores de salida: el nombre de la reserva (por ejemplo, nvidia-gb300-m7kp2xq9vd4j1), el ID del bloque (por ejemplo, 3f2a8c9b1d4e0756f8a2b3c1d9e4f0a5) y el ID del subbloque (por ejemplo, e7b91f4a3c2d58069e1a4b7f3d2c8056).

    2. Para identificar el nombre del recurso del bloque de reserva, consulta la lista de bloques de reserva de Compute Engine con el nombre de la reserva y filtra por el ID del bloque:

      gcloud compute reservations blocks list RESERVATION_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --filter="physicalTopology.block=BLOCK_ID"

      Reemplaza lo siguiente:

      • RESERVATION_NAME: el nombre de la reserva.
      • ZONE: la zona en la que existe la reserva.
      • PROJECT_ID: el ID del proyecto en el que existe la reserva.
      • BLOCK_ID: el ID del bloque recuperado de las etiquetas de nodo.

      Registra el nombre del bloque de la salida.

    3. Para identificar el nombre del recurso del subbloque de reserva, consulta la lista de subbloques de reserva con el nombre de la reserva y el nombre del bloque, y filtra por el ID del subbloque:

      gcloud compute reservations sub-blocks list RESERVATION_NAME \
    --block-name=BLOCK_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --filter="physicalTopology.subBlock=SUBBLOCK_ID"

      Reemplaza lo siguiente:

      • RESERVATION_NAME: el nombre de la reserva.
      • BLOCK_NAME: el nombre del recurso del bloque de reserva.
      • ZONE: la zona en la que existe la reserva.
      • PROJECT_ID: el ID del proyecto en el que existe la reserva.
      • SUBBLOCK_ID: el ID del subbloque recuperado de las etiquetas de nodo.

      El resultado muestra detalles sobre el subbloque de reserva coincidente, incluido su nombre de recurso.

  2. Divide las reservas en lotes: divide los subbloques de reserva de capacidad identificados en lotes iguales. Determina el tamaño del lote con la fórmula que se describe en el Calcula las restricciones de tiempo elemento de lista en la sección anterior Consideraciones antes de comenzar. Cada lote corresponde a uno o más subbloques de reserva, y cada lote debe tener al menos el tamaño de un subbloque.

  3. Realiza el mantenimiento del host: para cada lote, completa los siguientes pasos:

    1. Selecciona un lote de subbloques de reserva y activa el mantenimiento del host. Puedes activar el mantenimiento en tus reservas, bloques de reserva o subbloques de reserva. Para tipos de máquinas como A4X, A4X Max, TPU v6e y TPU7x, debes activar el mantenimiento de esta manera. El mantenimiento se realiza en grupos de subbloques. Usa el gcloud compute reservations sub-blocks perform-maintenance comando:

      gcloud compute reservations sub-blocks perform-maintenance RESERVATION_NAME \
    --block-name=BLOCK_NAME \
    --sub-block-name=SUB_BLOCK_NAME \
    --zone=ZONE

      Reemplaza lo siguiente:

      • RESERVATION_NAME: el nombre de la reserva.
      • BLOCK_NAME: el nombre del bloque de reserva.
      • SUB_BLOCK_NAME: el nombre del subbloque de reserva.
      • ZONE: la zona en la que existe la reserva.

      Compute Engine comienza a desviar y actualizar cualquier instancia en el subbloque de forma simultánea. Este proceso puede tardar algunas horas.

    2. Supervisa el estado del mantenimiento. Para ello, consulta el estado del mantenimiento. Para ello, verifica el campo de metadatos upcomingGroupMaintenance en los recursos de reserva. Para obtener más información, consulta Consulta el estado del mantenimiento de la reserva.

    3. Repite los pasos anteriores para cada lote restante hasta que hayas completado el mantenimiento del host para todos los lotes.

  4. Opcional: Actualiza la versión de los nodos de GKE: realiza este paso solo después de que se complete el mantenimiento del host para todos los subbloques de reserva, para evitar situaciones en las que los nodos de GKE se implementen en hosts que aún no hayan terminado el mantenimiento. Sigue las instrucciones para actualizar la versión de GKE de los nodos.

Actualiza los nodos en lotes

Para realizar el mantenimiento progresivo del host para las instancias de procesamiento según demanda o las reservas que no admiten subbloques en lotes, completa los siguientes pasos:

  1. Identifica los nodos para el mantenimiento: identifica todos los nodos en los que deseas realizar el mantenimiento y guarda esta lista. Para identificar nodos, usa cualquiera de los siguientes métodos o selecciónalos de forma manual:

    • Obtén todos los nodos del clúster que usan aceleradores (TPUs o GPUs):

      kubectl get nodes -o json | jq -r '.items[] | select(.spec.taints[]? | select(.key=="nvidia.com/gpu" or .key=="google.com/tpu")) | .metadata.name'

    • Obtén todos los nodos de un grupo de nodos específico:

      kubectl get nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME --no-headers -o custom-columns=":metadata.name"

      Reemplaza NODE_POOL_NAME por el nombre del grupo de nodos.

    • Obtén todos los nodos con una etiqueta específica:

      kubectl get nodes -l LABEL -o jsonpath='{.items[*].metadata.name}'

      Reemplaza LABEL por la etiqueta de nodo.

  2. Divide los nodos en lotes: divide los nodos identificados en lotes iguales. Determina el tamaño del lote con la fórmula que se describe en el Calcula las restricciones de tiempo elemento de lista en la sección anterior Consideraciones antes de comenzar.

  3. Realiza el mantenimiento del host: para cada lote, completa los siguientes pasos:

    1. Selecciona un lote de nodos y activa el mantenimiento en la capa de instancia con la API de instances. Para ello, aplica la etiqueta de mantenimiento:

      kubectl label nodes LIST_OF_NODES_IN_BATCH cloud.google.com/perform-maintenance=true --overwrite

      Reemplaza LIST_OF_NODES_IN_BATCH por una lista de nodos del lote separados por espacios. Por ejemplo, node-1 node-2 node-3.

      Compute Engine comienza a desviar y actualizar las instancias subyacentes de forma simultánea. Este proceso puede tardar algunas horas. Para obtener más información, consulta Proceso de finalización ordenada.

    2. Supervisa el estado del mantenimiento del host. GKE quita la etiqueta de mantenimiento cuando se completa el mantenimiento, si se aplicó. Cuando finaliza el mantenimiento, puedes encontrar un registro con el siguiente mensaje en Logging:

      Maintenance window has completed for this instance. All maintenance
notifications on the instance have been removed.

    3. Repite los pasos anteriores para cada lote restante hasta que hayas completado el mantenimiento del host para todos los lotes.

  4. Opcional: Actualiza la versión de los nodos de GKE: realiza este paso solo después de que se complete el mantenimiento del host para todos los nodos, para evitar situaciones en las que los nodos de GKE se implementen en hosts que aún no hayan terminado el mantenimiento. Sigue las instrucciones para actualizar la versión de GKE de los nodos.

Actualiza la versión de GKE de los nodos

Ten en cuenta la cantidad de nodos que deseas actualizar al mismo tiempo. Con la estrategia paralela, realizaste el mantenimiento del host para todo tu grupo de nodos o varios grupos de nodos al mismo tiempo. Con la estrategia progresiva, realizaste el mantenimiento del host en lotes. Determina qué método de actualización usarás según el tamaño de los grupos de nodos:

  • Estrategia paralela: si tus grupos de nodos tienen 100 nodos o menos por zona, usa actualizaciones de aumento. Si tus grupos de nodos tienen más de 100 nodos por zona, borra y vuelve a crear los grupos de nodos.
  • Estrategia progresiva: si tus lotes tienen 100 nodos, por zona, por grupo de nodos o menos, usa actualizaciones de aumento. Si tus lotes tienen más de 100 nodos, por zona, por grupo de nodos, borra y vuelve a crear los nodos.

Usa las actualizaciones de aumento

  1. Configura las actualizaciones de aumento, con el parámetro maxUnavailable para determinar cuántos nodos pueden no estar disponibles al mismo tiempo, por zona, en un grupo de nodos. Por ejemplo, si tienes 18 nodos en una zona en un grupo de nodos, establece el valor del campo maxUnavailable en 18.

    Este parámetro funciona mejor cuando se usa la capacidad de una reserva en la que no tienes capacidad en exceso. Para obtener más información sobre por qué usar este parámetro, consulta Actualiza en un entorno con recursos restringidos ambiente.

  2. Ejecuta el siguiente comando para actualizar el grupo de nodos. Si deseas actualizar varios grupos de nodos, ejecuta este comando para cada grupo de nodos:

    gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool NODE_POOL_NAME \
    --cluster-version VERSION \
    --location CONTROL_PLANE_LOCATION \
    --quiet

    Reemplaza lo siguiente:

Borra y vuelve a crear los nodos

Borra el grupo de nodos y vuelve a crearlo con la versión posterior:

  1. Borra el grupo de nodos:

    gcloud container node-pools delete NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location CONTROL_PLANE_LOCATION

  2. Vuelve a crear el grupo de nodos y pasa la versión nueva con la marca --cluster-version. Pasa el destino de actualización automática recomendado para el grupo de nodos. Para obtener más información, consulta Obtén información sobre las actualizaciones de los grupos de nodos del clúster Standard. Si tu clúster no tiene un destino de actualización automática recomendado, consulta las entradas más recientes de Actualizaciones de versiones en las notas de la versión de GKE.