Implementa cargas de trabajo de TPU en GKE Standard

En esta página, se proporciona una base para aprender a acelerar las cargas de trabajo de aprendizaje automático (AA) con TPU en Google Kubernetes Engine (GKE). Las TPU están diseñadas para el procesamiento de multiplicación de matrices, como el entrenamiento de modelos de aprendizaje profundo a gran escala. Las TPU están optimizadas para controlar los enormes conjuntos de datos y los modelos complejos del AA, por lo que son más rentables y energéticamente eficientes para las cargas de trabajo de AA debido a su rendimiento superior. En esta guía, aprenderás a implementar cargas de trabajo de AA con aceleradores de Cloud TPU, configurar cuotas para las TPU, configurar actualizaciones para los grupos de nodos que ejecutan TPU y supervisar las métricas de carga de trabajo de TPU.

Este instructivo está dirigido a ingenieros de aprendizaje automático (AA) y administradores y operadores de plataformas que estén interesados en usar la organización de contenedores de Kubernetes para administrar cargas de trabajo de inferencia, ajuste y entrenamiento de modelos a gran escala con TPU. Para obtener más información sobre los roles comunes y las tareas de ejemplo a los que se hace referencia en el contenido de Google Cloud , consulta Roles y tareas comunes de los usuarios de GKE.

Antes de leer esta página, asegúrate de estar familiarizado con lo siguiente:

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se describen en este documento.

Planifica tu configuración de TPU

Planifica tu configuración de TPU según tu modelo y la cantidad de memoria que requiere. Antes de usar esta guía para implementar tus cargas de trabajo en la TPU, completa los pasos de planificación en Planifica tu configuración de TPU.

Asegúrate de tener cuota de TPU

En las siguientes secciones, se te ayudará a asegurarte de tener suficiente cuota cuando uses TPUs en GKE.

Cuota para VMs según demanda o Spot

Si creas un grupo de nodos de porción TPU con VMs según demanda o Spot, debes tener suficiente cuota de TPU disponible en la región que deseas usar.

Crear un grupo de nodos de porción de TPU que consuma una reserva de TPU no requiere ninguna cuota de TPU.1 Puedes omitir esta sección de forma segura para las TPU reservadas.

La creación de un grupo de nodos de porción de TPU según demanda o Spot en GKE requiere cuota de la API de Compute Engine. La cuota de la API de Compute Engine (compute.googleapis.com) no es lo mismo que la cuota de la API de Cloud TPU (tpu.googleapis.com), que es necesaria cuando se crean TPU con la API de Cloud TPU.

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

  1. Dirígete a la página Cuotas en la consola de Google Cloud :

    Ir a Cuotas

  2. En la casilla Filtro, haz lo siguiente:

    1. Usa la siguiente tabla para seleccionar y copiar la propiedad de la cuota según la versión de TPU y el tipo de máquina. Por ejemplo, si planeas crear nodos TPU v5e a pedido cuyo tipo de máquina comience con ct5lp-, ingresa Name: TPU v5 Lite PodSlice chips.

      Versión de TPU, el tipo de máquina comienza con Propiedad y nombre de la cuota para instancias bajo demanda Propiedad y nombre de la cuota para las 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 (p. ej., ubicaciones) y, luego, ingresa region: seguido del nombre de la región en la que planeas crear TPUs en GKE. Por ejemplo, ingresa region:us-west4 si planeas crear nodos de porción TPU en la zona us-west4-a. La cuota de TPU es regional, por lo que todas las zonas dentro de la misma región consumen la misma cuota de TPU.

Si ninguna cuota coincide con el filtro que ingresaste, no se le otorgó ninguna de las cuotas especificadas para la región que necesitas al proyecto y debes solicitar un ajuste de la cuota de TPU.

Cuando se crea una reserva de TPU, los valores de límite y de uso actuales para la cuota correspondiente aumentan según la cantidad de chips en la reserva de TPU. Por ejemplo, cuando se crea una reserva para 16 chips TPU v5e cuyo tipo de máquina comienza con ct5lp-, tanto el límite como el uso actual de la cuota de TPU v5 Lite PodSlice chips en la región pertinente aumentan en 16.

  1. Cuando crees un grupo de nodos de porción de TPU, usa las marcas --reservation y --reservation-affinity=specific para crear una instancia reservada. Las reservas de TPU están disponibles cuando se compra un compromiso. ↩

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

Cuotas para recursos adicionales de GKE

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

  • Cuota de SSD de Persistent Disk (GB): El disco de arranque de cada nodo de Kubernetes requiere 100 GB de forma predeterminada. Por lo tanto, esta cuota debe establecerse al menos tan alta como el producto de la cantidad máxima de nodos de GKE que esperas 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 establecerse al menos tan alta como la cantidad máxima de nodos de GKE que esperas crear.
  • Asegúrate de que max-pods-per-node se alinee con el rango de la subred: Cada nodo de Kubernetes usa rangos de IP secundarios para los Pods. Por ejemplo, un 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 rango no se debe compartir con ningún otro clúster. Para evitar agotar el rango de direcciones IP, usa la marca --max-pods-per-node para limitar la cantidad de Pods que se pueden programar en un nodo. La cuota para max-pods-per-node debe establecerse al menos tan alta como la cantidad máxima de nodos de GKE que esperas crear.

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

Garantiza la disponibilidad de la reserva

Para crear un grupo de nodos de porción de TPU con 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 existen dentro de un proyecto y cuántos chips de TPU dentro de una reserva de TPU están disponibles, consulta una lista de tus reservas.

Crea un clúster

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

  • Usa Google Cloud CLI para crear manualmente tu instancia de clúster de GKE y personalizar o expandir con precisión los entornos de producción de GKE existentes.
  • 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 y consultar las instrucciones, consulta el README de XPK.

En el siguiente documento, se describe cómo configurar las TPU con Google Cloud CLI.

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

