Resolver problemas de TPUs no GKE

Padrão

Nesta página, mostramos como resolver problemas relacionados a TPUs no Google Kubernetes Engine (GKE).

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

Cota insuficiente para atender à solicitação de TPU

Um erro semelhante a Insufficient quota to satisfy the request indica que seu projeto do Google Cloud não tem cota suficiente para atender a solicitação.

Para resolver esse problema, verifique o limite da cota e o uso atual do seu projeto. Se necessário, solicite um aumento da sua cota de TPU.

Verificar o limite da cota e o uso atual

Para verificar o limite e o uso atual da sua cota da API Compute Engine para TPUs, siga estas etapas:

Acesse a página Cotas no console do Google Cloud.

Acessar "Cotas"
Na caixa Filtro , faça o seguinte:
1. Selecione a propriedade Serviço, insira API Compute Engine e pressione Enter.
2. Selecione a propriedade Tipo e escolha Cota.
3. Selecione a propriedade Dimensões (por exemplo, locais) e insira region: seguido do nome da região em que você planeja criar TPUs no GKE. Por exemplo, insira region:us-west4 se planeja criar nós de fração da TPU na zona us-west4-a. A cota de TPU é regional, portanto, todas as zonas na mesma região consomem a mesma cota de TPU.

Se nenhuma cota corresponder ao filtro inserido, isso significa que o projeto não recebeu nenhuma das cotas especificadas para a região desejada. Você precisará solicitar um aumento de cota de TPU.

Erro ao ativar o provisionamento automático de nós em um pool de nós de fração da TPU

O erro a seguir ocorre ao ativar o provisionamento automático de nós em um cluster do GKE que não dá suporte a TPUs.

A mensagem de erro é semelhante a esta:

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

Para resolver esse problema, faça upgrade do cluster do GKE para a versão 1.27.6 ou mais recente.

O GKE não provisiona os nós de fração da TPU de maneira automática

As seções a seguir descrevem os casos em que o GKE não provisiona os nós de fração da TPU de maneira automática e como corrigir esse problema.

Limitar configurações incorretas

O GKE não provisiona os nós de fração da TPU de maneira automática quando os limites de provisionamento automático definidos para um cluster são muito baixos. Nesses casos, é possível notar os seguintes erros:

Quando há um pool de nós de fração da TPU, mas o GKE não consegue escalonar os nós verticalmente devido à violação dos limites de recursos, a seguinte mensagem de erro é exibida ao 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, nesse cenário, é possível notar mensagens de aviso semelhantes às seguintes no console do Google Cloud:
```
"Your cluster has one or more unschedulable Pods"
```
Quando o GKE tenta provisionar automaticamente um pool de nós de fração da TPU que excede os limites de recursos, os registros de visibilidade do escalonador automático do cluster exibem a seguinte mensagem de erro:
```
messageId: "no.scale.up.nap.pod.zonal.resources.exceeded"
```
Além disso, nesse cenário, é possível notar mensagens de aviso semelhantes às seguintes no console do Google Cloud:
```
"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 esses problemas, aumente o número máximo de chips de TPU, núcleos de CPU e memória no cluster.

Para seguir essas etapas, faça o seguinte:

Calcule os requisitos de recursos para uma determinada contagem e um determinado tipo de máquina de TPU. Você precisa adicionar recursos para pools de nós de fração que não sejam de TPU, como cargas de trabalho do sistema.
Confira 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 gcloud CLI:
```
gcloud compute machine-types describe MACHINE_TYPE \
    --zone COMPUTE_ZONE
```
Substitua:
- MACHINE_TYPE: o tipo de máquina a ser pesquisado.
- COMPUTE_ZONE: o nome da zona do Compute.
A saída inclui uma linha de descrição semelhante à seguinte:
```
  description: 240 vCPUs, 407 GB RAM, 4 Google TPUs
  ```
```
Calcule o número total de CPU e memória multiplicando esses valores pelo número necessário de nós. 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. Supondo que você precise de 20 chips de TPU, que correspondem a cinco nós, defina os seguintes valores:
- --max-accelerator=type=tpu-v4-podslice,count=20.
- CPU = 1200 (240 x 5)
- memory = 2035 (407 x 5)
Defina os limites com alguma margem para acomodar nós de fração que não sejam de TPU, como cargas de trabalho do sistema.
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:
- CLUSTER_NAME: o nome do cluster.
- TPU_ACCELERATOR: o nome do acelerador de 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 atinge o tempo limite ou a solicitação não pode ser atendida e colocada na fila para provisionar pools de nós de TPU de host único ou de vários hosts. Para reduzir os problemas de capacidade, use reservas ou considere usar VMs spot.

Configuração incorreta de carga de trabalho

Esse erro ocorre devido à configuração incorreta da carga de trabalho. Confira a seguir algumas das causas mais comuns para esse erro:

Os rótulos cloud.google.com/gke-tpu-accelerator e cloud.google.com/gke-tpu-topology estão incorretos ou ausentes na especificação do pod. O GKE não vai provisionar pools de nós de fração da TPU, e o provisionamento automático de nós não vai escalonar verticalmente o cluster.
A especificação do pod não especifica google.com/tpu nos requisitos de recursos.

