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.
Na caixa Filtro
, faça o seguinte:Selecione a propriedade Serviço, insira API Compute Engine e pressione Enter.
Selecione a propriedade Tipo e escolha Cota.
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, insiraregion:us-west4
se planeja criar nós de fração da TPU na zonaus-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
ecloud.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
ecloud.google.com/gke-tpu-topology
emnodeSelector
. google.com/tpu
na solicitação.
- Os rótulos
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.