Práctica recomendada:

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

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

Reemplaza lo siguiente:

  • CLUSTER_NAME el nombre del clúster nuevo.
  • LOCATION: la región con la capacidad de TPU disponible.
  • VERSION: la versión de GKE, que debe ser compatible con el tipo de máquina que deseas usar. Ten en cuenta que es posible que la versión predeterminada de GKE no tenga disponibilidad para la TPU de destino. Para obtener información sobre cuáles son las versiones mínimas de GKE disponibles por tipo de máquina de TPU, consulta la disponibilidad de TPU en GKE.

Aprovisiona TPU

Para aprovisionar TPUs en GKE, tienes las siguientes opciones de configuración:
  • Crea un grupo de nodos de forma manual: Puedes crear un grupo de nodos con una versión y una topología de TPU específicas.
  • Usa el aprovisionamiento automático de nodos de GKE: Puedes habilitar el aprovisionamiento automático de nodos a nivel del clúster y, luego, 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 grupo de nodos nuevo que cumple con la solicitud. Este método requiere que establezcas límites de recursos a nivel del clúster para las TPU.
  • Define ComputeClasses personalizadas: Puedes solicitar TPU con ComputeClasses personalizadas. Las ComputeClasses personalizadas permiten que los administradores de la plataforma definan una jerarquía de configuraciones de nodos para que GKE las priorice durante las decisiones de ajuste de escala de nodos, de modo que las cargas de trabajo se ejecuten en el hardware seleccionado.

Crea un grupo de nodos de forma manual

Puedes crear un grupo de nodos de porción de TPU de host único o de varios hosts.

Crea un grupo de nodos de porción de TPU de host único

Puedes crear un grupo de nodos de porción de TPU de host único con Google Cloud CLI, 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]

Reemplaza lo siguiente:

  • NODE_POOL_NAME: el nombre del grupo de nodos nuevo
  • LOCATION: Es el nombre de la zona en función de la versión de TPU que deseas usar. Para identificar una ubicación disponible, consulta Disponibilidad de TPU en GKE.
  • CLUSTER_NAME: el nombre del clúster
  • NODE_ZONES: La lista separada por comas de una o más 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).

De manera opcional, también puedes usar las siguientes marcas:

  • --num-nodes=NUM_NODES: Es la cantidad inicial de nodos en el grupo de nodos en cada zona.

    Práctica recomendada:

    Si usas la marca enable-autoscaling para el grupo de nodos, establece num-nodes en 0 para que el escalador automático aprovisione nodos adicionales en cuanto tus cargas de trabajo los exijan.

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

  • --node-labels cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: Indica a GKE que el grupo de nodos de 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 grupo de nodos nuevo.
    • El grupo de nodos usa TPU Trillium.
    • El grupo de nodos no usa VMs Spot.

    Para obtener más información sobre la administración de la programación de colecciones, consulta Administra la programación de colecciones en porciones de TPU de host único.

  • --enable-autoscaling: Crea un grupo de nodos con el ajuste de escala automático habilitado. Se requieren las siguientes marcas adicionales:

    • --total-min-nodes=TOTAL_MIN_NODES: Es la cantidad mínima de todos los nodos en el grupo de nodos.
    • --total-max-nodes=TOTAL_MAX_NODES: Es la cantidad máxima de todos los nodos en el grupo de nodos.
    • --location-policy=ANY: Prioriza el uso de reservas sin usar y reduce el riesgo de interrupción de las VMs Spot.

  • --spot: Configura el grupo de nodos para usar VMs Spot para los nodos del grupo de nodos. Esto no se puede cambiar después de la creación del grupo de nodos.

  • --flex-start: Configura el grupo de nodos para que use VMs de inicio flexible. Las VMs de inicio flexible se crean con la opción de consumo flex-start. Para obtener más información, consulta Ejecuta una carga de trabajo de lotes pequeña con TPUs y VMs de inicio flexible.

Para obtener 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. Agrega el siguiente bloque a la 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
  }
}

Reemplaza lo siguiente:

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

De manera opcional, también puedes usar las siguientes variables:

  • autoscaling: Crea un grupo de nodos con el ajuste de escala automático habilitado. Para una porción de TPU de host único, GKE escala entre los valores TOTAL_MIN_NODES y TOTAL_MAX_NODES.
    • TOTAL_MIN_NODES: la cantidad mínima de todos los nodos en el grupo de nodos. Este campo es opcional, a menos que también se especifique el ajuste de escala automático.
    • TOTAL_MAX_NODES: la cantidad máxima de todos los nodos en el grupo de nodos. Este campo es opcional, a menos que también se especifique el ajuste de escala automático.
  • RESERVATION_NAME: Si usas Acerca de las reservas de Cloud TPU, esta es la lista de etiquetas de los recursos de reserva que se usarán cuando se cree el grupo de nodos. Para obtener más información sobre cómo completar RESERVATION_LABEL_VALUES en el campo reservation_affinity, consulta Proveedor de Terraform Beta.
  • spot: configura el grupo de nodos a fin de usar VMs Spot para los nodos TPU. Esto no se puede cambiar después de la creación del grupo de nodos. Para obtener más información, consulta VMs Spot.
  • flex_start: Configura el grupo de nodos para usar la opción de consumo flex-start. No se puede establecer en true si spot está habilitado. Flex-start es compatible con la versión 1.33.0-gke.1712000 o posterior de GKE.

Console

