Container Service for Kubernetes:GPU FAQ

Por que as configurações de ECC da GPU no meu cluster estão inconsistentes?

O modo Error-Correcting Code (ECC) detecta e corrige erros de memória da GPU, melhorando a estabilidade e a confiabilidade à custa de uma leve redução na memória GPU disponível. O ACK não impõe configurações uniformes de ECC; portanto, as definições podem variar entre os nós.

Quando ativar ou desativar o ECC:

Defina o modo ECC para um nó GPU:

1. Verifique o status atual do ECC.

   nvidia-smi

   Saída esperada:

   Fri Jun  6 11:49:05 2025
   +---------------------------------------------------------------------------------------+
   | NVIDIA-SMI 535.161.07             Driver Version: 535.161.07   CUDA Version: 12.2     |
   |-----------------------------------------+----------------------+----------------------+
   | GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
   | Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
   |                                         |                      |               MIG M. |
   |=========================================+======================+======================|
   |   0  Tesla T4                       On  | 00000000:00:08.0 Off |                    0 |
   | N/A   31C    P8               9W /  70W |      0MiB / 15360MiB |      0%      Default |
   |                                         |                      |                  N/A |
   +-----------------------------------------+----------------------+----------------------+
   
   +---------------------------------------------------------------------------------------+
   | Processes:                                                                            |
   |  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
   |        ID   ID                                                             Usage      |
   |=======================================================================================|
   |  No running processes found                                                           |
   +---------------------------------------------------------------------------------------+

   Na coluna Volatile Uncorr. ECC: 0 indica que o ECC está ativado e sem erros; Off indica que o ECC está desativado.

2. Ative ou desative o ECC conforme necessário.

   • Para ativar o ECC em todas as GPUs do nó: ``nvidia-smi -e 1``

   • Para desativar o ECC em todas as GPUs do nó: ``nvidia-smi -e 0``

3. Reinicie o sistema operacional para aplicar a alteração.

   Importante

   Salve todos os dados necessários antes de reiniciar o nó.

4. Confirme o novo status do ECC com nvidia-smi. A saída a seguir mostra o ECC desativado:

   Fri Jun  6 11:52:15 2025
   +---------------------------------------------------------------------------------------+
   | NVIDIA-SMI 535.161.07             Driver Version: 535.161.07   CUDA Version: 12.2     |
   |-----------------------------------------+----------------------+----------------------+
   | GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
   | Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
   |                                         |                      |               MIG M. |
   |=========================================+======================+======================|
   |   0  Tesla T4                       On  | 00000000:00:08.0 Off |                  Off |
   | N/A   31C    P8               9W /  70W |      0MiB / 16384MiB |      0%      Default |
   |                                         |                      |                  N/A |
   +-----------------------------------------+----------------------+----------------------+
   
   +---------------------------------------------------------------------------------------+
   | Processes:                                                                            |
   |  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
   |        ID   ID                                                             Usage      |
   |=======================================================================================|
   |  No running processes found                                                           |
   +---------------------------------------------------------------------------------------+

O ACK suporta instâncias aceleradas por vGPU?

Instâncias aceleradas por vGPU exigem uma licença GRID da NVIDIA. Adquira uma licença e construa seu próprio servidor de licenças.

A Alibaba Cloud não fornece servidores de licenças; portanto, não é possível usar instâncias aceleradas por vGPU diretamente, mesmo em um cluster acelerado por vGPU. O console ACK não oferece mais suporte à seleção de instâncias aceleradas por vGPU como nós de cluster.

Os prefixos de instância não suportados incluem ecs.vgn5i, ecs.vgn6i, ecs.vgn7i e ecs.sgn7i. Para utilizar essas instâncias, adquira uma licença GRID da NVIDIA e configure seu próprio servidor de licenças. Utilize uma instância Elastic Compute Service (ECS) e siga o tutorial oficial da NVIDIA. Consulte NVIDIA.

