Desplegar cargas de trabajo de TPUs en GKE Standard

En esta página se explica cómo acelerar las cargas de trabajo de aprendizaje automático (ML) con TPUs en Google Kubernetes Engine (GKE). Las TPUs se han diseñado para procesar multiplicaciones de matrices, como el entrenamiento de modelos de aprendizaje profundo a gran escala. Las TPUs están optimizadas para gestionar los enormes conjuntos de datos y los modelos complejos del aprendizaje automático, por lo que son más rentables y eficientes en cuanto al consumo de energía para las cargas de trabajo de aprendizaje automático debido a su rendimiento superior. En esta guía, aprenderás a implementar cargas de trabajo de aprendizaje automático mediante aceleradores de TPU de Cloud, configurar cuotas para TPUs, configurar actualizaciones para grupos de nodos que ejecuten TPUs y monitorizar métricas de cargas de trabajo de TPU.

Este tutorial está dirigido a ingenieros de aprendizaje automático, administradores y operadores de plataformas que quieran usar la orquestación de contenedores de Kubernetes para gestionar cargas de trabajo de entrenamiento, ajuste e inferencia de modelos a gran escala con TPUs. Para obtener más información sobre los roles habituales y las tareas de ejemplo que se mencionan en el contenido de Google Cloud , consulta Roles y tareas de usuario habituales de GKE.

Antes de leer esta página, asegúrate de que conoces los siguientes conceptos:

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la CLI de gcloud, obtén la versión más reciente ejecutando el comando gcloud components update. Es posible que las versiones anteriores de la interfaz de línea de comandos de gcloud no admitan la ejecución de los comandos de este documento.

Planificar la configuración de TPU

Planifica la configuración de las TPU en función de tu modelo y de la cantidad de memoria que necesite. Antes de usar esta guía para desplegar tus cargas de trabajo en una TPU, completa los pasos de planificación que se indican en Planificar la configuración de la TPU.

Asegúrate de que tienes cuota de TPU

En las siguientes secciones se explica cómo asegurarse de que tiene suficiente cuota al usar TPUs en GKE.

Cuota de VMs bajo demanda o de acceso puntual

Si vas a crear un grupo de nodos de segmento de TPU con VMs bajo demanda o Spot, debes tener suficiente cuota de TPU disponible en la región que quieras usar.

Para crear un pool de nodos de un slice de TPU que consuma una reserva de TPU, no se necesita ninguna cuota de TPU.1 Puedes saltarte esta sección si vas a usar TPUs reservadas.

Para crear un grupo de nodos de un slice de TPU bajo demanda o Spot en GKE, se necesita cuota de la API Compute Engine. La cuota de la API Compute Engine (compute.googleapis.com) no es la misma que la cuota de la API Cloud TPU (tpu.googleapis.com), que se necesita al crear TPUs con la API Cloud TPU.

Para comprobar el límite y el uso actual de la cuota de la API Compute Engine para las TPUs, sigue estos pasos:

  1. Ve a la página Cuotas de la Google Cloud consola:

    Ir a Cuotas

  2. En el cuadro Filtrar, haz lo siguiente:

    1. Usa la siguiente tabla para seleccionar y copiar la propiedad de la cuota en función de la versión de TPU y el tipo de máquina. Por ejemplo, si tienes previsto crear nodos de TPU v5e bajo demanda cuyo tipo de máquina empiece por ct5lp- , introduce Name: TPU v5 Lite PodSlice chips.

      Versión de TPU, el tipo de máquina empieza por Propiedad y nombre de la cuota de instancias bajo demanda Propiedad y nombre de la cuota de instancias Spot2
      TPU v3
      ct3- 
      Dimensions (e.g. location):
      tpu_family:CT3
      		 No aplicable
      TPU v3
      ct3p- 
      Dimensions (e.g. location):
      tpu_family:CT3P
      		 No aplicable
      TPU v4
      ct4p- 
      Name:
      TPU v4 PodSlice chips
      		 
      Name:
      Preemptible TPU v4 PodSlice chips
      TPU v5e
      ct5lp- 
      Name:
      TPU v5 Lite PodSlice chips
      		 
      Name:
      Preemptible TPU v5 Lite Podslice
      chips
      TPU v5p
      ct5p- 
      Name:
      TPU v5p chips
      		 
      Name:
      Preemptible TPU v5p chips
      TPU Trillium
      ct6e- 
      Dimensions (e.g. location):
      tpu_family:CT6E
      		 
      Name:
      Preemptible TPU slices v6e
      Ironwood (TPU7x) (vista previa)
      tpu7x-standard-4t 
      Dimensions (e.g. location):
      tpu_family:tpu7x
      		 
      Name:
      Preemptible TPU slices tpu7x

    2. Selecciona la propiedad Dimensiones (por ejemplo, ubicaciones) e introduce region: seguido del nombre de la región en la que tienes previsto crear las TPUs en GKE. Por ejemplo, introduce region:us-west4 si tienes previsto crear nodos de segmento de TPU en la zona us-west4-a. La cuota de TPU es regional, por lo que todas las zonas de la misma región consumen la misma cuota de TPU.

Si no hay ninguna cuota que coincida con el filtro que has introducido, significa que no se ha concedido al proyecto ninguna de las cuotas especificadas para la región que necesitas y debes solicitar un ajuste de cuota de TPU.

Cuando se crea una reserva de TPU, tanto el límite como los valores de uso actuales de la cuota correspondiente aumentan en el número de chips de la reserva de TPU. Por ejemplo, si se crea una reserva de 16 chips TPU v5e cuyo tipo de máquina empiece por ct5lp-, tanto el límite como el uso actual de la cuota TPU v5 Lite PodSlice chips en la región correspondiente aumentarán en 16.

  1. Cuando crees un grupo de nodos de un slice de TPU, usa las marcas --reservation y --reservation-affinity=specific para crear una instancia reservada. Las reservas de TPU están disponibles al comprar una confirmación. ↩

  2. Cuando crees un grupo de nodos de un slice de TPU, usa la marca --spot para crear una instancia Spot. ↩

Cuotas de recursos adicionales de GKE

Es posible que tengas que aumentar las siguientes cuotas relacionadas con GKE en las regiones en las que GKE crea tus recursos.

  • Cuota de Persistent Disk SSD (GB): el disco de arranque de cada nodo de Kubernetes requiere 100 GB de forma predeterminada. Por lo tanto, esta cuota debe ser al menos tan alta como el producto del número máximo de nodos de GKE que preveas crear y 100 GB (nodos × 100 GB).
  • Cuota de direcciones IP en uso: cada nodo de Kubernetes consume una dirección IP. Por lo tanto, esta cuota debe ser al menos tan alta como el número máximo de nodos de GKE que preveas crear.
  • Asegúrate de que max-pods-per-node se corresponda con el intervalo de la subred: cada nodo de Kubernetes usa intervalos de IP secundarios para los pods. Por ejemplo, max-pods-per-node de 32 requiere 64 direcciones IP, lo que se traduce en una subred /26 por nodo. Ten en cuenta que este intervalo no se debe compartir con ningún otro clúster. Para evitar agotar el intervalo de direcciones IP, usa la marca --max-pods-per-node para limitar el número de pods que se pueden programar en un nodo. La cuota de max-pods-per-node debe ser al menos tan alta como el número máximo de nodos de GKE que preveas crear.

Para solicitar un aumento de la cuota, consulta Solicitar un ajuste de cuota.

Asegurar la disponibilidad de las reservas

Para crear un grupo de nodos de segmento de TPU mediante una reserva, esta debe tener suficientes chips de TPU disponibles en el momento de la creación del grupo de nodos.

Para ver qué reservas hay en un proyecto y cuántos chips de TPU hay disponibles en una reserva de TPU, consulta la lista de tus reservas.

Crear un clúster

Puedes crear un clúster que use TPUs mediante la CLI de Google Cloud o un kit de procesamiento acelerado (XPK).

  • Usa la CLI de Google Cloud para crear manualmente tu instancia de clúster de GKE si quieres personalizarla con precisión o ampliar los entornos de producción de GKE que ya tengas.
  • Usa XPK para crear rápidamente clústeres de GKE y ejecutar cargas de trabajo para pruebas de concepto y pruebas. Para obtener más información e instrucciones, consulta el archivo README de XPK.

En este documento se describe cómo configurar las TPU mediante Google Cloud CLI.

Crea un clúster de GKE en el modo Estándar en una región con TPUs disponibles.

Práctica recomendada:

Usa clústeres regionales, que proporcionan una alta disponibilidad del plano de control de Kubernetes.

gcloud container clusters create CLUSTER_NAME \
  --location LOCATION \
  --cluster-version VERSION

Haz los cambios siguientes:

  • CLUSTER_NAME: el nombre del nuevo clúster.
  • LOCATION: la región en la que está disponible tu capacidad de TPU.
  • VERSION: la versión de GKE, que debe admitir el tipo de máquina que quieras usar. Ten en cuenta que es posible que la versión predeterminada de GKE no esté disponible para tu TPU de destino. Para saber cuáles son las versiones mínimas de GKE disponibles por tipo de máquina de TPU, consulta Disponibilidad de TPU en GKE.

