Esta página se ha traducido con Cloud Translation API.

Desplegar cargas de trabajo de TPUs en GKE Standard

Estándar

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 energéticamente 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úrese de que conoce 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 gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.
Nota: Si ya tienes instalada la CLI de gcloud, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

Planificar la configuración de la TPU

Planifica la configuración de las TPUs 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 asegurarte de que tienes suficiente cuota al usar TPUs en GKE.

Cuota de máquinas virtuales 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.¹ 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:

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

Ir a Cuotas

En el cuadro Filtrar, haz lo siguiente:

Usa la siguiente tabla para seleccionar y copiar la propiedad de la cuota en función de la versión de TPU y del 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 Spot²
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

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.

Cuando crees un grupo de nodos de un segmento 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. ↩
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 alinea 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 que se agote 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.

Opciones para aprovisionar TPUs en GKE

GKE te permite usar TPUs directamente en cargas de trabajo individuales mediante nodeSelectors de Kubernetes en el manifiesto de la carga de trabajo o creando grupos de nodos en modo estándar con TPUs.

También puedes solicitar TPUs mediante clases de computación personalizadas. Las clases de computación 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.

Para obtener instrucciones, consulta la sección Aprovisionar TPUs con clases de computación personalizadas.

Crear un clúster

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.

Crear un grupo de nodos

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: 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: 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 compatibles con TPU, consulta la tabla de la sección Elegir la versión de TPU.

También puedes usar los siguientes elementos opcionales:

--num-nodes=NUM_NODES: número inicial de nodos del grupo de nodos en cada zona. Si omite esta marca, GKE asigna el valor predeterminado 3.

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 tus cargas de trabajo lo requieran.
--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 las slices de TPU de un solo host.
--enable-autoscaling: crea un grupo de nodos con el autoescalado 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 las 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 flex-start, que es compatible con GKE 1.33.0-gke.1712000 o versiones posteriores.
--sandbox=type=gvisor: aprovisiona un nodo con GKE Sandbox habilitado. Requiere la versión 4 de TPU o versiones posteriores. Para obtener más información, consulta GKE Sandbox.

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

Terraform

Asegúrate de usar la versión 4.84.0 o una posterior del proveedor google.
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: 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 autoescalado 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:

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

Ir a Google Kubernetes Engine
En la lista de clústeres, haga clic en el nombre del clúster que quiera modificar.
Haz clic en Añadir grupo de nodos.
En la sección Detalles del grupo de nodos, marca la casilla Especificar ubicaciones de nodos.
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.
En el panel de navegación, haga clic en Nodos.
En la sección Configuración de la máquina, selecciona TPUs.
En el menú desplegable Serie, selecciona una de las siguientes opciones:
- CT3 dispositivo de TPU v3 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)
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.
En el menú desplegable Topología de TPU, selecciona la topología física del slice de TPU.
En el cuadro de diálogo Cambios necesarios, haga clic en Hacer cambios.
Asegúrate de que Tipo de disco de arranque sea Disco persistente estándar o Disco persistente SSD.
Si quieres usar Spot VMs para los nodos del grupo de nodos, puedes marcar la casilla Habilitar nodos en Spot VMs.
Haz clic en Crear.

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

Puedes crear un nodo de slice de TPU multihost mediante la CLI de Google Cloud, Terraform o la Google Cloud consola.

gcloud

gcloud container node-pools create POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --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.
LOCATION: 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: 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 del segmento 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 de la sección Elegir una topología.

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

También puedes usar los siguientes elementos opcionales:

NUM_NODES: 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: nombre de la reserva que usa GKE al crear el grupo de nodos. Si omite esta marca, GKE usará los grupos de nodos de segmentos 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 VMs 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 GKE 1.33.0-gke.1712000 o versiones posteriores.
--enable-autoscaling: crea un grupo de nodos con el autoescalado habilitado. Cuando GKE escala un grupo de nodos de un segmento de TPU multianfitrión, 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 en el nuevo grupo de nodos.
- El grupo de nodos usa TPU Trillium.
- Las máquinas virtuales de acceso puntual no admiten la programación de la recopilación.
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