Um servidor de licenças é necessário para atualizar a licença do driver NVIDIA para instâncias aceleradas por vGPU.

Adquira uma instância ECS e siga o tutorial oficial da NVIDIA para construir um servidor de licenças.

Caso já possua um servidor de licenças, siga estas etapas para adicionar instâncias aceleradas por vGPU a um cluster ACK.

Adicione instâncias aceleradas por vGPU a um cluster ACK:

1. Acesse Privilege Quota e solicite o recurso de imagem personalizada de SO.

2. Crie uma imagem personalizada de SO baseada em CentOS 7.x ou Alibaba Cloud Linux 2 com o driver NVIDIA GRID e a licença GRID configurados. Consulte Criar uma imagem personalizada a partir de uma instância e Instalar um driver GRID em uma instância acelerada por vGPU (Linux).

3. Crie um pool de nós. Consulte Criar e gerenciar um pool de nós.

4. Adicione as instâncias aceleradas por vGPU ao pool de nós. Consulte Adicionar nós existentes.

Próximos passos: Consulte Atualizar a licença do driver NVIDIA para instâncias aceleradas por vGPU (vGPU) em um cluster ACK.

Como atualizar manualmente o kernel em um nó GPU em um cluster existente

Após atualizar o kernel, reinstale o driver NVIDIA para restaurar a funcionalidade da GPU.

1. Isole o nó GPU para marcá-lo como não agendável. Este exemplo utiliza o nó cn-beijing.i-2ze19qyi8votgjz12345.

   kubectl cordon cn-beijing.i-2ze19qyi8votgjz12345
   
   node/cn-beijing.i-2ze19qyi8votgjz12345 already cordoned

2. Drene o nó GPU.

   kubectl drain cn-beijing.i-2ze19qyi8votgjz12345 --grace-period=120 --ignore-daemonsets=true
   
   node/cn-beijing.i-2ze19qyi8votgjz12345 cordoned
   WARNING: Ignoring DaemonSet-managed pods: flexvolume-9scb4, kube-flannel-ds-r2qmh, kube-proxy-worker-l62sf, logtail-ds-f9vbg
   pod/nginx-ingress-controller-78d847fb96-5fkkw evicted

3. Desinstale o driver NVIDIA atual.

   Nota

   Este exemplo usa a versão 384.111 do driver. Para uma versão diferente, baixe o pacote correspondente da NVIDIA e substitua o número da versão.

   1. Faça login no nó GPU e verifique a versão do driver usando nvidia-smi .

      sudo nvidia-smi -a | grep 'Driver Version'
      Driver Version                      : 384.111

   2. Baixe o pacote de instalação do driver NVIDIA.

      cd /tmp/ && sudo curl -O https://cn.download.nvidia.cn/tesla/384.111/NVIDIA-Linux-x86_64-384.111.run

      Nota

      Use obrigatoriamente o pacote de instalação para desinstalar o driver NVIDIA.

   3. Desinstale o driver.

      sudo chmod u+x NVIDIA-Linux-x86_64-384.111.run
      sudo sh ./NVIDIA-Linux-x86_64-384.111.run --uninstall -a -s -q

4. Atualize o kernel.

5. Reinicie a instância GPU.

   sudo reboot

6. Faça login novamente no nó GPU e instale o pacote kernel-devel.

   sudo yum install -y kernel-devel-$(uname -r)

7. Baixe e instale o driver NVIDIA necessário no site da NVIDIA. Este exemplo utiliza a versão 410,79.

   cd /tmp/
   sudo curl -O https://cn.download.nvidia.cn/tesla/410.79/NVIDIA-Linux-x86_64-410.79.run
   sudo chmod u+x NVIDIA-Linux-x86_64-410.79.run
   sudo sh ./NVIDIA-Linux-x86_64-410.79.run -a -s -q
   
   # warm up GPU
   sudo nvidia-smi -pm 1 || true
   sudo nvidia-smi -acp 0 || true
   sudo nvidia-smi --auto-boost-default=0 || true
   sudo nvidia-smi --auto-boost-permission=0 || true
   sudo nvidia-modprobe -u -c=0 -m || true

