Resolva problemas com GPUs no GKE

Esta página mostra-lhe como resolver problemas relacionados com GPUs no Google Kubernetes Engine (GKE).

Instalação do controlador da GPU

Esta secção fornece informações de resolução de problemas para a instalação automática de controladores de dispositivos NVIDIA no GKE.

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

Se usar nós do Ubuntu com GPUs L4, H100 ou H200 anexadas, o controlador de GPU predefinido que o GKE instala pode não estar na versão necessária ou posterior para essas GPUs. Como resultado, o plug-in do dispositivo GPU Pod permanece bloqueado no estado pendente e as suas cargas de trabalho da GPU nesses nós podem ter problemas.

Para resolver este problema para GPUs L4 e H100, recomendamos que atualize para as seguintes versões do GKE, que instalam a versão 535 do controlador da GPU como o controlador predefinido:

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

Em alternativa, pode instalar manualmente a versão 535 ou posterior do controlador 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 este problema para GPUs H200, tem de instalar manualmente a versão 550 ou posterior do controlador 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 seguinte problema ocorre se tiver usado o método de instalação manual de controladores no seu conjunto de nós antes de 25 de janeiro de 2023 e, posteriormente, tiver atualizado o seu conjunto de nós para uma versão do GKE que suporta a instalação automática de controladores. Ambas as cargas de trabalho de instalação existem em simultâneo e tentam instalar versões de controladores em conflito nos seus nós.

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

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

Para resolver este problema, experimente os seguintes métodos:

  • Remova o DaemonSet de instalação manual de controladores do cluster. Isto elimina a carga de trabalho de instalação em conflito e permite que o GKE instale automaticamente um controlador nos seus nós.

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

  • Volte a aplicar o manifesto do DaemonSet de instalação manual do controlador ao cluster. A 25 de janeiro de 2023, atualizámos o manifesto para ignorar os nós que usam a instalação automática de controladores.

    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 de controladores para o seu node pool. O DaemonSet de instalação do controlador existente deve funcionar conforme 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 o seguinte:

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

Para mais informações sobre o mapeamento da versão do controlador da GPU para a versão do GKE, consulte o artigo Mapeie a versão do GKE e a versão da imagem do nó do SO otimizado para contentores para a versão do controlador da GPU.

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

Este problema ocorre quando os nvidia-driver-installer pods estão no estado PodInitializing e o dispositivo do plug-in da GPU ou os pods do instalador do controlador da GPU comunicam o seguinte erro. A mensagem de erro específica depende do sistema operativo em execução 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.

Este problema pode ocorrer quando o coletor de lixo remove a imagem do controlador NVIDIA pré-carregada para libertar espaço num nó. Quando o pod do controlador é recriado ou o respetivo contentor é reiniciado, o GKE não consegue localizar a imagem pré-carregada.

Para mitigar o problema de recolha de lixo quando estiver a executar o COS, atualize os nós do GKE para uma destas versões que contêm a correção:

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

Para mais informações sobre o mapeamento da versão do controlador da GPU para a versão do GKE, consulte o artigo Mapeie a versão do GKE e a versão da imagem do nó do SO otimizado para contentores para a versão do controlador da GPU.

Se os seus nós estiverem a executar o Ubuntu, ainda não existe uma correção disponível para este problema de recolha de lixo. Para mitigar este problema no Ubuntu, pode executar um contentor privilegiado que interaja com o anfitrião para garantir a configuração correta dos controladores da GPU NVIDIA. Para tal, execute sudo /usr/local/bin/nvidia-container-first-boot a partir do 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 causa potencial do problema é quando as imagens do controlador NVIDIA são perdidas após o reinício do nó ou a manutenção do anfitrião. Isto pode ocorrer em nós confidenciais ou nós com GPUs que usam armazenamento SSD local efémero. Nesta situação, o GKE pré-carrega as imagens de contentores nvidia-installer-driver nos nós e move-as do disco de arranque para o SSD local no primeiro arranque.

Para confirmar que ocorreu um evento de manutenção do anfitrião, use o seguinte filtro de registo:

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

Para mitigar o problema de manutenção do anfitrião, atualize a versão do GKE para uma destas versões:

  • 1.27.13-gke.1166000 e posterior
  • 1.29.3-gke.1227000 e posteriores
  • 1.28.8-gke.1171000 e posteriores

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

Encontra este erro no contentor do instalador do controlador da GPU no interior do plugin do dispositivo GPU quando o fastsocket da 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.

Este problema só ocorre 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 da NCCL com o instalador do controlador da GPU.

Para mitigar este problema, atualize a versão do GKE para uma destas versões:

  • 1.28.8-gke.1206000 e posteriores
  • 1.29.3-gke.1344000 e posteriores

Para mais informações, leia as notas de lançamento do GPUDirect-TCPXO.

Erro: não foi possível obter o dispositivo para nvidia0: dispositivo nvidia0 não encontrado.

