本頁面說明如何解決 Google Kubernetes Engine (GKE) 中的 GPU 相關問題。
安裝 GPU 驅動程式
本節提供 GKE 中自動安裝 NVIDIA 裝置驅動程式的疑難排解資訊。
Ubuntu 節點中的驅動程式安裝失敗
如果您使用附加 L4、H100 或 H200 GPU 的 Ubuntu 節點,GKE 安裝的預設 GPU 驅動程式可能不是這些 GPU 的必要版本,或版本較舊。因此,GPU 裝置外掛程式 Pod 會持續處於 Pending 狀態,而這些節點上的 GPU 工作負載可能會發生問題。
如要解決 L4 和 H100 GPU 的這個問題,建議升級至下列 GKE 版本,這些版本會安裝 GPU 驅動程式 535 版做為預設驅動程式:
- 1.26.15-gke.1483000 以上版本
- 1.27.15-gke.1039000 以上版本
- 1.28.11-gke.1044000 以上版本
- 1.29.6-gke.1073000 以上版本
- 1.30.2-gke.1124000 以上版本
或者,您也可以執行下列指令,手動安裝 535 以上版本的驅動程式:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R535.yaml
如要解決 H200 GPU 的這個問題,請執行下列指令,手動安裝 550 以上版本的驅動程式:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R550.yaml
GPU 裝置外掛程式失敗,並顯示 CrashLoopBackOff 錯誤
如果您在 2023 年 1 月 25 日前,在節點集區中使用手動安裝驅動程式的方法,之後將節點集區升級至支援自動安裝驅動程式的 GKE 版本,就會發生下列問題。兩個安裝工作負載會同時存在,並嘗試在節點上安裝衝突的驅動程式版本。
GPU 裝置外掛程式初始化容器失敗,並顯示 Init:CrashLoopBackOff
狀態。容器的記錄類似於下列內容:
failed to verify installation: failed to verify GPU driver installation: exit status 18
如要解決這個問題,請嘗試下列方法:
從叢集中移除手動安裝驅動程式的 DaemonSet。這會刪除衝突的安裝工作負載,並讓 GKE 自動在節點中安裝驅動程式。
kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml
將手動安裝驅動程式的 DaemonSet 資訊清單重新套用至叢集。我們已在 2023 年 1 月 25 日更新資訊清單,忽略使用自動安裝驅動程式的節點。
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml
為節點集區停用驅動程式自動安裝功能。更新作業完成後,現有的驅動程式安裝 DaemonSet 應會正常運作。
gcloud container node-pools update POOL_NAME \ --accelerator=type=GPU_TYPE,count=GPU_COUNT,gpu-driver-version=disabled \ --cluster=CLUSTER_NAME \ --location=LOCATION
更改下列內容:
POOL_NAME
:節點集區的名稱。GPU_TYPE
:節點集區已使用的 GPU 類型。GPU_COUNT
:已附加至節點集區的 GPU 數量。CLUSTER_NAME
:節點集區所在 GKE 叢集的名稱。LOCATION
:叢集的 Compute Engine 位置。
錯誤:「Container image cos-nvidia-installer:fixed is not present with pull policy of Never.」(容器映像檔 cos-nvidia-installer:fixed 不存在,提取政策為「永不」) 或「Container image ubuntu-nvidia-installer:fixed is not present with pull policy of Never.」(容器映像檔 ubuntu-nvidia-installer:fixed 不存在,提取政策為「永不」)
當 nvidia-driver-installer
Pod 處於 PodInitializing
狀態,且 GPU 外掛程式裝置或 GPU 驅動程式安裝程式 Pod 回報下列錯誤時,就會發生這個問題。具體錯誤訊息取決於節點上執行的作業系統:
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.
當垃圾收集器移除預先載入的 NVIDIA 驅動程式映像檔,以釋出節點空間時,就可能發生這個問題。如果重新建立驅動程式 Pod 或重新啟動容器,GKE 就無法找到預先載入的映像檔。
如要解決執行 COS 時的垃圾收集問題,請將 GKE 節點升級至下列其中一個包含修正措施的版本:
- 1.25.15-gke.1040000 以上版本
- 1.26.10-gke.1030000 以上版本
- 1.27.6-gke.1513000 以上版本
- 1.28.3-gke.1061000 以上版本
如果節點執行的是 Ubuntu,目前尚無法修正這個垃圾收集問題。如要在 Ubuntu 上解決這個問題,您可以執行與主機互動的具備權限容器,確保 NVIDIA GPU 驅動程式設定正確。如要這麼做,請從節點執行 sudo /usr/local/bin/nvidia-container-first-boot
,或套用下列資訊清單:
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
如果節點重新啟動或主機維護後,NVIDIA 驅動程式映像檔遺失,也可能導致這個問題。如果機密節點或搭載 GPU 的節點使用暫時性本機 SSD 儲存空間,就可能發生這種情況。在這種情況下,GKE 會在節點上預先載入 nvidia-installer-driver
容器映像檔,並在首次開機時將映像檔從開機磁碟移至本機 SSD。
如要確認是否發生主機維護事件,請使用下列記錄檔篩選器:
resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
log_id("cloudaudit.googleapis.com/system_event")
如要解決主機維護問題,請將 GKE 版本升級至下列其中一個版本:
- 1.27.13-gke.1166000 以上版本
- 1.29.3-gke.1227000 以上版本
- 1.28.8-gke.1171000 以上版本
Error: 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.
啟用 NCCL fastsocket 時,GPU 裝置外掛程式內的 GPU 驅動程式安裝程式容器會發生這項錯誤:
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.
這個問題只會發生在執行 GKE 1.28 和 1.29 的叢集和節點上。
這個問題是由 NCCL fastsocket 競爭條件與 GPU 驅動程式安裝程式所造成。
如要解決這個問題,請將 GKE 版本升級至下列其中一個版本:
- 1.28.8-gke.1206000 以上版本
- 1.29.3-gke.1344000 以上版本
詳情請參閱 GPUDirect-TCPXO 版本資訊。
錯誤:無法取得 nvidia0 的裝置,找不到裝置 nvidia0。
下列錯誤表示次要 0 的 GPU 發生 XID 62 和 RmInitAdapter 失敗:
Failed to get device for nvidia0: device nvidia0 not found.
NVIDIA 驅動程式 525.105.17 版有錯誤,可能會導致通訊錯誤 (XID),並阻礙 GPU 正常初始化,進而導致 GPU 初始化失敗。
如要修正這個問題,請將 NVIDIA 驅動程式升級至 525.110.11 以上版本。
重設 A3 VM 上的 GPU
某些問題可能需要重設 A3 VM 上的 GPU。
如要重設 GPU,請按照下列步驟操作:
從需要重設 GPU 的節點中,移除要求 GPU 資源的 Pod。
在節點上停用 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=true
將
NODE_NAME
替換為節點名稱。在 SSH 工作階段中重設 GPU:
/home/kubernetes/bin/nvidia/bin/nvidia-smi --gpu-reset
重新啟用 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
機密 GKE 節點上的 GPU
以下各節說明如何找出並修正在機密 GKE 節點上執行的 GPU 問題。
GPU 工作負載未排定至機密 GKE 節點
使用機密 GKE 節點時,您必須手動安裝與所選 GPU 類型和 GKE 版本相符的 GPU 驅動程式。如果 GPU Pod 未排定在 Confidential GKE 節點上,且仍處於 Pending
狀態,請說明驅動程式安裝 DaemonSet:
kubectl --namespace=kube-system get daemonset nvidia-driver-installer -o yaml
如果輸出內容傳回 NotFound
錯誤,請安裝驅動程式。
如果 DaemonSet 正在執行,輸出結果會與下列內容相似:
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
在輸出內容中,確認 nodeAffinity
欄位包含 cloud.google.com/gke-confidential-nodes-instance-type
鍵。如果輸出內容未包含這個金鑰,表示驅動程式安裝 DaemonSet 不支援 Confidential GKE 節點。
在機密 GKE 節點上部署支援 GPU 的 DaemonSet:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/cos/daemonset-confidential.yaml
安裝驅動程式後,請檢查 GPU 工作負載是否順利啟動。
錯誤:無法分配裝置向量
如果 GPU 容器記錄中顯示下列錯誤訊息,表示 GPU 已從節點 VM 執行個體中分離:
Failed to allocate device vector A (error code unknown error)!
硬體錯誤或加密金鑰問題都可能導致這種情況。
如要解決這個問題,請重新啟動節點執行個體。這項作業會造成中斷,並影響該節點上的所有工作負載。如要重新啟動執行個體,請按照下列步驟操作:
取得執行 GPU Pod 的節點名稱:
kubectl get pod POD_NAME -o yaml | grep "nodeName"
將
POD_NAME
替換為失敗的 Pod 名稱。輸出結果會與下列內容相似:
nodeName: gke-cluster-1-default-pool-b7asdfbt-fd3e
重設 Compute Engine 執行個體:
gcloud compute instances reset NODE_NAME
將
NODE_NAME
替換為上一步輸出內容中的節點名稱。gcloud CLI 會在有效專案中尋找具有該名稱的 VM。如果系統提示選取區域,請指定
Y
。確認 GPU 工作負載是否能順利執行。
錯誤:解密失敗,錯誤代碼為 -74
節點記錄中的下列錯誤訊息表示 GPU 的加密金鑰遺失:
Decryption failed with error -74
如果節點 VM 執行個體上執行的 NVIDIA 持續性精靈失敗,就會發生這個錯誤。如果看到這則錯誤訊息,請重設執行個體:
gcloud compute instances reset NODE_NAME
將 NODE_NAME
替換為失敗節點的名稱。
gcloud CLI 會在有效專案中尋找具有該名稱的 VM。如果系統提示選取區域,請指定 Y
。
如果重設執行個體無法解決這個問題,請與 Cloud Customer Care 團隊聯絡,或提交產品錯誤。詳情請參閱「取得支援」一文。
找出 XID 錯誤
gpu-device-plugin
daemonset 會在 kube-system
命名空間中執行,並負責下列事項:
- GPU 工作負載排程:將 GPU 資源分配給 Pod。
- GPU 健康狀態檢查:監控 GPU 的健康狀態。
- 收集 GPU 指標:收集與 GPU 相關的指標,例如工作週期和記憶體用量。
gpu-device-plugin
會使用 NVIDIA 管理程式庫 (NVML) 偵測 XID 錯誤。發生 XID 錯誤時,受影響節點上執行的 gpu-device-plugin
Pod 會記錄錯誤。您會看到兩種類型的 XID 錯誤記錄:
- 非重大 XID 錯誤:
- 記錄檔格式:
Skip error Xid=%d as it is not Xid Critical
- 意義:這些錯誤屬於非重大錯誤。這類問題可能是由各種軟體或硬體問題所致。
- 動作:GKE 不會針對非重大 XID 錯誤採取任何自動化動作。
- 記錄檔格式:
- 嚴重 XID 錯誤:
- 記錄檔格式:
XidCriticalError: Xid=%d, All devices will go unhealthy
- 意義:這些錯誤表示 GPU 硬體有問題。
- 動作:
- GKE 會將節點的 GPU 資源標示為健康狀態不良。
- GKE 會防止在節點上排定 GPU 工作負載。
- 如果啟用節點自動修復功能,GKE 會重新建立節點。
- 記錄檔格式:
GPUDirect-TCPX(O) 問題
本節提供 GPUDirect-TCPX(O) 問題的疑難排解資訊。
版本資訊和升級操作說明
如果是新使用者,請參閱「在標準模式叢集中盡量提高 GPU 網路頻寬」一文,瞭解如何使用 GPUDirect-TCPX(O)。對於現有使用者,請參閱 GPUDirect-TCPXO 版本發行說明,瞭解版本資訊和升級說明,因為新版本會持續發布。
使用 NCCL 記錄檔進行偵錯
如果無法解決 NCCL 問題,請收集包含偵錯資訊的 NCCL 記錄。這些記錄含有 NCCL 作業的重要資訊,可協助您找出問題來源。如果無法解決問題,請先收集這些記錄,再向 Cloud Customer Care 團隊提出案件。這些記錄可協助 Cloud Customer Care 快速解決問題。
如要產生及收集記錄,請完成下列步驟:
在 Pod 或應用程式資訊清單中設定下列環境變數:
NCCL_DEBUG=INFO NCCL_DEBUG_SUBSYS=INIT,NET,ENV,COLL,GRAPH NCCL_DEBUG_FILE=/DIRECTORY/FILE_NAME.%h.%p
如要進一步瞭解這些環境變數,請參閱「收集 NCCL 偵錯記錄」。
如要產生記錄資料,請執行 NCCL 測試。執行這項測試的方式取決於您使用的叢集類型。如果是 GKE 叢集,您可以部署及執行 NCCL 測試,並使用拓撲感知排程 (TAS)。執行 NCCL 測試後,NCCL 會自動在所有參與節點上產生記錄。
從所有節點收集記錄檔。確認您已從所有節點收集 NCCL 記錄,方法是確認記錄包含下列資訊:
- 參與工作負載的所有 VM 主機名稱。
- VM 上所有相關程序的 PID。
- 每個 VM 上工作負載使用的所有 GPU 等級。
如果不確定記錄檔的位置,請參閱下列範例,瞭解 NCCL 在
NCCL_DEBUG_FILE
變數設為/tmp/nccl_log.%h.%p
時建立記錄檔的位置。您有兩個 VM,分別命名為a3plus-vm-1
和a3plus-vm-2
,且每個 VM 在工作負載容器中執行八個程序。在這個情境中,NCCL 會在每個 VM 的工作負載容器中,於/tmp
目錄下建立下列記錄檔:- 在
a3plus-vm-1
上:八個名為nccl_log.a3plus-vm-1.PID
的記錄檔,其中PID
是程序 ID。 - 在
a3plus-vm-2
中:八個名為nccl_log.a3plus-vm-2.PID
的記錄檔。
查看記錄。NCCL 記錄項目採用以下格式:
HOSTNAME:PID:TID [RANK] NCCL_MESSAGE
這些記錄項目包含下列值:
HOSTNAME
:VM 的主機名稱。這個值會指出 NCCL 產生記錄項目時使用的 VM。PID
:PID。這個值會指出產生記錄項目的程序。TID
:執行緒 ID。這個值會指出 NCCL 產生記錄項目時,程序中使用的執行緒。RANK
:當地排名 ID。這個值會指出 NCCL 產生記錄項目時使用的 GPU。等級編號為 0 到 N,其中 N 是參與程序的 GPU 總數。舉例來說,如果您的工作負載在每個 VM 中執行八個 GPU,則每個 VM 應有八個不同的等級值 (0-7)。NCCL_MESSAGE
:說明訊息,提供事件的詳細資訊,並包含 NCCL 建立記錄的時間戳記。
例如:
gke-a3plus-mega-np-2-aa33fe53-7wvq:1581:1634 [1] NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.
這個範例具有下列值:
gke-a3plus-mega-np-2-aa33fe53-7wvq
:主機名稱。1581
:程序 ID。1634
:執行緒 ID。1
:當地排名 ID。NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.
:說明發生情況的訊息。
如果開啟支援案件,請將收集到的記錄檔和 NCCL 測試輸出內容封裝成 ZIP 檔案。向 Cloud Customer Care 提交客服案件時,請附上 ZIP 檔案。
如要停止收集 NCCL 偵錯記錄,請移除您在步驟 1 中新增的變數。
後續步驟
如果無法在說明文件中找到問題的解決方法,請參閱「取得支援」一文,尋求進一步的協助, 包括下列主題的建議:
- 與 Cloud 客戶服務聯絡,建立支援案件。
- 在 StackOverflow 上提問,並使用
google-kubernetes-engine
標記搜尋類似問題,向社群尋求支援。你也可以加入#kubernetes-engine
Slack 頻道,取得更多社群支援。 - 使用公開問題追蹤工具回報錯誤或提出功能要求。