Solucionar problemas de TPUs en GKE

En esta página se explica cómo resolver problemas relacionados con las TPUs en Google Kubernetes Engine (GKE).

Cuota insuficiente para satisfacer la solicitud de TPU

Un error similar a Insufficient quota to satisfy the request indica que tu proyectoGoogle Cloud no tiene suficiente cuota disponible para satisfacer la solicitud.

Para solucionar este problema, comprueba el límite de cuota de tu proyecto y el uso actual. Si es necesario, solicita un aumento de tu cuota de TPU.

Comprobar el límite de cuota y el uso actual

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

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

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

    Ir a Cuotas

  2. En el cuadro Filtrar, haz lo siguiente:

    1. Usa la siguiente tabla para seleccionar y copiar la propiedad de la cuota en función de la versión de TPU y . Por ejemplo, si tienes previsto crear nodos de TPU v5e bajo demanda cuyo valor sea , introduce Name: TPU v5 Lite PodSlice chips.

      Versión de TPU Propiedad y nombre de la cuota de instancias bajo demanda Propiedad y nombre de la cuota de instancias Spot2
      TPU v3
      		 
      Dimensions (e.g. location):
      tpu_family:CT3
      		 No aplicable
      TPU v3
      		 
      Dimensions (e.g. location):
      tpu_family:CT3P
      		 No aplicable
      TPU v4,
      		 
      Name:
      TPU v4 PodSlice chips
      		 
      Name:
      Preemptible TPU v4 PodSlice chips
      TPU v5e,
      		 
      Name:
      TPU v5 Lite PodSlice chips
      		 
      Name:
      Preemptible TPU v5 Lite Podslice
      chips
      TPU v5p
      		 
      Name:
      TPU v5p chips
      		 
      Name:
      Preemptible TPU v5p chips
      TPU Trillium
      		 
      Dimensions (e.g. location):
      tpu_family:CT6E
      		 
      Name:
      Preemptible TPU slices v6e

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

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

Cuando se crea una reserva de TPU, tanto el límite como los valores de uso actuales de la cuota correspondiente aumentan en el número de chips de la reserva de TPU. Por ejemplo, si se crea una reserva de 16 chips TPU v5e, tanto el límite como el uso actual de la cuota TPU v5 Lite PodSlice chips en la región correspondiente aumentan en 16.

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.

No hay suficientes recursos de TPU para satisfacer la solicitud de TPU

Un error que contiene GCE_STOCKOUT indica que los recursos de TPU no están disponibles temporalmente para satisfacer la solicitud. GKE completa la solicitud de aprovisionamiento cuando los recursos de TPU están disponibles.

Para solucionar este problema, puedes usar cualquiera de las siguientes opciones de consumo:

Para elegir la opción de consumo que se adapte a los requisitos de tu carga de trabajo, consulta Acerca de las opciones de consumo de aceleradores para cargas de trabajo de IA y aprendizaje automático en GKE.

Error al habilitar el aprovisionamiento automático de nodos en un grupo de nodos de segmento de TPU

Este error se produce al habilitar el aprovisionamiento automático de nodos en un clúster de GKE que no admite TPUs.

El mensaje de error es similar al siguiente:

ERROR: (gcloud.container.clusters.create) ResponseError: code=400,
  message=Invalid resource: tpu-v4-podslice.

Para resolver este problema, actualiza tu clúster de GKE a la versión 1.27.6 o a una posterior.

GKE no aprovisiona automáticamente nodos de slices de TPU

En las siguientes secciones se describen los casos en los que GKE no aprovisiona automáticamente nodos de slice de TPU y cómo solucionarlos.

Configuración errónea de los límites

