Container Service for Kubernetes:Preguntas frecuentes sobre GPU

¿Por qué las configuraciones de ECC de GPU son inconsistentes en mi clúster?

El modo Error-Correcting Code (ECC) detecta y corrige errores de memoria de la GPU, lo que mejora la estabilidad y la confiabilidad a costa de reducir ligeramente la memoria GPU disponible. ACK no impone una configuración uniforme de ECC, por lo que los ajustes pueden variar entre nodos.

Cuándo habilitar o deshabilitar ECC:

Establezca el modo ECC para un nodo GPU:

1. Compruebe el estado actual de ECC.

   nvidia-smi

   Salida 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                                                           |
   +---------------------------------------------------------------------------------------+

   En la columna Volatile Uncorr. ECC: 0 indica que ECC está habilitado y no hay errores; Off significa que ECC está deshabilitado.

2. Habilite o deshabilite ECC según sea necesario.

   • Para habilitar ECC en todas las GPU del nodo: nvidia-smi -e 1

   • Para deshabilitar ECC en todas las GPU del nodo: nvidia-smi -e 0

3. Reinicie el sistema operativo para que el cambio surta efecto.

   Importante

   Guarde todos los datos necesarios antes de reiniciar el nodo.

4. Confirme el nuevo estado de ECC con nvidia-smi. La siguiente salida muestra ECC deshabilitado:

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

¿ACK admite instancias aceleradas por vGPU?

Las instancias aceleradas por vGPU requieren una licencia GRID de NVIDIA. Adquiera una licencia y construya su propio servidor de licencias.

Alibaba Cloud no proporciona servidores de licencias, por lo que las instancias aceleradas por vGPU no se pueden utilizar directamente, incluso en un clúster acelerado por vGPU. La consola de ACK ya no permite seleccionar instancias aceleradas por vGPU como nodos del clúster.

Los prefijos de instancia no compatibles incluyen ecs.vgn5i, ecs.vgn6i, ecs.vgn7i y ecs.sgn7i. Para usar estas instancias, adquiera una licencia GRID de NVIDIA y construya su propio servidor de licencias. Utilice una instancia de Elastic Compute Service (ECS) y siga el tutorial oficial de NVIDIA. Consulte NVIDIA.

Se requiere un servidor de licencias para actualizar la licencia del controlador NVIDIA en instancias aceleradas por vGPU.

Adquiera una instancia ECS y siga el tutorial oficial de NVIDIA para construir un servidor de licencias.

Si cuenta con un servidor de licencias, siga estos pasos para agregar instancias aceleradas por vGPU a un clúster ACK.

Agregar instancias aceleradas por vGPU a un clúster ACK:

1. Vaya a Privilege Quota y solicite la función de imagen de SO personalizada.

2. Cree una imagen de SO personalizada basada en CentOS 7.x o Alibaba Cloud Linux 2 con el controlador NVIDIA GRID y la licencia GRID configurados. Consulte Create a custom image from an instance y Install a GRID driver on a vGPU-accelerated instance (Linux).

3. Cree un node pool. Consulte Create and manage a node pool.

4. Agregue las instancias aceleradas por vGPU al node pool. Consulte Add existing nodes.

Pasos siguientes: Consulte Update the NVIDIA driver license for vGPU-accelerated (vGPU) instances in an ACK cluster.

Cómo actualizar manualmente el kernel en un nodo GPU de un clúster existente

Después de actualizar el kernel, reinstale el controlador NVIDIA para restaurar la funcionalidad de la GPU.

1. Aísle el nodo GPU para marcarlo como no programable. Este ejemplo utiliza el nodo cn-beijing.i-2ze19qyi8votgjz12345.

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

