全部產品
Search
文件中心

Container Service for Kubernetes:GPU FAQ

更新時間:Dec 25, 2025

本文介紹了GPU常見問題,包括效能最佳化、驅動安裝和故障排除等方面的詳細解答。

問題分類

描述

跳轉連結

GPU錯誤與故障排查

主要涉及GPU驅動、監控工具(如DCGM、Prometheus)、以及執行階段錯誤(如NVML初始化失敗、XID錯誤等)。

cGPU(容器化GPU)相關問題

主要涉及cGPU的配置、啟動、執行階段錯誤,以及與核心模組相關的許可權問題。

GPU節點與叢集管理

主要涉及叢集層面的操作,包括GPU卡的使用檢測、虛擬化支援、節點維護(如Kernel升級)、以及故障卡隔離等問題。

為什麼叢集中GPU ECC配置不統一?

ECC(Error-Correcting Code)模式通過檢測和糾正顯存錯誤,可提升GPU的穩定性和可靠性,但啟用該模式會略微降低可用顯存容量。

ECC模式選擇建議

  • 關閉ECC:適用於成本敏感和需要低延遲推理的情境(如線上即時推理)。

  • 開啟ECC:適用於對資料一致性和完整性有極高要求的應用(如資料庫伺服器、金融系統、科學計算及高效能運算HPC)。

基於以上原因,我們並未對ECC Mode進行統一初始化,因此叢集中GPU節點的ECC配置可能出現不統一的現象。

如何設定GPU節點的ECC模式?

  1. 執行以下命令,查看當前ECC模式的狀態。

    nvidia-smi 

    預期輸出:

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

    通過預期輸出可以看到,ECC列對應模式為0 ,表示已啟用ECC模式。若為Off,則表示已關閉ECC模式。

  2. 可通過以下命令,依據您的要求執行如下的開啟/關閉ECC Mode。

    • 開啟節點中所有GPU的ECC Mode。

      nvidia-smi -e 1
    • 關閉節點中所有GPU的ECC Mode。

      nvidia-smi -e 0
  3. 更換ECC模式後,需要重啟作業系統才會生效。

    重要

    確認必要的資料已儲存並根據需要重啟。

  4. 重啟後,再次使用 nvidia-smi 查看ECC模式的狀態,確保已啟用/關閉。已關閉ECC模式輸出如下:

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

阿里雲Container Service是否支援GPU虛擬化型(vGPU)執行個體?

vGPU執行個體需要購買NVIDIA官方提供的GRID License才能正常工作。如需使用vGPU執行個體,請先向NVIDIA購買GRID License並自建License伺服器。

阿里雲不提供License伺服器,即使建立了GPU虛擬化叢集,vGPU執行個體也無法直接使用,阿里雲Container Service控制台不再支援選擇vGPU執行個體作為叢集節點。

不支援的vGPU執行個體包括以ecs.vgn5i、ecs.vgn6i、ecs.vgn7i、ecs.sgn7i為首碼的ECS執行個體。如果需要使用vGPU執行個體,請向NVIDIA購買GRID License並自建License伺服器。

說明
  • 更新ACK叢集中vGPU執行個體的NVIDIA驅動License時,需要使用License伺服器。

  • 購買ECS執行個體並參考NVIDIA官網教程搭建License伺服器。更多資訊,請參見NVIDIA

如果您的License伺服器已經搭建完成,請參考以下步驟將vGPU執行個體加入ACK叢集。

將vGPU執行個體加入ACK叢集

  1. 請前往權益配額,申請開放自訂系統鏡像功能。

  2. 基於CentOS 7.X和Alibaba Cloud Linux 2製作自訂系統鏡像,鏡像中需要安裝NVIDIA GRID驅動並且正確配置GRID License。具體操作,請參見使用執行個體建立自訂鏡像在GPU虛擬化型執行個體中安裝GRID驅動(Linux)

  3. 建立節點池。具體操作,請參見建立和管理節點池

  4. 將vGPU執行個體加入到步驟3建立的節點池中,具體操作,請參見添加已有節點

後續相關步驟:更新ACK叢集中vGPU執行個體的NVIDIA驅動License

更新ACK叢集中vGPU執行個體的NVIDIA驅動License,具體操作,請參見更新ACK叢集中GPU虛擬化型(vGPU)執行個體的NVIDIA驅動License