Asegúrate de usar la versión 4.84.0 o una posterior del proveedor google.
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]
    }
    spot = true
    flex_start = false
  }

  placement_policy {
    type = "COMPACT"
    tpu_topology = TPU_TOPOLOGY
  }
}
```
Haz los cambios siguientes:
- NODE_POOL_RESOURCE_NAME: el nombre del recurso de perfil de nodo 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: nombre del grupo de nodos que se va a crear.
- 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.
- 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 deseada de la porción 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, 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 autoescalado habilitado. Cuando GKE escala un grupo de nodos de un segmento de TPU multianfitrión, 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 grupo 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:

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

Ir a Google Kubernetes Engine
En la lista de clústeres, haga clic en el nombre del clúster que quiera modificar.
Haz clic en Añadir grupo de nodos.
En la sección Detalles del grupo de nodos, marca la casilla Especificar ubicaciones de nodos.
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.
En el panel de navegación, haga clic en Nodos.
En la sección Configuración de la máquina, selecciona TPUs.
En el menú desplegable Serie, selecciona una de las siguientes opciones:
- CT3P: para TPU v3.
- CT4P: para TPU v4.
- CT5LP: para la TPU v5e.
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.
En el menú desplegable Topología de TPU, selecciona la topología física del slice de TPU.
En el cuadro de diálogo Cambios necesarios, haga clic en Hacer cambios.
Asegúrate de que Tipo de disco de arranque sea Disco persistente estándar o Disco persistente SSD.
Si quieres, marca la casilla Habilitar nodos en VMs Spot para usar VMs Spot en los nodos del grupo de nodos.
Haz clic en Crear.

Cómo gestiona GKE los problemas de capacidad

Si GKE no puede crear tu grupo de nodos de segmento de TPU porque no hay capacidad de TPU suficiente, GKE devuelve un mensaje de error que indica que no se pueden crear los nodos de segmento de TPU por falta de capacidad.

Si vas a crear un grupo de nodos de segmento de TPU de un solo host, el mensaje de error será similar a este:

2 nodes cannot be created due to lack of capacity. The missing nodes will be
created asynchronously once capacity is available. You can either wait for the
nodes to be up, or delete the node pool and try re-creating it again later.

Si vas a crear un grupo de nodos de segmento de TPU de varios hosts, el mensaje de error será similar a este:

The nodes (managed by ...) cannot be created now due to lack of capacity. They
will be created asynchronously once capacity is available. You can either wait
for the nodes to be up, or delete the node pool and try re-creating it again
later.

Tu solicitud de aprovisionamiento de TPU puede permanecer en la cola durante mucho tiempo y permanecer en el estado "Provisioning" (Aprovisionando) mientras está en la cola.

Cuando haya capacidad disponible, GKE creará los nodos restantes que no se hayan creado.

Si necesitas capacidad antes, prueba las máquinas virtuales de acceso puntual. Ten en cuenta que consumen una cuota diferente a las instancias bajo demanda.

Para eliminar la solicitud de TPU en cola, elimina el grupo de nodos de la porción de TPU.

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.

Preparar las cargas de trabajo

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

Frameworks como JAX, PyTorch y TensorFlow acceden a las VMs de TPU mediante la libtpubiblioteca compartida. libtpu incluye el compilador XLA, el software de tiempo de ejecución de TPU y el controlador de 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 JAX AI. Para usar TPUs en GKE, asegúrate de usar las siguientes versiones:

Tipo de TPU	Versión de `libtpu.so`
TPU Trillium (v6e) `tpu-v6e-slice`	Imagen de IA de JAX recomendada: jax0.4.35-rev1 o posterior Versión recomendada de jax[tpu]: v0.4.9 o posterior Versión recomendada de torchxla[tpuvm]: v2.1.0 o posterior
TPU v5e `tpu-v5-lite-podslice`	Imagen de IA de JAX recomendada: jax0.4.35-rev1 o posterior Versión recomendada de jax[tpu]: v0.4.9 o posterior Versión recomendada de torchxla[tpuvm]: v2.1.0 o posterior
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`	Imagen de IA de JAX recomendada: jax0.4.35-rev1 o posterior jax[tpu] recomendado: v0.4.4 o una versión posterior torchxla[tpuvm] recomendado: v2.0.0 o versiones posteriores
TPU v3 `tpu-v3-slice` `tpu-v3-device`	Imagen de IA de JAX recomendada: jax0.4.35-rev1 o posterior jax[tpu] recomendado: v0.4.4 o una versión posterior torchxla[tpuvm] recomendado: v2.0.0 o versiones posteriores

Define las siguientes variables de entorno para el contenedor que solicita los recursos de TPU:
- TPU_WORKER_ID: un número entero único para cada Pod. Este ID denota un ID de trabajador único en el segmento de TPU. Los valores admitidos para este campo van de cero al número de pods menos uno.
- TPU_WORKER_HOSTNAMES: lista separada por comas de nombres de host o direcciones IP de VMs de TPU que deben comunicarse entre sí en el slice. Debe haber un nombre de host o una dirección IP para cada VM de TPU de la porción. La lista de direcciones IP o nombres de host se ordena y se indexa desde cero por el TPU_WORKER_ID.
- 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
  
```
  Haz los cambios siguientes:
  - TPU_ACCELERATOR: nombre del acelerador 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, consulta Planificar TPUs en GKE.

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.

Ejemplo 1: 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 una porción 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.

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.

Implementa el archivo de manifiesto:
```
kubectl create -f available-chips-multihost.yaml
```
GKE ejecuta un segmento de TPU v4 con cuatro VMs (segmento de TPU de varios hosts). La porción tiene 16 chips de TPU interconectados.

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

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
```