2. Drene el nodo 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 el controlador NVIDIA actual.

   Nota

   Este ejemplo utiliza la versión 384,111 del controlador. Para una versión diferente, descargue el paquete correspondiente desde NVIDIA y reemplace el número de versión.

   1. Inicie sesión en el nodo GPU y compruebe la versión del controlador mediante nvidia-smi.

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

   2. Descargue el paquete de instalación del controlador NVIDIA.

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

      Nota

      Debe usar el paquete de instalación para desinstalar el controlador NVIDIA.

   3. Desinstale el controlador.

      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. Actualice el kernel.

5. Reinicie la instancia GPU.

   sudo reboot

6. Inicie sesión nuevamente en el nodo GPU e instale el paquete kernel-devel.

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

7. Descargue e instale el controlador NVIDIA requerido desde el sitio web de NVIDIA. Este ejemplo utiliza la versión 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. Compruebe que /etc/rc.d/rc.local contenga la siguiente configuración. Agréguela si falta.

   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 kubelet y Docker.

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

10. Configure el nodo GPU como programable nuevamente.

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

11. Verifique la versión del controlador en el pod del plugin de dispositivo en el nodo GPU.

    Si docker ps no muestra contenedores ejecutándose en el nodo GPU, consulte Fix container startup issues on GPU nodes .

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

Solucionar problemas de inicio de contenedores en nodos GPU

Síntoma: Después de reiniciar kubelet y Docker en un nodo GPU, no se inicia ningún contenedor.

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: Una discrepancia en el controlador de Cgroup entre Docker y kubelet. Compruebe el controlador de Cgroup para Docker:

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

Solución: Si la salida muestra cgroupfs, siga estos pasos.

1. Realice una copia de seguridad de /etc/docker/daemon.json y luego actualícelo con la siguiente configuración.

   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 Docker y 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 que el controlador de Cgroup ahora es systemd.

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

¿Qué hago si falla la adición de un nodo de instancia bare metal de ECS?

Síntoma: Falla la adición de un nodo de instancia bare metal de ECS ecs.ebmgn7 a un clúster.

Causa: Las instancias bare metal de ECS (ecs.ebmgn7) admiten GPU de múltiples instancias (MIG). ACK restablece la configuración existente de MIG al agregar estos nodos para evitar conflictos. Si el restablecimiento excede el tiempo de espera, falla la adición del nodo.

Diagnóstico: Revise el registro de despliegue de ACK en el host del nodo.

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

Si el registro muestra este error, el restablecimiento de MIG excedió el tiempo de espera:

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

Solución: Agregue el nodo nuevamente. Consulte Add existing nodes.

¿Qué hago si aparece Failed to initialize NVML: Unknown Error al ejecutar un contenedor GPU en Alibaba Cloud Linux 3?

Síntoma: Al ejecutar nvidia-smi en un contenedor GPU, se obtiene:

sudo nvidia-smi

Failed to initialize NVML: Unknown Error

Causa: Ejecutar systemctl daemon-reload o systemctl daemon-reexec en Alibaba Cloud Linux 3 actualiza las configuraciones de cgroup, lo que interfiere con el acceso a la biblioteca de administración de NVIDIA (NVML) en los contenedores. Consulte los problemas de la comunidad #1671 y #48.

Solución: Aplique una de las siguientes soluciones según su configuración.

• Si usa NVIDIA_VISIBLE_DEVICES=all: Agregue privileged: true al securityContext del contenedor.

  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

• Si usa programación compartida de GPU: Cambie a Alibaba Cloud Linux 2 o CentOS 7.

• Solución rápida: Vuelva a crear el pod de la aplicación. Esta es una solución temporal y el problema puede repetirse. Evalúe el impacto en el negocio antes de continuar.

• Si ninguna de las anteriores aplica: Evalúe si su carga de trabajo puede ejecutarse en un sistema operativo diferente, como Alibaba Cloud Linux 2 o CentOS 7.

¿Qué hago si una tarjeta GPU deja de estar disponible debido a errores XID 119 o XID 120?

Síntoma: Una tarjeta GPU no se inicializa. Ejecute sh nvidia-bug-report.sh; el registro mostrará errores XID 119 o XID 120. Ejemplo de error XID 119:

Para otros errores XID, consulte Errores XID comunes de NVIDIA .

Causa: Una excepción en el componente del procesador del sistema GPU (GSP).

Solución: Primero, actualice el controlador NVIDIA a la versión más reciente. Si el problema persiste, deshabilite GSP. NVIDIA introdujo GSP en la versión 510 del controlador. Consulte Capítulo 42. Firmware GSP.

Deshabilite GSP según su escenario:

Cómo aislar manualmente una tarjeta GPU defectuosa en un clúster

Con la programación compartida de GPU, una GPU defectuosa puede causar fallos repetidos en los trabajos. Marque la GPU como no saludable para excluirla de la programación.

Requisitos previos:

• Para clústeres que ejecutan Kubernetes 1.24 o posterior: versión del programador 1.xx.x-aliyun-6.4.3.xxx o posterior.

• Para clústeres que ejecutan Kubernetes 1.22: versión del programador 1.22.15-aliyun-6.2.4.xxx o posterior.

• Shared GPU scheduling está habilitado.

Envíe el siguiente ConfigMap. Reemplace <node-name> con el nombre real del nodo y establezca deviceId con el índice de GPU obtenido de 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

El ConfigMap debe estar en el namespace kube-system con el formato de nombre <node-name>-device-status. En el campo data, deviceId es el índice de GPU de nvidia-smi, deviceType es gpu y healthy es false. Una vez enviado, el programador dejará de asignar trabajo a esa GPU.

Resolver el mensaje "Failed to initialize NVML: Unknown Error" en contenedores GPU

Síntoma: Al ejecutar nvidia-smi en un contenedor GPU, se obtiene:

sudo nvidia-smi

Failed to initialize NVML: Unknown Error

Este problema afecta a nodos que ejecutan Ubuntu 22.04 o Red Hat Enterprise Linux (RHEL) 9.3 de 64 bits.

Causa: Ejecutar systemctl daemon-reload o systemctl daemon-reexec en el nodo actualiza las configuraciones de cgroup, lo que corta el acceso a NVML para los contenedores afectados.

Pods afectados:

• Pods que especifican aliyun.com/gpu-mem en resources.limits

• Pods que establecen NVIDIA_VISIBLE_DEVICES como variable de entorno del contenedor

• Pods que usan una imagen de contenedor que tiene NVIDIA_VISIBLE_DEVICES establecido de forma predeterminada

Los pods que solicitan recursos de GPU mediante nvidia.com/gpu en resources.limits no se ven afectados.

Tanto el plugin de dispositivo NVIDIA como ack-gpu-exporter establecen NVIDIA_VISIBLE_DEVICES=all de forma predeterminada.

Solución:

• Solución rápida: Vuelva a crear el pod de la aplicación. Esta es una solución temporal y el problema puede repetirse. Evalúe el impacto en el negocio antes de continuar.

• Si el pod usa NVIDIA_VISIBLE_DEVICES=all: Agregue privileged: true al securityContext del contenedor.

  Importante

  Otorgar permisos privileged introduce riesgos de seguridad. Prefiera volver a crear el pod cuando sea posible.

  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

Cómo evitar que el archivo /run/containerd/io.containerd.runtime.v2.task/k8s.io/<container ID>/log.json crezca continuamente en nodos GPU

Síntoma: El archivo /run/containerd/io.containerd.runtime.v2.task/k8s.io/<container ID>/log.json crece continuamente y consume espacio en disco.

Entorno afectado: Nodos donde la versión de nvidia-container-toolkit es anterior a 1.16.2.

Causa: Las llamadas frecuentes de exec a un contenedor (por ejemplo, desde un sondeo exec) provocan que el runtime de contenedores NVIDIA escriba una entrada de registro informativa por cada llamada.

Solución: Inicie sesión en el nodo. Cambie el nivel de registro de info a error y borre el contenido existente del registro.

#!/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