Container Service for Kubernetes:GPU FAQ

Pourquoi les configurations ECC des GPU de mon cluster sont-elles incohérentes ?

Le mode Error-Correcting Code (ECC) détecte et corrige les erreurs de mémoire du GPU, améliorant ainsi la stabilité et la fiabilité au prix d'une légère réduction de la mémoire GPU disponible. ACK n'impose pas de paramètres ECC uniformes ; par conséquent, les configurations peuvent varier d'un nœud à l'autre.

Quand activer ou désactiver l'ECC :

Définir le mode ECC pour un nœud GPU :

1. Vérifiez l'état actuel de l'ECC.

   nvidia-smi

   Sortie attendue :

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

   Dans la colonne Volatile Uncorr. ECC : 0 signifie que l'ECC est activé sans erreur ; Off signifie que l'ECC est désactivé.

2. Activez ou désactivez l'ECC selon vos besoins.

   • Activez l'ECC pour tous les GPU du nœud : nvidia-smi -e 1

   • Désactivez l'ECC pour tous les GPU du nœud : nvidia-smi -e 0

3. Redémarrez le système d'exploitation pour que la modification prenne effet.

   Important

   Enregistrez toutes les données nécessaires avant de redémarrer le nœud.

4. Confirmez le nouvel état de l'ECC avec nvidia-smi. La sortie suivante montre que l'ECC est désactivé :

   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 prend-il en charge les instances accélérées par vGPU ?

Les instances accélérées par vGPU nécessitent une licence GRID de NVIDIA. Achetez une licence et configurez votre propre serveur de licences.

Alibaba Cloud ne fournit pas de serveurs de licences ; il est donc impossible d'utiliser directement les instances accélérées par vGPU, même dans un cluster vGPU. La console ACK ne permet plus de sélectionner des instances accélérées par vGPU en tant que nœuds de cluster.

Les préfixes d'instance non pris en charge incluent ecs.vgn5i, ecs.vgn6i, ecs.vgn7i et ecs.sgn7i. Pour utiliser ces instances, achetez une licence GRID auprès de NVIDIA et configurez votre propre serveur de licences. Utilisez une instance Elastic Compute Service (ECS) et suivez le tutoriel officiel de NVIDIA. Consultez NVIDIA.

Un serveur de licences est requis pour mettre à jour la licence du pilote NVIDIA des instances accélérées par vGPU.

Achetez une instance ECS et suivez le tutoriel officiel de NVIDIA pour configurer un serveur de licences.

Si vous disposez d'un serveur de licences, suivez les étapes ci-dessous pour ajouter des instances accélérées par vGPU à un cluster ACK.

Ajouter des instances accélérées par vGPU à un cluster ACK :

1. Accédez à Privilege Quota et demandez la fonctionnalité d'image OS personnalisée.

2. Créez une image OS personnalisée basée sur CentOS 7.x ou Alibaba Cloud Linux 2, avec le pilote NVIDIA GRID et la licence GRID configurés. Consultez Créer une image personnalisée à partir d'une instance et Installer un pilote GRID sur une instance accélérée par vGPU (Linux).

3. Créez un pool de nœuds. Consultez Créer et gérer un pool de nœuds.

4. Ajoutez les instances accélérées par vGPU au pool de nœuds. Consultez Ajouter des nœuds existants.

Étapes suivantes : Consultez Mettre à jour la licence du pilote NVIDIA pour les instances accélérées par vGPU dans un cluster ACK.

Procédure de mise à niveau manuelle du noyau sur un nœud GPU dans un cluster existant

Après la mise à niveau du noyau, réinstallez le pilote NVIDIA pour restaurer les fonctionnalités du GPU.

1. Marquez le nœud GPU comme non planifiable (cordon). Cet exemple utilise le nœud cn-beijing.i-2ze19qyi8votgjz12345.

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

2. Videz le nœud 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. Désinstallez le pilote NVIDIA actuel.

   Remarque

   Cet exemple utilise la version 384.111 du pilote. Pour une autre version, téléchargez le package correspondant depuis NVIDIA et remplacez le numéro de version.

   1. Connectez-vous au nœud GPU et vérifiez la version du pilote à l'aide de nvidia-smi.

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

   2. Téléchargez le package d'installation du pilote NVIDIA.

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

      Remarque

      Vous devez utiliser ce package d'installation pour désinstaller le pilote NVIDIA.

   3. Désinstallez le pilote.

      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. Mettez à niveau le noyau.