Si faltan los límites de aprovisionamiento automático de tu clúster o son demasiado bajos, GKE no aprovisionará automáticamente nodos de slice de TPU. En estos casos, es posible que observes los siguientes errores:

  • Cuando GKE intenta aprovisionar automáticamente un grupo de nodos de segmento de TPU que no tiene límites definidos, los registros de visibilidad del escalador automático de clústeres muestran el siguiente mensaje de error:

    messageId: "no.scale.up.nap.pod.tpu.no.limit.defined"

  • Si existe un grupo de nodos de segmento de TPU, pero GKE no puede aumentar el número de nodos debido a que se superan los límites de recursos, puedes ver el siguiente mensaje de error al ejecutar el comando kubectl get events:

    11s Normal NotTriggerScaleUp pod/tpu-workload-65b69f6c95-ccxwz pod didn't
trigger scale-up: 1 node(s) didn't match Pod's node affinity/selector, 1 max
cluster cpu, memory limit reached

    Además, en este caso, puede ver mensajes de advertencia similares a los siguientes en la Google Cloud consola:

    "Your cluster has one or more unschedulable Pods"

  • Cuando GKE intenta aprovisionar automáticamente un grupo de nodos de segmento de TPU que supera los límites de recursos, los registros de visibilidad del escalador automático de clústeres mostrarán el siguiente mensaje de error:

    messageId: "no.scale.up.nap.pod.zonal.resources.exceeded"

    Además, en este caso, puede ver mensajes de advertencia similares a los siguientes en la Google Cloud consola:

    "Can't scale up because node auto-provisioning can't provision a node pool for
the Pod if it would exceed resource limits"

Para solucionar estos problemas, aumenta el número máximo de chips de TPU, núcleos de CPU y memoria del clúster.

