Resolva problemas de TPUs no GKE

Esta página mostra-lhe como resolver problemas relacionados com as TPUs no Google Kubernetes Engine (GKE).

Quota insuficiente para satisfazer o pedido de TPU

Um erro semelhante a Insufficient quota to satisfy the request indica que o seu Google Cloud projeto tem uma quota insuficiente disponível para satisfazer o pedido.

Para resolver este problema, verifique o limite de quota e a utilização atual do seu projeto. Se necessário, peça um aumento da sua quota de TPUs.

Verifique o limite de quota e a utilização atual

As secções seguintes ajudam a garantir que tem quota suficiente quando usa as UTPs no GKE.

Para verificar o limite e a utilização atual da sua quota da API Compute Engine para TPUs, siga estes passos:

  1. Aceda à página Quotas na Google Cloud consola:

    Aceder a Quotas

  2. Na caixa Filtro, faça o seguinte:

    1. Use a tabela seguinte para selecionar e copiar a propriedade da quota com base na versão da TPU e no . Por exemplo, se planeia criar nós de TPU v5e a pedido cujo nome comece por Name: TPU v5 Lite PodSlice chips, introduza Name: TPU v5 Lite PodSlice chips.

      Versão da TPU, Propriedade e nome da quota para instâncias a pedido Propriedade e nome da quota para instâncias do Spot2
      TPU v3,
      		 
      Dimensions (e.g. location):
      tpu_family:CT3
      		 Não aplicável
      TPU v3,
      		 
      Dimensions (e.g. location):
      tpu_family:CT3P
      		 Não aplicável
      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. Selecione a propriedade Dimensões (por exemplo, localizações) e introduza region: seguido do nome da região na qual planeia criar as TPUs no GKE. Por exemplo, introduza region:us-west4 se planear criar nós de fatia de TPU na zona us-west4-a. A quota de TPUs é regional, pelo que todas as zonas na mesma região consomem a mesma quota de TPUs.

Se nenhuma quota corresponder ao filtro que introduziu, significa que não foi concedida nenhuma das quotas especificadas ao projeto para a região de que precisa e tem de pedir um ajuste da quota de TPUs.

Quando é criada uma reserva de TPU, os valores do limite e da utilização atual da quota correspondente aumentam pelo número de chips na reserva de TPU. Por exemplo, quando é criada uma reserva para 16 chips de TPU v5e, o Limite e a Utilização atual da quota TPU v5 Lite PodSlice chips na região relevante aumentam em 16.

Quotas para recursos adicionais do GKE

Pode ter de aumentar as seguintes quotas relacionadas com o GKE nas regiões onde o GKE cria os seus recursos.

  • Quota de SSDs do Persistent Disk (GB): por predefinição, o disco de arranque de cada nó do Kubernetes requer 100 GB. Por conseguinte, esta quota deve ser definida, pelo menos, como tão elevada quanto o produto do número máximo de nós do GKE que prevê criar e 100 GB (nós * 100 GB).
  • Quota de endereços IP em utilização: cada nó do Kubernetes consome um endereço IP. Por conseguinte, esta quota deve ser definida, pelo menos, tão elevada quanto o número máximo de nós do GKE que prevê criar.
  • Certifique-se de que max-pods-per-node está alinhado com o intervalo de sub-redes: cada nó do Kubernetes usa intervalos de IP secundários para pods. Por exemplo, max-pods-per-node de 32 requer 64 endereços IP, o que se traduz numa sub-rede /26 por nó. Tenha em atenção que este intervalo não deve ser partilhado com nenhum outro cluster. Para evitar esgotar o intervalo de endereços IP, use a flag --max-pods-per-node para limitar o número de pods que podem ser agendados num nó. A quota para max-pods-per-node deve ser definida, pelo menos, tão elevada quanto o número máximo de nós do GKE que prevê criar.

Para pedir um aumento da quota, consulte o artigo Peça um ajuste da quota.

