Resolva problemas de TPUs no GKE

Quando executa cargas de trabalho de inferência ou preparação em grande escala no Google Kubernetes Engine (GKE), pode ter problemas com o aprovisionamento ou a utilização de unidades de processamento tensorial (TPUs). Os seus pods podem ficar bloqueados num estado Pending porque o GKE não consegue aprovisionar novos nós de fatias de TPU ou a sua carga de trabalho pode falhar devido a uma quota insuficiente, configurações de topologia incorretas ou configurações incorretas da carga de trabalho.

Use este documento para saber como verificar problemas de quota, confirmar se os pedidos de recursos e de nodeSelector da sua carga de trabalho estão corretos e encontrar registos para identificar a causa principal das falhas de agendamento ou inicialização.

Estas informações destinam-se aos administradores e operadores da plataforma que aprovisionam e gerem pools de nós com topologias de fatias de TPU específicas, e aos programadores de aplicações que estão a resolver problemas de cargas de trabalho de inferência ou de treino de TPU em grande escala. Para mais informações sobre as funções comuns e exemplos de tarefas que referimos no conteúdo, consulte o artigo Funções de utilizador e tarefas comuns do GKE. Google Cloud

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.

Quota para VMs a pedido ou do Spot

Se estiver a criar um conjunto de nós de fatias de TPU com VMs a pedido ou VMs Spot, tem de ter uma quota de TPU suficiente disponível na região que quer usar.

A criação de um node pool de fatias de TPU que consuma uma reserva de TPU não requer qualquer quota de TPU.1 Pode ignorar esta secção com segurança para TPUs reservadas.

A criação de um node pool de fatia de TPU a pedido ou Spot no GKE requer quota da API Compute Engine. A quota da API Compute Engine (compute.googleapis.com) não é igual à quota da API Cloud TPU (tpu.googleapis.com), que é necessária quando cria TPUs com a API Cloud TPU.

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 tipo de máquina. Por exemplo, se planear criar nós da TPU v5e a pedido cujo tipo de máquina comece por ct5lp-, introduza Name: TPU v5 Lite PodSlice chips.

      Versão da TPU, o tipo de máquina começa com Propriedade e nome da quota para instâncias a pedido Propriedade e nome da quota para instâncias do Spot2
      TPU v3,
      ct3- 
      Dimensions (e.g. location):
      tpu_family:CT3
      		 Não aplicável
      TPU v3,
      ct3p- 
      Dimensions (e.g. location):
      tpu_family:CT3P
      		 Não aplicável
      TPU v4,
      ct4p- 
      Name:
      TPU v4 PodSlice chips
      		 
      Name:
      Preemptible TPU v4 PodSlice chips
      TPU v5e,
      ct5lp- 
      Name:
      TPU v5 Lite PodSlice chips
      		 
      Name:
      Preemptible TPU v5 Lite Podslice
      chips
      TPU v5p,
      ct5p- 
      Name:
      TPU v5p chips
      		 
      Name:
      Preemptible TPU v5p chips
      TPU Trillium,
      ct6e- 
      Dimensions (e.g. location):
      tpu_family:CT6E
      		 
      Name:
      Preemptible TPU slices v6e
      Ironwood (TPU7x) (Pré-visualização),
      tpu7x-standard-4t 
      Dimensions (e.g. location):
      tpu_family:tpu7x
      		 
      Name:
      Preemptible TPU slices tpu7x

    2. Selecione a propriedade Dimensões (por exemplo, localizações) e introduza region: seguido do nome da região na qual planeia criar 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 TPU v5e cujo tipo de máquina começa por ct5lp-, o limite e a utilização atual da quota TPU v5 Lite PodSlice chips na região relevante aumentam em 16.

  1. Quando criar um node pool de fatia de TPU, use as flags --reservation e --reservation-affinity=specific para criar uma instância reservada. As reservas de TPUs estão disponíveis quando compra um compromisso. ↩

  2. Quando criar um node pool de fatia de TPU, use a flag --spot para criar uma instância Spot. ↩

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.

Como o GKE processa problemas de capacidade

Se o GKE não conseguir criar o seu conjunto de nós de fatia de TPU devido à capacidade de TPU insuficiente, o pedido pode falhar com um erro de rutura de stock ou o GKE pode colocar o pedido de aprovisionamento em fila até que a capacidade esteja disponível.

Se os recursos da TPU estiverem temporariamente indisponíveis, pode receber um erro com campos GCE_STOCKOUT ou ZONE_RESOURCE_POOL_EXHAUSTED. Para mais informações, consulte o artigo Recursos de TPU insuficientes para satisfazer o pedido de TPU.

Noutros casos, o GKE coloca o pedido em fila e é apresentada uma mensagem de erro a indicar que não é possível criar nós de fatia de TPU devido à falta de capacidade. O GKE cria os nós quando a capacidade fica disponível.

Se estiver a criar um node pool de fatia de TPU de anfitrião único, a mensagem de erro é semelhante à seguinte:

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

Se estiver a criar um node pool de fatia de TPU com vários anfitriões, a mensagem de erro é semelhante a esta:

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.

O seu pedido de aprovisionamento de UTPs pode permanecer na fila durante muito tempo e permanece no estado Provisioning enquanto estiver na fila.

Quando a capacidade está disponível, o GKE cria os nós que não foram criados.

Se precisar de capacidade mais cedo, considere experimentar as VMs do Spot, embora as VMs do Spot consumam uma quota diferente das instâncias a pedido.

Pode eliminar o pedido de TPU em fila eliminando o conjunto de nós da fatia de TPU.

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 não 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 pod, onde a 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 sem 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 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 no cluster.v4-32
  • 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 programa um pod da tarefa A numa fatia e, em seguida, programa 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. Por isso, 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 projeto.
    • TPU_ID: o ID da TPU que está a ter erros. Pode ver o ID da TPU na mensagem de erro.

  2. Contamine 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 uma etiqueta a 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 o TPU para uma carga de trabalho específica, o Cloud Logging oferece uma localização centralizada para consultar estes registos quando o registo do sistema e da carga de trabalho 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 TPUs.

{
  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 do nome do nó ou quiser listar todos os nós de 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 uma filtragem adicional com base nas etiquetas dos nós e nos respetivos valores. Por exemplo, o comando seguinte lista o nó da 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 ao 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 JobSet do Kubernetes, 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 analisar mais detalhadamente, 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?