Provisionar TPUs

Para aprovisionar TPUs en GKE, tienes las siguientes opciones de configuración:
  • Crear un grupo de nodos manualmente: puedes crear un grupo de nodos con una versión y una topología de TPU específicas.
  • Usar el aprovisionamiento automático de nodos de GKE: puedes habilitar el aprovisionamiento automático de nodos a nivel de clúster y, a continuación, en el manifiesto de tu pod, usar un nodeSelector para especificar la versión y la topología de la TPU. Cuando un pod pendiente coincide con estos selectores, GKE crea automáticamente un nuevo grupo de nodos que cumple los requisitos. Con este método, debes definir límites de recursos a nivel de clúster para las TPUs.
  • Define ComputeClasses personalizados: puedes solicitar TPUs mediante ComputeClasses personalizados. Las ComputeClasses personalizadas permiten a los administradores de la plataforma definir una jerarquía de configuraciones de nodos para que GKE las priorice durante las decisiones de escalado de nodos, de modo que las cargas de trabajo se ejecuten en el hardware seleccionado.

Crear un grupo de nodos manualmente

Puedes crear un grupo de nodos de segmento de TPU de un solo host o de varios hosts.

Crear un grupo de nodos de segmento de TPU de un solo host

Puedes crear un grupo de nodos de segmento de TPU de un solo host con la CLI de Google Cloud, Terraform o la Google Cloud consola.

gcloud

gcloud container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE \
    [--sandbox=type=gvisor]

Haz los cambios siguientes:

  • NODE_POOL_NAME: el nombre del nuevo grupo de nodos.
  • LOCATION: el nombre de la zona en función de la versión de TPU que quieras usar. Para identificar una ubicación disponible, consulta Disponibilidad de las TPUs en GKE.
  • CLUSTER_NAME: el nombre del clúster.
  • NODE_ZONES: lista separada por comas de una o varias zonas en las que GKE crea el grupo de nodos.
  • MACHINE_TYPE: la versión y el tipo de TPU. Por ejemplo, usa tpu7x-standard-4t para Ironwood (TPU7x).

También puedes usar los siguientes elementos opcionales:

  • --num-nodes=NUM_NODES: número inicial de nodos del grupo de nodos en cada zona.

    Práctica recomendada:

    Si usas la marca enable-autoscaling en el grupo de nodos, asigna el valor 0 a num-nodes para que el autoescalador aprovisione nodos adicionales en cuanto lo requieran tus cargas de trabajo.

  • --reservation=RESERVATION_NAME: nombre de la reserva que usa GKE al crear el grupo de nodos. Si omites esta marca, GKE usará las TPUs disponibles. Para obtener más información sobre las reservas de TPU, consulta el artículo Acerca de las reservas de TPU de Cloud.

  • --node-labels cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: indica a GKE que el grupo de nodos de la porción de TPU de un solo host forma parte de una colección. Usa esta marca si se cumplen las siguientes condiciones:

    • El grupo de nodos ejecuta la carga de trabajo de inferencia en el nuevo grupo de nodos.
    • El grupo de nodos usa TPU Trillium.
    • El grupo de nodos no usa Spot VMs.

    Para obtener más información sobre la gestión de la programación de recolecciones, consulta Gestionar la programación de recolecciones en slices de TPU de un solo host.

  • --enable-autoscaling: crea un grupo de nodos con el escalado automático habilitado. Requiere las siguientes marcas adicionales:

    • --total-min-nodes=TOTAL_MIN_NODES: número mínimo de todos los nodos del grupo de nodos.
    • --total-max-nodes=TOTAL_MAX_NODES: número máximo de todos los nodos del grupo de nodos.
    • --location-policy=ANY: prioriza el uso de reservas sin usar y reduce el riesgo de interrupción de las máquinas virtuales de acceso puntual.

  • --spot: define que el grupo de nodos use máquinas virtuales de acceso puntual para los nodos del grupo de nodos. No se puede cambiar después de crear el grupo de nodos.

  • --flex-start: define que el grupo de nodos use VMs de inicio flexible. Las VMs de inicio flexible se crean con la opción de consumo inicio flexible. Para obtener más información, consulta Ejecutar una carga de trabajo de un lote pequeño con TPUs y VMs de inicio flexible.

Para ver una lista completa de todas las marcas que puedes especificar, consulta la referencia de gcloud container clusters create.

Terraform

  1. Asegúrate de usar la versión 4.84.0 o una posterior del proveedor google.
  2. Añade el siguiente bloque a tu configuración de Terraform:
resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]

  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    spot = true
    flex_start = false
  }
}

Haz los cambios siguientes:

  • NODE_POOL_RESOURCE_NAME: nombre del recurso del grupo de nodos en la plantilla de Terraform.
  • PROJECT_ID: tu ID de proyecto.
  • CLUSTER_NAME: el nombre del clúster.
  • POOL_NAME: nombre del grupo de nodos que se va a crear.
  • CLUSTER_LOCATION: las zonas de computación del clúster. Especifica la región en la que está disponible la versión de TPU. Para obtener más información, consulta Seleccionar una versión y una topología de TPU.
  • NODE_ZONES: lista separada por comas de una o varias zonas en las que GKE crea el grupo de nodos.
  • MACHINE_TYPE: el tipo de máquina TPU que se va a usar. Para ver los tipos de máquina compatibles con TPU, consulta la tabla de la sección Elegir la versión de TPU.

También puedes usar las siguientes variables:

  • autoscaling: crea un grupo de nodos con el escalado automático habilitado. En el caso de las porciones de TPU de un solo host, GKE se escala entre los valores TOTAL_MIN_NODES y TOTAL_MAX_NODES.
    • TOTAL_MIN_NODES: número mínimo de todos los nodos del grupo de nodos. Este campo es opcional, a menos que también se especifique el ajuste automático de escala.
    • TOTAL_MAX_NODES: número máximo de todos los nodos del grupo de nodos. Este campo es opcional, a menos que también se especifique el ajuste automático de escala.
  • RESERVATION_NAME: Si usas Acerca de las reservas de TPU de Cloud, esta es la lista de etiquetas de los recursos de reserva que se usarán al crear el grupo de nodos. Para obtener más información sobre cómo rellenar el campo RESERVATION_LABEL_VALUES en reservation_affinity, consulta Proveedor de Terraform.
  • spot: define el grupo de nodos para usar máquinas virtuales de acceso puntual en los nodos de TPU. No se puede cambiar después de crear el grupo de nodos. Para obtener más información, consulta VMs de acceso puntual.
  • flex_start: define que el grupo de nodos use la opción de consumo inicio flexible. No se puede definir como true si spot está habilitado. El inicio flexible se admite en GKE 1.33.0-gke.1712000 o versiones posteriores.

Consola

Para crear un grupo de nodos con TPUs, sigue estos pasos:

  1. Ve a la página Google Kubernetes Engine en la Google Cloud consola.

    Ir a Google Kubernetes Engine

  2. En la lista de clústeres, haga clic en el nombre del clúster que quiera modificar.

  3. Haz clic en Añadir grupo de nodos.

  4. En la sección Detalles del grupo de nodos, marca la casilla Especificar ubicaciones de nodos.

  5. Selecciona la zona en función de la versión de TPU que quieras usar. Para identificar una zona disponible, consulta Disponibilidad de TPU en GKE.

  6. En el panel de navegación, haga clic en Nodos.

  7. En la sección Configuración de la máquina, selecciona TPUs.

  8. En el menú desplegable Serie, selecciona una de las siguientes opciones:

    • CT3 TPU v3, dispositivo de un solo host
    • CT3P: TPU v3, segmento de pod multihost
    • CT4P: TPU v4
    • CT5LP: TPU v5e
    • CT5P: TPU v5p
    • CT6E: TPU Trillium (v6e)

  9. En el menú desplegable Tipo de máquina, selecciona el nombre de la máquina que quieras usar para los nodos. Consulta la tabla Elegir la versión de TPU para saber cómo definir el tipo de máquina y la topología de TPU que crean un pool de nodos de segmento de TPU de un solo host.

  10. En el menú desplegable Topología de TPU, selecciona la topología física del slice de TPU.

  11. En el cuadro de diálogo Cambios necesarios, haga clic en Hacer cambios.

  12. Asegúrate de que el Tipo de disco de arranque sea Disco persistente estándar o Disco persistente SSD.

  13. Si quieres, marca la casilla Habilitar nodos en VMs Spot para usar VMs Spot en los nodos del grupo de nodos.

  14. Haz clic en Crear.

Crear un grupo de nodos de un slice de TPU de varios hosts

Los pasos para crear un grupo de nodos de un slice de TPU de varios hosts varían en función de si usas Ironwood (TPU7x) o una versión anterior de TPU.

Ironwood (TPU7x)

Puedes crear un grupo de nodos de slice de TPU multihost en la versión Ironwood (TPU7x) mediante Google Cloud CLI o Terraform:

gcloud