Para crear un grupo de nodos con TPUs, haz lo siguiente:

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

    Ir a Google Kubernetes Engine

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

  3. Haz clic en Agregar grupo de nodos.

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

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

  6. Desde el panel de navegación, haz 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 host único
    • CT3P: TPU v3, porción de Pod de varios hosts
    • CT4P: TPU v4
    • CT5LP: TPU v5e
    • CT5P: TPU v5p
    • CT6E: TPU Trillium (v6e)

  9. En el menú desplegable Tipo de máquina, elige el nombre de la máquina que se usará para los nodos. Usa la tabla Elige la versión de TPU para saber cómo definir el tipo de máquina y la topología de TPU que crean un grupo de nodos de porción de TPU de host único.

  10. En el menú desplegable Topología de TPU, elige la topología física para la porción de TPU.

  11. En el diálogo Cambios necesarios, haz 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. De manera opcional, selecciona la casilla de verificación Habilitar nodos en VMs Spot a fin de usar VMs Spot para los nodos en el grupo de nodos.

  14. Haz clic en Crear.

Crea un grupo de nodos de porción de TPU de varios hosts

Los pasos para crear un grupo de nodos de porción de TPU de varios hosts difieren según si usas Ironwood (TPU7x) o una versión anterior de la TPU.

Ironwood (TPU7x)

Puedes crear un grupo de nodos de porción de TPU de varios hosts en la versión Ironwood (TPU7x) con Google Cloud CLI o Terraform:

gcloud

Para crear un grupo de nodos de porción de TPU de varios hosts con Ironwood (TPUv7), primero debes crear una política de carga de trabajo.

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

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

    Reemplaza lo siguiente:

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

  2. Crea el grupo de nodos con la política de cargas 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

    Reemplaza lo siguiente:

    • NODE_POOL_NAME: Es el nombre de tu grupo de nodos nuevo.
    • CLUSTER_NAME: Es el nombre del clúster de GKE.
    • WORKLOAD_POLICY_NAME: Es el nombre de la política de cargas de trabajo que creaste.
    • 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: Es el nombre de la zona en función de la versión de TPU que deseas usar. Para identificar una ubicación disponible, consulta Disponibilidad de TPU en GKE.
    • PROJECT_ID: El ID de tu proyecto Google Cloud .
    • RESERVATION_NAME: Es el nombre de la reserva que se usará.

    En este comando, la marca --tpu-topology se reemplazó 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 carga de trabajo:

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

    Reemplaza lo siguiente:

    • WORKLOAD_POLICY_NAME: Es un nombre para tu política de carga de trabajo.
    • CLUSTER_LOCATION: la ubicación de procesamiento del clúster. Recomendamos tener un clúster regional para obtener una mayor confiabilidad del plano de control de Kubernetes. También puedes usar un clúster zonal. Para obtener más información, consulta Selecciona una versión y una topología de TPU.
    • TPU_TOPOLOGY: Es la topología de la TPU Ironwood (TPU7x). Por ejemplo, 2x2x2 Para ver todas las topologías compatibles con Ironwood (TPU7x), consulta Planifica las TPU.

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

  3. En la configuración de Terraform, agrega 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
  }
}

    Reemplaza lo siguiente:

    • NODE_POOL_RESOURCE_NAME: El nombre del recurso del grupo de nodos en la plantilla de Terraform.
    • PROJECT_ID: el ID de tu proyecto
    • CLUSTER_NAME: Es el nombre del clúster existente al que se agregará el grupo de nodos.
    • POOL_NAME: el nombre del grupo de nodos que se creará.
    • NODE_ZONES: La lista separada por comas de una o más zonas en las que GKE crea el grupo de nodos.
    • NUM_NODES: Es la cantidad de nodos en el grupo de nodos. Debe ser cero o el producto de la cantidad de chips TPU dividido por cuatro, ya que en las porciones de TPU multihost cada nodo de porción de TPU tiene cuatro chips. Por ejemplo, si TPU_TOPOLOGY es 4x8, entonces hay 32 chips, lo que significa que NUM_NODES debe ser 8. Para obtener más información sobre las topologías de TPU, usa la tabla de Elige la versión de TPU.
    • TPU_TOPOLOGY: Indica la topología física seleccionada para la porción de TPU. El formato de la topología depende de la versión de la TPU que usas. Para obtener más información sobre las topologías de TPU, usa la tabla de Elige una topología.

    De manera opcional, también puedes usar las siguientes variables:

    • RESERVATION_NAME: Si usas una reserva de TPU, proporciona una lista de etiquetas de recursos de reserva para usar cuando crees el grupo de nodos. Para obtener más información sobre cómo completar RESERVATION_LABEL_VALUES en el campo reservation_affinity, consulta Proveedor de Terraform Beta.
    • autoscaling: Crea un grupo de nodos con el ajuste de escala automático habilitado. Cuando GKE escala un grupo de nodos de porción de TPU de varios hosts, escala de forma atómica desde el cero hasta el tamaño máximo.
      • MAX_NODES: Es el 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}) divididos por la cantidad de chips en cada VM. Por ejemplo, si TPU_TOPOLOGY es 2x2x2, el producto es 8. Dado que cada VM en tpu7x-standard-4t tiene 4 chips, la cantidad de nodos es 2.
    • spot: Es el grupo de nodos que usará VMs Spot para los nodos de porción de TPU. Este parámetro de configuración no se puede cambiar después de crear el grupo de nodos. Para obtener más información, consulta VMs Spot.
    • flex_start: Es el grupo de nodos que usará la opción de consumo de flex-start. Este parámetro de configuración no se puede establecer en true si spot está habilitado.

Otras versiones de TPU

Puedes crear un grupo de nodos de porción de TPU de varios hosts en las versiones v3, v4, v5p, v5e y Trillium (v6e) con Google Cloud CLI, Terraform o la consola de Google Cloud .

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]