8. Verifique se /etc/rc.d/rc.local contém a seguinte configuração. Adicione-a se estiver ausente.

   sudo nvidia-smi -pm 1 || true
   sudo nvidia-smi -acp 0 || true
   sudo nvidia-smi --auto-boost-default=0 || true
   sudo nvidia-smi --auto-boost-permission=0 || true
   sudo nvidia-modprobe -u -c=0 -m || true

9. Reinicie o kubelet e o Docker.

   sudo service kubelet stop
   sudo service docker restart
   sudo service kubelet start

10. Torne o nó GPU agendável novamente.

     kubectl uncordon cn-beijing.i-2ze19qyi8votgjz12345
    
     node/cn-beijing.i-2ze19qyi8votgjz12345 already uncordoned

11. Verifique a versão do driver no pod do plugin de dispositivo no nó GPU.

    Se docker ps não mostrar contêineres em execução no nó GPU, consulte Corrigir problemas de inicialização de contêineres em nós GPU .

     kubectl exec -n kube-system -t nvidia-device-plugin-cn-beijing.i-2ze19qyi8votgjz12345 nvidia-smi
     Thu Jan 17 00:33:27 2019
     +-----------------------------------------------------------------------------+
     | NVIDIA-SMI 410.79       Driver Version: 410.79       CUDA Version: N/A      |
     |-------------------------------+----------------------+----------------------+
     | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
     | Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
     |===============================+======================+======================|
     |   0  Tesla P100-PCIE...  On   | 00000000:00:09.0 Off |                    0 |
     | N/A   27C    P0    28W / 250W |      0MiB / 16280MiB |      0%      Default |
     +-------------------------------+----------------------+----------------------+
    
     +-----------------------------------------------------------------------------+
     | Processes:                                                       GPU Memory |
     |  GPU       PID   Type   Process name                             Usage      |
     |=============================================================================|
     |  No running processes found                                                 |
     +-----------------------------------------------------------------------------+

Corrigir problemas de inicialização de contêineres em nós GPU

Sintoma: Após reiniciar o kubelet e o Docker em um nó GPU, nenhum contêiner inicia.

sudo service kubelet stop
Redirecting to /bin/systemctl stop kubelet.service
sudo service docker stop
Redirecting to /bin/systemctl stop docker.service
sudo service docker start
Redirecting to /bin/systemctl start docker.service
sudo service kubelet start
Redirecting to /bin/systemctl start kubelet.service

sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

Causa: Incompatibilidade de driver Cgroup entre Docker e kubelet. Verifique o driver Cgroup do Docker:

sudo docker info | grep -i cgroup
Cgroup Driver: cgroupfs

Solução: Se a saída mostrar cgroupfs, siga estas etapas.

1. Faça backup de /etc/docker/daemon.json e atualize-o com a seguinte configuração.

   sudo cat >/etc/docker/daemon.json <<-EOF
   {
       "default-runtime": "nvidia",
       "runtimes": {
           "nvidia": {
               "path": "/usr/bin/nvidia-container-runtime",
               "runtimeArgs": []
           }
       },
       "exec-opts": ["native.cgroupdriver=systemd"],
       "log-driver": "json-file",
       "log-opts": {
           "max-size": "100m",
           "max-file": "10"
       },
       "oom-score-adjust": -1000,
       "storage-driver": "overlay2",
       "storage-opts": ["overlay2.override_kernel_check=true"],
       "live-restore": true
   }
   EOF

2. Reinicie o Docker e o kubelet.

   sudo service kubelet stop
   Redirecting to /bin/systemctl stop kubelet.service
   sudo service docker restart
   Redirecting to /bin/systemctl restart docker.service
   sudo service kubelet start
   Redirecting to /bin/systemctl start kubelet.service