Para crear un grupo de nodos de un segmento de TPU de varios hosts con Ironwood (TPU7x), primero debes crear una política de carga de trabajo.

  1. Crea una política de cargas de trabajo:

    gcloud compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type=HIGH_THROUGHPUT \
    --accelerator-topology=TPU_TOPOLOGY \
    --project=PROJECT_ID \
    --region=REGION

    Haz los cambios siguientes:

    • WORKLOAD_POLICY_NAME: un nombre para tu política de carga de trabajo.
    • TPU_TOPOLOGY: la topología de la TPU Ironwood (TPU7x). Por ejemplo, 2x2x2. Para ver todas las topologías de Ironwood (TPU7x) admitidas, consulta la sección de topología.
    • PROJECT_ID: tu ID de proyecto Google Cloud .
    • REGION: la región de la política de cargas de trabajo. Una política de carga de trabajo es un recurso regional y se puede reutilizar en grupos de nodos que compartan la misma topología.

  2. Crea el grupo de nodos con la política de carga de trabajo:

    gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --machine-type=tpu7x-standard-4t \
  --placement-policy=WORKLOAD_POLICY_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --node-locations=NODE_ZONE \
  --project=PROJECT_ID \
  --reservation=RESERVATION_NAME \
  --reservation-affinity=specific

    Haz los cambios siguientes:

    • NODE_POOL_NAME: el nombre del nuevo grupo de nodos.
    • CLUSTER_NAME: el nombre de tu clúster de GKE.
    • WORKLOAD_POLICY_NAME: el nombre de la política de carga de trabajo que has creado.
    • CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.
    • NODE_ZONE: el nombre de la zona en función de la versión de TPU que quieras usar. Para identificar una ubicación disponible, consulta Disponibilidad de las TPUs en GKE.
    • PROJECT_ID: tu ID de proyecto Google Cloud .
    • RESERVATION_NAME: el nombre de la reserva que se va a usar.

    En este comando, la marca --tpu-topology se ha sustituido por la marca --placement-policy.

Terraform

  1. Asegúrate de usar la versión 4.84.0 o una posterior del proveedor google.

  2. Crea una política de cargas de trabajo:

    resource "google_compute_resource_policy" {
  name   = "WORKLOAD_POLICY_NAME"
  region = CLUSTER_LOCATION
  workload_policy {
    type = "HIGH_THROUGHPUT"
    accelerator_topology = "TPU_TOPOLOGY"
  }
}

    Haz los cambios siguientes:

    • WORKLOAD_POLICY_NAME: un nombre para tu política de carga de trabajo.
    • CLUSTER_LOCATION: ubicación de cálculo del clúster. Te recomendamos que tengas un clúster regional para aumentar la fiabilidad del plano de control de Kubernetes. También puedes usar un clúster zonal. Para obtener más información, consulta Seleccionar una versión y una topología de TPU.
    • TPU_TOPOLOGY: la topología de la TPU Ironwood (TPU7x). Por ejemplo, 2x2x2. Para ver todas las topologías de Ironwood (TPU7x) compatibles, consulta Planificar TPUs.

    Para obtener más información sobre la referencia de google_compute_resource_policy, consulta Proveedor de Terraform.

  3. En tu configuración de Terraform, añade el siguiente bloque:

    resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]
  initial_node_count = NUM_NODES

  autoscaling {
    max_node_count = MAX_NODES
    location_policy      = "ANY"
  }
  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    flex_start = false
    spot = true
  }

  placement_policy {
    policy_name = WORKLOAD_POLICY_NAME
  }
}

    Haz los cambios siguientes:

    • NODE_POOL_RESOURCE_NAME: el nombre del recurso de grupo de nodos en la plantilla de Terraform.
    • PROJECT_ID: tu ID de proyecto.
    • CLUSTER_NAME: el nombre del clúster al que quieres añadir el grupo de nodos.
    • POOL_NAME: el nombre del grupo de nodos que se va a crear.
    • NODE_ZONES: lista separada por comas de una o varias zonas en las que GKE crea el grupo de nodos.
    • NUM_NODES: número de nodos del grupo de nodos. Debe ser cero o el producto del número de chips de TPU dividido entre cuatro, ya que en las porciones de TPU de varios hosts, cada nodo de la porción de TPU tiene cuatro chips. Por ejemplo, si TPU_TOPOLOGY es 4x8, hay 32 chips, lo que significa que NUM_NODES debe ser 8. Para obtener más información sobre las topologías de TPU, consulta la tabla de la sección Elegir la versión de TPU.
    • TPU_TOPOLOGY: indica la topología física seleccionada del segmento de TPU. El formato de la topología depende de la versión de TPU que estés usando. Para obtener más información sobre las topologías de TPU, consulta la tabla de la sección Elegir una topología.

    También puedes usar las siguientes variables:

    • RESERVATION_NAME: si usas una reserva de TPU, proporciona una lista de etiquetas de recursos de reserva que se usarán al crear el grupo de nodos. Para obtener más información sobre cómo rellenar el campo RESERVATION_LABEL_VALUES en reservation_affinity, consulta Proveedor de Terraform.
    • autoscaling: crea un grupo de nodos con el autoescalado habilitado. Cuando GKE escala un grupo de nodos de un segmento de TPU multihost, escala el grupo de nodos de forma atómica de cero al tamaño máximo.
      • MAX_NODES: tamaño máximo del grupo de nodos. El valor debe ser igual al producto de los valores definidos en TPU_TOPOLOGY ({A}x{B}x{C}) dividido por el número de chips de cada máquina virtual. Por ejemplo, si TPU_TOPOLOGY es 2x2x2, el producto es 8. Como cada VM de tpu7x-standard-4t tiene 4 chips, el número de nodos es 2.
    • spot: el grupo de nodos que usará Spot VMs para los nodos de la porción de TPU. Este ajuste no se puede cambiar después de crear el grupo de nodos. Para obtener más información, consulta Máquinas virtuales de acceso puntual.
    • flex_start: el grupo de nodos que usará la opción de consumo flex-start. Este ajuste no se puede definir en true si spot está habilitado.

Otras versiones de TPU

Puedes crear un grupo de nodos de slice de TPU multihost en las versiones v3, v4, v5p, v5e y Trillium (v6e) mediante la CLI de Google Cloud, Terraform o la Google Cloud consola.

gcloud

  gcloud container node-pools create POOL_NAME \
      --location=CONTROL_PLANE_LOCATION \
      --cluster=CLUSTER_NAME \
      --node-locations=NODE_ZONE \
      --machine-type=MACHINE_TYPE \
      --tpu-topology=TPU_TOPOLOGY \
      [--num-nodes=NUM_NODES] \
      [--spot \]
      [--flex-start \]
      [--enable-autoscaling \
        --max-nodes MAX_NODES]
      [--reservation-affinity=specific \
      --reservation=RESERVATION_NAME] \
      [--node-labels cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME,cloud.google.com/gke-workload-type=HIGH_AVAILABILITY]
      [--placement-type=COMPACT]

Haz los cambios siguientes:

  • POOL_NAME: el nombre del nuevo grupo de nodos.
  • CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.
  • CLUSTER_NAME: el nombre del clúster.
  • NODE_ZONES: el nombre de la zona en función de la versión de TPU que quieras usar. Para identificar una ubicación disponible, consulta Disponibilidad de las TPUs en GKE.
  • MACHINE_TYPE: el tipo de máquina que se va a usar en los nodos. Para obtener más información sobre los tipos de máquinas disponibles, consulta Elegir la versión de TPU.

  • TPU_TOPOLOGY: la topología física de la porción de TPU. El formato de la topología depende de la versión de la TPU. Para obtener más información sobre las topologías de TPU, consulta la tabla del artículo Elegir una topología.

    Para obtener más información, consulta Topología.

    También puedes usar las siguientes marcas:

  • NUM_NODES: el número de nodos del grupo de nodos. Debe ser cero o el producto de los valores definidos en TPU_TOPOLOGY ({A}x{B}x{C}) dividido entre el número de chips de cada máquina virtual. En el caso de las TPU v4 y v5e multihost, el número de chips de cada VM es cuatro. Por lo tanto, si tu TPU_TOPOLOGY es 2x4x4 (TPU v4 con cuatro chips en cada VM), entonces el NUM_NODES es 32/4, lo que equivale a 8. Si omite esta marca, el número de nodos se calcula y se establece de forma predeterminada en función de la topología y el tipo de máquina.

  • RESERVATION_NAME: el nombre de la reserva que usa GKE al crear el grupo de nodos. Si omites esta marca, GKE usará los grupos de nodos de segmento de TPU disponibles. Para obtener más información sobre las reservas de TPU, consulta el artículo Reservas de TPU.

  • --spot: define el grupo de nodos que usará las máquinas virtuales de Spot para los nodos de la porción de TPU. No se puede cambiar después de crear el grupo de nodos. Para obtener más información, consulta VMs de acceso puntual.

  • --flex-start: define que el grupo de nodos use VMs de inicio flexible. Las VMs de inicio flexible se crean con la opción de consumo inicio flexible, que es compatible con la versión 1.33.0-gke.1712000 de GKE o una posterior.

  • --enable-autoscaling: crea un grupo de nodos con el escalado automático habilitado. Cuando GKE escala un grupo de nodos de un segmento de TPU multihost, escala el grupo de nodos de forma atómica de cero al tamaño máximo.

    • MAX_NODES: tamaño máximo del grupo de nodos. La marca --max-nodes es obligatoria si se proporciona --enable-autoscaling y debe ser igual al producto de los valores definidos en TPU_TOPOLOGY ({A}x{B}x{C}) dividido entre el número de chips de cada máquina virtual.

  • --node-label=cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME, cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: indica a GKE que el grupo de nodos de la porción de TPU multihost es una colección. Usa esta marca si se cumplen las siguientes condiciones:

    • El grupo de nodos ejecuta cargas de trabajo de inferencia.
    • El grupo de nodos usa TPU Trillium.
    • Las máquinas virtuales de acceso puntual no admiten la programación de la recogida.

    Para obtener más información sobre la gestión de la programación de la recogida, consulta Gestionar la programación de la recogida en slices de TPU de varios hosts.

  • --placement-type=COMPACT: crea un grupo de nodos con la colocación compacta habilitada. Esta opción debe usarse con la marca --tpu-topology. Para obtener más información, consulta Crear una política de colocación compacta y Topología de TPU.