Reemplaza lo siguiente:

  • POOL_NAME: el nombre del grupo de nodos nuevo
  • 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: Es el nombre de la zona en función de la versión de TPU que deseas usar. Para identificar una ubicación disponible, consulta Disponibilidad de TPU en GKE.
  • MACHINE_TYPE: Es el tipo de máquina que se usará para los nodos. Para obtener más información sobre los tipos de máquinas disponibles, consulta Elige la versión de TPU.

  • TPU_TOPOLOGY: la topología física para 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, usa la tabla en Elige una topología.

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

    De manera opcional, también puedes usar las siguientes marcas:

  • NUM_NODES: Es la cantidad de nodos en el grupo de nodos. Debe ser cero o el producto de los valores definidos en TPU_TOPOLOGY ({A}x{B}x{C}) divididos por la cantidad de chips en cada VM. Para TPU v4 y TPU v5e de varios hosts, el número de chips en cada VM es cuatro. Por lo tanto, si tu TPU_TOPOLOGY es 2x4x4 (TPU v4 con cuatro chips en cada VM), la NUM_NODES es 32/4, que es igual a 8. Si omites esta marca, la cantidad de nodos se calcula y se establece de forma predeterminada según la topología y el tipo de máquina.

  • RESERVATION_NAME: Es el nombre de la reserva que GKE usa cuando crea el grupo de nodos. Si omites esta marca, GKE usa los grupos de nodos de porción de TPU disponibles. Para obtener más información sobre las reservas de TPU, consulta Reserva de TPU.

  • --spot: Configura el grupo de nodos para que use VMs Spot para los nodos de la porción de TPU. Esto no se puede cambiar después de la creación del grupo de nodos. Para obtener más información, consulta VMs Spot.

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

  • --enable-autoscaling: Crea un grupo de nodos con el ajuste de escala automático habilitado. Cuando GKE escala un grupo de nodos de porción de TPU de varios hosts, escala de forma atómica desde el cero hasta el tamaño máximo.

    • MAX_NODES: Es el 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}) divididos por la cantidad de chips en cada VM.

  • --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 de varios hosts 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 VMs Spot no admiten la programación de la recopilación.

    Para obtener más información sobre la administración de la programación de colecciones, consulta Administra la programación de colecciones en segmentos de TPU de varios hosts.

  • --placement-type=COMPACT: Crea un grupo de nodos con la posición de compactación habilitada. Esta opción se debe usar con la marca --tpu-topology. Para obtener más información, consulta Crea una política de posició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. Agrega el siguiente bloque a la 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
  }
}

    Reemplaza lo siguiente:

    • NODE_POOL_RESOURCE_NAME: El nombre del recurso del grupo de nodos en la plantilla de Terraform.
    • PROJECT_ID: el ID de tu proyecto
    • CLUSTER_NAME: Es el nombre del clúster existente al que se agregará el grupo de nodos.
    • POOL_NAME: el nombre del grupo de nodos que se creará.
    • CLUSTER_LOCATION: Es la ubicación de procesamiento del clúster. Recomendamos tener un clúster regional para obtener una mayor confiabilidad del plano de control de Kubernetes. También puedes usar un clúster zonal. Para obtener más información, consulta Selecciona una versión y una topología de TPU.
    • NODE_ZONES: La lista separada por comas de una o más zonas en las que GKE crea el grupo de nodos.
    • NUM_NODES: Es la cantidad de nodos en el grupo de nodos. Debe ser cero o el producto del número de chips TPU dividido por cuatro, ya que en las porciones de TPU multihost cada nodo de porción de TPU tiene 4 chips. Por ejemplo, si TPU_TOPOLOGY es 4x8, entonces hay 32 chips, lo que significa que NUM_NODES debe ser 8. Para obtener más información sobre las topologías de TPU, usa la tabla de Elige la versión de TPU.
    • TPU_TOPOLOGY: Indica 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 que usas. Para obtener más información sobre las topologías de TPU, usa la tabla de Elige una topología.

    De manera opcional, también puedes usar las siguientes variables:

    • RESERVATION_NAME: Si usas la reserva de TPU, esta es la lista de etiquetas de los recursos de reserva que se usarán cuando se cree el grupo de nodos. Para obtener más información sobre cómo completar RESERVATION_LABEL_VALUES en el campo reservation_affinity, consulta Proveedor de Terraform Beta.
    • autoscaling: Crea un grupo de nodos con el ajuste de escala automático habilitado. Cuando GKE escala un grupo de nodos de porción de TPU de varios hosts, escala de forma atómica desde el cero hasta el tamaño máximo.
      • MAX_NODES: Es el tamaño máximo del grupo de nodos. Debe ser igual al producto de los valores definidos en TPU_TOPOLOGY ({A}x{B}x{C}) divididos por la cantidad de chips en cada VM.
    • spot: Permite que el grupo de nodos use VMs Spot para los nodos de porción de TPU. Esto no se puede cambiar después de la creación del grupo de nodos. Para obtener más información, consulta VMs Spot.
    • flex_start: Configura el grupo de nodos para usar la opción de consumo flex-start. No se puede establecer en true si spot está habilitado.

Console

Para crear un grupo de nodos con TPUs, haz lo siguiente:

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

    Ir a Google Kubernetes Engine

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

  3. Haz clic en Agregar grupo de nodos.

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

  5. Selecciona el nombre de la zona según la versión de TPU que deseas usar. Para identificar una ubicación disponible, consulta Disponibilidad de TPU en GKE.

  6. Desde el panel de navegación, haz 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 host único
    • CT3P: TPU v3, porción de Pod de varios hosts
    • CT4P: TPU v4
    • CT5LP: TPU v5e
    • CT5P: TPU v5p
    • CT6E: TPU Trillium (v6e)

  9. En el menú desplegable Tipo de máquina, elige el nombre de la máquina que se usará para los nodos. Usa la tabla Elige la versión de TPU para saber cómo definir el tipo de máquina y la topología de TPU que crean un grupo de nodos de porción de TPU de varios hosts.

  10. En el menú desplegable Topología de TPU, elige la topología física para la porción de TPU.

  11. En el diálogo Cambios necesarios, haz 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. De manera opcional, selecciona la casilla de verificación Habilitar nodos en VMs Spot a fin de usar VMs Spot para los nodos en el grupo de nodos.

  14. Haz clic en Crear.