Recursos de TPU insuficientes para satisfazer o pedido de TPU

Um erro que contém GCE_STOCKOUT indica que os recursos da TPU estão temporariamente indisponíveis para satisfazer o pedido. O GKE cumpre o pedido de aprovisionamento quando os recursos de TPU ficam disponíveis.

Para resolver este problema, pode usar qualquer uma das seguintes opções de consumo:

Para escolher a opção de consumo que cumpre os requisitos da sua carga de trabalho, consulte o artigo Acerca das opções de consumo de aceleradores para cargas de trabalho de IA/ML no GKE.

Erro ao ativar a administração de contas automática de nós num conjunto de nós de uma fatia de TPU

O seguinte erro ocorre quando ativa o aprovisionamento automático de nós num cluster do GKE que não suporta TPUs.

A mensagem de erro é semelhante à seguinte:

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

Para resolver este problema, atualize o cluster do GKE para a versão 1.27.6 ou posterior.

O GKE não aprovisiona automaticamente nós de fatia de TPU

As secções seguintes descrevem os casos em que o GKE não aprovisiona automaticamente nós de fatia de TPU e como corrigi-los.

Evite erros de configuração de limites

Se os limites de aprovisionamento automático do cluster estiverem em falta ou forem demasiado baixos, o GKE não aprovisiona automaticamente nós de fatias de TPU. Pode observar os seguintes erros nestes cenários:

  • Quando o GKE tenta aprovisionar automaticamente um conjunto de nós de fatia de TPU que não tem limites definidos, os registos de visibilidade do dimensionamento automático do cluster apresentam a seguinte mensagem de erro:

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

  • Se existir um pool de nós de fatia de TPU, mas o GKE não conseguir aumentar a escala dos nós devido à violação dos limites de recursos, pode ver a seguinte mensagem de erro quando executar o 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

    Além disso, neste cenário, pode ver mensagens de aviso semelhantes às seguintes na Google Cloud consola:

    "Your cluster has one or more unschedulable Pods"

  • Quando o GKE tenta aprovisionar automaticamente um conjunto de nós de fatia de TPU que excede os limites de recursos, os registos de visibilidade do escalador automático do cluster apresentam a seguinte mensagem de erro:

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

    Além disso, neste cenário, pode ver mensagens de aviso semelhantes às seguintes na 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 resolver estes problemas, aumente o número máximo de chips de TPU, núcleos de CPU e memória no cluster.

Para concluir estes passos:

  1. Calcule os requisitos de recursos para um determinado tipo de máquina de TPU e quantidade. Tenha em atenção que tem de adicionar recursos para pools de nós de fatias de TPU, como cargas de trabalho do sistema.

  2. Obtenha uma descrição da TPU, da CPU e da memória disponíveis para um tipo de máquina e uma zona específicos. Use a CLI gcloud:

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

    Substitua o seguinte:

    A saída inclui uma linha de descrição semelhante à seguinte:

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

  3. Calcule o número total de CPU e memória multiplicando estes valores pelo número de nós necessário. Por exemplo, o tipo de máquina ct4p-hightpu-4t usa 240 núcleos de CPU e 407 GB de RAM com 4 chips de TPU. Partindo do princípio de que precisa de 20 chips de TPU, o que corresponde a cinco nós, tem de definir os seguintes valores:

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

    Deve definir os limites com alguma margem para acomodar nós de fatias não pertencentes à TPU, como cargas de trabalho do sistema.

  4. Atualize os limites do cluster:

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

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster.
    • TPU_ACCELERATOR: o nome do acelerador da TPU.
    • MAXIMUM_ACCELERATOR: o número máximo de chips de TPU no cluster.
    • MAXIMUM_CPU: o número máximo de núcleos no cluster.
    • MAXIMUM_MEMORY: o número máximo de gigabytes de memória no cluster.