Terraform

  1. Asegúrate de usar la versión 4.84.0 o una posterior del proveedor google.

  2. Añade el siguiente bloque a tu configuración de Terraform:

    resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]
  initial_node_count = NUM_NODES

  autoscaling {
    max_node_count = MAX_NODES
    location_policy      = "ANY"
  }
  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    flex_start = false
    spot = true
  }

  placement_policy {
    type = "COMPACT"
    tpu_topology = TPU_TOPOLOGY
  }
}

    Haz los cambios siguientes:

    • NODE_POOL_RESOURCE_NAME: el nombre del recurso de grupo de nodos en la plantilla de Terraform.
    • PROJECT_ID: tu ID de proyecto.
    • CLUSTER_NAME: el nombre del clúster al que quieres añadir el grupo de nodos.
    • POOL_NAME: el nombre del grupo de nodos que se va a crear.
    • CLUSTER_LOCATION: calcula la ubicación del clúster. Te recomendamos que tengas un clúster regional para aumentar la fiabilidad del plano de control de Kubernetes. También puedes usar un clúster zonal. Para obtener más información, consulta Seleccionar una versión y una topología de TPU.
    • NODE_ZONES: lista separada por comas de una o varias zonas en las que GKE crea el grupo de nodos.
    • NUM_NODES: número de nodos del grupo de nodos. Debe ser cero o el resultado de dividir el número de chips de TPU entre cuatro, ya que en las porciones de TPU multihost, cada nodo de la porción de TPU tiene cuatro chips. Por ejemplo, si TPU_TOPOLOGY es 4x8, hay 32 chips, lo que significa que NUM_NODES debe ser 8. Para obtener más información sobre las topologías de TPU, consulta la tabla de la sección Elegir la versión de TPU.
    • TPU_TOPOLOGY: indica la topología física del segmento de TPU. El formato de la topología depende de la versión de TPU que estés usando. Para obtener más información sobre las topologías de TPU, consulta la tabla de la sección Elegir una topología.

    También puedes usar las siguientes variables:

    • RESERVATION_NAME: si usas reservas de TPU, esta es la lista de etiquetas de los recursos de reserva que se usarán al crear el grupo de nodos. Para obtener más información sobre cómo rellenar el campo RESERVATION_LABEL_VALUES en reservation_affinity, consulta Proveedor de Terraform.
    • autoscaling: crea un grupo de nodos con el escalado automático habilitado. Cuando GKE escala un grupo de nodos de un segmento de TPU multihost, escala el grupo de nodos de forma atómica de cero al tamaño máximo.
      • MAX_NODES: es el tamaño máximo del pool de nodos. Debe ser igual al producto de los valores definidos en TPU_TOPOLOGY ({A}x{B}x{C}) dividido entre el número de chips de cada máquina virtual.
    • spot: permite que el grupo de nodos use máquinas virtuales de Spot para los nodos de la porción de TPU. No se puede cambiar después de crear el grupo de nodos. Para obtener más información, consulta Máquinas virtuales de acceso puntual.
    • flex_start: define que el grupo de nodos use la opción de consumo inicio flexible. No se puede definir como true si spot está habilitado.

Consola

Para crear un grupo de nodos con TPUs, sigue estos pasos:

  1. Ve a la página Google Kubernetes Engine en la Google Cloud consola.

    Ir a Google Kubernetes Engine

  2. En la lista de clústeres, haga clic en el nombre del clúster que quiera modificar.

  3. Haz clic en Añadir grupo de nodos.

  4. En la sección Detalles del grupo de nodos, marca la casilla Especificar ubicaciones de nodos.

  5. Selecciona el nombre de la zona en función de la versión de TPU que quieras usar. Para identificar una ubicación disponible, consulta Disponibilidad de las TPUs en GKE.

  6. En el panel de navegación, haga clic en Nodos.

  7. En la sección Configuración de la máquina, selecciona TPUs.

  8. En el menú desplegable Serie, selecciona una de las siguientes opciones:

    • CT3 TPU v3, dispositivo de un solo host
    • CT3P: TPU v3, porción de pod multihost
    • CT4P: TPU v4
    • CT5LP: TPU v5e
    • CT5P: TPU v5p
    • CT6E: TPU Trillium (v6e)

  9. En el menú desplegable Tipo de máquina, selecciona el nombre de la máquina que quieras usar para los nodos. Consulta la tabla Elegir la versión de TPU para saber cómo definir el tipo de máquina y la topología de TPU que crean un bloque de nodos de TPU multihost.

  10. En el menú desplegable Topología de TPU, selecciona la topología física del slice de TPU.

  11. En el cuadro de diálogo Cambios necesarios, haga clic en Hacer cambios.

  12. Asegúrate de que el Tipo de disco de arranque sea Disco persistente estándar o Disco persistente SSD.

  13. Si quieres, marca la casilla Habilitar nodos en VMs Spot para usar VMs Spot en los nodos del grupo de nodos.

  14. Haz clic en Crear.

Usar el aprovisionamiento automático de nodos de GKE

Puedes configurar GKE para que cree y elimine automáticamente grupos de nodos con el fin de satisfacer las demandas de recursos de tus cargas de trabajo de TPU.

  1. Para habilitar el aprovisionamiento automático de grupos de nodos, edita los límites de recursos de TPU del clúster:

      gcloud container clusters update CLUSTER_NAME \
      --location=CONTROL_PLANE_LOCATION \
      --enable-autoprovisioning \
      --min-cpu=MINIMUM_CPU \
      --min-memory=MINIMUM_MEMORY \
      --max-cpu=MAXIMUM_CPU \
      --max-memory=MAXIMUM_MEMORY \
      --min-accelerator=type=TPU_TYPE,count=MINIMUM_TPU_COUNT \
      --max-accelerator=type=TPU_TYPE,count=MAXIMUM_TPU_COUNT

    Haz los cambios siguientes:

    • TPU_TYPE: el tipo de TPU. Por ejemplo, usa tpu7x-standard-4t para Ironwood (TPU7x).
    • MINIMUM_TPU_COUNT: número mínimo de chips de TPU del tipo especificado que puede tener el clúster. Si el valor que especifiques es mayor que el número de chips de TPU de un slice de TPU de varios hosts, GKE eliminará todos los nodos del slice. Los grupos de nodos multihost se escalan entre 0 y el número de nodos del segmento, sin valores intermedios.
    • MAXIMUM_TPU_COUNT: número máximo de chips de TPU del tipo especificado que puede tener el clúster. En el caso de los slices de TPU de varios hosts, especifica un valor superior al número de chips de cada slice para que GKE pueda escalar el slice de forma atómica. El número de chips de un segmento es el producto de la topología de la TPU. Por ejemplo, si la topología es 2x2x2, el número de chips de la porción es 8, lo que significa que el valor de MAXIMUM_TPU_COUNT debe ser mayor que 8.

Definir ComputeClasses personalizados

También puedes configurar GKE para que solicite TPUs durante las operaciones de escalado que creen nodos nuevos mediante ComputeClasses personalizados.

Puedes especificar opciones de configuración de TPU en tu especificación de ComputeClass personalizada. Cuando una carga de trabajo de GKE usa esa ComputeClass personalizada, GKE intenta aprovisionar TPUs que usen la configuración que hayas especificado al aumentar la escala.

En las siguientes secciones se muestra cómo crear una ComputeClass personalizada y, a continuación, crear un trabajo que consuma las TPUs definidas en la ComputeClass.

Crear un ComputeClass personalizado

Los pasos para crear una ComputeClass personalizada que siga las reglas de las TPU varían en función de si usas Ironwood (TPU7x) o una versión anterior de TPU.