Usa el aprovisionamiento automático de nodos de GKE

Puedes configurar GKE a fin de crear y borrar grupos de nodos de forma automática para 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

    Reemplaza lo siguiente:

    • TPU_TYPE: Es el tipo de TPU. Por ejemplo, usa tpu7x-standard-4t para Ironwood (TPU7x).
    • MINIMUM_TPU_COUNT: Es la cantidad mínima de chips TPU del tipo especificado que puede tener el clúster. Si el valor que especificas es mayor que la cantidad de chips TPU en una porción de TPU de varios hosts, GKE quita todos los nodos de la porción. Los grupos de nodos de varios hosts se ajustan entre 0 y la cantidad de nodos de la división, sin valores intermedios.
    • MAXIMUM_TPU_COUNT: Es la cantidad máxima de chips TPU del tipo especificado que puede tener el clúster. En el caso de las porciones de TPU de varios hosts, especifica un valor mayor que la cantidad de chips en cada porción para que GKE pueda escalar la porción de forma atómica. La cantidad de chips en una porción es el producto de la topología de TPU. Por ejemplo, si la topología es 2x2x2, la cantidad de chips en la porción es 8, lo que significa que el valor de MAXIMUM_TPU_COUNT debe ser mayor que 8.

Define ComputeClasses personalizadas

También puedes configurar GKE para que solicite TPU durante las operaciones de ajuste de escala que crean nodos nuevos con ComputeClasses personalizadas.

Puedes especificar opciones de configuración de TPU en la especificación de ComputeClass personalizada. Cuando una carga de trabajo de GKE usa esa ComputeClass personalizada, GKE intenta aprovisionar TPU que usen la configuración especificada cuando se realiza el ajuste de escala.

En las siguientes secciones, se muestra cómo crear una ComputeClass personalizada y, luego, crear un trabajo que consuma las TPU definidas en la ComputeClass.

Crea una ComputeClass personalizada

Los pasos para crear una ComputeClass personalizada que siga las reglas de TPU difieren según si usas Ironwood (TPUv7) o una versión anterior de TPU.

Ironwood (TPU7x)

  1. Crea una política de carga de trabajo. Este paso solo es obligatorio si creas un grupo de nodos de varios hosts, que depende de la topología que elijas. Si usas un grupo de nodos de host único, omite este paso.

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

    Reemplaza lo siguiente:

    • WORKLOAD_POLICY_NAME: Es un nombre para tu política de carga de trabajo.
    • TPU_TOPOLOGY: Es 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: Es el ID del proyecto de Google Cloud .
    • REGION: Es la región de la política de carga de trabajo. Una política de carga de trabajo es un recurso regional que puedes usar en todos los grupos de nodos.

  2. Guarda el siguiente 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 agregar el siguiente specs a tu manifiesto de ComputeClass:

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

    Reemplaza lo siguiente:

    • RESERVATION_NAME es el nombre de la reserva de capacidad de Compute Engine.
    • RESERVATION_BLOCK_NAME: Es el nombre del bloque de reserva de capacidad de Compute Engine.
    • RESERVATION_SUB_BLOCK_NAME: Es el nombre del sub-bloque de la reserva de capacidad de Compute Engine.

    Para obtener más información, consulta Consume recursos zonales reservados.

Otras versiones de TPU

Para aprovisionar TPU v3, v4, v5p, v5e o v6e (Trillium) con una ComputeClass personalizada configurada para TPUs, completa los siguientes pasos:

  1. Guarda el siguiente 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

    Reemplaza lo siguiente:

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

  2. Implementa ComputeClass:

    kubectl apply -f tpu-compute-class.yaml

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

Crea un trabajo que consuma TPUs

  1. Guarda el siguiente 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

    Reemplaza lo siguiente:

    • NUMBER_OF_CHIPS: Es la cantidad de chips TPU que usará el contenedor. Debe ser el mismo valor para limits y requests, igual al valor de CHIP_COUNT en la ComputeClass personalizada seleccionada.
    • MEMORY_SIZE: Es la 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 uses. Para obtener más información, consulta Valores mínimos y máximos para los aceleradores.
    • NUMBER_OF_CHIPS: Es la cantidad de chips TPU que usará el contenedor. Debe ser el mismo valor para limits y requests.

  2. Implementa el trabajo:

    kubectl create -f tpu-job.yaml

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

    • Aprovisiona nodos para ejecutar los Pods. Según el tipo de TPU, la topología y las solicitudes de recursos que especificaste, estos nodos son porciones de host único o de varios hosts. Según la disponibilidad de los recursos de TPU en la prioridad más alta, es posible que GKE recurra a prioridades más bajas para maximizar la capacidad de obtención.
    • Agrega taints 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 borrar los recursos que creaste para evitar que se te siga facturando:

    kubectl delete -f tpu-job.yaml

Prepara tus cargas de trabajo

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

  1. Los frameworks como JAX, PyTorch y TensorFlow acceden a las VMs de TPU con la biblioteca compartida libtpu. libtpu incluye el compilador XLA, el software del entorno de ejecución de TPU y el controlador de TPU. Cada versión de PyTorch y JAX requiere una versión determinada de libtpu.so. Para evitar conflictos de versiones de paquetes, te recomendamos que uses una imagen generada por IA de JAX. Para usar las TPUs en GKE, asegúrate de usar las siguientes versiones: tpu7x
    Tipo de TPU libtpu.so versión
    Ironwood (TPU7x) (vista previa)
    TPU Trillium (v6e)
    tpu-v6e-slice
    TPU v5e
    tpu-v5-lite-podslice
    TPU v5p
    tpu-v5p-slice
    • Imagen generada por 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 de compilación nocturna del 23 de octubre de 2023.
    TPU v4
    tpu-v4-podslice
    TPU v3
    tpu-v3-slice
    tpu-v3-device
  2. En el manifiesto de la carga de trabajo, agrega un selector de nodos de Kubernetes para asegurarte de que GKE programe la carga de trabajo de TPU en el tipo de máquina de TPU y la topología de TPU que definiste:

      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)

    Reemplaza lo siguiente:

    • TPU_ACCELERATOR: Es el nombre del acelerador de TPU. Por ejemplo, usa tpu7x-standard-4t.
    • TPU_TOPOLOGY: la topología física para 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 Planifica las TPU en GKE.
    • WORKLOAD_POLICY: Es el nombre de la política de cargas de trabajo que deseas usar para colocar tus Pods de TPU. Este selector de nodos solo es obligatorio para Ironwood (TPU7x).

