Resolver problemas de TPUs no GKE

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

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 de cota e o uso atual da TPU, siga estas etapas.

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

    Acessar "Cotas"

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

    1. Selecione a propriedade Serviço, insira API Compute Engine e pressione Enter.

    2. Selecione a propriedade Cota e digite o nome da cota com base na versão da TPU e no tipo de máquina. Por exemplo, se você planeja criar nós da TPU v5e sob demanda com o tipo de máquina que começa com ct5lp-, digite TPU v5 Lite PodSlice chips.

      Versão da TPU O tipo de máquina começa com Nome da cota para instâncias sob demanda Nome da cota para instâncias de VMs spot1 Nome da cota para instâncias reservadas2
      TPU v4 ct4p- TPU v4 PodSlice chips Preemptible TPU v4 PodSlice chips Committed TPU v4 PodSlice chips
      TPU v5e ct5l- TPU v5 Lite Device chips Preemptible TPU v5 Lite Device chips Committed TPU v5 Lite Device chips
      TPU v5e ct5lp- TPU v5 Lite PodSlice chips Preemptible TPU v5 Lite PodSlice chips Committed TPU v5 Lite PodSlice chips

    3. Como opção, para aplicar filtros mais avançados e restringir os resultados, selecione a propriedade Dimensões (por exemplo, locais), adicione o nome da região em que você quer criar TPUs no GKE e pressione Enter. Por exemplo, insira region:us-west4 se planeja criar nós da TPU v5e na zona us-west4-a.

Se nenhuma cota corresponder ao filtro inserido, isso significa que o projeto não recebeu nenhuma das cotas especificadas e você precisará solicitar um aumento na cota de TPU.

  1. Ao criar um pool de nós de TPU, use a sinalização --spot para criar uma instância de VMs spot. ↩

  2. Ao criar um pool de nós de TPU, use a sinalização --reservation para criar uma instância reservada. As reservas de TPU estão disponíveis ao comprar um compromisso. ↩

Solicitar aumento da cota de TPU

Se você precisar de mais cota para criar nós de TPU no GKE, entre em contato com o representante da sua conta do Google Cloud para solicitar um aumento na sua cota de TPU. As TPUs provisionadas com o GKE usam uma cota alocada da API Compute Engine. A cota solicitada para a cota da API Cloud TPU não se aplica quando as TPUs no GKE são usadas.

Erro ao ativar o provisionamento automático de nós em um pool de nós 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 da TPU de maneira automática

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

Limitar configurações incorretas

O GKE não provisiona os nós 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 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 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:

  1. 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 que não sejam de TPU, como cargas de trabalho do sistema.

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

  3. 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 que não sejam de 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:

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

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

  1. 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.
  2. 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 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 TPU. Por exemplo, isso pode ocorrer quando alguns pods que não são de TPU já estavam programados 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.

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.

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.