如何在已有叢集的GPU節點上手動升級Kernel?

下面為您介紹如何在已有叢集的GPU節點上手動升級Kernel。

說明
  • 當kernel版本低於3.10.0-957.21.3時需升級。

  • 請確認需要升級的目標kernel版本,並謹慎操作。

  • 本文提供方案並不涉及kernel升級,僅針對在kernel升級的前提下對應的NVIDIA驅動升級。

  1. 將GPU節點設定為不可調度(本例以節點 cn-beijing.i-2ze19qyi8votgjz12345為例)。

    kubectl cordon cn-beijing.i-2ze19qyi8votgjz12345
    
    node/cn-beijing.i-2ze19qyi8votgjz12345 already cordoned
  2. 將要升級驅動的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. 卸載當前的NVIDIA驅動。

    說明

    本步驟中卸載的是版本為384.111的驅動包,如果您的驅動版本不是384.111,請在NVIDIA官網下載對應版本的驅動安裝包,並替換相應的版本號碼。

    1. 登入到該GPU節點,通過nvidia-smi查看驅動版本。

      sudo nvidia-smi -a | grep 'Driver Version'
      Driver Version                      : 384.111
    2. 下載NVIDIA驅動安裝包。

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

      需要在安裝包中卸載NVIDIA。

    3. 卸載當前NVIDIA驅動。

      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. 升級Kernel。

  5. 重啟GPU機器。

    sudo reboot
  6. 重新登入GPU節點,安裝對應的Kernel Devel。

    sudo yum install -y kernel-devel-$(uname -r)
  7. 請到NVIDIA官網下載和安裝您需要的NVIDIA驅動。本文以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. 查看/etc/rc.d/rc.local,確認其中是否包含以下配置,如果沒有請手動添加。

    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. 重啟kubelet和Docker。

    sudo service kubelet stop
    sudo service docker restart
    sudo service kubelet start
  10. 將這個GPU節點重新設定為可調度。

    kubectl uncordon cn-beijing.i-2ze19qyi8votgjz12345
    
    node/cn-beijing.i-2ze19qyi8votgjz12345 already uncordoned
  11. 在GPU節點上的Device Plugin Pod驗證版本。

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

    如果通過docker ps命令,發現GPU節點沒有容器被啟動,請參見修複GPU節點容器啟動問題

修複GPU節點容器啟動問題

在某些特定Kubernetes版本的GPU節點上,重啟Kubelet和Docker時,發現沒有容器被啟動。

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

執行以下命令,查看Docker的Cgroup Driver。

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

此時發現的Cgroup Driver類型是cgroupfs。

您可以按照以下操作,修複該問題。

  1. 備份/etc/docker/daemon.json,完成後,執行以下命令更新/etc/docker/daemon.json。

    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. 重啟Docker和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. 確認Docker的Cgroup Driver的類型為systemd。

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

裸金屬執行個體節點添加失敗怎麼辦?

由於裸金屬執行個體(ecs.ebmgn7)支援開啟MIG。為避免已有MIG設定對節點部署造成影響,系統會在該類型節點每一次添加進叢集時對已有的MIG設定進行重設。由於該類型執行個體的重設時間不定,可能會出現重設時間過長的情況,從而導致添加節點指令碼運行逾時添加節點失敗。

如果該系列節點添加失敗,請在節點宿主機上執行以下命令:

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

查看輸出結果中是否有以下報錯:

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

如果存在該報錯,說明添加節點失敗是由MIG的reset引起的。請重新添加該節點,詳細資料,請參見添加已有節點

Alibaba Cloud Linux 3運行GPU容器出現Failed to initialize NVML: Unknown Error的問題怎麼辦?

問題現象

在GPU容器內部執行nvidia-smi會出現如下報錯。

sudo nvidia-smi

Failed to initialize NVML: Unknown Error

問題原因

在Alibaba Cloud Linux 3上使用systemd時會有如下行為:在執行systemctl daemon-reloadsystemctl daemon-reexec等操作時,會更新cgroup相關配置,進而影響NVIDIA GPU裝置在容器中的正常使用。更詳細的資訊,請參見社區相關的issue167148

解決方案