3. Confirme se o driver Cgroup agora é systemd.

   sudo docker info | grep -i cgroup
   Cgroup Driver: systemd

O que fazer se a adição de um nó ECS Bare Metal Instance falhar?

Sintoma: Falha ao adicionar um nó ECS Bare Metal Instance ecs.ebmgn7 a um cluster.

Causa: As instâncias ECS Bare Metal Instance (ecs.ebmgn7) suportam GPU multi-instância (MIG). O ACK redefine as configurações MIG existentes ao adicionar esses nós para evitar conflitos. Se a redefinição atingir o tempo limite, a adição do nó falhará.

Diagnóstico: Verifique o log de implantação do ACK no host do nó.

sudo cat /var/log/ack-deploy.log

Se o log exibir este erro, a redefinição do MIG atingiu o tempo limite:

command timeout: timeout 300 nvidia-smi --gpu-reset

Solução: Adicione o nó novamente. Consulte Adicionar nós existentes.

O que fazer se ocorrer Failed to initialize NVML: Unknown Error ao executar um contêiner GPU no Alibaba Cloud Linux 3?

Sintoma: A execução de nvidia-smi em um contêiner GPU retorna:

sudo nvidia-smi

Failed to initialize NVML: Unknown Error

Causa: Executar systemctl daemon-reload ou systemctl daemon-reexec no Alibaba Cloud Linux 3 atualiza as configurações de cgroup, o que interfere no acesso à NVIDIA Management Library (NVML) nos contêineres. Consulte os problemas da comunidade #1671 e #48.

Solução: Aplique uma das seguintes soluções com base na sua configuração.

• Ao usar NVIDIA_VISIBLE_DEVICES=all: Adicione privileged: true ao securityContext do contêiner.

  apiVersion: v1
  kind: Pod
  metadata:
    name: test-gpu-pod
  spec:
    containers:
      - name: test-gpu-pod
        image: centos:7
        command:
        - sh
        - -c
        - sleep 1d
        securityContext: # Add privileged permissions to the container.
          privileged: true

• Ao usar agendamento compartilhado de GPU: Migre para Alibaba Cloud Linux 2 ou CentOS 7.

• Solução rápida: Recrie o pod da aplicação. Esta é uma correção temporária e o problema pode retornar. Avalie o impacto nos negócios antes de prosseguir.

• Se nenhuma das opções acima se aplicar: Avalie se sua carga de trabalho pode ser executada em um sistema operacional diferente, como Alibaba Cloud Linux 2 ou CentOS 7.

O que fazer se uma placa GPU ficar indisponível devido a erros XID 119 ou XID 120?

Sintoma: Uma placa GPU falha ao inicializar. Execute sh nvidia-bug-report.sh — o log mostra erros XID 119 ou XID 120. Exemplo de erro XID 119:

Para outros erros XID, consulte Erros XID comuns da NVIDIA .

Causa: Uma exceção no componente GPU System Processor (GSP).

Solução: Primeiro, atualize o driver NVIDIA para a versão mais recente. Se o problema persistir, desative o GSP. A NVIDIA introduziu o GSP na versão 510 do driver. Consulte Capítulo 42. Firmware GSP.

Desative o GSP com base no seu cenário:

Como isolar manualmente uma placa GPU defeituosa em um cluster

No agendamento compartilhado de GPU, uma GPU defeituosa pode causar falhas repetidas em jobs. Marque a GPU como não saudável para excluí-la do agendamento.

Pré-requisitos:

• Para clusters executando Kubernetes 1.24 ou posterior: versão do scheduler 1.xx.x-aliyun-6.4.3.xxx ou superior.

• Para clusters executando Kubernetes 1.22: versão do scheduler 1.22.15-aliyun-6.2.4.xxx ou superior.

• O Agendamento compartilhado de GPU está ativado.