Ironwood (TPU7x)

  1. Crea una política de carga de trabajo. Este paso solo es obligatorio si vas a crear un pool de nodos multihost, que depende de la topología que elijas. Si usas un grupo de nodos de un solo host, sáltate este paso.

    gcloud compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type=HIGH_THROUGHPUT \
    --accelerator-topology=TPU_TOPOLOGY \
    --project=PROJECT_ID \
    --region=REGION

    Haz los cambios siguientes:

    • WORKLOAD_POLICY_NAME: un nombre para tu política de carga de trabajo.
    • TPU_TOPOLOGY: la topología de la TPU Ironwood (TPU7x). Por ejemplo, usa 2x2x2. Para obtener más información sobre todas las topologías compatibles con Ironwood (TPU7x), consulta la sección de topología.
    • PROJECT_ID: tu ID de proyecto Google Cloud .
    • REGION: la región de la política de cargas de trabajo. Una política de carga de trabajo es un recurso regional y puedes usarla en varios grupos de nodos.

  2. Guarda el siguiente archivo de manifiesto como tpu-compute-class.yaml:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
    - tpu:
        type: tpu7x
        topology: TPU_TOPOLOGY
        count: 4
      placement:
        policyName: WORKLOAD_POLICY_NAME
  nodePoolAutoCreation:
    enabled: true

  3. Opcional: Puedes consumir una reserva o un subbloque específicos. Por ejemplo, puedes añadir lo siguiente specs a tu archivo de manifiesto ComputeClass:

      reservations:
    affinity: Specific
    specific:
      - name: RESERVATION_NAME
        reservationBlock:
          name: RESERVATION_BLOCK_NAME
          reservationSubBlock:
            name: RESERVATION_SUB_BLOCK_NAME

    Haz los cambios siguientes:

    • RESERVATION_NAME: el nombre de la reserva de capacidad de Compute Engine.
    • RESERVATION_BLOCK_NAME: el nombre del bloque de reserva de capacidad de Compute Engine.
    • RESERVATION_SUB_BLOCK_NAME: el nombre del subbloque de reserva de capacidad de Compute Engine.

    Para obtener más información, consulta el artículo sobre cómo consumir recursos de zona reservados.

Otras versiones de TPU

Para aprovisionar TPUs de las versiones 3, 4, 5p, 5e o 6e (Trillium) mediante una ComputeClass personalizada configurada para TPUs, sigue estos pasos:

  1. Guarda el siguiente archivo de manifiesto como tpu-compute-class.yaml:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: TPU_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  - spot: true
    tpu:
      type: {"<var>"}}TPU_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  - flexStart:
      enabled: true
    tpu:
      type: {"<var>"}}TPU_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  nodePoolAutoCreation:
    enabled: true

    Haz los cambios siguientes:

    • TPU_TYPE: el tipo de TPU que se va a usar, como tpu-v4-podslice. Debe ser un valor admitido por GKE.
    • TOPOLOGY: la disposición de los chips de TPU en el slice, como 2x2x4. Debe ser una topología compatible con el tipo de TPU seleccionado.
    • NUMBER_OF_CHIPS: número de chips de TPU que usará el contenedor. Debe ser el mismo valor para limits y requests.

  2. Despliega el ComputeClass:

    kubectl apply -f tpu-compute-class.yaml

    Para obtener más información sobre las ComputeClasses personalizadas y las TPUs, consulta Configuración de TPUs.

Crear un trabajo que consuma TPUs

  1. Guarda el siguiente archivo de manifiesto como tpu-job.yaml:

    apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-job
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-job
spec:
  backoffLimit: 0
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/compute-class: tpu-class
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())'
        resources:
          requests:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS
          limits:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS

    Haz los cambios siguientes:

    • NUMBER_OF_CHIPS: número de chips de TPU que usará el contenedor. Debe ser el mismo valor para limits y requests, igual al valor de CHIP_COUNT en el elemento ComputeClass personalizado seleccionado.
    • MEMORY_SIZE: cantidad máxima de memoria que usa la TPU. Los límites de memoria dependen de la versión y la topología de la TPU que utilices. Para obtener más información, consulta Mínimos y máximos de los aceleradores.
    • NUMBER_OF_CHIPS: número de chips de TPU que usará el contenedor. Debe ser el mismo valor para limits y requests.

  2. Desplegar el trabajo:

    kubectl create -f tpu-job.yaml

    Cuando creas este trabajo, GKE hace lo siguiente automáticamente:

    • Aprovisiona nodos para ejecutar los pods. En función del tipo de TPU, la topología y las solicitudes de recursos que hayas especificado, estos nodos serán slices de un solo host o slices de varios hosts. En función de la disponibilidad de los recursos de TPU en la prioridad más alta, GKE puede recurrir a prioridades más bajas para maximizar la obtenibilidad.
    • Añade intolerancias a los pods y tolerancias a los nodos para evitar que otras cargas de trabajo se ejecuten en los mismos nodos que las cargas de trabajo de TPU.

    Para obtener más información, consulta Acerca de las ComputeClasses personalizadas.

  3. Cuando termines esta sección, puedes evitar que se te siga facturando eliminando los recursos que has creado:

    kubectl delete -f tpu-job.yaml

Preparar las cargas de trabajo

Las cargas de trabajo de TPU tienen los siguientes requisitos de preparación.

  1. Frameworks como JAX, PyTorch y TensorFlow acceden a las VMs de TPU mediante la biblioteca compartida libtpu. libtpu incluye el compilador XLA, el software de tiempo de ejecución de la TPU y el controlador de la TPU. Cada lanzamiento de PyTorch y JAX requiere una versión libtpu.so concreta. Para evitar conflictos entre versiones de paquetes, te recomendamos que uses una imagen de IA de JAX. Para usar TPUs en GKE, asegúrate de que utilizas las siguientes versiones: tpu7x
    Tipo de TPU Versión de libtpu.so
    Ironwood (TPU7x) (vista previa)
    TPU Trillium (v6e)
    tpu-v6e-slice
    TPU v5e
    tpu-v5-lite-podslice
    TPU v5p
    tpu-v5p-slice
    • Imagen de IA de JAX recomendada: jax0.4.35-rev1 o posterior
    • Versión recomendada de jax[tpu]: 0.4.19 o posterior.
    • Versión recomendada de torchxla[tpuvm]: se sugiere usar una versión nightly compilada el 23 de octubre del 2023.
    TPU v4
    tpu-v4-podslice
    TPU v3
    tpu-v3-slice
    tpu-v3-device
  2. En el manifiesto de tu carga de trabajo, añade selectores de nodos de Kubernetes para asegurarte de que GKE programa tu carga de trabajo de TPU en el tipo de máquina y la topología de TPU que has definido:

      nodeSelector:
    cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
    cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
    cloud.google.com/placement-policy-name: WORKLOAD_POLICY # Required only for Ironwood (TPU7x)

    Haz los cambios siguientes:

    • TPU_ACCELERATOR: nombre del acelerador de TPU. Por ejemplo, usa tpu7x-standard-4t.
    • TPU_TOPOLOGY: la topología física de la porción de TPU. El formato de la topología depende de la versión de la TPU. Por ejemplo, usa 2x2x2. Para obtener más información, consulta Planificar TPUs en GKE.
    • WORKLOAD_POLICY: el nombre de la política de carga de trabajo que quieras usar para colocar tus pods de TPU. Este selector de nodos solo es necesario para Ironwood (TPU7x).

Una vez que hayas completado la preparación de la carga de trabajo, puedes ejecutar un trabajo que use las TPUs.

En las secciones siguientes se muestran ejemplos de cómo ejecutar un trabajo que realice cálculos básicos con TPUs.

Ejecutar tu carga de trabajo en nodos de segmento de TPU

En esta sección se explica cómo preparar las cargas de trabajo y se ofrecen ejemplos de cómo puede ejecutarlas.

Ejemplo 1: Ejecutar un Deployment que solicite TPUs en la especificación de Pod

GKE usa la configuración de tu Pod o ComputeClass para determinar la configuración de tus nodos de TPU. El siguiente manifiesto es un ejemplo de una especificación de implementación que solicita TPUs en la especificación de Pod. Si el ajuste de aprovisionamiento automático de nodos a nivel de clúster está habilitado, esta implementación activará la creación automática de grupos de nodos. Cuando creas este ejemplo de Deployment, GKE crea un grupo de nodos que contiene una porción de TPU v4 con una topología 2x2x2 y dos máquinas ct4p-hightpu-4t.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tpu-workload
  labels:
    app: tpu-workload
spec:
  replicas: 2
  template:
    spec:
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice
        cloud.google.com/gke-tpu-topology: 2x2x2
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        securityContext:
          privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("Total TPU chips:", jax.device_count())'
        resources:
          requests:
            google.com/tpu: 4
          limits:
            google.com/tpu: 4
        ports:
        - containerPort: 80

En este manifiesto, los siguientes campos definen la configuración de la TPU:

  • cloud.google.com/gke-tpu-accelerator: la versión y el tipo de TPU. Por ejemplo, usa tpu7x-standard-4t para Ironwood (TPU7x).
  • cloud.google.com/gke-tpu-topology: la topología con el número y la disposición física de los chips de TPU en una porción de TPU. Por ejemplo, usa 2x2x2.
  • limits.google.com/tpu: el número de chips de TPU por VM. Por ejemplo, si usas tpu7x-standard-4t, el número de chips de TPU por VM es 4.