Para completar estos pasos, haz lo siguiente:

  1. Calcula los requisitos de recursos de un tipo y un número de máquinas de TPU determinados. Ten en cuenta que debes añadir recursos para los grupos de nodos de las porciones que no sean de TPU, como las cargas de trabajo del sistema.

  2. Obtener una descripción de la TPU, la CPU y la memoria disponibles para un tipo de máquina y una zona específicos. Usa la CLI de gcloud:

    gcloud compute machine-types describe MACHINE_TYPE \
    --zone COMPUTE_ZONE

    Haz los cambios siguientes:

    • MACHINE_TYPE: el tipo de máquina que se va a buscar.
    • COMPUTE_ZONE: nombre de la zona de cálculo.

    La salida incluye una línea de descripción similar a la siguiente:

      description: 240 vCPUs, 407 GB RAM, 4 Google TPUs
  ```

  3. Para calcular el número total de CPUs y la cantidad de memoria, multiplica estos valores por el número de nodos que necesites. Por ejemplo, el tipo de máquina ct4p-hightpu-4t usa 240 núcleos de CPU y 407 GB de RAM con 4 chips de TPU. Si necesitas 20 chips de TPU, que corresponden a cinco nodos, debes definir los siguientes valores:

    • --max-accelerator=type=tpu-v4-podslice,count=20.
    • CPU = 1200 (240 veces 5)
    • memory = 2035 (407 veces 5)

    Debes definir los límites con cierto margen para dar cabida a los nodos de las porciones que no sean de TPU, como las cargas de trabajo del sistema.

  4. Actualiza los límites del clúster:

    gcloud container clusters update CLUSTER_NAME \
    --max-accelerator type=TPU_ACCELERATOR \
    count=MAXIMUM_ACCELERATOR \
    --max-cpu=MAXIMUM_CPU \
    --max-memory=MAXIMUM_MEMORY

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster.
    • TPU_ACCELERATOR: el nombre del acelerador de TPU.
    • MAXIMUM_ACCELERATOR: número máximo de chips de TPU del clúster.
    • MAXIMUM_CPU: número máximo de núcleos del clúster.
    • MAXIMUM_MEMORY: número máximo de gigabytes de memoria del clúster.

No se están ejecutando todas las instancias

ERROR: 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.

Este error puede aparecer cuando se agota el tiempo de espera de la operación de GKE o cuando no se puede completar la solicitud y se pone en cola para aprovisionar grupos de nodos de TPU de un solo host o de varios hosts. Para mitigar los problemas de capacidad, puedes usar reservas o plantearte usar máquinas virtuales de acceso puntual.

Configuración incorrecta de la carga de trabajo

Este error se produce debido a una configuración incorrecta de la carga de trabajo. A continuación, se indican algunas de las causas más habituales del error:

  • Las etiquetas cloud.google.com/gke-tpu-accelerator y cloud.google.com/gke-tpu-topology son incorrectas o faltan en PodSpec. GKE no aprovisionará grupos de nodos de segmento de TPU y el aprovisionamiento automático de nodos no podrá escalar el clúster.
  • Las especificaciones del pod no especifican google.com/tpu en sus requisitos de recursos.

Para solucionar este problema, haz una de las siguientes acciones:

  1. Comprueba que no haya etiquetas no admitidas en el selector de nodos de carga de trabajo. Por ejemplo, un selector de nodos para la etiqueta cloud.google.com/gke-nodepool impedirá que GKE cree grupos de nodos adicionales para tus pods.
  2. Asegúrate de que las especificaciones de la plantilla de Pod, donde se ejecuta tu carga de trabajo de TPU, incluyan los siguientes valores:
    • cloud.google.com/gke-tpu-accelerator y etiquetas de cloud.google.com/gke-tpu-topology en su nodeSelector.
    • google.com/tpu en su solicitud.

Para saber cómo desplegar cargas de trabajo de TPU en GKE, consulta el artículo Ejecutar una carga de trabajo que muestre el número de chips de TPU disponibles en un grupo de nodos de segmento de TPU.

Errores de programación al desplegar pods que consumen TPUs en GKE

El siguiente problema se produce cuando GKE no puede programar pods que solicitan TPUs en nodos de segmentos de TPU. Por ejemplo, esto puede ocurrir si ya se han programado algunas porciones que no son de TPU en nodos de TPU.

El mensaje de error, emitido como un evento FailedScheduling en el pod, es similar al siguiente:

Cannot schedule pods: Preemption is not helpful for scheduling.

Error message: 0/2 nodes are available: 2 node(s) had untolerated taint
{google.com/tpu: present}. preemption: 0/2 nodes are available: 2 Preemption is
not helpful for scheduling

Para solucionar este problema, sigue estos pasos:

Comprueba que tu clúster tenga al menos un grupo de nodos de CPU para que los pods críticos del sistema puedan ejecutarse en los nodos que no sean de TPU. Para obtener más información, consulta Desplegar un pod en un grupo de nodos específico.

Solucionar problemas habituales con JobSets en GKE

Para obtener información sobre los problemas habituales con JobSet y sugerencias para solucionarlos, consulta la página de solución de problemas de JobSet. En esta página se tratan problemas habituales, como el error "Webhook no disponible", los trabajos secundarios o los pods que no se crean, así como los problemas de reanudación de cargas de trabajo anticipadas mediante JobSet y Kueue.

No se ha podido inicializar la TPU

El siguiente problema se produce cuando GKE no puede aprovisionar nuevas cargas de trabajo de TPU debido a que no tiene permiso para acceder a los dispositivos de TPU.

El mensaje de error es similar al siguiente:

TPU platform initialization failed: FAILED_PRECONDITION: Couldn't mmap: Resource
temporarily unavailable.; Unable to create Node RegisterInterface for node 0,
config: device_path: "/dev/accel0" mode: KERNEL debug_data_directory: ""
dump_anomalies_only: true crash_in_debug_dump: false allow_core_dump: true;
could not create driver instance

Para solucionar este problema, asegúrese de ejecutar su contenedor de TPU en modo privilegiado o de aumentar el ulimit dentro del contenedor.

Bloqueo de programación

Es posible que se produzca un interbloqueo al programar dos o más tareas. Por ejemplo, en la situación en la que se dan las siguientes circunstancias:

  • Tienes dos trabajos (Trabajo A y Trabajo B) con reglas de afinidad de pods. GKE programa las porciones de TPU para ambos trabajos con una topología de TPU de v4-32.
  • Tienes dos segmentos de TPU v4-32 en el clúster.
  • Tu clúster tiene capacidad suficiente para programar ambos trabajos y, en teoría, cada trabajo se puede programar rápidamente en cada segmento de TPU.
  • El programador de Kubernetes programa un pod de la tarea A en una porción y, a continuación, programa un pod de la tarea B en la misma porción.

En este caso, dadas las reglas de afinidad de Pods del trabajo A, el programador intenta programar todos los Pods restantes del trabajo A y del trabajo B en una sola porción de TPU cada uno. Como resultado, GKE no podrá programar completamente la tarea A ni la tarea B. Por lo tanto, el estado de ambos trabajos seguirá siendo Pendiente.

Para solucionar este problema, usa antafinidades de pods con cloud.google.com/gke-nodepool como topologyKey, tal como se muestra en el siguiente ejemplo:

apiVersion: batch/v1
kind: Job
metadata:
 name: pi
spec:
 parallelism: 2
 template:
   metadata:
     labels:
       job: pi
   spec:
     affinity:
       podAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: job
               operator: In
               values:
               - pi
           topologyKey: cloud.google.com/gke-nodepool
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: job
               operator: NotIn
               values:
               - pi
           topologyKey: cloud.google.com/gke-nodepool
           namespaceSelector:
             matchExpressions:
             - key: kubernetes.io/metadata.name
               operator: NotIn
               values:
               - kube-system
     containers:
     - name: pi
       image: perl:5.34.0
       command: ["sleep",  "60"]
     restartPolicy: Never
 backoffLimit: 4

Permiso denegado durante la creación de un clúster en us-central2

Si intentas crear un clúster en us-central2 (la única región en la que está disponible la TPU v4), es posible que aparezca un mensaje de error similar al siguiente:

ERROR: (gcloud.container.clusters.create) ResponseError: code=403,
message=Permission denied on 'locations/us-central2' (or it may not exist).

Este error se produce porque la región us-central2 es privada.

Para solucionar este problema, envía un caso de asistencia o ponte en contacto con tu equipo de cuenta para solicitar que se muestre us-central2 en tu proyectoGoogle Cloud .

Cuota insuficiente durante la creación de un grupo de nodos de TPU en us-central2

Si intentas crear un grupo de nodos de un segmento de TPU en us-central2 (la única región en la que está disponible la TPU v4), es posible que tengas que aumentar las siguientes cuotas relacionadas con GKE la primera vez que crees grupos de nodos de TPU v4:

  • Cuota de Persistent Disk SSD (GB) en us-central2: 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 en us-central2 y 100 GB (maximum_nodes × 100 GB).
  • Cuota de direcciones IP en uso en us-central2: 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 en us-central2.

Falta una subred durante la creación del clúster de GKE

Si intentas crear un clúster en us-central2 (la única región en la que está disponible la TPU v4), es posible que aparezca un mensaje de error similar al siguiente:

ERROR: (gcloud.container.clusters.create) ResponseError: code=404,
message=Not found: project <PROJECT> does not have an auto-mode subnetwork
for network "default" in region <REGION>.

Se necesita una subred en tu red de VPC para proporcionar conectividad a tus nodos de GKE. Sin embargo, en algunas regiones, como us-central2, es posible que no se cree una subred predeterminada, aunque uses la red VPC predeterminada en modo automático (para la creación de subredes).

Para solucionar este problema, asegúrate de haber creado una subred personalizada en la región antes de crear el clúster de GKE. Esta subred no debe solaparse con otras subredes creadas en otras regiones de la misma red VPC.

Habilitar el puerto kubelet de solo lectura

Si usas una versión de clúster de GKE anterior a la 1.32, asegúrate de que el campo insecureKubeletReadonlyPortEnabled esté definido como true.

Para comprobar el valor del campo insecureKubeletReadonlyPortEnabled, describe tu grupo de nodos:

gcloud container node-pools describe NODEPOOL_NAME --cluster=CLUSTER_NAME

Si el resultado incluye insecureKubeletReadonlyPortEnabled: false, habilita el puerto ejecutando el siguiente comando:

gcloud container node-pools update NODEPOOL_NAME --cluster CLUSTER_NAME --enable-insecure-kubelet-readonly-port

En los siguientes ejemplos de errores se menciona un error de conexión TCP al puerto 10255, lo que indica que es posible que tengas que habilitar el puerto.

error sending request: Get "http://gke-tpu-d32e5ca6-f4gp:10255/pods": GET http://gke-tpu-d32e5ca6-f4gp:10255/pods giving up after 5 attempt(s): Get "http://gke-tpu-d32e5ca6-f4gp:10255/pods": dial tcp [2600:1901:8130:662:0:19c::]:10255: connect: connection refused

failed to get TPU container Info: failed to call kubelet: Get "http://gke-tpu-d32e5ca6-f4gp:10255/pods": GET http://gke-tpu-d32e5ca6-f4gp:10255/pods giving up after 5 attempt(s): Get "http://gke-tpu-d32e5ca6-f4gp:10255/pods": dial tcp [2600:1901:8130:662:0:19c::]:10255: connect: connection refused

Error de conexión al ejecutar una carga de trabajo de entrenamiento con JAX

Si intentas inicializar el framework JAX para ejecutar una carga de trabajo de entrenamiento en máquinas TPU, es posible que aparezca un mensaje de error similar al siguiente:

E0115 19:06:10.727412 340 master.cc:246] Initialization of slice failed with
error status: INVALID_ARGUMENT: When linking node TPU_ID:pe0:0
to TPU_ID:pe0:3</code> with link TPU_ID:pe0:0:p5:x couldn't find opposite link in destination node.; Failed to create the mesh (xW, xW, xW); Please make sure the topology is correct.;
Failed to discover ICI network topology

Este error se produce cuando GKE no puede establecer la topología de red de interconexiones entre chips (ICI) de alta velocidad en grandes porciones de TPU.

Para mitigar este problema, sigue estos pasos:

  1. Identifica los slices de TPU que tienen el error de conectividad. Para ver los registros de eventos, usa la siguiente consulta:

    resource.type="k8s_container"
resource.labels.project_id=PROJECT_ID
severity>=DEFAULT
SEARCH("`[/dev/vfio/0` `TPU_ID` Driver `opened.`")

    Haz los cambios siguientes:

    • PROJECT_ID: tu ID de proyecto.
    • TPU_ID: ID de la TPU que tiene errores. Puedes ver el ID de la TPU en el mensaje de error.

  2. Taint el grupo de nodos o uno de los nodos incluidos en el mensaje de error. Para obtener más información, consulta Etiquetar y contaminar un grupo de nodos para tus cargas de trabajo.

  3. Vuelve a ejecutar el trabajo en otro grupo de nodos.

Si el problema persiste, presenta un caso de asistencia o ponte en contacto con tu equipo de cuenta.

Ver los registros de TPU de GKE

Para ver todos los registros relacionados con las TPUs de una carga de trabajo específica, Cloud Logging ofrece una ubicación centralizada para consultar estos registros cuando se habilitan los registros del sistema y de las cargas de trabajo de GKE. En Cloud Logging, los registros se organizan en entradas de registro y cada entrada de registro tiene un formato estructurado. A continuación, se muestra un ejemplo de una entrada de registro de una tarea de entrenamiento de TPU.

{
  insertId: "gvqk7r5qc5hvogif"
  labels: {
  compute.googleapis.com/resource_name: "gke-tpu-9243ec28-wwf5"
  k8s-pod/batch_kubernetes_io/controller-uid: "443a3128-64f3-4f48-a4d3-69199f82b090"
  k8s-pod/batch_kubernetes_io/job-name: "mnist-training-job"
  k8s-pod/controller-uid: "443a3128-64f3-4f48-a4d3-69199f82b090"
  k8s-pod/job-name: "mnist-training-job"
}
logName: "projects/gke-tpu-demo-project/logs/stdout"
receiveTimestamp: "2024-06-26T05:52:39.652122589Z"
resource: {
  labels: {
    cluster_name: "tpu-test"
    container_name: "tensorflow"
    location: "us-central2-b"
    namespace_name: "default"
    pod_name: "mnist-training-job-l74l8"
    project_id: "gke-tpu-demo-project"
}
  type: "k8s_container"
}
severity: "INFO"
textPayload: "
  1/938 [..............................] - ETA: 13:36 - loss: 2.3238 - accuracy: 0.0469
  6/938 [..............................] - ETA: 9s - loss: 2.1227 - accuracy: 0.2995
 13/938 [..............................] - ETA: 8s - loss: 1.7952 - accuracy: 0.4760
 20/938 [..............................] - ETA: 7s - loss: 1.5536 - accuracy: 0.5539
 27/938 [..............................] - ETA: 7s - loss: 1.3590 - accuracy: 0.6071
 36/938 [>.............................] - ETA: 6s - loss: 1.1622 - accuracy: 0.6606
 44/938 [>.............................] - ETA: 6s - loss: 1.0395 - accuracy: 0.6935
 51/938 [>.............................] - ETA: 6s - loss: 0.9590 - accuracy: 0.7160
……
937/938 [============================>.] - ETA: 0s - loss: 0.2184 - accuracy: 0.9349"
timestamp: "2024-06-26T05:52:38.962950115Z"
}

Cada entrada de registro de los nodos de la porción de TPU tiene la etiqueta compute.googleapis.com/resource_name con el valor definido como el nombre del nodo. Si quieres ver los registros de un nodo concreto y sabes su nombre, puedes filtrar los registros por ese nodo en tu consulta. Por ejemplo, la siguiente consulta muestra los registros del nodo de TPU gke-tpu-9243ec28-wwf5:

resource.type="k8s_container"
labels."compute.googleapis.com/resource_name" = "gke-tpu-9243ec28-wwf5"

GKE asigna las etiquetas cloud.google.com/gke-tpu-accelerator y cloud.google.com/gke-tpu-topology a todos los nodos que contienen TPUs. Por lo tanto, si no estás seguro del nombre del nodo o quieres enumerar todos los nodos de la porción de TPU, puedes ejecutar el siguiente comando:

kubectl get nodes -l cloud.google.com/gke-tpu-accelerator

Ejemplo de salida:

NAME                    STATUS   ROLES    AGE     VERSION
gke-tpu-9243ec28-f2f1   Ready    <none>   25m     v1.30.1-gke.1156000
gke-tpu-9243ec28-wwf5   Ready    <none>   7d22h   v1.30.1-gke.1156000

Puede aplicar filtros adicionales en función de las etiquetas de los nodos y sus valores. Por ejemplo, el siguiente comando muestra el nodo de TPU con un tipo y una topología específicos:

kubectl get nodes -l cloud.google.com/gke-tpu-accelerator=tpu-v5-lite-podslice,cloud.google.com/gke-tpu-topology=1x1

Para ver todos los registros de los nodos de la porción de TPU, puedes usar la consulta que coincida con la etiqueta del sufijo del nodo de la porción de TPU. Por ejemplo, usa la siguiente consulta:

resource.type="k8s_container"
labels."compute.googleapis.com/resource_name" =~ "gke-tpu-9243ec28.*"
log_id("stdout")

Para ver los registros asociados a una carga de trabajo de TPU concreta mediante un trabajo de Kubernetes, puedes filtrar los registros con la etiqueta batch.kubernetes.io/job-name. Por ejemplo, para el trabajo mnist-training-job, puedes ejecutar la siguiente consulta para los registros STDOUT:

resource.type="k8s_container"
labels."k8s-pod/batch_kubernetes_io/job-name" = "mnist-training-job"
log_id("stdout")

Para ver los registros de una carga de trabajo de TPU mediante un JobSet de Kubernetes, puedes filtrar los registros con la etiqueta k8s-pod/jobset_sigs_k8s_io/jobset-name. Por ejemplo:

resource.type="k8s_container"
labels."k8s-pod/jobset_sigs_k8s_io/jobset-name"="multislice-job"

Para obtener información más detallada, puede filtrar por las otras etiquetas de carga de trabajo. Por ejemplo, para ver los registros de una carga de trabajo de varios segmentos del trabajador 0 y del segmento 1, puede filtrar por las etiquetas job-complete-index y job-index:

​​resource.type="k8s_container"
labels."k8s-pod/jobset_sigs_k8s_io/jobset-name"="multislice-job"
labels."k8s-pod/batch_kubernetes_io/job-completion-index"="0"
labels."k8s-pod/jobset_sigs_k8s_io/job-index"="1"

También puedes filtrar por el patrón de nombre del pod:

resource.labels.pod_name:<jobSetName>-<replicateJobName>-<job-index>-<worker-index>

Por ejemplo, en la siguiente consulta, jobSetName es "multislice-job" y replicateJobName es "slice". Tanto job-index como worker-index son 0:

resource.type="k8s_container"
labels."k8s-pod/jobset_sigs_k8s_io/jobset-name"="multislice-job"
resource.labels.pod_name:"multislice-job-slice-0-0"

En otras cargas de trabajo de TPU, como una carga de trabajo de un solo pod de GKE, puedes filtrar los registros por nombres de pods. Por ejemplo:

resource.type="k8s_container"
resource.labels.pod_name="tpu-job-jax-demo"

Si quieres comprobar si el complemento del dispositivo TPU se está ejecutando correctamente, puedes usar la siguiente consulta para comprobar los registros de su contenedor:

resource.type="k8s_container"
labels.k8s-pod/k8s-app="tpu-device-plugin"
resource.labels.namespace_name="kube-system"

Ejecuta la siguiente consulta para comprobar los eventos relacionados:

jsonPayload.involvedObject.name=~"tpu-device-plugin.*"
log_id("events")

En todas las consultas, puede añadir filtros adicionales, como el nombre del clúster, la ubicación y el ID del proyecto. También puedes combinar condiciones para acotar los resultados. Por ejemplo:

resource.type="k8s_container" AND
resource.labels.project_id="gke-tpu-demo-project" AND
resource.labels.location="us-west1" AND
resource.labels.cluster_name="tpu-demo" AND
resource.labels.namespace_name="default" AND
labels."compute.googleapis.com/resource_name" =~ "gke-tpu-9243ec28.*" AND
labels."k8s-pod/batch_kubernetes_io/job-name" = "mnist-training-job" AND
log_id("stdout")

El operador AND es opcional entre comparaciones y se puede omitir. Para obtener más información sobre el lenguaje de consulta, consulta la especificación del lenguaje de consulta de Logging. También puedes consultar consultas de registro relacionadas con Kubernetes para ver más ejemplos de consultas.

Si prefieres usar SQL con Analíticas de registros, puedes consultar ejemplos de consultas en Consulta de SQL con Analíticas de registros. También puedes ejecutar las consultas con Google Cloud CLI en lugar de con el Explorador de registros. Por ejemplo:

gcloud logging read 'resource.type="k8s_container" labels."compute.googleapis.com/resource_name" =~ "gke-tpu-9243ec28.*" log_id("stdout")' --limit 10 --format json

Siguientes pasos