Opcional: Elimina la carga de trabajo:

kubectl delete -f available-chips-multihost.yaml

Ejemplo 2: 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 la topología seleccionada dan como resultado un slice de un solo host.

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.

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).
Obtén los registros del pod:
```
kubectl logs tpu-job-jax-v5
```
El resultado debería ser similar al siguiente:
```
Total TPU chips: 8
```

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

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.

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 slices de TPU a la colección, crea otro grupo de nodos de slice 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 grupo de nodos del 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 TPU 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 una porción 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, la salida 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. Al eliminar el clúster, se eliminarán todas las colecciones que contenga.

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.

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. Para obtener más información, consulta Configurar TPUs de Cloud.

Aprovisionar TPUs mediante clases de computación personalizadas

También puedes configurar GKE para que solicite TPUs durante las operaciones de escalado que creen nodos nuevos mediante clases de computación personalizadas.

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

Para aprovisionar TPUs con una clase de computación personalizada que siga las reglas de las TPUs y desplegar la carga de trabajo, sigue estos pasos:

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-v5-lite-podslice
      count: 4
      topology: 2x4
  - spot: true
    tpu:
      type: tpu-v5-lite-podslice
      count: 4
      topology: 2x4
  - flexStart:
      enabled: true
    tpu:
      type: tpu-v6e-slice
      count: 4
      topology: 2x4
  nodePoolAutoCreation:
    enabled: true

Despliega la clase de cálculo:
```
kubectl apply -f tpu-compute-class.yaml
```
Para obtener más información sobre las clases de computación personalizadas y las TPUs, consulta Configuración de TPUs.

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 del campo tpu.count de la clase de cálculo personalizada seleccionada.
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.

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 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, consulte Acerca de las clases de cálculo personalizadas.
Cuando termines esta sección, puedes evitar que se te siga facturando eliminando los recursos que has creado:
```
kubectl delete -f tpu-job.yaml
```

Configurar la reparación automática de nodos de un slice 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 número de TPUs no asignables superior a cero.
Cualquier instancia de VM de una porción de TPU que se haya detenido (debido a una interrupción) o se haya terminado.
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 que no tienes suficiente cuota, ponte en contacto con tuGoogle 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 ejecutan la versión 1.29.1-gke.1425000 o una 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 plazo 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 tu nodo de 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 valor ulimit más alto. Si quieres reducir el ámbito de los permisos de tu contenedor, sigue estos pasos:

Edita el securityContext para incluir los siguientes campos:

securityContext:
  capabilities:
    add: ["SYS_RESOURCE"]

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 al 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 las 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 nodo 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

Monitorizar 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 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 grupo 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 pool 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, actualice 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 único 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 pool 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) de los grupos de nodos

El tiempo entre interrupciones de un grupo de nodos mide cuánto tiempo se ejecuta tu infraestructura antes de sufrir una interrupción. Se calcula como la media de un periodo determinado, 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 segundos) entre el ancho de banda máximo admitido durante el mismo periodo.

Estas métricas se encuentran en el esquema de nodo 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 las métricas de Kubernetes y las métricas del sistema de GKE.

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

Desplegar cargas de trabajo de TPUs en GKE Standard Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Antes de empezar

Planificar la configuración de la TPU

Asegúrate de que tienes cuota de TPU

Cuota de máquinas virtuales bajo demanda o de acceso puntual

Cuotas de recursos adicionales de GKE

Asegurar la disponibilidad de las reservas

Opciones para aprovisionar TPUs en GKE

Crear un clúster

Crear un grupo de nodos

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

gcloud

Terraform

Consola

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

gcloud

Terraform

Consola

Cómo gestiona GKE los problemas de capacidad

Ejecutar tu carga de trabajo en nodos de segmento de TPU

Preparar las cargas de trabajo

Ejemplo 1: 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

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

Actualizar grupos de nodos con aceleradores (GPUs y TPUs)

Limpieza

Configurar ajustes adicionales

Gestionar la programación de colecciones

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

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

Usar Multislice

Migrar tu reserva de TPU

Activar el almacenamiento de registros

Usar el aprovisionamiento automático de nodos de GKE

Aprovisionar TPUs mediante clases de computación personalizadas

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

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

Ejecutar contenedores sin modo privilegiado

Observabilidad y métricas

Panel de control

Métricas de tiempo de ejecución

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

Estado del nodo

Estado del grupo de nodos

Disponibilidad del grupo de nodos

Número de interrupciones de nodos

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

Tiempo entre interrupciones (TBI) de los grupos de nodos

Métricas de host

Problemas conocidos

Siguientes pasos

Desplegar cargas de trabajo de TPUs en GKE Standard