O seguinte erro 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.

A versão 525.105.17 do controlador NVIDIA tem um erro que pode causar erros de comunicação (XID) e impedir a inicialização adequada da GPU, o que leva a uma falha na inicialização da GPU.

Para corrigir este problema, atualize o controlador NVIDIA para a versão 525.110.11 ou posterior.

Mapeie a versão do GKE e a versão da imagem do nó do SO otimizado para contentores para a versão do controlador da GPU

Para encontrar as versões dos controladores da GPU mapeadas com as versões do GKE e as versões das imagens dos nós do SO otimizado para contentores, siga estes passos:
  1. Mapeie as versões de imagens de nós do Container-Optimized OS para as versões de patches do GKE para a versão específica do GKE onde quer encontrar a versão do controlador da GPU. Por exemplo, 1.33.0-gke.1552000 usa cos-121-18867-90-4.
  2. Escolha a etapa da versão da imagem do nó do SO otimizado para contentores nas notas de lançamento do SO otimizado para contentores. Por exemplo, escolha o marco 121 para cos-121-18867-90-4.
  3. Na página de notas de lançamento da etapa específica, encontre a nota de lançamento correspondente à versão específica da imagem do nó do SO otimizado para contentores. Por exemplo, em Notas de lançamento do SO otimizado para contentores: marco 121, consulte cos-121-18867-90-4. Na tabela na coluna Drivers de GPU, clique em Ver lista para ver as informações da versão do driver de GPU.

Reponha as GPUs em VMs A3

Alguns problemas podem exigir que reponha a GPU numa VM A3.

Para repor a GPU, siga estes passos:

  1. Remova os pods que pedem recursos de GPU do nó onde tem de repor 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. Estabeleça ligação à VM que suporta o nó.

  4. Na sessão SSH, reponha 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 GKE confidenciais

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

As cargas de trabalho de GPU não estão a ser agendadas em Confidential GKE Nodes

Os nós do GKE confidenciais requerem que instale manualmente um controlador de GPU que corresponda ao tipo de GPU selecionado e à versão do GKE. Se os seus pods de GPU não estiverem a ser agendados em nós do GKE confidenciais e permanecerem no estado Pending, descreva o DaemonSet de instalação do controlador:

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

Se o resultado devolver um erro NotFound, instale o controlador.

Se o DaemonSet estiver em execução, o resultado é semelhante ao seguinte:

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

Neste resultado, verifique se o campo nodeAffinity contém a chave cloud.google.com/gke-confidential-nodes-instance-type. Se o resultado não contiver esta chave, o DaemonSet de instalação do controlador não suporta nós do GKE confidenciais.

Implemente o DaemonSet que suporta GPUs em nós do GKE confidenciais:

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 controladores, verifique se as cargas de trabalho da GPU são iniciadas com êxito.

Erro: falha na atribuição do vetor do dispositivo

A seguinte mensagem de erro nos registos do contentor da GPU indica que a GPU foi separada da instância de VM do nó:

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

Esta desassociação pode ocorrer devido a um erro de hardware ou a um problema com as chaves de encriptação.

Para resolver este problema, reinicie a instância do nó. Esta operação é disruptiva e afeta todas as cargas de trabalho nesse nó. Para reiniciar a instância, siga os passos seguintes:

  1. Obtenha o nome do nó que executa o pod de GPU:

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

    Substitua POD_NAME pelo nome do pod com falhas.

    O resultado é semelhante ao seguinte:

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

  2. Reponha a instância do Compute Engine:

    gcloud compute instances reset NODE_NAME

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

    A CLI gcloud procura VMs com esse nome no seu projeto ativo. Se vir um comando para selecionar uma zona, especifique Y.

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

Erro: falha na desencriptação com o erro -74

A seguinte mensagem de erro nos registos do nó indica que as chaves de encriptação da GPU foram perdidas:

Decryption failed with error -74

Este erro ocorre quando o daemon de persistência da NVIDIA, que é executado na instância de VM do nó, falha. Se vir esta mensagem de erro, reponha a instância:

gcloud compute instances reset NODE_NAME

Substitua NODE_NAME pelo nome do nó com falhas.

A CLI gcloud procura VMs com esse nome no seu projeto ativo. Se vir um comando para selecionar uma zona, especifique Y.

Se a reposição da instância não resolver este problema, contacte o apoio ao cliente do Google Cloud ou envie um erro do produto. Para mais informações, consulte Obtenha apoio técnico.

Encontrar erros XID

O daemonset gpu-device-plugin é executado no espaço de nomes kube-system e é responsável pelo seguinte:

  • Programação da carga de trabalho da GPU: atribuição de recursos da GPU a pods.
  • Verificação do estado da GPU: monitorização do estado das suas GPUs.
  • Recolha de métricas da GPU: recolha de métricas relacionadas com a GPU, como o ciclo de atividade e a utilização de memória.