Envie o ConfigMap a seguir. Substitua <node-name> pelo nome real do nó e defina deviceId como o índice da GPU obtido via nvidia-smi.

apiVersion: v1
kind: ConfigMap
metadata:
  name: <node-name>-device-status   # Replace <node-name> with the actual node name.
  namespace: kube-system
data:
  devices: |
    - deviceId: 0          # Run nvidia-smi to get the GPU index.
      deviceType: gpu
      healthy: false

O ConfigMap deve estar no namespace kube-system com o formato de nome <node-name>-device-status. No campo data, deviceId é o índice da GPU obtido via nvidia-smi, deviceType é gpu e healthy é false. Após o envio, o scheduler interrompe a alocação de trabalho para essa GPU.

Resolver a mensagem "Failed to initialize NVML: Unknown Error" em contêineres GPU

Sintoma: A execução de nvidia-smi em um contêiner GPU retorna:

sudo nvidia-smi

Failed to initialize NVML: Unknown Error

Este problema afeta nós executando Ubuntu 22.04 ou Red Hat Enterprise Linux (RHEL) 9,3 64 bits.

Causa: Executar systemctl daemon-reload ou systemctl daemon-reexec no nó atualiza as configurações de cgroup, o que corta o acesso ao NVML para os contêineres afetados.

Pods afetados:

• Pods que especificam aliyun.com/gpu-mem em resources.limits

• Pods que definem NVIDIA_VISIBLE_DEVICES como variável de ambiente do contêiner

• Pods que usam uma imagem de contêiner com NVIDIA_VISIBLE_DEVICES definido por padrão

Pods que solicitam recursos de GPU via nvidia.com/gpu em resources.limits não são afetados.

Tanto o NVIDIA Device Plugin quanto o ack-gpu-exporter definem NVIDIA_VISIBLE_DEVICES=all por padrão.

Solução:

• Solução rápida: Recrie o pod da aplicação. Esta é uma correção temporária e o problema pode retornar. Avalie o impacto nos negócios antes de prosseguir.

• Se o pod usar NVIDIA_VISIBLE_DEVICES=all: Adicione privileged: true ao securityContext do contêiner.

  Importante

  Conceder permissões privileged introduz riscos de segurança. Prefira recriar o pod sempre que possível.

  apiVersion: v1
  kind: Pod
  metadata:
    name: test-gpu-pod
  spec:
    containers:
      - name: test-gpu-pod
        image: centos:7
        command:
        - sh
        - -c
        - sleep 1d
        securityContext: # Add privileged permissions to the container.
          privileged: true

Como evitar que o arquivo /run/containerd/io.containerd.runtime.v2.task/k8s.io/<container ID>/log.json cresça continuamente em nós GPU

Sintoma: O arquivo /run/containerd/io.containerd.runtime.v2.task/k8s.io/<container ID>/log.json cresce continuamente e consome espaço em disco.

Ambiente afetado: Nós onde a versão do nvidia-container-toolkit é anterior a 1.16.2.

Causa: Chamadas frequentes de exec para um contêiner — por exemplo, de uma sonda exec — fazem com que o runtime de contêiner da NVIDIA grave uma entrada de log informativa por chamada.

Solução: Faça login no nó. Altere o nível de log de info para error e limpe o conteúdo de log existente.

#!/bin/bash
set -e

export CONFIG=/etc/nvidia-container-runtime/config.toml
export CONTAINER_ROOT_PATH="/run/containerd/io.containerd.runtime.v2.task/k8s.io"

if [ -f $CONFIG ];then
    # Change the log level in the nvidia-container-runtime configuration from "info" to "error".
sed -i 's@^log-level = "info"@log-level = "error"@g' $CONFIG
    # Clear the content of the container's log.json file.
find $CONTAINER_ROOT_PATH -mindepth 2 -maxdepth 2 -name log.json -type f -exec sh -c 'echo "" > "{}"' \;
fi