如果出現上述問題,您可以參考如下情況描述和對應方法,結合自身業務要求,嘗試解決。

  • 情況一:如果您的應用Pod申請GPU資源的方式是通過為容器設定環境變數NVIDIA_VISIBLE_DEVICES=all實現,您可以評估能否給該應用程式容器添加一個privileged許可權,privileged許可權的添加可以參考以下樣本。

    apiVersion: v1
    kind: Pod
    metadata:
      name: test-gpu-pod
    spec:
      containers:
        - name: test-gpu-pod
          image: centos:7
          command:
          - sh
          - -c
          - sleep 1d
          securityContext: # 為容器添加privileged許可權
            privileged: true
  • 情況二:對於使用共用GPU調度的應用,目前建議使用Alibaba Cloud Linux 2或CentOS 7。

  • 情況三:重建該應用Pod。但在執行該操作前,您需要評估重建該應用Pod是否會對您的業務造成影響,並且該方案並不能保證重建後的Pod不會再出現該問題。

  • 情況四:如果以上情況都不適用,可以評估您的業務能否使用其他動作系統,例如:Alibaba Cloud Linux 2或者CentOS 7。

使用GPU時出現XID 119/XID 120錯誤導致GPU掉卡怎麼辦?

問題現象

使用GPU時出現GPU掉卡現象,例如在Linux系統上使用GPU時,出現GPU卡初始化失敗的錯誤提示。執行sh nvidia-bug-report.sh命令後,在產生的日誌中,可以看到XID 119或XID 120錯誤資訊。以XID 119報錯頁面為例,顯示如下:

123

說明

關於其他XID Errors的更多資訊,請參見NVIDIA Common XID Errors

問題原因

引起上述問題的原因可能是GPU的GSP(GPU System Processor)組件運行狀態異常,升級NVIDIA最新版本驅動後,如果GPU掉卡問題仍然會複現,則建議您關閉GSP功能。

說明

如果您想瞭解更多關於GSP功能的影響詳情,請參見開啟或關閉GSP功能的影響

解決方案

以下根據不同情境說明如何關閉GSP。

擴容新節點

您可以建立節點池或編輯已有節點池的配置,在進階配置中為節點池配置標籤ack.aliyun.com/disable-nvidia-gsp=true。後續擴容新節點時,ACK會自動在該節點上設定關閉GSP所需的配置。

操作入口和節點池配置項說明,請參見建立和管理節點池

image

說明

關閉GSP相關步驟可能會造成擴容節點的時延增加。

添加已有節點

  1. 您可以建立節點池或編輯待添加節點的節點池的配置,在進階配置中為節點池配置標籤ack.aliyun.com/disable-nvidia-gsp=true。已有節點添加到節點池中後,ACK會自動在該節點上設定關閉GSP所需的配置。

    操作入口和節點池配置項說明,請參見建立和管理節點池

    image

    說明

    關閉GSP相關步驟可能會造成添加節點到叢集的時延增加。

  2. 將已有節點添加至節點池。操作入口和相關注意事項,請參見添加已有節點

管理叢集中已有節點

您可以通過以下方式在已有節點中關閉GSP。

通過節點池標籤方式關閉GSP

  1. 為節點所在節點池配置標籤ack.aliyun.com/disable-nvidia-gsp=true

    操作入口和節點池配置項說明,請參見編輯節點池

    image

  2. 將該節點移除叢集,但不釋放ECS。具體操作,請參見移除節點

  3. 以添加已有節點的方式將已移除的節點重新添加到叢集中。操作入口和相關注意事項,請參見添加已有節點

登入節點手動執行關閉GSP

如果您的節點無法通過移除叢集再添加到叢集方式來關閉GSP,那麼您可以登入節點,手動執行關閉GSP的步驟。具體操作,請參見常見問題

說明

NVIDIA驅動在510版本引入了GSP。例如,如果您需要登入節點,手動將驅動由470升級至525版本,那麼您在470版本時無需關閉GSP,但升級至525版本後,有可能會觸發GSP缺陷。請在升級驅動完成後,參見常見問題手動執行關閉GSP的步驟。

如何手動隔離叢集中的故障卡?

在使用共用GPU調度時,叢集中可能會出現壞卡導致任務運行失敗的情況。為防止重啟後的任務再次調度到壞卡上導致重複失敗,您可以手動標記壞卡,調度器將不再使用該卡,從而實現故障隔離。