5. Redémarrez l'instance GPU.

   sudo reboot

6. Reconnectez-vous au nœud GPU et installez le package kernel-devel.

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

7. Téléchargez et installez le pilote NVIDIA requis depuis le site Web de NVIDIA. Cet exemple utilise la version 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. Vérifiez que le fichier /etc/rc.d/rc.local contient la configuration suivante. Ajoutez-la si elle est manquante.

   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. Redémarrez kubelet et Docker.

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

10. Rétablissez le nœud GPU comme planifiable.

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

11. Vérifiez la version du pilote dans le pod du plug-in de périphérique sur le nœud GPU.

    Si docker ps n'affiche aucun conteneur en cours d'exécution sur le nœud GPU, consultez Résolution des problèmes de démarrage des conteneurs sur les nœuds 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                                                 |
     +-----------------------------------------------------------------------------+

Résolution des problèmes de démarrage des conteneurs sur les nœuds GPU

Symptôme : Après le redémarrage de kubelet et de Docker sur un nœud GPU, aucun conteneur ne démarre.

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

Cause : Incompatibilité entre les pilotes Cgroup de Docker et de kubelet. Vérifiez le pilote Cgroup pour Docker :

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

Solution : Si la sortie affiche cgroupfs, suivez les étapes ci-dessous.

1. Sauvegardez le fichier /etc/docker/daemon.json, puis mettez-le à jour avec la configuration suivante.

   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. Redémarrez Docker et 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. Confirmez que le pilote Cgroup est désormais défini sur systemd.

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

Que faire en cas d'échec de l'ajout d'un nœud d'instance ECS Bare Metal ?

Symptôme : L'ajout d'un nœud d'instance ECS Bare Metal ecs.ebmgn7 à un cluster échoue.

Cause : Les instances ECS Bare Metal (ecs.ebmgn7) prennent en charge le GPU multi-instance (MIG). ACK réinitialise les paramètres MIG existants lors de l'ajout de ces nœuds pour éviter les conflits. Si la réinitialisation expire, l'ajout du nœud échoue.

Diagnostic : Consultez le journal de déploiement ACK sur l'hôte du nœud.

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

Si le journal affiche l'erreur suivante, la réinitialisation MIG a expiré :

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

Solution : Ajoutez à nouveau le nœud. Consultez la section Ajout de nœuds existants.

Que faire si l'erreur Failed to initialize NVML: Unknown Error survient lors de l'exécution d'un conteneur GPU sur Alibaba Cloud Linux 3 ?

Symptôme : L'exécution de la commande nvidia-smi dans un conteneur GPU renvoie le message suivant :

sudo nvidia-smi

Failed to initialize NVML: Unknown Error

Cause : L'exécution des commandes systemctl daemon-reload ou systemctl daemon-reexec sur Alibaba Cloud Linux 3 met à jour les configurations cgroup, ce qui interfère avec l'accès à la bibliothèque NVIDIA Management Library (NVML) depuis les conteneurs. Consultez les problèmes communautaires #1671 et #48.

Solution : Appliquez l'une des solutions suivantes en fonction de votre configuration.

• Utilisation de NVIDIA_VISIBLE_DEVICES=all : Ajoutez le paramètre privileged: true au champ securityContext du conteneur.

  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

• Utilisation de la planification GPU partagée : Basculez vers Alibaba Cloud Linux 2 ou CentOS 7.

• Solution de contournement rapide : Recréez le pod applicatif. Il s'agit d'une solution temporaire ; le problème peut se reproduire. Évaluez l'impact sur votre activité avant de procéder.

• Si aucune des solutions ci-dessus ne s'applique : Évaluez la possibilité d'exécuter votre charge de travail sur un autre système d'exploitation, tel qu'Alibaba Cloud Linux 2 ou CentOS 7.

Que faire si une carte GPU devient indisponible en raison d'erreurs XID 119 ou XID 120 ?

Symptôme : Une carte GPU ne parvient pas à s'initialiser. Exécutez la commande sh nvidia-bug-report.sh ; le journal affiche des erreurs XID 119 ou XID 120. Voici un exemple d'erreur XID 119 :

