Solucionar problemas de GPUs no GKE

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

Instalação do driver de GPU

Esta seção fornece informações de solução de problemas para instalação automática de driver de dispositivo NVIDIA no GKE.

A instalação do driver falha em nós do Ubuntu

Se você usar nós do Ubuntu com GPUs L4, H100 ou H200 anexadas, o driver de GPU padrão instalado pelo GKE pode não ser a versão necessária para essas GPUs. Como resultado, o pod do plug-in do dispositivo de GPU permanece travado no estado "Pendente", e as cargas de trabalho da GPU nesses nós podem apresentar problemas.

Para resolver esse problema em GPUs L4 e H100, recomendamos fazer upgrade para as seguintes versões do GKE, que instalam a versão 535 do driver da GPU como padrão:

  • 1.26.15-gke.1483000 e mais recente
  • 1.27.15-gke.1039000 e mais recente
  • 1.28.11-gke.1044000 e mais recente
  • 1.29.6-gke.1073000 e mais recente
  • 1.30.2-gke.1124000 e mais recente

Como alternativa, instale manualmente a versão 535 ou mais recente do driver executando o seguinte comando:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R535.yaml

Para resolver esse problema em GPUs H200, instale manualmente a versão 550 ou mais recente do driver executando o seguinte comando:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R550.yaml

Os plug-ins de dispositivos de GPU falham com erros CrashLoopBackOff

O problema a seguir ocorre se você usou o método de instalação manual do driver no pool de nós antes de 25 de janeiro de 2023 e depois fez upgrade do pool de nós para uma versão do GKE compatível com instalação automática de driver. Ambas as cargas de trabalho de instalação existem ao mesmo tempo e tentam instalar versões de driver conflitantes nos seus nós.

O contêiner de inicialização do plug-in do dispositivo GPU falha com o status Init:CrashLoopBackOff. Os logs do contêiner são semelhantes aos seguintes:

failed to verify installation: failed to verify GPU driver installation: exit status 18

Para resolver esse problema, tente o seguinte:

  • Remova o DaemonSet de instalação manual do driver do seu cluster. Isso exclui a carga de trabalho de instalação conflitante e permite que o GKE instale automaticamente um driver nos seus nós.

    kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml

  • Aplique novamente o manifesto DaemonSet de instalação manual do driver ao seu cluster. Em 25 de janeiro de 2023, atualizamos o manifesto para ignorar nós que usam instalação automática de driver.

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml

  • Desative a instalação automática do driver para seu pool de nós. O DaemonSet de instalação do driver existente deve funcionar conforme o esperado após a conclusão da operação de atualização.

    gcloud container node-pools update POOL_NAME \
    --accelerator=type=GPU_TYPE,count=GPU_COUNT,gpu-driver-version=disabled \
    --cluster=CLUSTER_NAME \
    --location=LOCATION

    Substitua:

    • POOL_NAME: o nome do pool de nós.
    • GPU_TYPE: o tipo de GPU que o pool de nós já usa.
    • GPU_COUNT: o número de GPUs que já estão anexadas ao pool de nós.
    • CLUSTER_NAME: o nome do cluster do GKE que contém o pool de nós.
    • LOCATION: o local do Compute Engine do cluster.

Erro: "A imagem do contêiner cos-nvidia-installer:fixed não está presente com a política de extração de "Never"." ou "A imagem do contêiner ubuntu-nvidia-installer:fixed não está presente com a política de extração de "Never"."

Esse problema ocorre quando os pods nvidia-driver-installer estão no estado PodInitializing e o dispositivo do plug-in da GPU ou os pods do instalador do driver da GPU informam o seguinte erro. A mensagem de erro específica depende do sistema operacional executado no seu nó:

COS

Container image "cos-nvidia-installer:fixed" is not present with pull policy of Never.

Ubuntu

Container image "gke-nvidia-installer:fixed" is not present with pull policy of Never.

Esse problema pode ocorrer quando o coletor de lixo remove a imagem do driver NVIDIA pré-carregada para liberar espaço em um nó. Quando o pod do driver é recriado ou o contêiner é reiniciado, o GKE não consegue localizar a imagem pré-carregada.

Para atenuar o problema de coleta de lixo ao executar o COS, faça upgrade dos nós do GKE para uma destas versões que contêm a correção:

  • 1.25.15-gke.1040000 e mais recente
  • 1.26.10-gke.1030000 e mais recente
  • 1.27.6-gke.1513000 e mais recente
  • 1.28.3-gke.1061000 e mais recente

Se os nós estiverem executando o Ubuntu, ainda não há uma correção disponível para esse problema de coleta de lixo. Para atenuar esse problema no Ubuntu, é possível executar um contêiner privilegiado que interage com o host para garantir a configuração correta dos drivers da GPU NVIDIA. Para fazer isso, execute sudo /usr/local/bin/nvidia-container-first-boot no seu nó ou aplique o seguinte manifesto:

apiVersion: v1
kind: Pod
metadata:
  name: gke-nvidia-installer-fixup
spec:
  nodeSelector:
    cloud.google.com/gke-os-distribution: ubuntu
  hostPID: true
  containers:
  - name: installer
    image: ubuntu
    securityContext:
      privileged: true
    command:
      - nsenter
      - -at
      - '1'
      - --
      - sh
      - -c
      - "/usr/local/bin/nvidia-container-first-boot"
  restartPolicy: Never

Outra possível causa do problema é quando as imagens do driver da NVIDIA são perdidas após a reinicialização do nó ou a manutenção do host. Isso pode ocorrer em nós confidenciais ou com GPUs que usam armazenamento SSD local temporário. Nessa situação, o GKE carrega previamente as imagens do contêiner nvidia-installer-driver nos nós e as move do disco de inicialização para o SSD local na primeira inicialização.

Para confirmar se houve um evento de manutenção do host, use o seguinte filtro de registro:

resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
log_id("cloudaudit.googleapis.com/system_event")

Para atenuar o problema de manutenção do host, faça upgrade da versão do GKE para uma destas versões:

  • 1.27.13-gke.1166000 e mais recente
  • 1.29.3-gke.1227000 e mais recente
  • 1.28.8-gke.1171000 e mais recente

Erro: falha ao configurar os diretórios de instalação do driver da GPU: falha ao criar a sobreposição lib64: falha ao criar o diretório /usr/local/nvidia/lib64: mkdir /usr/local/nvidia/lib64: não é um diretório.

Você encontra este erro no contêiner do instalador do driver da GPU dentro do plug-in do dispositivo GPU quando o fastsocket do NCCL está ativado:

failed to configure GPU driver installation dirs: failed to create lib64 overlay: failed to create dir /usr/local/nvidia/lib64: mkdir /usr/local/nvidia/lib64: not a directory.

Esse problema só acontece em clusters e nós que executam o GKE 1.28 e 1.29.

O problema é causado por uma condição de corrida de fastsocket do NCCL com o instalador do driver da GPU.

Para atenuar esse problema, faça upgrade da versão do GKE para uma destas versões:

  • 1.28.8-gke.1206000 e mais recente
  • 1.29.3-gke.1344000 e mais recente

Para mais informações, leia as notas da versão do GPUDirect-TCPXO.

Erro: falha ao receber o dispositivo nvidia0: dispositivo nvidia0 não encontrado.

O erro a seguir indica que o XID 62 e o RmInitAdapter falharam para a GPU com o número secundário 0:

Failed to get device for nvidia0: device nvidia0 not found.

O driver NVIDIA versão 525.105.17 tem um bug que pode causar erros de comunicação (XID) e impedir que a GPU seja inicializada corretamente, levando a uma falha na inicialização da GPU.

Para corrigir esse problema, atualize o driver NVIDIA para a versão 525.110.11 ou mais recente.

Redefinir GPUs em VMs A3

Alguns problemas podem exigir a redefinição da GPU em uma VM A3.

Para redefinir a GPU, siga estas etapas:

  1. Remova do nó os pods que solicitam recursos de GPU, onde você precisa redefinir a GPU.

  2. Desative o plug-in do dispositivo GPU no nó:

    kubectl get nodes \
    --selector=kubernetes.io/hostname=NODE_NAME \
    --no-headers | awk '{print $1}' \
    | xargs -I{} kubectl label node {} gke-no-default-nvidia-gpu-device-plugin=true

    Substitua NODE_NAME pelo nome do nó.

  3. Conecte-se à VM que faz backup do nó.

  4. Na sessão SSH, redefina a GPU:

    /home/kubernetes/bin/nvidia/bin/nvidia-smi --gpu-reset

  5. Reative o plug-in do dispositivo GPU:

    kubectl get nodes --selector=kubernetes.io/hostname=NODE_NAME \
    --no-headers \| awk '{print $1}' \
    | xargs -I{} kubectl label node {} gke-no-default-nvidia-gpu-device-plugin=false \
    --overwrite

GPUs em nós confidenciais do GKE

As seções a seguir mostram como identificar e corrigir problemas com GPUs que são executadas em nós confidenciais do GKE.

Cargas de trabalho de GPU não sendo programadas em nós confidenciais do GKE

Os nós confidenciais do GKE exigem que você instale manualmente um driver de GPU que corresponda ao tipo de GPU selecionado e à versão do GKE. Se os pods de GPU não estiverem sendo programados em nós confidenciais do GKE e permanecerem no estado Pending, descreva o DaemonSet de instalação do driver:

kubectl --namespace=kube-system get daemonset nvidia-driver-installer -o yaml

Se a saída retornar um erro NotFound, instale o driver.

Se o DaemonSet estiver em execução, a saída será semelhante a esta:

apiVersion: apps/v1
kind: DaemonSet
# lines omitted for clarity
spec:
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: nvidia-driver-installer
  template:
    metadata:
      creationTimestamp: null
      labels:
        k8s-app: nvidia-driver-installer
        name: nvidia-driver-installer
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/gke-accelerator
                operator: Exists
              - key: cloud.google.com/gke-gpu-driver-version
                operator: DoesNotExist
              - key: cloud.google.com/gke-confidential-nodes-instance-type
                operator: In
                values:
                - TDX

Nessa saída, verifique se o campo nodeAffinity contém a chave cloud.google.com/gke-confidential-nodes-instance-type. Se a saída não contiver essa chave, o DaemonSet de instalação do driver não vai oferecer suporte a nós confidenciais do GKE.

Implante o DaemonSet que oferece suporte a GPUs nos Confidential GKE Nodes:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/cos/daemonset-confidential.yaml

Depois de instalar os drivers, verifique se as cargas de trabalho da GPU são iniciadas com sucesso.

Erro: falha ao alocar o vetor do dispositivo

A seguinte mensagem de erro nos registros do contêiner da GPU indica que ela foi separada da instância de VM do nó:

Failed to allocate device vector A (error code unknown error)!

Isso pode acontecer devido a um erro de hardware ou a um problema com as chaves de criptografia.

Para resolver esse problema, reinicie a instância do nó. Essa operação é destrutiva e afeta todas as cargas de trabalho no nó. Para reiniciar a instância, siga estas etapas:

  1. Consiga o nome do nó que executa o pod da GPU:

    kubectl get pod POD_NAME -o yaml | grep "nodeName"

    Substitua POD_NAME pelo nome do pod com falha.

    O resultado será assim:

    nodeName: gke-cluster-1-default-pool-b7asdfbt-fd3e

  2. Redefina a instância do Compute Engine:

    gcloud compute instances reset NODE_NAME

    Substitua NODE_NAME pelo nome do nó da saída da etapa anterior.

    A CLI gcloud procura VMs com esse nome no seu projeto ativo. Se aparecer uma solicitação para selecionar uma zona, especifique Y.

  3. Verifique se as cargas de trabalho da GPU são executadas sem erros.

Erro: falha na descriptografia com o erro -74

A seguinte mensagem de erro nos registros do nó indica que as chaves de criptografia da GPU foram perdidas:

Decryption failed with error -74

Esse erro ocorre quando o daemon de persistência da NVIDIA, que é executado na instância de VM do nó, falha. Se você receber essa mensagem de erro, redefina a instância:

gcloud compute instances reset NODE_NAME

Substitua NODE_NAME pelo nome do nó com falha.

A CLI gcloud procura VMs com esse nome no seu projeto ativo. Se aparecer uma solicitação para selecionar uma zona, especifique Y.

Se a redefinição da instância não resolver o problema, entre em contato com o Cloud Customer Care ou envie um bug do produto. Para mais informações, consulte Receber suporte.

Encontrar erros de XID

O daemonset gpu-device-plugin é executado no namespace kube-system e é responsável pelo seguinte:

  • Programação de carga de trabalho de GPU:alocação de recursos de GPU para pods.
  • Verificação de integridade da GPU:monitoramento da integridade das GPUs.
  • Coleta de métricas da GPU:coleta de métricas relacionadas à GPU, como ciclo de trabalho e uso da memória.

O gpu-device-plugin usa a NVIDIA Management Library (NVML) para detectar erros XID. Quando um erro de XID ocorre, o pod gpu-device-plugin em execução no nó afetado registra o erro. Você vai encontrar dois tipos de registros de erros de XID:

  • Erros de XID não críticos:
    • Formato do registro: Skip error Xid=%d as it is not Xid Critical
    • Significado: esses erros são considerados não críticos. Eles podem ser causados por vários problemas de software ou hardware.
    • Ação: o GKE não realiza nenhuma ação automatizada para erros XID não críticos.
  • Erros críticos de XID:
    • Formato do registro: XidCriticalError: Xid=%d, All devices will go unhealthy
    • Significado: esses erros indicam um problema de hardware da GPU.
    • Ação:
      • O GKE marca os recursos de GPU do nó como não íntegros.
      • O GKE impede que cargas de trabalho de GPU sejam programadas no nó.
      • Se o reparo automático de nós estiver ativado, o GKE vai recriar o nó.

Problemas com o GPUDirect-TCPX(O)