Ejemplo 2: Ejecutar una carga de trabajo que muestre el número de chips de TPU disponibles en un pool de nodos de un segmento de TPU

La siguiente carga de trabajo devuelve el número de chips de TPU de todos los nodos de un segmento de TPU de varios hosts. Para crear una porción multihost, la carga de trabajo tiene los siguientes parámetros:

  • Versión de TPU: TPU v4
  • Topología: 2x2x4

Esta versión y la topología seleccionadas dan como resultado un slice multihost.

  1. Guarda el siguiente archivo de manifiesto como available-chips-multihost.yaml: 
    apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-available-chips
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-available-chips
spec:
  backoffLimit: 0
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice # Node selector to target TPU v4 slice nodes.
        cloud.google.com/gke-tpu-topology: 2x2x4 # Specifies the physical topology for the TPU slice.
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        securityContext:
          privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())' # Python command to count available TPU chips.
        resources:
          requests:
            cpu: 10
            memory: 407Gi
            google.com/tpu: 4 # Request 4 TPU chips for this workload.
          limits:
            cpu: 10
            memory: 407Gi
            google.com/tpu: 4 # Limit to 4 TPU chips for this workload.
  2. Implementa el archivo de manifiesto: 
    kubectl create -f available-chips-multihost.yaml

    GKE ejecuta un slice de TPU v4 con cuatro VMs (slice de TPU de varios hosts). La porción tiene 16 chips de TPU interconectados.

  3. Verifica que el trabajo ha creado cuatro pods: 
    kubectl get pods

    El resultado debería ser similar al siguiente:

    NAME                       READY   STATUS      RESTARTS   AGE
tpu-job-podslice-0-5cd8r   0/1     Completed   0          97s
tpu-job-podslice-1-lqqxt   0/1     Completed   0          97s
tpu-job-podslice-2-f6kwh   0/1     Completed   0          97s
tpu-job-podslice-3-m8b5c   0/1     Completed   0          97s
  4. Obtén los registros de uno de los pods: 
    kubectl logs POD_NAME

    Sustituye POD_NAME por el nombre de uno de los pods creados. Por ejemplo, tpu-job-podslice-0-5cd8r.

    El resultado debería ser similar al siguiente: 

    TPU cores: 16
  5. Opcional: Elimina la carga de trabajo: 
    kubectl delete -f available-chips-multihost.yaml

Ejemplo 3: Ejecutar una carga de trabajo que muestre el número de chips de TPU disponibles en el segmento de TPU

La siguiente carga de trabajo es un pod estático que muestra el número de chips de TPU conectados a un nodo específico. Para crear un nodo de un solo host, la carga de trabajo tiene los siguientes parámetros:

  • Versión de TPU: TPU v5e
  • Topología: 2x4

Esta versión y topología dan como resultado un segmento de un solo host.

  1. Guarda el siguiente archivo de manifiesto como available-chips-singlehost.yaml: 
    apiVersion: v1
kind: Pod
metadata:
  name: tpu-job-jax-v5
spec:
  restartPolicy: Never
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice # Node selector to target TPU v5e slice nodes.
    cloud.google.com/gke-tpu-topology: 2x4 # Specify the physical topology for the TPU slice.
  containers:
  - name: tpu-job
    image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
    ports:
    - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
    securityContext:
      privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
    command:
    - bash
    - -c
    - |
      python -c 'import jax; print("Total TPU chips:", jax.device_count())'
    resources:
      requests:
        google.com/tpu: 8 # Request 8 TPU chips for this container.
      limits:
        google.com/tpu: 8 # Limit to 8 TPU chips for this container.
  2. Implementa el archivo de manifiesto: 
    kubectl create -f available-chips-singlehost.yaml

    GKE aprovisiona nodos con ocho slices de TPU de un solo host que usan la versión 5e de la TPU. Cada nodo de TPU tiene ocho chips de TPU (slice de TPU de un solo host).

  3. Obtén los registros del pod: 
    kubectl logs tpu-job-jax-v5

    El resultado debería ser similar al siguiente: 

    Total TPU chips: 8
  4. Opcional: Elimina la carga de trabajo: 
      kubectl delete -f available-chips-singlehost.yaml

Actualizar grupos de nodos con aceleradores (GPUs y TPUs)

GKE actualiza automáticamente los clústeres estándar, incluidos los grupos de nodos. También puedes actualizar manualmente los grupos de nodos si quieres que tus nodos tengan una versión posterior antes. Para controlar cómo funcionan las actualizaciones en tu clúster, usa los canales de lanzamiento, las ventanas y exclusiones de mantenimiento y la secuencia de lanzamiento.

También puedes configurar una estrategia de actualización de nodos para tu grupo de nodos, como actualizaciones con compensación, actualizaciones azul-verde o actualizaciones de corta duración. Al configurar estas estrategias, puedes asegurarte de que los grupos de nodos se actualicen de forma que se consiga el equilibrio óptimo entre velocidad e interrupción en tu entorno. En el caso de los grupos de nodos de un slice de TPU de varios hosts, en lugar de usar la estrategia de actualización de nodos configurada, GKE vuelve a crear todo el grupo de nodos de forma atómica en un solo paso. Para obtener más información, consulta la definición de atomicidad en Terminología relacionada con las TPU en GKE.

Para usar una estrategia de actualización de nodos, GKE debe aprovisionar recursos adicionales temporalmente, en función de la configuración. Si Google Cloud tiene una capacidad limitada para los recursos de tu grupo de nodos (por ejemplo, si ves errores de disponibilidad de recursos al intentar crear más nodos con GPUs o TPUs), consulta Actualizar en un entorno con recursos limitados.

Limpieza

Para evitar que se apliquen cargos en tu Google Cloud cuenta por los recursos utilizados en esta guía, puedes eliminar los grupos de nodos de la porción de TPU que ya no tengan cargas de trabajo programadas. Si las cargas de trabajo que se están ejecutando deben finalizarse correctamente, usa kubectl drain para limpiar las cargas de trabajo antes de eliminar el nodo.

  1. Eliminar un grupo de nodos de un slice de TPU:

    gcloud container node-pools delete POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME

    Haz los cambios siguientes:

    • POOL_NAME: el nombre del grupo de nodos.
    • CLUSTER_NAME: el nombre del clúster.
    • LOCATION: la ubicación de cálculo del clúster.

Configurar ajustes adicionales

En las secciones siguientes se describen las configuraciones adicionales que puedes aplicar a tus cargas de trabajo de TPU.

Usar Multislice

Puedes agregar porciones más pequeñas en un Multislice para gestionar cargas de trabajo de entrenamiento más grandes. Para obtener más información, consulta TPUs multislice en GKE.

Migrar tu reserva de TPU

Si tienes reservas de TPU, primero debes migrar tu reserva de TPU a un nuevo sistema de reservas basado en Compute Engine. También puedes crear un sistema de reservas basado en Compute Engine en el que no sea necesario realizar ninguna migración. Para saber cómo migrar tus reservas de TPU, consulta Reservas de TPU.

Activar el almacenamiento de registros

El agente de registro de GKE recoge los registros emitidos por los contenedores que se ejecutan en los nodos de GKE, incluidas las máquinas virtuales de TPU, los envía a Logging y se pueden ver en Logging.

Configurar la reparación automática de nodos de un segmento de TPU

Si un nodo de segmento de TPU de un grupo de nodos de segmento de TPU de varios hosts no está en buen estado, se vuelve a crear todo el grupo de nodos. En cambio, en un grupo de nodos de segmento de TPU de un solo host, solo se repara automáticamente el nodo de TPU que no funciona correctamente.

Entre las condiciones que provocan que los nodos de las slices de TPU no estén en buen estado se incluyen las siguientes:

  • Cualquier nodo de segmento de TPU con condiciones de nodo comunes.
  • Cualquier nodo de segmento de TPU con un recuento de TPUs no asignables superior a cero.
  • Cualquier instancia de VM de una porción de TPU que se haya detenido (por interrupción) o se haya cancelado.
  • Mantenimiento de nodos: si se produce un error en algún nodo de segmento de TPU de un grupo de nodos de segmento de TPU de varios hosts debido al mantenimiento del host, GKE vuelve a crear todo el grupo de nodos de segmento de TPU.

Puedes ver el estado de la reparación (incluido el motivo del fallo) en el historial de operaciones. Si el error se debe a una cuota insuficiente, póngase en contacto con suGoogle Cloud representante de cuentas para aumentar la cuota correspondiente.

Configurar la finalización correcta de los nodos de las slices de TPU

En los clústeres de GKE con el plano de control que ejecute la versión 1.29.1-gke.1425000 o posterior, los nodos de las slices de TPU admiten señales SIGTERM que alertan al nodo de un cierre inminente. La notificación de cierre inminente se puede configurar hasta cinco minutos en los nodos de TPU.

Para configurar GKE de forma que finalice tus cargas de trabajo correctamente en este periodo de notificación, sigue los pasos que se indican en Gestionar interrupciones de nodos de GKE para GPUs y TPUs.

Ejecutar contenedores sin modo privilegiado

