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 en 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 se migran 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 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 forma opcional, inician las actualizaciones del clúster de GKE.

Usa la estrategia paralela para los nodos de cargas de trabajo en los que puedes tener un solo período de tiempo de inactividad, como para los nodos de cargas de trabajo de entrenamiento. Usa la estrategia progresiva para los nodos de 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 para los nodos de 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 en un grupo de nodos que usan aceleradores. Puedes usar esta estrategia para las cargas de trabajo de entrenamiento. También puedes usarlo para otros tipos de cargas de trabajo en las que el método menos disruptivo para realizar cambios es tener un solo período de inactividad completo 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 muévelas a otros nodos que sigan disponibles.
  2. Activar 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 tareas de mantenimiento y actualización del host, reinicia las cargas de trabajo.

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

Para minimizar las interrupciones mientras recibes cambios críticos en 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, solo puedes realizar el mantenimiento del host si no deseas actualizar la versión de tus nodos de GKE.

Consideraciones antes de comenzar

Antes de comenzar, revisa las siguientes consideraciones:

  • 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 para las interrupciones: Asegúrate de que tus cargas de trabajo se puedan interrumpir durante un período. Estos pasos tardan varias horas en completarse, principalmente debido al tiempo que se requiere 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 reserva o los subbloques de reserva 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 por el nombre de la reserva.
      • BLOCK_NAME: Es el nombre del bloque de reserva.
      • SUB_BLOCK_NAME: Es el nombre del subbloque de reserva.
      • ZONE: Es la zona en la que existe la reserva.

      Compute Engine comienza a vaciar y actualizar todas las instancias del subbloque de forma simultánea. Este proceso puede tardar algunas horas.

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

    • Instancias que usan la programación de mantenimiento independiente: Activa el mantenimiento de las instancias bajo demanda o de las reservas que no usan subbloques aplicando 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 vaciar 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 correcta.

      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

En esta estrategia, se describe un enfoque manual para realizar el mantenimiento de 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 determinado porcentaje de réplicas esté sin conexión de forma temporal.

La estrategia sigue estos pasos de alto nivel:

  1. Identifica y agrupa los nodos por lotes: Elige los grupos de nodos que deseas actualizar. Agrupa los nodos en lotes con un tamaño que se ajuste a la tolerancia a fallas de tu carga de trabajo.
  2. Itera por 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

Antes de comenzar, revisa las siguientes consideraciones:

  • Comprende tu implementación: El éxito requiere un conocimiento detallado de la distribución de la carga de trabajo, la ubicación de las réplicas y los dominios con fallas. Asegúrate de mantener suficiente capacidad de entrega durante todo el proceso.
  • Planifica los tamaños de los lotes: Actualiza los nodos en lotes. El tamaño de cada lote se determina según la tolerancia a errores de tu carga de trabajo. Entre los factores que se deben tener en cuenta, se incluyen los siguientes:
    • La cantidad de réplicas por modelo de entrega.
    • La distribución de réplicas en los nodos y los dominios con fallas.
    • Los PodDisruptionBudgets pueden 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 garantizar 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 los 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 los lotes.
    • Grupos de nodos de varios hosts (TPU, MNNVL): Para estas configuraciones, es probable que desactives 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 de hosts, puedes actualizar tu capacidad desde 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 una programación de mantenimiento independiente.

Elige la estrategia adecuada para tus recursos:

Actualiza las reservas en lotes de subbloques

Para realizar el mantenimiento progresivo de hosts 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 o 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 comando gcloud compute reservations:

    1. Enumera el nombre de la reserva y los IDs de topología de bloque físico y subbloque 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.

      Toma nota de 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 por el nombre de la reserva.
      • ZONE: Es la zona en la que existe la reserva.
      • PROJECT_ID: el ID del proyecto en el que existe la reserva.
      • BLOCK_ID: Es el ID del bloque recuperado de las etiquetas del nodo.

      Registra el nombre del bloque del resultado.

    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 por el nombre de la reserva.
      • BLOCK_NAME: Es el nombre del recurso del bloque de reserva.
      • ZONE: Es la zona en la que existe la reserva.
      • PROJECT_ID: el ID del proyecto en el que existe la reserva.
      • SUBBLOCK_ID: Es el ID del subbloque recuperado de las etiquetas del nodo.

      En el resultado, se muestran detalles sobre el subbloque de reserva coincidente, incluido el nombre del 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 elemento de la lista Calcula las restricciones de tiempo de la sección Consideraciones antes de comenzar anterior. 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 los 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 comando gcloud compute reservations sub-blocks perform-maintenance:

      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 por el nombre de la reserva.
      • BLOCK_NAME: Es el nombre del bloque de reserva.
      • SUB_BLOCK_NAME: Es el nombre del subbloque de reserva.
      • ZONE: Es la zona en la que existe la reserva.

      Compute Engine comienza a vaciar y actualizar todas las instancias del subbloque de forma simultánea. Este proceso puede tardar algunas horas.

    2. Supervisa el estado del mantenimiento. Para ello, consulta el campo de metadatos upcomingGroupMaintenance en los recursos de reserva. Para obtener más información, consulta Visualiza el estado de 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 terminaron el mantenimiento. Sigue las instrucciones para actualizar la versión de GKE de los nodos.

Actualiza nodos en lotes

Para realizar el mantenimiento progresivo de hosts para instancias bajo demanda o 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 los 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 (TPU o GPU):

      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 del 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 elemento de lista Calcula las restricciones de tiempo de la sección Consideraciones antes de comenzar anterior.

  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 la instancia con la API de instances aplicando 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 vaciar 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 correcta.

    2. Supervisar 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 terminaron el mantenimiento. Sigue las instrucciones para actualizar la versión de GKE de los nodos.

Actualiza la versión de GKE de los nodos

Considera la cantidad de nodos que deseas actualizar al mismo tiempo. Con la estrategia paralela, realizaste el mantenimiento del host para todo el 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 en función del 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 cada uno de tus grupos de nodos tiene más de 100 nodos por zona, bórralos y vuelve a crearlos.
  • 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 y por grupo de nodos, borra y vuelve a crear los nodos.

Usa actualizaciones de aumento

  1. Configura las actualizaciones de aumento con el parámetro de configuración 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 de un grupo de nodos, establece el valor del campo maxUnavailable en 18.

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

  2. Actualiza el grupo de nodos ejecutando el siguiente comando. Si deseas actualizar varios grupos de nodos, ejecuta este comando para cada uno de ellos:

    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 más reciente:

  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 de clústeres de 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.