Después de completar la preparación de la carga de trabajo, puedes ejecutar un trabajo que use TPUs.

En las siguientes secciones, se muestran ejemplos sobre cómo ejecutar un trabajo que realiza procesamiento básico con las TPUs.

Ejecuta tu carga de trabajo en nodos de porción de TPU

En esta sección, se explica cómo preparar tus cargas de trabajo y se incluyen ejemplos de cómo puedes ejecutarlas.

Ejemplo 1: Ejecuta una Deployment que solicite TPUs en la especificación del 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 Deployment que solicita TPUs en la especificación de Pod. Si está habilitado el parámetro de configuración de aprovisionamiento automático de nodos a nivel del clúster, esta Deployment activa la creación automática del grupo 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 la cantidad y la disposición física de los chips TPU dentro de una porción de TPU. Por ejemplo, usa 2x2x2.
  • limits.google.com/tpu: Es la cantidad de chips de TPU por VM. Por ejemplo, si usas tpu7x-standard-4t, la cantidad de chips TPU por VM es 4.

Ejemplo 2: Ejecuta una carga de trabajo que muestre la cantidad de chips TPU disponibles en un grupo de nodos de porción de TPU

La siguiente carga de trabajo devuelve la cantidad de chips TPU en todos los nodos de una porción de TPU de varios hosts. Para crear una porción de varios hosts, la carga de trabajo tiene los siguientes parámetros:

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

Esta elección de versión y topología dan como resultado una porción de varios hosts.

  1. Guarda el siguiente 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 manifiesto: 
    kubectl create -f available-chips-multihost.yaml

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

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

    El resultado es similar a este:

    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

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

    El resultado es similar a lo siguiente: 

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

Ejemplo 3: Ejecuta una carga de trabajo que muestre la cantidad de chips TPU disponibles en la porción de TPU

La siguiente carga de trabajo es un Pod estático que muestra la cantidad de chips TPU adjuntos a un nodo específico. Para crear un nodo de host único, la carga de trabajo tiene los siguientes parámetros:

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

Esta elección de versión y topología da como resultado una porción de host único.

  1. Guarda el siguiente 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 manifiesto: 
    kubectl create -f available-chips-singlehost.yaml

    GKE aprovisiona nodos con ocho porciones de TPU de host único que usan TPU v5e. Cada nodo TPU tiene ocho chips TPU (porción de TPU de host único).

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

    El resultado es similar a lo siguiente: 

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

Actualiza los grupos de nodos mediante aceleradores (GPU y TPU)

GKE actualiza de forma automática los clústeres de Standard, incluidos los grupos de nodos. También puedes actualizar manualmente los grupos de nodos si deseas que los nodos se usen en una versión posterior antes. Para controlar cómo funcionan las actualizaciones de tu clúster, usa canales de versiones, períodos de mantenimiento y exclusiones, y secuenciación de lanzamientos.

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

El uso de una estrategia de actualización de nodos requiere que GKE aprovisione de forma temporal recursos adicionales, según la configuración. Si Google Cloud tiene capacidad limitada para los recursos de tu grupo de nodos, por ejemplo, si ves errores de disponibilidad de recursos cuando intentas crear más nodos con GPU o TPU, consulta Actualiza en un entorno con recursos restringidos.

Realiza una limpieza

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos que usaste en esta guía, considera borrar los grupos de nodos de segmentos de TPU que ya no tengan cargas de trabajo programadas. Si las cargas de trabajo que se ejecutan deben finalizarse de forma correcta, usa kubectl drain para limpiar las cargas de trabajo antes de borrar el nodo.

  1. Borra un grupo de nodos de porción de TPU:

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

    Reemplaza lo siguiente:

    • POOL_NAME: Es el nombre del grupo de nodos.
    • CLUSTER_NAME: Es el nombre del clúster.
    • LOCATION: Es la ubicación de procesamiento del clúster.

Configura los parámetros adicionales

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

Usa Multislice

Puedes hacer una agregación de porciones más pequeñas que formen una porción múltiple para manejar cargas de trabajo de entrenamiento más grandes. Para obtener más información, consulta TPUs de porciones múltiples en GKE.

Migra tu reserva de TPU

Si tienes reservas de TPU existentes, primero debes migrar tu reserva de TPU a un sistema de reserva nuevo basado en Compute Engine. También puedes crear un sistema de reserva basado en Compute Engine en el que no se necesite migración. Para obtener información sobre cómo migrar tus reservas de TPU, consulta Reserva de TPU.

Habilitar registro

Los registros que emiten los contenedores que se ejecutan en nodos de GKE, incluidas las VMs de TPU, son recopiladas por el agente de Logging de GKE, se envían a Logging y son visibles en Logging.

Configura la reparación automática para los nodos de porción de TPU

Si un nodo de porción de TPU en un grupo de nodos de porción de TPU de varios hosts está en mal estado, se vuelve a crear todo el grupo de nodos. En cambio, en un grupo de nodos de porción de TPU de host único, solo se repara automáticamente el nodo TPU en mal estado.