Los contenedores que se ejecutan en nodos de GKE 1.28 o versiones posteriores no necesitan tener habilitado el modo con privilegios para acceder a las TPUs. Los nodos de la versión 1.28 y anteriores de GKE requieren el modo con privilegios.

Si el nodo de tu segmento de TPU ejecuta versiones anteriores a la 1.28, consulta la siguiente sección:

Un contenedor que se ejecuta en una VM de un segmento de TPU necesita acceder a límites más altos de memoria bloqueada para que el controlador pueda comunicarse con los chips de TPU a través del acceso directo a memoria (DMA). Para habilitar esta opción, debes configurar un ulimit más alto. Si quieres reducir el ámbito de los permisos de tu contenedor, sigue estos pasos:

  1. Edita el securityContext para incluir los siguientes campos:

    securityContext:
  capabilities:
    add: ["SYS_RESOURCE"]

  2. Aumenta ulimit ejecutando el siguiente comando en el contenedor antes de configurar tus cargas de trabajo para que usen recursos de TPU:

    ulimit -l 68719476736

En el caso de la TPU v5e, los contenedores se pueden ejecutar sin el modo con privilegios en clústeres con la versión 1.27.4-gke.900 y posteriores.

Observabilidad y métricas

Panel de control

La observabilidad de los grupos de nodos en la Google Cloud consola está disponible de forma general. Para ver el estado de tus grupos de nodos de TPU de varios hosts en GKE, ve al panel de control Estado de los grupos de nodos de TPU de GKE proporcionado por Cloud Monitoring:

Ir a Estado del grupo de nodos de TPU de GKE

Este panel te ofrece estadísticas completas sobre el estado de tus grupos de nodos de TPU multihost. Para obtener más información, consulta Monitorizar las métricas de estado de los nodos y los grupos de nodos de TPU.

En la página Clústeres de Kubernetes de la consola deGoogle Cloud , la pestaña Observabilidad también muestra métricas de observabilidad de la TPU, como el uso de la TPU, en el encabezado Aceleradores > TPU. Para obtener más información, consulta Ver métricas de observabilidad.

El panel de control de TPU solo se rellena si tienes las métricas del sistema habilitadas en tu clúster de GKE.

Métricas de tiempo de ejecución

En GKE 1.27.4-gke.900 o versiones posteriores, las cargas de trabajo de TPU que usen JAX 0.4.14 o versiones posteriores y especifiquen containerPort: 8431 exportan métricas de utilización de la TPU como métricas del sistema de GKE. En Cloud Monitoring están disponibles las siguientes métricas para monitorizar el rendimiento del tiempo de ejecución de tu carga de trabajo de TPU:

  • Ciclo de trabajo: porcentaje del tiempo durante el último periodo de muestreo (60 segundos) en el que los Tensor Cores han estado procesando activamente en un chip de TPU. Un porcentaje mayor significa un mejor uso de la TPU.
  • Memoria usada: cantidad de memoria del acelerador asignada en bytes. Se muestrea cada 60 segundos.
  • Memoria total: memoria total del acelerador en bytes. Se muestrea cada 60 segundos.

Estas métricas se encuentran en el esquema de nodos de Kubernetes (k8s_node) y de contenedores de Kubernetes (k8s_container).

Contenedor de Kubernetes:

  • kubernetes.io/container/accelerator/duty_cycle
  • kubernetes.io/container/accelerator/memory_used
  • kubernetes.io/container/accelerator/memory_total

Nodo de Kubernetes:

  • kubernetes.io/node/accelerator/duty_cycle
  • kubernetes.io/node/accelerator/memory_used
  • kubernetes.io/node/accelerator/memory_total

Monitorizar métricas de estado de nodos y grupos de nodos de TPU

Cuando un trabajo de entrenamiento tiene un error o finaliza con un fallo, puedes consultar las métricas relacionadas con la infraestructura subyacente para determinar si la interrupción se ha debido a un problema con el nodo o el pool de nodos subyacente.

Estado del nodo

En la versión 1.32.1-gke.1357001 de GKE o una posterior, la siguiente métrica del sistema de GKE expone el estado de un nodo de GKE:

  • kubernetes.io/node/status_condition

El campo condition informa sobre las condiciones del nodo, como Ready, DiskPressure y MemoryPressure. El campo status muestra el estado notificado de la condición, que puede ser True, False o Unknown. Se trata de una métrica con el tipo de recurso monitorizado k8s_node.

Esta consulta de PromQL muestra si un nodo concreto está Ready:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    node_name="NODE_NAME",
    condition="Ready",
    status="True"}

Para solucionar problemas en un clúster, puede que quieras consultar los nodos que hayan mostrado otras condiciones:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition!="Ready",
    status="True"}

Puede que quieras consultar específicamente los nodos que no sean Ready:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition="Ready",
    status="False"}

Si no hay datos, los nodos estarán listos. La condición de estado se muestrea cada 60 segundos.

Puedes usar la siguiente consulta para conocer el estado de los nodos de toda la flota:

avg by (condition,status)(
  avg_over_time(
    kubernetes_io:node_status_condition{monitored_resource="k8s_node"}[${__interval}]))

Estado del grupo de nodos

La siguiente métrica del sistema de GKE del recurso monitorizado k8s_node_pool muestra el estado de un grupo de nodos de GKE:

  • kubernetes.io/node_pool/status

Esta métrica solo se registra en los grupos de nodos de TPU multihost.

El campo status indica el estado del grupo de nodos, como Provisioning, Running, Error, Reconciling o Stopping. Las actualizaciones de estado se producen después de que se completen las operaciones de la API de GKE.

Para verificar si un grupo de nodos concreto tiene el estado Running, usa la siguiente consulta de PromQL:

kubernetes_io:node_pool_status{
    monitored_resource="k8s_node_pool",
    cluster_name="CLUSTER_NAME",
    node_pool_name="NODE_POOL_NAME",
    status="Running"}

Para monitorizar el número de grupos de nodos de tu proyecto agrupados por su estado, usa la siguiente consulta de PromQL:

count by (status)(
  count_over_time(
    kubernetes_io:node_pool_status{monitored_resource="k8s_node_pool"}[${__interval}]))

Disponibilidad del grupo de nodos

La siguiente métrica del sistema de GKE muestra si hay disponible un grupo de nodos de TPU de varios hosts:

  • kubernetes.io/node_pool/multi_host/available

La métrica tiene el valor True si todos los nodos del grupo de nodos están disponibles y False en caso contrario. La métrica se muestrea cada 60 segundos.

Para comprobar la disponibilidad de los grupos de nodos de TPU de varios hosts en tu proyecto, usa la siguiente consulta de PromQL:

avg by (node_pool_name)(
  avg_over_time(
    kubernetes_io:node_pool_multi_host_available{
      monitored_resource="k8s_node_pool",
      cluster_name="CLUSTER_NAME"}[${__interval}]))

Número de interrupciones de nodos

La siguiente métrica del sistema de GKE informa del número 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 explicar por qué se ha interrumpido 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 del 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}]))

Tiempo de recuperación (TTR) de los grupos de nodos

La siguiente métrica del sistema de GKE informa de la distribución de las duraciones del periodo de recuperación de los grupos de nodos de TPU de varios hosts de GKE:

  • kubernetes.io/node_pool/accelerator/times_to_recover

Cada muestra registrada en esta métrica indica un evento de recuperación del grupo de nodos tras un periodo de inactividad.

Esta métrica es útil para monitorizar el tiempo de recuperación y el tiempo entre interrupciones del grupo de nodos de TPU de varios hosts.

Puedes usar la siguiente consulta de PromQL para calcular el tiempo medio de recuperación (MTTR) de los últimos 7 días en tu clúster:

sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_sum{
    monitored_resource="k8s_node_pool", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_count{
    monitored_resource="k8s_node_pool",cluster_name="CLUSTER_NAME"}[7d]))

Tiempo entre interrupciones (TBI) del grupo de nodos

El tiempo entre interrupciones de un grupo de nodos mide el tiempo que se ejecuta tu infraestructura antes de sufrir una interrupción. Se calcula como la media de un periodo, en el que el numerador mide el tiempo total que tu infraestructura ha estado activa y el denominador mide las interrupciones totales de tu infraestructura.

En el siguiente ejemplo de PromQL se muestra el tiempo medio entre interrupciones (MTBI) de 7 días del clúster en cuestión:

sum(count_over_time(
  kubernetes_io:node_memory_total_bytes{
    monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_interruption_count{
    monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))

Métricas de host

En GKE 1.28.1-gke.1066000 o versiones posteriores, las VMs de un segmento de TPU exportan métricas de utilización de TPU como métricas del sistema de GKE. En Cloud Monitoring están disponibles las siguientes métricas para monitorizar el rendimiento de tu host de TPU:

  • Uso de TensorCore: porcentaje actual de TensorCore que se está utilizando. El valor de Tensor Core es igual a la suma de las unidades de multiplicación de matrices (MXUs) más la unidad vectorial. El valor de utilización de Tensor Core es el resultado de dividir las operaciones de Tensor Core que se han realizado durante el periodo de muestreo anterior (60 segundos) entre el número admitido de operaciones de Tensor Core durante el mismo periodo. Cuanto mayor sea el valor, mejor será la utilización.
  • Uso del ancho de banda de la memoria: porcentaje actual del ancho de banda de la memoria del acelerador que se está usando. Se calcula dividiendo el ancho de banda de la memoria usado durante un periodo de muestra (60 s) entre el ancho de banda máximo admitido durante el mismo periodo de muestra.

Estas métricas se encuentran en el esquema de nodos de Kubernetes (k8s_node) y de contenedores de Kubernetes (k8s_container).

Contenedor de Kubernetes:

  • kubernetes.io/container/accelerator/tensorcore_utilization
  • kubernetes.io/container/accelerator/memory_bandwidth_utilization

Nodo de Kubernetes:

  • kubernetes.io/node/accelerator/tensorcore_utilization
  • kubernetes.io/node/accelerator/memory_bandwidth_utilization

Para obtener más información, consulta las métricas de Kubernetes y las métricas del sistema de GKE.

Gestionar la programación de colecciones

En TPU Trillium, puedes usar la programación de colecciones para agrupar nodos de slices de TPU. Al agrupar estos nodos de segmento de TPU, es más fácil ajustar el número de réplicas para satisfacer la demanda de la carga de trabajo. Google Cloud controla las actualizaciones de software para asegurarse de que siempre haya suficientes segmentos disponibles en la colección para servir el tráfico.

TPU Trillium admite la programación de recolecciones para grupos de nodos de un solo host y de varios hosts que ejecutan cargas de trabajo de inferencia. A continuación, se describe cómo se comporta la programación de la recogida en función del tipo de segmento de TPU que utilices:

  • Slice de TPU de varios hosts: GKE agrupa los slices de TPU de varios hosts para formar una colección. Cada grupo de nodos de GKE es una réplica de esta colección. Para definir una colección, crea un segmento de TPU multihost y asigna un nombre único a la colección. Para añadir más porciones de TPU a la colección, crea otro grupo de nodos de porción de TPU multihost con el mismo nombre de colección y tipo de carga de trabajo.
  • Slice de TPU de un solo host: GKE considera todo el pool de nodos de slice de TPU de un solo host como una colección. Para añadir más porciones de TPU a la colección, puedes cambiar el tamaño del grupo de nodos de la porción de TPU de un solo host.

Para gestionar una colección, realiza cualquiera de estas acciones en función del tipo de grupo de nodos que utilices.

Gestionar la programación de la recogida en grupos de nodos de segmentos de TPU de varios hosts

Sigue estos pasos para gestionar los grupos de nodos de los sectores de TPUs de varios hosts.

  • Para comprobar si un pool de segmentos de TPU multihost forma parte de una colección, ejecuta el siguiente comando:

    gcloud container node-pools describe NODE_POOL_NAME \
    --location LOCATION \
    --cluster CLUSTER_NAME \
    --format="json" | jq -r \
    '"nodepool-group-name: \(.config.labels["cloud.google.com/gke-nodepool-group-name"] // "")\ngke-workload-type: \(.config.labels["cloud.google.com/gke-workload-type"] // "")"'

    El resultado debería ser similar al siguiente:

    nodepool-group-name: <code><var>NODE_POOL_COLLECTION_NAME</var></code>
gke-workload-type: HIGH_AVAILABILITY

    Si el pool de slices de TPU multihost forma parte de una colección, la salida tendrá las siguientes etiquetas:

    • cloud.google.com/gke-workload-type: HIGH_AVAILABILITY
    • cloud.google.com/gke-nodepool-group-name: <code><var>COLLECTION_NAME</var></code>

  • Para obtener la lista de colecciones del clúster, ejecuta el siguiente comando:

    #!/bin/bash

# Replace with your cluster name, project, and location
CLUSTER_NAME=CLUSTER_NAME
PROJECT=PROJECT_ID
LOCATION=LOCATION

declare -A collection_names

node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")

# Iterate over each node pool
for pool in $node_pools; do
    # Describe the node pool and extract labels using jq
    collection_name=$(gcloud container node-pools describe "$pool" \
        --cluster "$CLUSTER_NAME" \
        --project "$PROJECT" \
        --location "$LOCATION" \
        --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')

    # Add the collection name to the associative array if it's not empty
    if [[ -n "$collection_name" ]]; then
        collection_names["$collection_name"]=1
    fi
done

# Print the unique node pool collection names
echo "Unique cloud.google.com/gke-nodepool-group-name values:"
for name in "${!collection_names[@]}"; do
    echo "$name"
done

    El resultado debería ser similar al siguiente:

    Unique cloud.google.com/gke-nodepool-group-name values: {COLLECTION_NAME_1}, {COLLECTION_NAME_2}, {COLLECTION_NAME_3}

  • Para obtener una lista de los grupos de nodos que pertenecen a una colección, ejecuta el siguiente comando:

    #!/bin/bash

TARGET_COLLECTION_NAME=COLLECTION_NAME
CLUSTER_NAME=CLUSTER_NAME
PROJECT=PROJECT_ID
LOCATION=LOCATION

matching_node_pools=()

# Get the list of all node pools in the cluster
node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")

# Iterate over each node pool
for pool in $node_pools; do
    # Get the value of the cloud.google.com/gke-nodepool-group-name label
    collection_name=$(gcloud container node-pools describe "$pool" \
        --cluster "$CLUSTER_NAME" \
        --project "$PROJECT" \
        --location "$LOCATION" \
        --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')

    # Check if the group name matches the target value
    if [[ "$collection_name" == "$TARGET_COLLECTION_NAME" ]]; then
        matching_node_pools+=("$pool")
    fi
done

# Print the list of matching node pools
echo "Node pools with collection name '$TARGET_COLLECTION_NAME':"
for pool in "${matching_node_pools[@]}"; do
    echo "$pool"
done

    El resultado debería ser similar al siguiente:

    Node pools with collection name 'COLLECTION_NAME':
{NODE_POOL_NAME_1}
{NODE_POOL_NAME_2}
{NODE_POOL_NAME_3}

  • Para ampliar la colección, crea otro grupo de nodos de segmento de TPU multihost y añade cloud.google.com/gke-workload-type y cloud.google.com/gke-nodepool-group-name. Usa el mismo nombre de colección en cloud.google.com/gke-nodepool-group-name y ejecuta el mismo tipo de carga de trabajo. Si el aprovisionamiento automático de nodos está habilitado en el clúster, GKE crea automáticamente grupos en función de las demandas de las cargas de trabajo.

  • Para reducir la escala de la colección, elimina el grupo de nodos.

  • Para eliminar la colección, quita todos los grupos de nodos adjuntos. Puedes eliminar el grupo de nodos o eliminar el clúster. Al eliminar el clúster, se eliminan todas las colecciones que contiene.

Gestionar la programación de la recogida en grupos de nodos de slices de TPU de un solo host

Sigue estos pasos para gestionar los grupos de nodos de sectores de TPUs de un solo host.

  • Para comprobar si un pool de segmentos de TPU de un solo host tiene habilitada la programación de recolección, ejecuta el siguiente comando:

    gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --project PROJECT_NAME \
    --location LOCATION \
    --format="json" | jq -r '.config.labels["cloud.google.com/gke-workload-type"]'

    El resultado debería ser similar al siguiente:

    gke-workload-type: HIGH_AVAILABILITY

    Si el pool de slices de TPU de un solo host forma parte de una colección, el resultado tendrá la etiqueta cloud.google.com/gke-workload-type: HIGH_AVAILABILITY.

  • Para aumentar la escala de la colección, cambia el tamaño del grupo de nodos manualmente o automáticamente con el aprovisionamiento automático de nodos.

  • Para reducir la escala de la colección, elimina el grupo de nodos.

  • Para eliminar la colección, quita todos los grupos de nodos adjuntos. Puedes eliminar el grupo de nodos o eliminar el clúster. Si eliminas el clúster, se eliminarán todas las colecciones que contenga.

Problemas conocidos

  • La herramienta de ajuste automático de escala del clúster puede calcular incorrectamente la capacidad de los nuevos nodos de segmento de TPU antes de que estos nodos informen de las TPUs disponibles. La herramienta de adaptación dinámica de clústeres podría realizar un escalado vertical adicional y, como resultado, crear más nodos de los necesarios. La herramienta de adaptación dinámica de clústeres reduce el número de nodos adicionales, si no son necesarios, después de una operación de reducción normal.
  • La herramienta de ajuste automático de escala del clúster cancela el escalado vertical de los grupos de nodos de las slices de TPU que permanecen en estado de espera durante más de 10 horas. La herramienta de adaptación dinámica de clústeres vuelve a intentar estas operaciones de escalado vertical más adelante. Este comportamiento puede reducir la disponibilidad de las TPU para los clientes que no usan reservas.
  • Las cargas de trabajo que no son de TPU y que tienen una tolerancia a la contaminación de TPU pueden impedir que se reduzca el tamaño del grupo de nodos si se vuelven a crear durante el drenaje del grupo de nodos de la porción de TPU.
  • La métrica de utilización del ancho de banda de la memoria no está disponible en las TPUs v5e.

Siguientes pasos