Esta seção fornece informações de solução de problemas para problemas do GPUDirect-TCPX(O).

Notas da versão e instruções de upgrade

Para novos usuários, Maximizar a largura de banda da rede GPU em clusters do modo padrão oferece orientações sobre como usar o GPUDirect-TCPX(O). Para usuários atuais, leia as Notas de lançamento do GPUDirect-TCPXO para informações de lançamento e instruções de upgrade, já que novas versões são lançadas continuamente.

Depurar com registros do NCCL

Se não for possível resolver um problema com o NCCL, colete os registros dele com informações de depuração. Esses registros contêm informações valiosas sobre operações do NCCL e podem ajudar você a encontrar a origem do problema. Se não for possível resolver o problema, colete esses registros antes de abrir um caso com o Cloud Customer Care. Esses registros podem ajudar Cloud Customer Care a resolver seu problema com mais rapidez.

Para gerar e coletar os registros, siga estas etapas:

  1. Defina as seguintes variáveis de ambiente no manifesto do pod ou do aplicativo:

    NCCL_DEBUG=INFO
NCCL_DEBUG_SUBSYS=INIT,NET,ENV,COLL,GRAPH
NCCL_DEBUG_FILE=/DIRECTORY/FILE_NAME.%h.%p

    Para mais informações sobre essas variáveis de ambiente, leia Coletar registros de depuração do NCCL.

  2. Para gerar dados para seus registros, execute um teste do NCCL. A maneira de executar esse teste depende do tipo de cluster que você usa. Para clusters do GKE, é possível implantar e executar o teste do NCCL com o agendamento com reconhecimento de topologia (TAS). Depois de executar o teste do NCCL, ele gera automaticamente os registros em todos os nós participantes.

  3. Colete os registros de todos os nós. Verifique se você coletou registros do NCCL de todos os nós. Para isso, confira se os registros contêm as seguintes informações:

    • Os nomes de host de todas as VMs envolvidas em uma carga de trabalho.
    • Os PIDs de todos os processos relevantes na VM.
    • As classificações de todas as GPUs usadas pela carga de trabalho em cada VM.

    Se você não souber onde os arquivos de registro estão localizados, o exemplo a seguir mostra onde o NCCL cria os arquivos de registro quando a variável NCCL_DEBUG_FILE é definida como /tmp/nccl_log.%h.%p. Você tem duas VMs chamadas a3plus-vm-1 e a3plus-vm-2, e cada uma executa oito processos no contêiner de carga de trabalho. Nesse cenário, o NCCL cria os seguintes arquivos de registro no diretório /tmp dentro do contêiner de carga de trabalho em cada VM:

    • Em a3plus-vm-1: oito arquivos de registros chamados nccl_log.a3plus-vm-1.PID, em que PID é o ID do processo.
    • Em a3plus-vm-2: oito arquivos de registro chamados nccl_log.a3plus-vm-2.PID.

  4. Analise os registros. As entradas de registro do NCCL têm o seguinte formato:

    HOSTNAME:PID:TID [RANK] NCCL_MESSAGE

    Essas entradas de registro contêm os seguintes valores:

    • HOSTNAME: o nome do host da VM. Esse valor identifica qual VM estava sendo usada quando o NCCL gerou a entrada de registro.
    • PID: o PID. Esse valor identifica qual processo gerou a entrada de registro.
    • TID: o ID da conversa. Esse valor identifica qual thread dentro do processo estava sendo usada quando o NCCL gerou a entrada de registro.
    • RANK: o ID da classificação local. Esse valor identifica qual GPU estava sendo usada quando a NCCL gerou a entrada de registro. Os ranks são numerados de 0 a N, em que N é o número total de GPUs envolvidas no processo. Por exemplo, se a carga de trabalho for executada com oito GPUs por VM, cada VM terá oito valores de classificação diferentes (0 a 7).
    • NCCL_MESSAGE: uma mensagem descritiva que fornece mais informações sobre o evento e inclui o carimbo de data/hora de quando o NCCL criou o registro.

    Exemplo:

    gke-a3plus-mega-np-2-aa33fe53-7wvq:1581:1634 [1] NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.

    Este exemplo tem os seguintes valores:

    • gke-a3plus-mega-np-2-aa33fe53-7wvq: o nome do host.
    • 1581: o ID do processo.
    • 1634: o ID da conversa.
    • 1: o ID da classificação local.
    • NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.: a mensagem explicando o que aconteceu.

  5. Se você estiver abrindo um caso de suporte, coloque os registros coletados e a saída do teste NCCL em um arquivo ZIP. Inclua o arquivo ZIP ao enviar um caso de suporte para o Cloud Customer Care.

  6. Para interromper a coleta de registros de depuração da NCCL, remova as variáveis adicionadas na etapa 1.

A seguir