如果 Google Kubernetes Engine (GKE) Pod 在要求 nvidia.com/gpu 資源時卡在 Pending 狀態，或節點無法註冊可用的 GPU，可能是 NVIDIA 驅動程式安裝或節點集區設定有問題。這些問題會導致工作負載無法存取所需的 GPU 硬體。
本文說明如何診斷及解決常見問題，避免 GKE 無法排定或執行 GPU 加速工作負載。瞭解如何驗證 GPU 驅動程式安裝作業、檢查 Pod 和節點記錄檔是否有錯誤，以及確認設定是否正確。
本文資訊適用於管理支援 GPU 的節點集區，且需要解決 NVIDIA 驅動程式問題的平台管理員和操作員，以及需要對卡住或無法啟動的 GPU 工作負載進行偵錯的應用程式開發人員。如要進一步瞭解 Google Cloud內容中提及的常見角色和範例工作，請參閱「常見的 GKE 使用者角色和工作」。
安裝 GPU 驅動程式
本節提供在 GKE 中自動安裝 NVIDIA 裝置驅動程式的疑難排解資訊。
Ubuntu 節點中的驅動程式安裝失敗
如果您使用的 Ubuntu 節點已連接 L4、RTX PRO 6000、H100 或 H200 GPU，GKE 安裝的預設 GPU 驅動程式可能不符合或高於這些 GPU 的必要版本。因此，GPU 裝置外掛程式 Pod 會卡在「Pending」(待處理) 狀態，這些節點上的 GPU 工作負載可能會發生問題。
如要解決這個問題，請參閱各 GPU 的操作說明：
L4 和 H100
如要解決 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
RTX PRO 6000
如要解決 RTX PRO 6000 GPU 的問題，請升級至下列任一 GKE 版本。這些版本會安裝 GPU 驅動程式 580 版做為預設驅動程式：
- 1.32.8-gke.1170000 以上版本
- 1.33.4-gke.1245000 以上版本
- 1.34.0-gke.1662000 以上版本
這項解決方案僅適用於具有一或多個 GPU 的 G4 機型。GPU 數量少於一個的 G4 機器類型不支援 Ubuntu 節點映像檔。
H200
如要解決 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 容器失敗，狀態為 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 位置。
如要進一步瞭解如何將 GPU 驅動程式版本對應至 GKE 版本，請參閱「將 GKE 版本和 Container-Optimized OS 節點映像檔版本對應至 GPU 驅動程式版本」。
錯誤：「容器映像檔 cos-nvidia-installer:fixed is not present with pull policy of Never.」或「容器映像檔 ubuntu-nvidia-installer:fixed is not present with pull policy of Never.」
如果 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 以上版本
如要進一步瞭解如何將 GPU 驅動程式版本對應至 GKE 版本，請參閱「將 GKE 版本和 Container-Optimized OS 節點映像檔版本對應至 GPU 驅動程式版本」。
如果節點執行 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 驅動程式映像檔遺失。這可能發生在使用暫時性本機 SSD 儲存空間的機密節點，或具備 GPU 的節點。在這種情況下，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 以上版本
錯誤：無法設定 GPU 驅動程式安裝目錄：無法建立 lib64 疊加層：無法建立目錄 /usr/local/nvidia/lib64：mkdir /usr/local/nvidia/lib64：不是目錄。
啟用 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 裝置。
下列錯誤表示 XID 62 和 RmInitAdapter 失敗，GPU 次要編號為 0：
Failed to get device for nvidia0: device nvidia0 not found.
NVIDIA 驅動程式 525.105.17 版有錯誤，可能導致通訊錯誤 (XID)，並使 GPU 無法正確初始化，導致 GPU 初始化失敗。
如要修正這個問題，請將 NVIDIA 驅動程式升級至 525.110.11 以上版本。
GPUDirect RDMA 問題
本節提供 GPUDirect RDMA 問題的疑難排解資訊。
錯誤：找不到網路 gIB 外掛程式
PyTorch 存放區中的 pytorch/pytorch:latest 映像檔不含 gIB 外掛程式所需的 Netlink 程式庫通訊協定套件 (libnl)。下列錯誤表示 gIB 外掛程式未載入，因為映像檔缺少 libnl 程式庫：
ncclInvalidUsage: Error: network gIB not found.
如要解決這個問題，請使用其他 Pytorch 基本映像檔，或手動將程式庫新增至容器。這個問題不限於任何機器類型。如要進一步瞭解如何使用 NCCL/gIB，請參閱「運用 NCCL/gIB 最佳化調整叢集網路」。
使用 Nvidia PyTorch 映像檔解決問題
如要修正這個問題，請使用 NVIDIA PyTorch 映像檔。如要查看最新版本，請參閱 PyTorch 版本資訊。
手動安裝以解決問題
如果無法遷移至其他映像檔基礎，也可以在容器映像檔中手動安裝 libnl 程式庫。
apt update -y && apt upgrade -y && apt install -y libnl-3-200 libnl-route-3-200
為確保工作負載容器中的 IBVerbs 程式庫一致，請使用更新後的 NCCL RDMA Installer DaemonSet，在容器路徑上安裝 gIB 外掛程式程式庫。
如要下載 DaemonSet 設定，請複製容器引擎加速器存放區：
cd
git clone https://github.com/GoogleCloudPlatform/container-engine-accelerators.git
在 tree/master/gpudirect-rdma 目錄下找到設定：
cd container-engine-accelerators/gpudirect-rdma
ls -l nccl-rdma-installer*
-rw-r----- 1 adelab primarygroup 2899 May 6 15:57 nccl-rdma-installer-a4x.yaml
-rw-r----- 1 adelab primarygroup 2743 Apr 30 00:34 nccl-rdma-installer-autopilot.yaml
-rw-r----- 1 adelab primarygroup 2677 May 6 15:57 nccl-rdma-installer.yaml
選擇下列其中一種安裝程式設定：
| 說明 | nccl-rdma-installer.yaml |
nccl-rdma-installer-a4x.yaml |
nccl-rdma-installer-autopilot.yaml |
|---|---|---|---|
| GKE 作業模式 | GKE Standard | GKE Standard | GKE Autopilot |
| 機型 | A4 和 A3 Ultra 機型 | A4X 機型 | A4 和 A3 Ultra 機型 |
| 命名空間 | 部署至 kube-system。 |
部署至 kube-system。 |
部署至專屬 rdma-system 命名空間 (因為 Autopilot 會限制對 kube-system 命名空間的修改)。 |
| 優先順序類別 | 使用 system-node-critical，確保安裝程式以高優先順序執行。 |
使用 system-node-critical。 |
無，(Autopilot 會限制使用系統層級的優先順序類別)。 |
| 函式 | 以 DaemonSet 的形式執行，並將 GPUDirect-TCPX (GIB) NCCL 外掛程式 (特別是 nccl-plugin-gib:v1.1.1) 安裝至 /home/kubernetes/bin/nvidia/lib64 和 /home/kubernetes/bin/gib 主機目錄。這種做法可為 GKE 節點上的 NCCL 提供高效能 RDMA 通訊。 |
與基本安裝程式類似，但會安裝 ARM64 編譯版本的 GPUDirect-TCPX (GIB) NCCL 外掛程式 (nccl-plugin-gib-arm64:v1.1.0)。此外，也包含 nvidia-gb200 和 arm64 的特定節點親和性，確保只在這些特定 GKE 節點上執行。 |
安裝 GPUDirect-TCPX (GIB) NCCL 外掛程式 (nccl-plugin-gib:v1.1.1)，但會進行修改，以支援 Autopilot 模式的安全性和作業模式：
|
套用 DaemonSet：
kubectl apply -f nccl-rdma-installer.yaml
將 GKE 版本和 Container-Optimized OS 節點映像檔版本對應至 GPU 驅動程式版本
如要找出與 GKE 版本和 Container-Optimized OS 節點映像檔版本對應的 GPU 驅動程式版本，請按照下列步驟操作：- 將 Container-Optimized OS 節點映像檔版本對應至 GKE 修補程式版本，找出特定 GKE 版本的 GPU 驅動程式版本。舉例來說，1.33.0-gke.1552000 使用 cos-121-18867-90-4。
- 在 Container-Optimized OS 版本資訊中，選擇 Container-Optimized OS 節點映像檔版本的里程碑。例如，為 cos-121-18867-90-4 選擇「Milestone 121」。
- 在特定里程碑的版本資訊頁面中，找出與特定 Container-Optimized OS 節點映像檔版本對應的版本資訊。舉例來說，在「Container-Optimized OS 版本資訊：里程碑 121」中，請參閱 cos-121-18867-90-4。在表格的「GPU Drivers」(GPU 驅動程式) 欄中，按一下「See List」(查看清單)，即可查看 GPU 驅動程式版本資訊。
在 GKE 1.36.0-gke.3302004 以上版本中，GKE 會自動將安裝的 NVIDIA 驅動程式版本，發布為執行中 GPU 節點的註解。如要查看 GPU 節點上的驅動程式版本註解，請執行下列指令：
kubectl get node GPU_NODE_NAME -o jsonpath='{.metadata.annotations}'
將 GPU_NODE_NAME 替換為 GPU 節點名稱。
輸出內容包含類似下列的註解：
{
"cloud.google.com/cuda.driver-version.full": "580.126.20",
"cloud.google.com/cuda.driver-version.major": "580",
"cloud.google.com/cuda.driver-version.minor": "126",
"cloud.google.com/cuda.driver-version.revision": "20"
}
nvidia-smi 指令失敗
在 GKE 中使用 GPU VM 執行工作負載時，容器中的 nvidia-smi 等指令可能會失敗，並顯示下列任一錯誤：
bash: nvidia-smi: command not found- 錯誤指出找不到
libnvidia-ml.so或其他 NVIDIA 程式庫。
GKE 會從容器的主機節點掛接必要的 NVIDIA 驅動程式和工具，通常位於 /usr/local/nvidia/ 路徑下。不過，容器的預設環境變數 (PATH 和 LD_LIBRARY_PATH) 可能不包含這些 NVIDIA 二進位檔和程式庫的路徑。
如要解決這些錯誤，請更新 Pod 或 Deployment 資訊清單，在容器的 PATH 和 LD_LIBRARY_PATH 環境變數中加入必要的 NVIDIA 路徑。
舉例來說，請將下列 env 區塊新增至 spec.template.spec.containers 規格：
spec:
containers:
- name: gpu-container
image: gpu-image
env:
- name: LD_LIBRARY_PATH
# Prepend NVIDIA lib64 directory to existing LD_LIBRARY_PATH
value: /usr/local/nvidia/lib64
- name: PATH
# Prepend NVIDIA bin directory to existing PATH
value: /usr/local/nvidia/bin:$PATH
# ... other container settings
標準叢集的客體 OS 重新啟動
本節說明如何使用 GKE，管理標準叢集節點上執行的訪客 OS 重新啟動作業。
如果 GKE 節點發生 Xid 或其他 GPU 問題，可能需要重新啟動。如需 Xid 問題範例，請參閱「Compute Engine Xid 處理」。
使用這個方法重新啟動客體 OS 時，會發生下列情況：
- 訪客 OS 已重設。
- GPU 已重設。
- 基礎執行個體不會變更，開機磁碟也會保留，但重新啟動後，開機 ID 會不同。
重新啟動作業約需五分鐘。這段時間不包含在 Pod 設定的終止寬限期內。如要進一步瞭解 Pod 生命週期和終止期限，請參閱「終止 Pod」。
需求條件
如要使用這個方法重新啟動訪客 OS，叢集必須執行 GKE 1.37.0-gke.3503000 以上版本。請勿在舊版觸發客體 OS 重新啟動，因為重新啟動完成後，GKE 可能無法在節點上排定工作負載。
重新啟動 GKE 節點上的訪客 OS
如要重新啟動 GKE 節點上的訪客 OS，請按照下列步驟操作：
找出要重新啟動的節點。
使用下列指令套用
cloud.google.com/perform-reboot=true標籤：kubectl label nodes NODE_NAME cloud.google.com/perform-reboot=true將
NODE_NAME替換為節點名稱。套用這個標籤後，GKE 會執行下列步驟，重新啟動訪客 OS：
- 限制節點。
- 驅逐 Pod，並遵循任何分配預算和終止寬限期。如要進一步瞭解如何設定這些終止行為，請參閱「設定 GKE 以妥善終止工作負載」
- 使用
systemd重新啟動節點。節點會關閉並重新啟動，且開機 ID 會變更。
前往節點事件，確認節點已成功重新啟動。
在 Google Cloud 控制台中，依序前往「Kubernetes Engine」>「Clusters」(叢集)。
選取要重新啟動的節點所在的叢集。
按一下「Nodes」(節點)，然後選取要重新啟動的節點。
按一下「事件」，查看節點事件頁面。
這個頁面會記錄節點事件。重新啟動程序成功時，會出現下列事件：
- 節點在重新啟動後啟動時。
- 維護處理常式移除
perform-reboot節點標籤時。 - 偵測到啟動 ID 變更時。
如果對執行 1.37.0-gke.3503000 之前版本的節點執行這些步驟，節點可能會在重新啟動完成後，保留 cloud.google.com/impending-node-termination 污點和 cloud.google.com/perform-reboot=true 標籤。節點處於 Ready 狀態，但無法執行工作負載。如要解決這個問題，請升級至 GKE 1.37.0-gke.3503000 以上版本。如要在不升級的情況下緩解這個問題，請執行下列指令，手動移除受影響節點的污點和標籤：
# Remove the perform-reboot label
kubectl label node NODE_NAME cloud.google.com/perform-reboot-
# Remove the boot ID annotation (might report "not found", which is expected)
kubectl annotate node NODE_NAME node.gke.io/reboot-boot-id-
# Remove the taint (might already be removed automatically, which is expected)
kubectl taint nodes NODE_NAME cloud.google.com/impending-node-termination:NoSchedule-
將 NODE_NAME 替換為卡住的節點名稱。
移除卡住狀態後，請等待至少 60 秒，讓維護處理常式偵測變更。除非叢集執行 1.37.0-gke.3503000 以上版本，否則請勿再次嘗試重新啟動客體 OS。
快速重新套用時，系統會忽略重新啟動標籤
在所有 GKE 版本中，如果您在重新啟動完成後 60 秒內重新套用 cloud.google.com/perform-reboot=true 標籤，維護處理常式可能會因內部狀態的競爭狀況，而不會對新標籤採取行動。節點會卡在 perform-reboot 標籤和 cloud.google.com/impending-node-termination 汙點，但不會重新啟動。
如要緩解這個問題，請在重新啟動完成後等待至少 60 秒，再重新套用 cloud.google.com/perform-reboot=true 標籤。您可以檢查節點是否已移除 perform-reboot 標籤和 reboot-boot-id 註解，確認重新啟動作業是否完成：
kubectl get node NODE_NAME -o jsonpath='{.metadata.labels.cloud\.google\.com/perform-reboot}'
kubectl get node NODE_NAME -o jsonpath='{.metadata.annotations.node\.gke\.io/reboot-boot-id}'
將 NODE_NAME 替換為節點名稱。
重新套用標籤前，這兩項指令都應傳回空白輸出內容。
如果節點已卡住，請手動移除導致卡住狀態的 Kubernetes 節點中繼資料：
移除
cloud.google.com/perform-reboot節點標籤：kubectl label node NODE_NAME \ cloud.google.com/perform-reboot-將
NODE_NAME替換為卡住的節點名稱。移除
node.gke.io/reboot-boot-id註解：kubectl annotate node NODE_NAME \ node.gke.io/reboot-boot-id-如果輸出內容為
not found，表示註解已移除。移除
cloud.google.com/impending-node-termination:NoSchedule污點：kubectl taint nodes NODE_NAME \ cloud.google.com/impending-node-termination:NoSchedule-如果輸出內容為
not found，表示已移除。請至少等候 60 秒。
重新套用
cloud.google.com/perform-reboot標籤：kubectl label node NODE_NAME \ cloud.google.com/perform-reboot=true
重設 A3 和 A4 VM 的 GPU
某些問題可能需要重設 A3 或 A4 VM 的 GPU。
注意：您也可以使用 gpu-reset-tool 重設所有 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替換為節點名稱。如果您已啟用 DCGM 指標，請變更驅動程式版本標籤，暫時停用節點上的 DCGM 匯出工具：
a. 請記下節點上
cloud.google.com/gke-gpu-driver-version標籤目前的值。b. 將標籤值變更為
reset，即可淘汰 DCGM 匯出工具 Pod：kubectl label node NODE_NAME \ cloud.google.com/gke-gpu-driver-version=reset --overwritePod 會自動遭到剔除，因為標籤必須是
default或latest。在 SSH 工作階段中重設 GPU：
重設 VM 上的所有 GPU
/home/kubernetes/bin/nvidia/bin/nvidia-smi --gpu-reset如要重設特定 GPU
# Identify the faulty GPU /home/kubernetes/bin/nvidia/bin/nvidia-smi # Reset the specifc GPU using either the GPU index or PCI bus ID from above command output /home/kubernetes/bin/nvidia/bin/nvidia-smi --gpu-reset -i <gpu_id>還原節點標籤，重新啟用 GPU 裝置外掛程式和 DCGM 匯出工具：
a. 重新啟用 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 \ --overwriteb. 還原
cloud.google.com/gke-gpu-driver-version標籤的原始值 (例如latest或default)，重新啟用 DCGM 匯出工具：kubectl label node NODE_NAME \ cloud.google.com/gke-gpu-driver-version=ORIGINAL_VALUE --overwrite
機密 GKE 節點上的 GPU
以下各節說明如何找出並修正機密 GKE 節點上執行的 GPU 問題。
GPU 工作負載未排定在機密 GKE 節點上
使用機密 GKE 節點時，您必須手動安裝與所選 GPU 類型和 GKE 版本對應的 GPU 驅動程式。如果 GPU Pod 未在機密 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 不支援機密 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 持續性 daemon 失敗時，就會發生這個錯誤。如果看到這則錯誤訊息，請重設執行個體：
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) 問題的疑難排解資訊。如果您使用的是受影響的 GKE 1.34 或 1.35 版，請一併參閱「GKE 已知問題」頁面。
版本資訊和升級操作說明
如果您是新使用者，請參閱「在 Standard 模式叢集中盡可能提高 GPU 網路頻寬」，瞭解如何使用 GPUDirect-TCPX(O)。現有使用者請參閱 GPUDirect-TCPXO 版本資訊，瞭解版本資訊和升級操作說明，因為新版本會持續發布。
GKE 版本升級後，tcpx-daemon 和 tcpxo-daemon 失敗
如果 tcpx-daemon 或 tcpxo-daemon Pod 失敗，您可能會遇到下列錯誤：
cuda error detected! name: CUDA_ERROR_NO_DEVICE; string: no CUDA-capable device is detected
另外，請檢查 kube-system 命名空間中的 device-injector Pod 是否處於 CrashLoopBackOff 或 Error 狀態。
如果將 GKE 節點集區升級至下列任一版本或更新版本，就會發生這個問題：
- GKE 1.31：1.31.14-gke.1033000
- GKE 1.32：1.32.9-gke.1575000
- GKE 1.33：1.33.5-gke.1862000
- GKE 1.34：1.34.1-gke.3225000
- GKE 1.35 以上版本
這個問題是因為使用舊版 NRI 裝置注入器資訊清單，其中包含名為 enable-nri 的 initContainer。在這些受影響的 GKE 版本中，節點設定預設會啟用 NRI。過時的 enable-nri 容器會嘗試修改設定並重新啟動容器執行階段，這與系統預設值衝突，導致 nri-device-injector Pod 停止運作。這項失敗會導致 GPU 裝置無法向 tcpx-daemon 或 tcpxo-daemon 容器公開。
如要解決這個問題，請將 nri-device-injector DaemonSet 更新至最新版本，移除衝突的 initContainer。
刪除現有的 DaemonSet：
kubectl delete daemonset device-injector -n kube-system套用最新資訊清單：
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nri_device_injector/nri-device-injector.yaml重新啟動工作負載 Pod。
使用 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 叢集，您可以使用拓撲感知調度 (TAS) 部署及執行 NCCL 測試。執行 NCCL 測試後，NCCL 會自動在所有參與節點上產生記錄。
收集所有節點的記錄。確認記錄包含下列資訊，驗證您已從所有節點收集 NCCL 記錄：
- 工作負載中所有 VM 的主機名稱。
- VM 上所有相關程序的 PID。
- 每個 VM 上工作負載使用的所有 GPU 排名。
如果不確定記錄檔的位置，以下範例說明當
NCCL_DEBUG_FILE變數設為/tmp/nccl_log.%h.%p時，NCCL 會在何處建立記錄檔。您有兩個 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 Customer Care 聯絡，建立客服案件。
- 在 StackOverflow 提問，並使用
google-kubernetes-engine標記搜尋類似問題，向社群尋求支援。您也可以加入#kubernetes-engineSlack 頻道，取得更多社群支援。 - 使用公開 Issue Tracker 提出問題或功能要求。