Nem todas as instâncias estão em execução

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 erro pode aparecer quando a operação do GKE excede o tempo limite ou o pedido não pode ser cumprido e é colocado em fila para o aprovisionamento de pools de nós de TPU de anfitrião único ou vários anfitriões. Para mitigar problemas de capacidade, pode usar reservas ou considerar VMs do Spot.

Erro de configuração da carga de trabalho

Este erro ocorre devido à configuração incorreta da carga de trabalho. Seguem-se algumas das causas mais comuns do erro:

  • As etiquetas cloud.google.com/gke-tpu-accelerator e cloud.google.com/gke-tpu-topology estão incorretas ou em falta no PodSpec. O GKE não aprovisiona pools de nós de fatias de TPU e o aprovisionamento automático de nós não consegue aumentar a escala do cluster.
  • A especificação do agrupamento não especifica google.com/tpu nos respetivos requisitos de recursos.

Para resolver este problema, faça uma das seguintes ações:

  1. Verifique se não existem etiquetas não suportadas no seletor de nós da carga de trabalho. Por exemplo, um seletor de nós para a etiqueta cloud.google.com/gke-nodepool impede que o GKE crie pools de nós adicionais para os seus pods.
  2. Certifique-se de que as especificações do modelo de agrupamento, onde a sua carga de trabalho da TPU é executada, incluem os seguintes valores:
    • cloud.google.com/gke-tpu-accelerator e cloud.google.com/gke-tpu-topology etiquetas no respetivo nodeSelector.
    • google.com/tpu no seu pedido.

Para saber como implementar cargas de trabalho de TPU no GKE, consulte o artigo Execute uma carga de trabalho que apresente o número de chips de TPU disponíveis num conjunto de nós de fatia de TPU.

Erros de agendamento ao implementar pods que consomem TPUs no GKE

O seguinte problema ocorre quando o GKE não consegue agendar pods que pedem TPUs em nós de fatia de TPU. Por exemplo, isto pode ocorrer se algumas fatias não TPU já tiverem sido agendadas em nós TPU.

A mensagem de erro, emitida como um evento FailedScheduling no Pod, é semelhante à seguinte:

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 resolver este problema, faça o seguinte:

Verifique se tem, pelo menos, um conjunto de nós da CPU no cluster para que os pods críticos do sistema possam ser executados nos nós que não são da TPU. Para saber mais, consulte o artigo Implemente um pod num conjunto de nós específico.

Resolução de problemas comuns com JobSets no GKE

Para ver problemas comuns com o JobSet e sugestões de resolução de problemas, consulte a página de resolução de problemas do JobSet. Esta página aborda problemas comuns, como o erro "Webhook not available", a tarefa secundária ou os pods que não são criados, e a retoma do problema de cargas de trabalho antecipadas através do JobSet e do Kueue.

Falha na inicialização da TPU

O seguinte problema ocorre quando o GKE não consegue aprovisionar novas cargas de trabalho de TPU devido à falta de autorização para aceder a dispositivos de TPU.

A mensagem de erro é semelhante à seguinte:

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 resolver este problema, certifique-se de que executa o contentor de TPU no modo privilegiado ou aumenta o ulimit no contentor.

Impasse de agendamento

O agendamento de duas ou mais tarefas pode falhar devido a um impasse. Por exemplo, no cenário em que ocorrem todas as seguintes situações:

  • Tem dois trabalhos (Trabalho A e Trabalho B) com regras de afinidade de pods. O GKE agenda as fatias de TPU para tarefas com uma topologia de TPU de v4-32.
  • Tem 2 fatias de TPU v4-32 no cluster.
  • O cluster tem capacidade suficiente para agendar tarefas e, em teoria, cada tarefa pode ser agendada rapidamente em cada fatia da TPU.
  • O programador do Kubernetes agenda um pod da tarefa A numa fatia e, em seguida, agenda um pod da tarefa B na mesma fatia.