Las condiciones que dan como resultado nodos de porción de TPU en mal estado incluyen las siguientes:

  • Cualquier nodo de porción de TPU con condiciones de nodo comunes
  • Cualquier nodo de porción de TPU con un recuento de TPU no asignables superior a cero
  • Cualquier instancia de VM en una porción de TPU que se detenga (debido a una interrupción) o que se cierre
  • Mantenimiento de nodos: Si algún nodo de porción de TPU dentro de un grupo de nodos de porción de TPU de varios hosts queda inactivo para el mantenimiento del host, GKE vuelve a crear todo el grupo de nodos de porción de TPU.

Puedes ver el estado de reparación (incluido el motivo de la falla) en el historial de operaciones. Si la falla se debe a una cuota insuficiente, comunícate con tu representante de cuenta deGoogle Cloud para aumentar la cuota correspondiente.

Configura la finalización correcta para los nodos de porción de TPU

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

Para configurar GKE para finalizar tus cargas de trabajo de forma ordenada en el plazo de este período de notificación, sigue los pasos que se indican en Administra la interrupción de nodos de GKE para GPUs y TPUs.

Ejecutar contenedores sin modo privilegiado

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

Si tu nodo de porción de TPU ejecuta versiones anteriores a la 1.28, lee la siguiente sección:

Un contenedor que se ejecuta en una VM en una porción de TPU necesita acceso a límites más altos en la memoria bloqueada para que el controlador pueda comunicarse con los chips TPU a través del acceso directo a la memoria (DMA). Para habilitar esto, debes configurar un ulimit más alto. Si deseas reducir el permiso de permisos en tu contenedor, completa los siguientes pasos:

  1. Edita securityContext para que incluya los siguientes campos:

    securityContext:
  capabilities:
    add: ["SYS_RESOURCE"]

  2. Aumenta ulimit mediante la ejecución del siguiente comando dentro del contenedor antes de configurar las cargas de trabajo para que usen recursos TPU:

    ulimit -l 68719476736

En el caso de las TPU v5e, la ejecución de contenedores sin modo privilegiado está disponible en los clústeres en la versión 1.27.4-gke.900 y posteriores.

Observabilidad y métricas

Panel

La observabilidad del grupo 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 Estado del grupo de nodos de TPU de GKE que proporciona Cloud Monitoring:

Ir al estado del grupo de nodos de TPU de GKE

Este panel te brinda estadísticas integrales sobre el estado de tus grupos de nodo TPU de varios hosts. Para obtener más información, consulta Supervisa 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 las métricas de observabilidad de TPU, como el uso de TPU, en el encabezado Aceleradores > TPU. Para obtener más información, consulta Visualiza métricas de observabilidad.

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

Métricas del entorno de ejecución

En la versión 1.27.4-gke.900 o posterior de GKE, las cargas de trabajo de TPU que usan la versión 0.4.14 o posterior de JAX y especifican containerPort: 8431 exportan las métricas de uso de TPU como métricas del sistema de GKE. Las siguientes métricas están disponibles en Cloud Monitoring para supervisar el rendimiento del entorno de ejecución de tu carga de trabajo de TPU:

  • Ciclo de trabajo: Porcentaje de tiempo durante el último período de muestreo (60 segundos) durante el cual los TensorCores se procesaron de forma activa en un chip TPU. Un porcentaje mayor significa un mejor uso de TPU.
  • Memoria usada: Cantidad de memoria del acelerador asignada en bytes. Se tomaron muestras cada 60 segundos.
  • Memoria total: Memoria total del acelerador en bytes. Se hace un muestreo cada 60 segundos.

Estas métricas se encuentran en el esquema de nodos de Kubernetes (k8s_node) y de contenedor 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

Supervisa las métricas de estado de los nodos y grupos de nodos de TPU

Cuando un trabajo de entrenamiento tiene un error o finaliza con una falla, puedes verificar las métricas relacionadas con la infraestructura subyacente para determinar si la interrupción se debió a un problema con el nodo o el grupo de nodos subyacente.

Estado del nodo

En la versión 1.32.1-gke.1357001 o posterior de GKE, 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 las condiciones del nodo, como Ready, DiskPressure y MemoryPressure. El campo status muestra el estado informado de la condición, que puede ser True, False o Unknown. Esta es una métrica con el tipo de recurso supervisado k8s_node.

Esta consulta de PromQL muestra si un nodo en particular es Ready:

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

Para ayudarte a solucionar problemas en un clúster, puedes consultar los nodos que hayan presentado otras condiciones:

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

Es posible que desees observar específicamente los nodos que no son Ready:

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

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

Puedes usar la siguiente consulta para comprender el estado de los nodos en 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 para el recurso supervisado k8s_node_pool expone el estado de un grupo de nodos de GKE:

  • kubernetes.io/node_pool/status

Esta métrica solo se informa para los grupos de nodo TPU de varios hosts.

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

Para verificar si un grupo de nodos en particular 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 supervisar la cantidad de grupos de nodos en 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 nodo TPU de varios hosts:

  • kubernetes.io/node_pool/multi_host/available

La métrica tiene un valor de 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 verificar la disponibilidad de los grupos de nodo 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}]))

Recuento de interrupciones de nodos

La siguiente métrica del sistema de GKE informa el recuento de interrupciones de un nodo de GKE desde la última muestra (la métrica se muestrea cada 60 segundos):

  • kubernetes.io/node/interruption_count

Los campos interruption_type (como TerminationEvent, MaintenanceEvent o PreemptionEvent) y interruption_reason (como HostError, Eviction o AutoRepair) pueden ayudar a proporcionar el motivo por el que se interrumpió un nodo.

Para obtener un desglose de las interrupciones y sus causas en los nodos 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 para el interruption_reason. Usa la siguiente consulta de PromQL:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