說明
  • 使用該功能之前,請確認您的調度器版本以及叢集版本滿足以下要求。

    • 1.24及以上版本叢集,調度器版本不低於1.xx.x-aliyun-6.4.3.xxx。

    • 1.22版本叢集,調度器版本不低於1.22.15-aliyun-6.2.4.xxx。

  • 叢集已使用共用GPU調度

您可以通過向叢集中提交一個特殊的ConfigMap的方式來標記故障GPU,參考以下樣本:

apiVersion: v1
kind: ConfigMap
metadata:
  name: <node-name>-device-status   # 替換 <node-name>為實際的節點名。
  namespace: kube-system
data:
  devices: |
    - deviceId: 0          #執行nvidia-smi擷取GPU序號
      deviceType: gpu
      healthy: false

ConfigMap應在kube-system命名空間中,且命名應當為故障卡所在的節點名加上-device-status尾碼。datadeviceId為通過nvidia-smi擷取的GPU序號,deviceTypegpuhealthyfalse。提交配置後,調度器將隔離對應GPU卡。

運行GPU容器出現Failed to initialize NVML: Unknown Error的問題怎麼辦?

問題現象

若您節點作業系統為Ubuntu 22.04或Red Hat Enterprise Linux(RHEL) 9.3 64位時,在GPU容器內部執行nvidia-smi可能會出現如下報錯。

sudo nvidia-smi

Failed to initialize NVML: Unknown Error

問題原因

在節點上執行systemctl daemon-reloadsystemctl daemon-reexec等操作後,會更新cgroup相關配置,進而影響NVIDIA GPU裝置在容器中的正常使用。

通過以下幾種方式為Pod申請GPU資源將會受影響:

  • 在Pod的resources.limits中指定aliyun.com/gpu-mem資源。

  • 在Pod中為容器設定環境變數NVIDIA_VISIBLE_DEVICES,以便Pod能夠訪問節點上的GPU資源。

  • Pod所使用的容器鏡像在製作時預設設定NVIDIA_VISIBLE_DEVICES的環境變數,且Pod希望訪問節點GPU資源。

說明
  • 在Pod的resources.limits中指定資源nvidia.com/gpu申請GPU資源不會受影響。

  • NVIDIA Device Plugin組件及ack-gpu-exporter組件會為Pod預設配置環境變數NVIDIA_VISIBLE_DEVICES=all

解決方案

  • 您可以通過重建該應用Pod的方式來臨時修複此問題。在執行該操作前,請評估重建該應用Pod是否會對您的業務造成影響。若問題重複出現,則需要您再次重建Pod。

  • 如果您的應用Pod通過將環境變數NVIDIA_VISIBLE_DEVICES=all的方式來申請GPU資源時。您可以為該應用程式容器添加privileged許可權,樣本配置如下:

    重要

    privileged許可權本身存在一定安全風險,也可重建該應用Pod,重建Pod僅為臨時修複,無法避免問題複發。

    apiVersion: v1
    kind: Pod
    metadata:
      name: test-gpu-pod
    spec:
      containers:
        - name: test-gpu-pod
          image: centos:7
          command:
          - sh
          - -c
          - sleep 1d
          securityContext: # 為容器添加privileged許可權
            privileged: true

如何解決GPU節點上/run/containerd/io.containerd.runtime.v2.task/k8s.io/<容器ID>/log.json檔案不斷增大問題?

問題現象

GPU節點上/run/containerd/io.containerd.runtime.v2.task/k8s.io/<容器ID>/log.json檔案不斷增大。

問題分析

前提條件:節點nvidia-container-toolkit版本低於1.16.2。

問題原因:GPU節點上存在頻繁調用容器exec操作(例如Pod配置了exec探針),每次調用容器exec操作時,nvidia container runtime會列印info層級的日誌。

影響結果:導致/run/containerd/io.containerd.runtime.v2.task/k8s.io/<容器ID>/log.json檔案持續增大,佔用磁碟空間。

解決方案

登入節點執行如下指令碼:

#!/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
    # nvidia-container-runtime配置中的記錄層級由原本的info切換為"error"
	sed -i 's@^log-level = "info"@log-level = "error"@g' $CONFIG
    # 清空容器的log.json內容
	find $CONTAINER_ROOT_PATH -mindepth 2 -maxdepth 2 -name log.json -type f -exec sh -c 'echo "" > "{}"' \;
fi