Neste caso, dadas as regras de afinidade de pods para a tarefa A, o programador tenta agendar todos os pods restantes para a tarefa A e para a tarefa B numa única fatia de TPU cada. Como resultado, o GKE não consegue agendar totalmente o Job A nem o Job B. Assim, o estado de ambas as tarefas permanece pendente.

Para resolver este problema, use a antafinidade de pods com cloud.google.com/gke-nodepool como topologyKey, conforme mostrado no exemplo seguinte:

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

Autorização recusada durante a criação do cluster em us-central2

Se estiver a tentar criar um cluster em us-central2 (a única região onde a TPU v4 está disponível), pode receber uma mensagem de erro semelhante à seguinte:

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

Este erro ocorre porque a região us-central2 é uma região privada.

Para resolver este problema, apresente um registo de apoio técnico ou contacte a sua equipa de conta para pedir que o us-central2 seja visível no seu projetoGoogle Cloud .

Quota insuficiente durante a criação do node pool da TPU em us-central2

Se estiver a tentar criar um node pool de fatia de TPU em us-central2 (a única região onde a TPU v4 está disponível), pode ter de aumentar as seguintes quotas relacionadas com o GKE quando criar node pools de TPU v4 pela primeira vez:

  • Quota de SSDs de discos persistentes (GB) em us-central2: o disco de arranque de cada nó do Kubernetes requer 100 GB por predefinição. Por conseguinte, esta quota deve ser definida, pelo menos, tão elevada quanto o produto do número máximo de nós do GKE que prevê criar em us-central2 e 100 GB (maximum_nodes X 100 GB).
  • Quota de endereços IP em utilização em us-central2: cada nó do Kubernetes consome um endereço IP. Por conseguinte, esta quota deve ser definida, pelo menos, tão elevada quanto o número máximo de nós do GKE que prevê criar em us-central2.

Sub-rede em falta durante a criação do cluster do GKE

Se estiver a tentar criar um cluster em us-central2 (a única região onde a TPU v4 está disponível), pode receber uma mensagem de erro semelhante à seguinte:

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

É necessária uma sub-rede na sua rede VPC para fornecer conetividade aos seus nós do GKE. No entanto, em determinadas regiões, como us-central2, pode não ser criada uma sub-rede predefinida, mesmo quando usa a rede VPC predefinida no modo automático (para a criação de sub-redes).

Para resolver este problema, certifique-se de que criou uma sub-rede personalizada na região antes de criar o cluster do GKE. Esta sub-rede não pode sobrepor-se a outras sub-redes criadas noutras regiões na mesma rede VPC.

Ative a porta kubelet só de leitura

Se usar uma versão do cluster do GKE anterior à 1.32, certifique-se de que o campo insecureKubeletReadonlyPortEnabled está definido como true.

Pode verificar o valor do campo insecureKubeletReadonlyPortEnabled descrevendo o seu conjunto de nós:

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

Se a saída incluir insecureKubeletReadonlyPortEnabled: false, ative a porta executando o seguinte comando:

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

Os seguintes erros de exemplo mencionam um erro de ligação TCP à porta 10255, o que indica que pode ter de ativar a porta.

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

Erro de ligação ao executar uma carga de trabalho de preparação com o JAX

Se estiver a tentar inicializar a framework JAX para executar uma carga de trabalho de preparação em máquinas TPU, pode encontrar uma mensagem de erro semelhante à seguinte:

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 erro ocorre quando o GKE não consegue estabelecer a topologia de rede de interconexões de alta velocidade entre chips (ICI) em grandes fatias de TPU.

Para mitigar este problema, conclua os seguintes passos:

  1. Identifique as fatias de TPU que têm o erro de conetividade. Para ver os registos de eventos, use a seguinte consulta:

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

    Substitua o seguinte:

    • PROJECT_ID: o ID do seu projeto.
    • TPU_ID: o ID da TPU que está a ter erros. Pode ver o ID da TPU na mensagem de erro.

  2. Contaminar o conjunto de nós ou um dos nós incluídos na mensagem de erro. Para saber mais, consulte o artigo Aplique um taint e etiquete um conjunto de nós para as suas cargas de trabalho

  3. Execute novamente a tarefa noutro conjunto de nós.