Para ver el recuento de interrupciones agregado por grupo de nodos, usa la siguiente consulta de PromQL:

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

Tiempos de recuperación (TTR) del grupo de nodos

La siguiente métrica del sistema de GKE informa la distribución de las duraciones del período de recuperación para los grupos de nodo TPU de varios hosts de GKE:

  • kubernetes.io/node_pool/accelerator/times_to_recover

Cada muestra registrada en esta métrica indica un solo evento de recuperación del grupo de nodos a partir de un período de inactividad.

Esta métrica es útil para hacer un seguimiento del tiempo de recuperación y el tiempo entre interrupciones del grupo de nodo 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]))

Tiempos entre interrupciones (TBI) del grupo de nodos

Los tiempos entre interrupciones del grupo de nodos miden cuánto tiempo se ejecuta tu infraestructura antes de experimentar una interrupción. Se calcula como el promedio en un período, en el que el numerador mide el tiempo total que estuvo activa tu infraestructura y el denominador mide las interrupciones totales en tu infraestructura.

En el siguiente ejemplo de PromQL, se muestra el tiempo medio entre interrupciones (MTBI) de 7 días para el clúster determinado:

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 la versión 1.28.1-gke.1066000 o posterior de GKE, las VMs de una porción de TPU exportan las métricas de uso de TPU como métricas del sistema de GKE. Las siguientes métricas están disponibles en Cloud Monitoring para supervisar el rendimiento de tu host TPU:

  • Uso de TensorCore: Porcentaje actual del TensorCore que se usa. El valor de TensorCore es igual a la suma de las unidades de multiplicación de matriz (MXUs) más la unidad vectorial. El valor de uso de TensorCore es la división de las operaciones de TensorCore que se llevaron a cabo durante el último período de muestra (60 segundos) por la cantidad compatible de operaciones de TensorCore durante el mismo período. Un valor mayor significa un mejor uso.
  • Uso de ancho de banda de memoria: Porcentaje actual del ancho de banda de memoria del acelerador que se usa. Se calcula dividiendo el ancho de banda de memoria usado durante un período de muestra (60 s) por el ancho de banda máximo admitido durante el mismo período de muestra.

Estas métricas se encuentran en el esquema de nodos de Kubernetes (k8s_node) y de contenedor 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 Métricas de Kubernetes y Métricas del sistema de GKE.

Administra la programación de la colección

En la TPU Trillium, puedes usar la programación de recopilación para agrupar los nodos de porción de TPU. Agrupar estos nodos de segmentación de TPU facilita el ajuste de la cantidad de réplicas para satisfacer la demanda de la carga de trabajo. Google Cloud controla las actualizaciones de software para garantizar que siempre haya suficientes segmentaciones disponibles en la colección para atender el tráfico.

La TPU Trillium admite la programación de recopilación para grupos de nodos de host único 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 recopilación según el tipo de porción de TPU que uses:

  • Porción de TPU de varios hosts: GKE agrupa las porciones de TPU de varios hosts para formar una colección. Cada grupo de nodos de GKE es una réplica dentro de esta colección. Para definir una colección, crea una porción de TPU de varios hosts y asígnale un nombre único. Para agregar más porciones de TPU a la colección, crea otro grupo de nodos de porción de TPU de varios hosts con el mismo nombre de colección y tipo de carga de trabajo.
  • Porción de TPU de host único: GKE considera todo el grupo de nodos de porción de TPU de host único como una colección. Para agregar más porciones de TPU a la colección, puedes cambiar el tamaño del grupo de nodos de porción de TPU de host único.

Para administrar una colección, realiza cualquiera de estas acciones según el tipo de grupo de nodos que uses.

Administra la programación de la recopilación en grupos de nodos de porciones de TPU de varios hosts

Usa las siguientes tareas para administrar grupos de nodos de porción de TPU de varios hosts.

  • Para verificar si un grupo de porciones de TPU de varios hosts 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 es similar a lo siguiente:

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

    Si el grupo de porciones de TPU de varios hosts forma parte de una colección, el resultado 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 es similar a lo 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 es similar a lo siguiente:

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

  • Para aumentar la escala de la colección, crea otro grupo de nodos de porción de TPU de varios hosts y agrega 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 según las demandas de la carga de trabajo.

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

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

Administra la programación de la recopilación en grupos de nodos de porción de TPU de host único

Usa las siguientes tareas para administrar grupos de nodos de porción de TPU de host único.

  • Para verificar si un grupo de porciones de TPU de un solo host tiene habilitada la programación de recopilació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 es similar a lo siguiente:

    gke-workload-type: HIGH_AVAILABILITY

    Si el grupo de porciones de TPU de host único 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 recopilació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, borra el grupo de nodos.

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

Problemas conocidos

  • El escalador automático del clúster podría calcular de forma incorrecta la capacidad de los nodos de porción TPU nuevos antes de que esos nodos informen las TPUs disponibles. Luego, el escalador automático del clúster puede realizar un escalamiento vertical adicional y, como resultado, crear más nodos de los necesarios. El escalador automático del clúster reduce la escala verticalmente de los nodos adicionales, si no son necesarios, después de la operación de reducción de escala vertical regular.
  • El escalador automático de clústeres cancela el escalamiento vertical de los grupos de nodos de la porción de TPU que permanecen en estado de espera durante más de 10 horas. El escalador automático del clúster volverá a intentar esas operaciones de escalamiento vertical más adelante. Este comportamiento puede reducir la capacidad de obtención de TPUs para los clientes que no usan reservas.
  • Las cargas de trabajo que no sean de TPU y tengan tolerancia al taint de TPU pueden impedir la reducción de la escala vertical del grupo de nodos si se vuelven a crear durante el vaciado del grupo de nodos de la porción de TPU.
  • La métrica de uso del ancho de banda de la memoria no está disponible para las TPU v5e.

¿Qué sigue?