Pour les autres erreurs XID, consultez la page NVIDIA Common XID Errors .

Cause : Une exception survient dans le composant GPU System Processor (GSP).

Solution : Commencez par mettre à jour le pilote NVIDIA vers sa dernière version. Si le problème persiste, désactivez GSP. NVIDIA a introduit GSP dans la version 510 du pilote. Consultez la section Chapter 42. GSP firmware.

Désactivation de GSP selon votre scénario :

Comment isoler manuellement une carte GPU défectueuse dans un cluster

Dans le cadre d'une planification GPU partagée, une carte GPU défectueuse peut provoquer des échecs répétés des tâches. Marquez la carte GPU comme non saine pour l'exclure de la planification.

Prérequis :

• Pour les clusters exécutant Kubernetes 1.24 ou version ultérieure : version du planificateur 1.xx.x-aliyun-6.4.3.xxx ou ultérieure.

• Pour les clusters exécutant Kubernetes 1.22 : version du planificateur 1.22.15-aliyun-6.2.4.xxx ou ultérieure.

• La fonctionnalité Shared GPU scheduling est activée.

Soumettez le ConfigMap suivant. Remplacez <node-name> par le nom réel du nœud et définissez le champ deviceId avec l'index GPU obtenu via la commande 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

Le ConfigMap doit se trouver dans l'espace de noms kube-system et respecter le format de nommage <node-name>-device-status. Dans le champ data, le paramètre deviceId correspond à l'index GPU obtenu via la commande nvidia-smi, deviceType doit être défini sur gpu et healthy sur false. Une fois soumis, le planificateur cesse d'allouer des travaux à cette carte GPU.

Résoudre le message « Failed to initialize NVML: Unknown Error » dans les conteneurs GPU

Symptôme : L'exécution de la commande nvidia-smi dans un conteneur GPU renvoie l'erreur suivante :

sudo nvidia-smi

Failed to initialize NVML: Unknown Error

Ce problème affecte les nœuds exécutant Ubuntu 22.04 ou Red Hat Enterprise Linux (RHEL) 9.3 64 bits.

Cause : L'exécution des commandes systemctl daemon-reload ou systemctl daemon-reexec sur le nœud met à jour les configurations cgroup, ce qui interrompt l'accès NVML pour les conteneurs concernés.

Pods concernés :

• Les pods qui spécifient aliyun.com/gpu-mem dans resources.limits

• Les pods qui définissent NVIDIA_VISIBLE_DEVICES comme variable d'environnement du conteneur

• Les pods utilisant une image de conteneur pour laquelle NVIDIA_VISIBLE_DEVICES est définie par défaut

Les pods demandant des ressources GPU via nvidia.com/gpu dans resources.limits ne sont pas affectés.

Le plug-in de périphérique NVIDIA et ack-gpu-exporter définissent tous deux NVIDIA_VISIBLE_DEVICES=all par défaut.

Solution :

• Contournement rapide : Recréez le pod d'application. Il s'agit d'une solution temporaire, car le problème peut se reproduire. Évaluez l'impact métier avant de procéder.

• Si le pod utilise NVIDIA_VISIBLE_DEVICES=all : Ajoutez privileged: true au champ securityContext du conteneur.

  Important

  L'octroi des permissions privileged introduit des risques de sécurité. Privilégiez la recréation du pod lorsque cela est possible.

  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

Empêcher la croissance continue du fichier /run/containerd/io.containerd.runtime.v2.task/k8s.io/<container ID>/log.json sur les nœuds GPU

Symptôme : Le fichier /run/containerd/io.containerd.runtime.v2.task/k8s.io/<container ID>/log.json augmente continuellement en taille et consomme de l'espace disque.

Environnement concerné : Nœuds dont la version de nvidia-container-toolkit est antérieure à la 1.16.2.

Cause : Des appels exec fréquents vers un conteneur — par exemple, issus d'une sonde exec — amènent le runtime de conteneur NVIDIA à écrire une entrée de journal informative à chaque appel.

Solution : Connectez-vous au nœud. Modifiez le niveau de journalisation de info à error et effacez le contenu des journaux existants.

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