Para resolver esse problema, siga uma das seguintes recomendações:

Verifique se há algum rótulo sem suporte no seletor de nós de carga de trabalho. Por exemplo, um seletor de nós para o rótulo cloud.google.com/gke-nodepool vai impedir que o GKE crie pools de nós adicionais para os pods.
Verifique se as especificações do modelo de pod, em que a carga de trabalho da TPU é executada, incluem os seguintes valores:
- Os rótulos cloud.google.com/gke-tpu-accelerator e cloud.google.com/gke-tpu-topology em nodeSelector.
- google.com/tpu na solicitação.

Para saber como implantar cargas de trabalho de TPU no GKE, consulte Executar uma carga de trabalho que exibe o número de chips de TPU disponíveis em um pool de nós de fração da TPU.

Como programar erros ao implantar pods que consomem TPUs no GKE

O problema a seguir ocorre quando o GKE não consegue programar pods que solicitam TPUs em nós de fração de TPU. Por exemplo, isso pode ocorrer quando algumas frações que não são de TPU já estavam programadas em nós de TPU.

A mensagem de erro, emitida como um evento FailedScheduling no pod, é semelhante ao 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 esse problema, faça o seguinte:

Verifique se você tem pelo menos um pool de nós de CPU no cluster para que os pods críticos do sistema possam ser executados nos nós não TPU. Para saber mais, consulte Implantar um pod em um pool de nós específico.

Como solucionar problemas comuns com JobSets no GKE

Para problemas comuns com o JobSet e sugestões de solução de problemas, consulte a página de solução de problemas do JobSet. Nesta página, abordamos problemas comuns, como o erro "Webhook não disponível", job filho ou pods que não são criados, além de retomar o problema de cargas de trabalho preemptivas usando JobSet e Kueue.

Falha na inicialização da TPU

O problema a seguir ocorre quando o GKE não consegue provisionar novas cargas de trabalho de TPU devido à falta de permissão para acessar dispositivos de TPU.

A mensagem de erro é semelhante a esta:

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 esse problema, execute o contêiner da TPU no modo privilegiado ou aumente a ulimit dentro do contêiner.

Programando impasse

A programação de dois ou mais jobs pode falhar no impasse. Por exemplo, no cenário em que ocorre o seguinte:

Você tem dois jobs (Job A e Job B) com regras de afinidade de pod. O GKE programa as frações de TPU para os dois jobs com uma topologia de TPU de v4-32.
Você tem duas frações de TPU v4-32 no cluster.
O cluster tem ampla capacidade de programar jobs e, teoricamente, cada job pode ser programado rapidamente em cada fração de TPU.
O programador do Kubernetes programa um pod do job A em uma fração e, em seguida, programa um pod do job B na mesma fatia.

Nesse caso, dadas as regras de afinidade de pod para o job A, o programador tenta programar todos os pods restantes para o job A e para o job B em cada fatia da TPU. Como resultado, o GKE não conseguirá programar completamente os jobs A ou B. Portanto, o status de ambos os jobs permanecerá pendente.

Para resolver esse problema, use a antiafinidade de pods com cloud.google.com/gke-nodepool como topologyKey, conforme mostrado no exemplo a seguir:

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

Permissão negada durante a criação do cluster em us-central2

Ao tentar criar um cluster em us-central2 (a única região em que a TPU v4 está disponível), talvez você encontre uma mensagem de erro semelhante a esta:

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

Esse erro ocorre porque a região us-central2 é particular.

Para resolver esse problema, registre um caso de suporte ou entre em contato com sua equipe de conta para solicitar que us-central2 fique visível no projeto do Google Cloud.

Cota insuficiente durante a criação do pool de nós de TPU em us-central2

Se você estiver tentando criar um pool de nós de fração de TPU em us-central2 (a única região em que a TPU v4 está disponível), talvez seja necessário aumentar as seguintes cotas relacionadas ao GKE ao criar pools de nós TPU v4 pela primeira vez:

Cota SSD de disco permanente (GB) em us-central2: o disco de inicialização de cada nó do Kubernetes requer 100 GB por padrão. Portanto, essa cota precisa ser definida pelo menos até o produto do número máximo de nós do GKE que você espera criar em us-central2 e 100 GB (maximum_nodes X100 GB).
Cota de endereços IP em uso na us-central2: cada nó do Kubernetes consome um endereço IP. Portanto, essa cota precisa ser definida pelo menos tão alta quanto o número máximo de nós do GKE que você prevê que serão criados em us-central2.

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

Ao tentar criar um cluster em us-central2 (a única região em que a TPU v4 está disponível), talvez você encontre uma mensagem de erro semelhante a esta:

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

Uma sub-rede é necessária na rede VPC para fornecer conectividade com os nós do GKE. No entanto, em determinadas regiões, como us-central2, uma sub-rede padrão pode não ser criada, mesmo quando você usa a rede VPC padrão no modo automático (para criação de sub-redes).

Para resolver esse problema, verifique se você criou uma sub-rede personalizada na região antes de criar o cluster do GKE. Essa sub-rede não pode se sobrepor a outras criadas em regiões na mesma rede VPC.

A seguir

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.