O gpu-device-plugin usa a NVIDIA Management Library (NVML) para detetar erros XID. Quando ocorre um erro de XID, o gpu-device-plugin em execução no nó afetado regista o erro. Encontra dois tipos de registos de erros XID:

  • Erros de XID não críticos:
    • Formato de registo: Skip error Xid=%d as it is not Xid Critical
    • Significado: estes erros são considerados não críticos. Podem ser causados por vários problemas de software ou hardware.
    • Ação: o GKE não toma nenhuma ação automática para erros XID não críticos.
  • Erros críticos de XID:
    • Formato de registo: XidCriticalError: Xid=%d, All devices will go unhealthy
    • Significado: estes 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 as cargas de trabalho de GPU sejam agendadas no nó.
      • Se a autorreparação de nós estiver ativada, o GKE recria o nó.

Problemas com GPUDirect-TCPX(O)

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

Notas de lançamento e instruções de atualização

Para novos utilizadores, a opção Maximizar a largura de banda da rede da GPU em clusters no modo padrão fornece orientações sobre a utilização do GPUDirect-TCPX(O). Para os utilizadores existentes, leia as notas de lançamento do GPUDirect-TCPXO para ver informações de lançamento e instruções de atualização, uma vez que são lançadas novas versões continuamente.

Depure com registos da NCCL

Se não conseguir resolver um problema com a NCCL, recolha registos da NCCL com informações de depuração. Estes registos contêm informações valiosas sobre as operações da NCCL e podem ajudar a encontrar a origem do seu problema. Se não conseguir resolver o problema, reúna estes registos antes de abrir um registo junto ao apoio técnico ao cliente do Google Cloud. Estes registos podem ajudar o Cloud Customer Care a resolver o seu problema mais rapidamente.

Para gerar e recolher os registos, conclua os seguintes passos:

  1. Defina as seguintes variáveis de ambiente no manifesto do Pod ou da aplicação:

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

    Para mais informações sobre estas variáveis de ambiente, leia o artigo Recolha registos de depuração da NCCL.

  2. Para gerar dados para os seus registos, execute um teste NCCL. A forma de executar este teste depende do tipo de cluster que usa. Para clusters do GKE, pode implementar e executar o teste NCCL com o agendamento com reconhecimento da topologia (TAS). Depois de executar o teste NCCL, o NCCL gera automaticamente os registos em todos os nós participantes.

  3. Recolha os registos de todos os nós. Verifique se recolheu registos da NCCL de todos os nós, confirmando se os registos contêm as seguintes informações:

    • Os nomes de anfitrião de todas as VMs envolvidas numa 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 não tiver a certeza da localização dos ficheiros de registo, o exemplo seguinte mostra onde o NCCL cria os ficheiros de registo quando a variável NCCL_DEBUG_FILE está definida como /tmp/nccl_log.%h.%p. Tem duas VMs denominadas a3plus-vm-1 e a3plus-vm-2, e cada VM executa oito processos no contentor de carga de trabalho. Neste cenário, a NCCL cria os seguintes ficheiros de registo no diretório /tmp no contentor de carga de trabalho em cada VM:

    • No a3plus-vm-1: oito ficheiros de registo com o nome nccl_log.a3plus-vm-1.PID, em que PID é o ID do processo.
    • Em a3plus-vm-2: oito ficheiros de registo com o nome nccl_log.a3plus-vm-2.PID.

  4. Reveja os registos. As entradas do registo da NCCL têm o seguinte formato:

    HOSTNAME:PID:TID [RANK] NCCL_MESSAGE

    Estas entradas do registo contêm os seguintes valores:

    • HOSTNAME: o nome do anfitrião da VM. Este valor identifica a MV que estava a ser usada quando o NCCL gerou a entrada do registo.
    • PID: o PID. Este valor identifica o processo que gerou a entrada do registo.
    • TID: o ID da discussão. Este valor identifica o segmento no processo que estava a ser usado quando o NCCL gerou a entrada do registo.
    • RANK: o ID de classificação local. Este valor identifica que GPU estava a ser usada quando o NCCL gerou a entrada de registo. As classificações são numeradas de 0 a N, em que N é o número total de GPUs envolvidas no processo. Por exemplo, se a sua carga de trabalho for executada com oito GPUs por MV, cada MV deve 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 a data/hora em que o NCCL criou o registo.

    Por 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 anfitrião.
    • 1581: o ID do processo.
    • 1634: o ID da discussão.
    • 1: o ID de classificação local.
    • NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.: a mensagem a explicar o que aconteceu.

  5. Se estiver a abrir um registo de apoio técnico, comprima os registos recolhidos, juntamente com o resultado do teste NCCL, num ficheiro ZIP. Inclua o ficheiro ZIP quando enviar um registo de apoio ao cliente para o Cloud Customer Care.

  6. Para parar de recolher registos de depuração da NCCL, remova as variáveis que adicionou no passo 1.

O que se segue?