Se o problema persistir, apresente um registo de apoio técnico ou contacte a sua equipa de conta.

Veja os registos do GKE TPU

Para ver todos os registos relacionados com a TPU para uma carga de trabalho específica, o Cloud Logging oferece uma localização centralizada para consultar estes registos quando o registo de cargas de trabalho e do sistema do GKE está ativado. No Cloud Logging, os registos estão organizados em entradas de registo, e cada entrada de registo individual tem um formato estruturado. Segue-se um exemplo de uma entrada de registo de uma tarefa de preparação 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 registo dos nós de fatia da TPU tem a etiqueta compute.googleapis.com/resource_name com o valor definido como o nome do nó. Se quiser ver os registos de um nó específico e souber o nome do nó, pode filtrar os registos por esse nó na sua consulta. Por exemplo, a seguinte consulta mostra os registos do nó da TPU gke-tpu-9243ec28-wwf5:

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

O GKE anexa a etiqueta cloud.google.com/gke-tpu-accelerator e cloud.google.com/gke-tpu-topology a todos os nós que contêm TPUs. Assim, se não tiver a certeza acerca do nome do nó ou quiser listar todos os nós da fatia de TPU, pode executar o seguinte comando:

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

Exemplo de saída:

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

Pode fazer filtragem adicional com base nas etiquetas dos nós e nos respetivos valores. Por exemplo, o comando seguinte lista o nó de TPU com um tipo e uma topologia 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 os registos nos nós da fatia de TPU, pode usar a consulta que corresponde à etiqueta do sufixo do nó da fatia de TPU. Por exemplo, use a seguinte consulta:

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

Para ver os registos associados a uma carga de trabalho de TPU específica através de um trabalho do Kubernetes, pode filtrar os registos através da etiqueta batch.kubernetes.io/job-name. Por exemplo, para a tarefa mnist-training-job, pode executar a seguinte consulta para os registos STDOUT:

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

Para ver os registos de uma carga de trabalho de TPU através de um Kubernetes JobSet, pode filtrar os registos através da etiqueta k8s-pod/jobset_sigs_k8s_io/jobset-name. Por exemplo:

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

Para ver mais detalhes, pode filtrar com base nas outras etiquetas de carga de trabalho. Por exemplo, para ver os registos de uma carga de trabalho com várias divisões do trabalhador 0 e da divisão 1, pode filtrar com base nas etiquetas: job-complete-index e 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"

Também pode filtrar através do padrão do nome do pod:

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

Por exemplo, na consulta seguinte, jobSetName é multislice-job e replicateJobName é slice. Ambos os valores job-index e worker-index são 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"

Para outras cargas de trabalho de TPU, como uma única carga de trabalho de pod do GKE, pode filtrar os registos por nomes de pods. Por exemplo:

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

Se quiser verificar se o plug-in do dispositivo TPU está a ser executado corretamente, pode usar a seguinte consulta para verificar os respetivos registos do contentor:

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

Execute a seguinte consulta para verificar os eventos relacionados:

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

Para todas as consultas, pode adicionar filtros adicionais, como o nome do cluster, a localização e o ID do projeto. Também pode combinar condições para restringir os resultados. Por exemplo:

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")

O operador AND é opcional entre comparações e pode ser omitido. Para mais informações sobre a linguagem de consulta, pode ler a especificação da linguagem de consulta de registo. Também pode ler consultas de registo relacionadas com o Kubernetes para ver mais exemplos de consultas.

Se preferir usar SQL com o Log Analytics, pode encontrar exemplos de consultas em Consulta SQL com o Log Analytics. Em alternativa, também pode executar as consultas através da Google Cloud CLI em vez de no Explorador de registos. Por exemplo:

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

O que se segue?