動(dòng)到device-plugin的完整實(shí)戰(zhàn))
把昇騰 NPU 接進(jìn) Kubernetes這句話聽(tīng)起來(lái)就是一行需求但實(shí)際上背后藏著一整條軟件鏈驅(qū)動(dòng)、CANN、Ascend Docker Runtime、device-plugin再加上監(jiān)控。任何一個(gè)環(huán)節(jié)沒(méi)對(duì)上NPU 在容器里就是“看不見(jiàn)、摸不著、調(diào)度不了”。最近在 CubeStudio 這套環(huán)境里完整跑了一遍昇騰基礎(chǔ)部署從裸機(jī)裝驅(qū)動(dòng)一直到 K8s 里跑通多卡訓(xùn)練中間踩了不少坑也把整條鏈路的邏輯徹底捋順了。這篇就按實(shí)操順序把步驟、原理和排查經(jīng)驗(yàn)一次講清楚適合正在做昇騰 NPU 容器化接入、或者準(zhǔn)備在企業(yè) K8s 集群里納管異構(gòu)算力的朋友參考。1. 昇騰 NPU 接入 Kubernetes 的整體思路1.1 容器要“看見(jiàn)” NPU繞不開(kāi)這三件事很多人第一次接觸這個(gè)需求時(shí)會(huì)覺(jué)得K8s 里調(diào)度 CPU、內(nèi)存這么成熟把 NPU 加進(jìn)去不就是多一種資源嗎實(shí)際上沒(méi)那么簡(jiǎn)單。Kubernetes 默認(rèn)認(rèn)識(shí)的資源只有 CPU 和內(nèi)存GPU 是依靠 device-plugin 以 Extended Resource 的形式上報(bào)給 kubelet再由調(diào)度器感知和分配的。昇騰 NPU 走的是同一個(gè)機(jī)制但底下的硬件和軟件棧比 GPU 更特殊一點(diǎn)。要讓容器真正用上昇騰 NPU必須解決三件事。第一件是系統(tǒng)層面能不能看見(jiàn)設(shè)備。昇騰 NPU 在宿主機(jī)上體現(xiàn)為/dev/davinci0、/dev/davinci1這類(lèi)設(shè)備節(jié)點(diǎn)外加一個(gè)/dev/davinci_manager管理設(shè)備。這些設(shè)備由驅(qū)動(dòng)程序創(chuàng)建驅(qū)動(dòng)沒(méi)裝好一切免談。第二件是容器層面能不能訪問(wèn)設(shè)備。即使宿主機(jī)能看到設(shè)備容器默認(rèn)是隔離的你必須在創(chuàng)建容器時(shí)把設(shè)備文件、驅(qū)動(dòng)目錄、CANN 相關(guān)庫(kù)都掛載進(jìn)去并且配置好運(yùn)行時(shí)環(huán)境。這一步在昇騰體系里由 Ascend Docker Runtime 自動(dòng)完成。第三件是調(diào)度層面能不能按卡分配。K8s 調(diào)度器不知道davinci0是什么東西需要 device-plugin 把節(jié)點(diǎn)上的 NPU 資源數(shù)量上報(bào)給 kubelet并負(fù)責(zé)在 Pod 啟動(dòng)時(shí)把具體的設(shè)備列表交出去。三件事環(huán)環(huán)相扣任何一層斷了都會(huì)表現(xiàn)為“資源有了但容器里用不了”或者“節(jié)點(diǎn)上明明有卡但調(diào)度不上去”。1.2 軟件棧分工驅(qū)動(dòng)、CANN、Runtime 與 device-plugin 各管一段整條鏈路可以拆成四個(gè)軟件角色它們各管一段職責(zé)非常清晰但都是缺一不可的。表格里列一下方便對(duì)照組件作用出問(wèn)題時(shí)的典型現(xiàn)象固件與驅(qū)動(dòng)初始化 NPU 硬件創(chuàng)建/dev/davinci*設(shè)備節(jié)點(diǎn)提供npu-smi工具宿主機(jī)npu-smi info報(bào)錯(cuò)找不到設(shè)備CANN Toolkit提供算子庫(kù)、圖編譯、運(yùn)行時(shí)等開(kāi)發(fā)能力類(lèi)似 CUDA 在 NVIDIA 體系里的位置訓(xùn)練時(shí)報(bào)算子不兼容、庫(kù)文件找不到Ascend Docker RuntimeDocker/containerd 創(chuàng)建容器時(shí)自動(dòng)注入 NPU 設(shè)備、驅(qū)動(dòng)庫(kù)和 CANN 環(huán)境變量容器內(nèi)沒(méi)有/dev/davinci*npu-smi無(wú)法執(zhí)行device-plugin向 kubelet 上報(bào)huawei.com/Ascend910等擴(kuò)展資源支持調(diào)度與設(shè)備分配節(jié)點(diǎn)資源數(shù)為 0Pod 調(diào)度失敗或分配不到設(shè)備以我實(shí)際部署的感受來(lái)說(shuō)最容易翻車(chē)的不是驅(qū)動(dòng)本身而是 Runtime 和 device-plugin 之間的配合。因?yàn)?Runtime 管的是“容器起來(lái)時(shí)設(shè)備在不在”device-plugin 管的是“這個(gè) Pod 被調(diào)度到節(jié)點(diǎn)后容器該用哪張卡”。如果只裝了 device-plugin 沒(méi)配 Runtime調(diào)度能成功但容器進(jìn)去發(fā)現(xiàn)/dev/davinci0不存在訓(xùn)練直接啟動(dòng)失敗而且報(bào)錯(cuò)信息還很不直觀。1.3 為什么用 CubeStudio 來(lái)做這套基礎(chǔ)部署CubeStudio 在我們的環(huán)境里是一個(gè)統(tǒng)一管理昇騰算力資源和部署流程的平臺(tái)它把所有碎片化的操作收斂成了可復(fù)用的流程。剛剛接觸昇騰 K8s 接入時(shí)可以完全靠手搓命令但如果集群規(guī)模變大、節(jié)點(diǎn)變多每次都去 SSH 到每臺(tái)機(jī)器上裝驅(qū)動(dòng)、改配置顯然不現(xiàn)實(shí)。CubeStudio 的價(jià)值在于把“節(jié)點(diǎn)納管 - 驅(qū)動(dòng)安裝 - Runtime 配置 - device-plugin 部署 - 監(jiān)控接入”串成一條標(biāo)準(zhǔn)的部署流水線任何新節(jié)點(diǎn)加入后能快速?gòu)?fù)制環(huán)境。當(dāng)然平臺(tái)只是把操作標(biāo)準(zhǔn)化了底層每一步的原理還是得搞清楚。下面所有實(shí)操內(nèi)容都是我在裸機(jī)環(huán)境下先手工驗(yàn)證過(guò)一遍再固化成 CubeStudio 里的部署流程的。接下來(lái)按順序拆解。2. 環(huán)境準(zhǔn)備與版本配套檢查2.1 硬件形態(tài)與操作系統(tǒng)選擇昇騰 NPU 的產(chǎn)品形態(tài)比較多。如果是 Atlas 300I/300T 推理卡通常是 PCIe 插卡插在通用服務(wù)器上如果是 Atlas 800 訓(xùn)練服務(wù)器一般是整機(jī)交付里面有多張昇騰芯片。不管哪種形態(tài)對(duì) Kubernetes 接入來(lái)說(shuō)看到的都是/dev/davinci*設(shè)備只是數(shù)量不同。操作系統(tǒng)方面昇騰官方支持的主要是 Ubuntu、openEuler、CentOS 等常見(jiàn)發(fā)行版但要注意 CPU 架構(gòu)。昇騰服務(wù)器大多是aarch64ARM 架構(gòu)也有少數(shù) x86 平臺(tái)驅(qū)動(dòng)包和 CANN 包都是分架構(gòu)的下載時(shí)一定要選對(duì)。我第一次部署時(shí)誤下了 x86 的 CANN 包在 aarch64 機(jī)器上直接提示架構(gòu)不匹配浪費(fèi)了不少時(shí)間。Kubernetes 版本建議選 1.26 以上的穩(wěn)定版因?yàn)樾掳?K8s 對(duì)擴(kuò)展資源的調(diào)度、設(shè)備插件的接口更成熟。如果集群還是用 Docker cri-dockerd 的舊模式或者已經(jīng)切換到 containerdRuntime 的配置方式會(huì)略有不同這個(gè)后面會(huì)單獨(dú)說(shuō)。2.2 版本配套關(guān)系是最大的隱形坑昇騰軟件體系的版本配套關(guān)系非常嚴(yán)格這是新手最容易踩的坑。驅(qū)動(dòng)、固件、CANN 三者必須滿足官方配套表的要求不是說(shuō)“驅(qū)動(dòng)是最新的就行”。比如某張訓(xùn)練卡固件需要 X 版本驅(qū)動(dòng)需要 Y 版本CANN 需要 Z 版本三者搭錯(cuò)一個(gè)輕則告警重則設(shè)備直接掛掉。我整理了部署前必查的幾項(xiàng)信息硬件型號(hào)npu-smi info能夠輸出芯片型號(hào)、固件版本、驅(qū)動(dòng)版本前提是驅(qū)動(dòng)已經(jīng)裝好。固件版本如果卡是全新的需要先刷固件再裝驅(qū)動(dòng)。CANN 版本工具包分為cann-toolkit、cann-kernels等一定要和驅(qū)動(dòng)版本、昇騰芯片匹配。torch_npu / MindSpore 版本后續(xù)要跑訓(xùn)練框架的話框架版本和 CANN 版本也要對(duì)齊。昇騰社區(qū)官網(wǎng)有“軟件配套表”里面有非常詳細(xì)的版本矩陣。我的建議是先確定要用什么訓(xùn)練框架PyTorch 還是 MindSpore再根據(jù)框架要求的 CANN 版本反推驅(qū)動(dòng)和固件版本這樣最不容易出錯(cuò)。2.3 安裝前三條硬檢查在開(kāi)始安裝之前我會(huì)強(qiáng)制自己在每臺(tái)節(jié)點(diǎn)上做三件事。第一確認(rèn)系統(tǒng)干凈。如果有舊版驅(qū)動(dòng)殘留直接用./Ascend-hdk-*.run --uninstall卸載干凈或者用npu-smi info看看是否已經(jīng)能識(shí)別設(shè)備。強(qiáng)行覆蓋安裝偶爾能成功但容易留下版本殘留。第二確認(rèn)內(nèi)核頭文件齊全。昇騰驅(qū)動(dòng)安裝時(shí)會(huì)編譯內(nèi)核模塊需要當(dāng)前內(nèi)核對(duì)應(yīng)的 kernel-devel 或 linux-headers 包。很多節(jié)點(diǎn)裝完系統(tǒng)后內(nèi)核升級(jí)過(guò)但頭文件沒(méi)跟上驅(qū)動(dòng)裝到一半就報(bào)編譯失敗。第三確認(rèn) BIOS 和 PCIe 狀態(tài)。用lspci | grep -i ascend或lspci | grep -i huawei看設(shè)備是否存在如果看不到設(shè)備先排查硬件插槽、PCIe 鏈路而不是急著裝軟件。這三條檢查五分鐘就能做完但能省下后面半小時(shí)的排錯(cuò)時(shí)間。3. 驅(qū)動(dòng)與 CANN 安裝實(shí)操3.1 安裝固件和驅(qū)動(dòng)在昇騰網(wǎng)站上按硬件型號(hào)和操作系統(tǒng)下載好固件包和驅(qū)動(dòng)包之后安裝命令很簡(jiǎn)單都是.run包執(zhí)行。以 Atlas 訓(xùn)練卡為例命令大致是# 安裝固件 ./Ascend-hdk-910b-firmware_6.3.3_linux-aarch64.run --full --quiet # 安裝驅(qū)動(dòng) ./Ascend-hdk-910b-npu-driver_23.0.rc3_linux-aarch64.run --full --quiet注意不同型號(hào)的包名不一樣910b只是示例。--full表示完整安裝--quiet表示靜默模式不給交互提示。裝完驅(qū)動(dòng)之后執(zhí)行npu-smi info如果能看到類(lèi)似下面的輸出說(shuō)明驅(qū)動(dòng)和固件已經(jīng)正常工作------------------------------------------------------------------------------------ | npu-smi 23.0.rc3 Version: 23.0.rc3 | -------------------------------------------------------------------------------------- | NPU Name | Health | Power(W) Temp(C) Hugepages-Usage(page)| | Chip | Bus-Id | AICore(%) Memory-Usage(MB) HBM-Usage(MB) | | 0 | OK | ...如果這里就報(bào)錯(cuò)先不要繼續(xù)往后走一定是驅(qū)動(dòng)或固件有問(wèn)題。3.2 驗(yàn)證驅(qū)動(dòng)并安裝 CANN Toolkit驅(qū)動(dòng)裝好之后npu-smi能看到卡只能說(shuō)明設(shè)備節(jié)點(diǎn)有了。接下來(lái)要裝 CANN Toolkit這是讓上層框架PyTorch、MindSpore能夠調(diào)用 NPU 算力的關(guān)鍵。CANN 的安裝包同樣是.run格式./Ascend-cann-toolkit_8.0.RC1_linux-aarch64.run --install安裝完成之后需要把環(huán)境變量加到 shell 配置里CANN 的set_env.sh腳本會(huì)幫你一次性配好所有路徑source /usr/local/Ascend/ascend-toolkit/set_env.sh建議把這一行寫(xiě)到/etc/profile或每個(gè)用戶的.bashrc里否則每次登錄都要手動(dòng) source。對(duì)容器場(chǎng)景來(lái)說(shuō)這個(gè)環(huán)境變量實(shí)際上不是由宿主機(jī)傳遞的而是由 Ascend Docker Runtime 在容器啟動(dòng)時(shí)注入的所以宿主機(jī)的環(huán)境變量配置主要用于裸機(jī)驗(yàn)證。3.3 驅(qū)動(dòng)、CANN 裝完后先做一次裸機(jī)驗(yàn)證很多人裝完 CANN 就直接跳到 K8s 環(huán)節(jié)這是不對(duì)的。至少要花五分鐘在宿主機(jī)上確認(rèn)“裸機(jī)可以調(diào)用 NPU”。最簡(jiǎn)單的驗(yàn)證是跑一個(gè) Python 腳本確認(rèn) torch_npu 能正常裝載并識(shí)別設(shè)備import torch import torch_npu print(torch.npu.device_count()) print(torch.npu.get_device_name(0))如果輸出正常的設(shè)備數(shù)量和名稱(chēng)說(shuō)明驅(qū)動(dòng)、CANN、torch_npu 三者已經(jīng)打通。這時(shí)候再去接容器化和 K8s排錯(cuò)范圍會(huì)小很多。我踩過(guò)一個(gè)教訓(xùn)當(dāng)時(shí)直接上了容器出了問(wèn)題排查了半天最后發(fā)現(xiàn)是宿主機(jī)裸機(jī)環(huán)境下 CANN 版本和 torch_npu 不匹配。如果先做裸機(jī)驗(yàn)證問(wèn)題在第一步就暴露了。4. Ascend Docker Runtime 接入容器運(yùn)行時(shí)4.1 Ascend Docker Runtime 到底做了什么昇騰的 Ascend Docker Runtime 在角色上很像 NVIDIA Container Toolkit。它的原理是Docker 創(chuàng)建容器時(shí)可以通過(guò)--runtime參數(shù)指定一個(gè)自定義 OCI Runtime這個(gè) Runtime 在真正啟動(dòng)容器進(jìn)程之前會(huì)把宿主機(jī)上的/dev/davinci*設(shè)備、驅(qū)動(dòng)目錄、CANN 庫(kù)目錄以及環(huán)境變量注入到容器里。所以它本質(zhì)上不是“讓 NPU 變快”的組件而是“讓容器看見(jiàn) NPU”的組件。如果沒(méi)配置 Runtime即使設(shè)備節(jié)點(diǎn)存在容器內(nèi)的 namespace 也看不到這些設(shè)備文件自然無(wú)法訪問(wèn)。安裝 Ascend Docker Runtime 很簡(jiǎn)單把包解壓到宿主機(jī)目錄然后配置 Docker。解壓后的目錄通常包含一個(gè)ascend-docker-runtime可執(zhí)行文件這就是我們要掛到 Docker 里的 Runtime。4.2 Docker 運(yùn)行時(shí)配置對(duì)于使用 Docker 作為容器運(yùn)行時(shí)的情況需要修改/etc/docker/daemon.json。這里有個(gè)細(xì)節(jié)昇騰官方提供的安裝腳本有時(shí)候會(huì)直接幫你把配置寫(xiě)好但也有時(shí)候只解壓文件。手動(dòng)配置的話格式如下{ runtimes: { ascend: { path: /usr/local/Ascend/Ascend-Docker-Runtime/ascend-docker-runtime, runtimeArgs: [] } } }配置完成后重啟 Dockersystemctl restart docker docker info | grep -A5 Runtimes如果配置正確docker info的 Runtimes 列表里會(huì)出現(xiàn)ascend。在測(cè)試階段建議先手動(dòng)跑一個(gè)容器看看設(shè)備是否注入成功docker run --rm --runtimeascend -it \ ascendhub.huawei.com/public/ascend-mindspore:latest \ npu-smi info容器里能看到 NPU 信息說(shuō)明 Runtime 生效了。4.3 containerd 場(chǎng)景下的配置如果你的 K8s 集群用的是 containerd現(xiàn)在主流版本基本都是不能只配 Docker還需要把昇騰 Runtime 接入 containerd。containerd 的配置在/etc/containerd/config.toml需要在 CRI 插件下面增加 runtime 配置。大致的配置段如下實(shí)際操作時(shí)版本不同格式會(huì)稍有差異[plugins.io.containerd.grpc.v1.cri.containerd.runtimes.ascend] runtime_type io.containerd.runc.v2 runtime_path /usr/local/Ascend/Ascend-Docker-Runtime/ascend-docker-runtime改完以后重啟 containerdsystemctl restart containerd這里要特別提醒K8s 1.24 版本之后默認(rèn)不再支持 Docker 作為運(yùn)行時(shí)除非額外部署 cri-dockerd所以新集群幾乎都是 containerd配置好 containerd 的 Runtime 是必須做的一步。有些部署文檔只寫(xiě)了 Docker 而沒(méi)寫(xiě) containerd照著做就會(huì)卡在容器起不來(lái)。4.4 驗(yàn)證容器內(nèi) NPU 是否可見(jiàn)Runtime 配完后除了用docker run --runtimeascend驗(yàn)證還要驗(yàn)證 containerd 環(huán)境下是否也能自動(dòng)注入?？梢酝ㄟ^(guò)crictl工具創(chuàng)建一個(gè)測(cè)試容器或者直接跳到下一步用 K8s 的 Pod 來(lái)驗(yàn)證。我的經(jīng)驗(yàn)是越早驗(yàn)證容器層后面 device-plugin 出問(wèn)題時(shí)就越容易定位是調(diào)度問(wèn)題還是運(yùn)行時(shí)問(wèn)題。有一個(gè)細(xì)節(jié)要留神如果容器內(nèi)的鏡像沒(méi)有安裝npu-smi工具即使設(shè)備注入成功你也無(wú)法用npu-smi info檢驗(yàn)。所以驗(yàn)證鏡像要選昇騰官方帶工具的鏡像或者自己在基礎(chǔ)鏡像里拷貝一份驅(qū)動(dòng)下的npu-smi可執(zhí)行文件。5. device-plugin 部署與資源調(diào)度驗(yàn)證5.1 Extended Resource 機(jī)制K8s 怎么知道節(jié)點(diǎn)有 NPUK8s 官方留給異構(gòu)設(shè)備接入的標(biāo)準(zhǔn)接口是 device plugin 框架。device-plugin 是一個(gè)運(yùn)行在節(jié)點(diǎn)上的 gRPC 服務(wù)kubelet 啟動(dòng)時(shí)會(huì)去/var/lib/kubelet/device-plugins/目錄下尋找 Unix socket然后通過(guò)這個(gè) socket 和 device-plugin 通信。device-plugin 需要做兩件事第一向 kubelet 上報(bào)這個(gè)節(jié)點(diǎn)上有多少?gòu)?NPU 卡這個(gè)數(shù)字會(huì)體現(xiàn)在節(jié)點(diǎn)的allocatable里第二當(dāng) Pod 被調(diào)度到該節(jié)點(diǎn)后kubelet 會(huì)拿著 Pod 請(qǐng)求的資源數(shù)量問(wèn) device-plugin 要具體的設(shè)備 IDdevice-plugin 返回/dev/davinci0、/dev/davinci1這樣的設(shè)備列表和對(duì)應(yīng)的驅(qū)動(dòng)掛載信息。昇騰體系里擴(kuò)展資源的名稱(chēng)一般是huawei.com/Ascend910或者h(yuǎn)uawei.com/Ascend310取決于芯片型號(hào)。Pod 的 YAML 里只要寫(xiě)上resources: requests: huawei.com/Ascend910: 1 limits: huawei.com/Ascend910: 1調(diào)度器在看到這類(lèi)資源請(qǐng)求時(shí)就會(huì)自動(dòng)把 Pod 分配到有對(duì)應(yīng)資源的節(jié)點(diǎn)上。5.2 部署 Ascend device-plugin昇騰的 device-plugin 是以 DaemonSet 形式部署的也就是說(shuō)每個(gè)節(jié)點(diǎn)上跑一個(gè) agent負(fù)責(zé)上報(bào)本節(jié)點(diǎn)設(shè)備、響應(yīng) kubelet 的分配請(qǐng)求。部署前確認(rèn)幾件事節(jié)點(diǎn)上已經(jīng)配好 Ascend Docker Runtime或 containerd Runtime。節(jié)點(diǎn)驅(qū)動(dòng)已經(jīng)正常npu-smi info能看到設(shè)備。給節(jié)點(diǎn)打上標(biāo)簽方便調(diào)度和篩選例如kubectl label node node-name acceleratorhuawei-ascenddevice-plugin 的 YAML 大致如下具體鏡像名和掛載路徑以官方文檔為準(zhǔn)apiVersion: apps/v1 kind: DaemonSet metadata: name: ascend-device-plugin namespace: kube-system spec: selector: matchLabels: app: ascend-device-plugin template: metadata: labels: app: ascend-device-plugin spec: hostNetwork: true containers: - name: device-plugin image: ascendhub.huawei.com/public/ascend-k8sdeviceplugin:latest imagePullPolicy: IfNotPresent securityContext: privileged: true volumeMounts: - name: device-plugins mountPath: /var/lib/kubelet/device-plugins - name: ascend-driver mountPath: /usr/local/Ascend/driver volumes: - name: device-plugins hostPath: path: /var/lib/kubelet/device-plugins - name: ascend-driver hostPath: path: /usr/local/Ascend/driver這里需要解釋一下為什么要掛載/usr/local/Ascend/driver。device-plugin 需要訪問(wèn)宿主機(jī)驅(qū)動(dòng)里的某些模塊來(lái)獲取設(shè)備狀態(tài)和分配信息如果不掛載插件可能能啟動(dòng)但拿不到設(shè)備列表。部署完成后查看節(jié)點(diǎn)資源kubectl describe node node-name | grep -A5 huawei.com/Ascend910如果一切正常capacity和allocatable里會(huì)顯示對(duì)應(yīng)的卡數(shù)量。如果這里為 0多半是 device-plugin 的 Pod 有問(wèn)題去看日志。5.3 跑一個(gè)測(cè)試 Pod 走通全鏈路節(jié)點(diǎn)資源上報(bào)成功之后創(chuàng)建測(cè)試 Pod 驗(yàn)證整條鏈路。昇騰官方的推理或訓(xùn)練鏡像體積比較大但勝在環(huán)境齊全。我在 CubeStudio 環(huán)境里用的驗(yàn)證 YAML 大致是apiVersion: v1 kind: Pod metadata: name: ascend-test spec: restartPolicy: OnFailure containers: - name: ascend-test image: ascendhub.huawei.com/public/ascend-mindspore:latest command: [sleep, 3600] resources: requests: huawei.com/Ascend910: 1 limits: huawei.com/Ascend910: 1 securityContext: runAsUser: 0創(chuàng)建后進(jìn)入容器執(zhí)行kubectl exec -it ascend-test -- npu-smi info容器內(nèi)能正常顯示 NPU 信息說(shuō)明從驅(qū)動(dòng)到 Runtime 再到 device-plugin 的整條鏈路已經(jīng)打通。這時(shí)候如果直接用昇騰官方鏡像跑一段訓(xùn)練代碼比如用 MindSpore 跑 LeNet或者用 torch_npu 跑一個(gè)矩陣乘法能真實(shí)看到算力調(diào)用。5.4 用 Kubernetes Dashboard 發(fā)布測(cè)試服務(wù)在實(shí)際交付的時(shí)候很多運(yùn)維同學(xué)習(xí)慣用 Kubernetes Dashboard 來(lái)管理服務(wù)和 Pod而不是每次敲kubectl apply。這里有一個(gè)典型的使用場(chǎng)景想通過(guò) Dashboard 創(chuàng)建一個(gè)新的 Pod 作為新服務(wù)發(fā)布。具體操作路徑是這樣的在 Dashboard 的 Namespace 里選擇對(duì)應(yīng)命名空間進(jìn)入“工作負(fù)載 - Pod”點(diǎn)擊右上角創(chuàng)建按鈕可以直接粘貼 YAML也可以走表單。如果你走表單需要手動(dòng)填鏡像地址和資源請(qǐng)求但 Dashboard 的舊版本表單在“資源請(qǐng)求”里不一定支持huawei.com/Ascend910這種自定義資源所以穩(wěn)妥的做法是直接選“從 YAML 創(chuàng)建”把上面那份測(cè)試 Pod 的 YAML 粘貼進(jìn)去。另外要強(qiáng)調(diào)一點(diǎn)Dashboard 本身是一個(gè)高權(quán)限管理組件千萬(wàn)不要把它暴露到公網(wǎng)。企業(yè)內(nèi)部建議通過(guò) ingress 加認(rèn)證、或用 kubectl proxy 方式訪問(wèn)利用 KubeConfig 的 token 鑒權(quán)。之前安全圈通報(bào)過(guò)不少 Kubernetes 未授權(quán)訪問(wèn)漏洞很多就是 Dashboard 或 API Server 直接暴露在公網(wǎng)沒(méi)有開(kāi)啟 RBAC 限制。Kubernetes 只要配置了合理的 RBAC給 Dashboard 賬號(hào)只授予需要的 namespace 的只讀或指定權(quán)限就能避免大多數(shù)風(fēng)險(xiǎn)。6. 監(jiān)控體系搭建NPU 狀態(tài)可視化6.1 快速排查容器內(nèi)看 npu-smi接入 K8s 之后最基礎(chǔ)的監(jiān)控還是npu-smi。這個(gè)工具在宿主機(jī)可以看整機(jī)的卡在容器內(nèi)只能看到分配給當(dāng)前 Pod 的設(shè)備。如果容器內(nèi)執(zhí)行npu-smi info只看到一張卡而宿主機(jī)上明明有四張卡這是正常的因?yàn)?Runtime 只把分配給 Pod 的卡注入到了容器里。一條非常實(shí)用的命令是持續(xù)刷新當(dāng)前設(shè)備狀態(tài)watch -n 1 npu-smi info在訓(xùn)練過(guò)程中可以觀察 AICore 利用率、HBM 占用率、溫度、功耗這幾個(gè)指標(biāo)。利用率長(zhǎng)期低于 30%說(shuō)明算子下發(fā)或者數(shù)據(jù)讀取有瓶頸HBM 接近滿說(shuō)明 batch size 或者模型尺寸需要調(diào)整。6.2 Prometheus 導(dǎo)出器采集 NPU 指標(biāo)生產(chǎn)環(huán)境不可能靠人肉watch npu-smi需要把指標(biāo)接入 Prometheus 和 Grafana。昇騰的監(jiān)控方案有兩類(lèi)一類(lèi)是官方提供的 exporter另一類(lèi)是自己寫(xiě)腳本基于驅(qū)動(dòng)接口采集。官方 exporter 的部署方式一般是 DaemonSet在每個(gè) NPU 節(jié)點(diǎn)上跑一個(gè)指標(biāo)導(dǎo)出器暴露/metrics接口給 Prometheus 抓取。指標(biāo)包括 NPU 溫度、HBM 使用量、AICore 利用率、芯片功耗等。如果你暫時(shí)找不到合適的官方 exporter也可以用 Python 腳本每隔 5 秒解析一次npu-smi info的輸出轉(zhuǎn)成 Prometheus metrics 格式這不是最優(yōu)雅的方案但能快速解決問(wèn)題。Prometheus 采集端的配置只需要在scrape_configs里增加一個(gè) job選擇帶有ascend-exporter標(biāo)簽的節(jié)點(diǎn)scrape_configs: - job_name: ascend-npu kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_label_app] action: keep regex: ascend-exporter打上標(biāo)簽、配置完 Prometheus再到 Grafana 里導(dǎo)入一個(gè) NPU 相關(guān)的 dashboard很快就能看到全集群 NPU 的實(shí)時(shí)狀態(tài)。我自己習(xí)慣把“卡健康狀態(tài)”“平均利用率”“溫度告警”放在一個(gè)面板上運(yùn)維同事看板子不需要懂昇騰細(xì)節(jié)也能快速定位問(wèn)題。6.3 訓(xùn)練場(chǎng)景的深層次監(jiān)控與性能分析Prometheus 監(jiān)控解決的是“節(jié)點(diǎn)活著嗎、卡忙不忙”的問(wèn)題但真實(shí)訓(xùn)練場(chǎng)景里還需要更深的性能數(shù)據(jù)。比如在跑 swift Megatron 大規(guī)模模型訓(xùn)練時(shí)經(jīng)常出現(xiàn)“卡利用率不錯(cuò)但整體吞吐上不去”的情況這時(shí)候必須看通信和算子層面的 profile。CANN 自帶的 msprof 工具可以抓取 NPU 算子耗時(shí)和通信耗時(shí)。在容器里執(zhí)行類(lèi)似msprof --output/tmp/profiling python train.py跑一小段時(shí)間后分析輸出的op_statistic和timeline能看到每個(gè)算子耗時(shí)、AICore 利用率、HCCS 通信等待時(shí)間等。這一步對(duì)于我們后期做分布式訓(xùn)練調(diào)優(yōu)非常有價(jià)值尤其是多卡并行時(shí)通信時(shí)間占比過(guò)高的話需要檢查單卡 batch size、梯度同步策略、是否啟用了混合精度等設(shè)置。還有一個(gè)小技巧用torch_npu跑 PyTorch 時(shí)torch.npu.synchronize()可以用來(lái)做計(jì)時(shí)基準(zhǔn)避免異步執(zhí)行導(dǎo)致的時(shí)間測(cè)量不準(zhǔn)。這個(gè)在評(píng)估單卡算子性能時(shí)很關(guān)鍵否則你會(huì)以為算子很快其實(shí)根本沒(méi)跑完。7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄7.1 device-plugin 上報(bào)資源為 0先看 device-plugin 的 Pod 日志常見(jiàn)報(bào)錯(cuò)是拿不到設(shè)備列表。這時(shí)候按順序檢查npu-smi info在宿主機(jī)上是否正常。device-plugin 是否掛載了/usr/local/Ascend/driver。節(jié)點(diǎn)是否打上了 device-plugin 需要匹配的標(biāo)簽。如果用的是 containerd 而不是 Docker要確認(rèn) device-plugin 的存活探針和 kubelet 通信正常。有個(gè)容易忽略的點(diǎn)device-plugin 是通過(guò) kubelet 的 socket 通信的如果 kubelet 啟動(dòng)時(shí)加了--feature-gatesDevicePluginsfalse老版本有這個(gè)參數(shù)或者 socket 目錄權(quán)限不對(duì)插件注冊(cè)不會(huì)成功。新版本 K8s 里DevicePlugins默認(rèn)開(kāi)啟一般不會(huì)遇到但排查時(shí)值得確認(rèn)。7.2 Pod 調(diào)度失敗提示節(jié)點(diǎn)資源不足明明kubectl describe node里顯示有 NPU 資源但 Pod 一直 Pending。大概率是以下原因Pod 請(qǐng)求的資源名和節(jié)點(diǎn)上報(bào)的資源名不一致。比如節(jié)點(diǎn)上報(bào)的是huawei.com/Ascend910而 Pod 寫(xiě)的是huawei.com/Ascend910B調(diào)度器自然認(rèn)為資源不存在。資源請(qǐng)求值超過(guò)了節(jié)點(diǎn)可用值。比如節(jié)點(diǎn)只剩 1 張卡而 Pod 一次性申請(qǐng) 2 張。節(jié)點(diǎn)被打了taintPod 沒(méi)有對(duì)應(yīng)的容忍。用kubectl describe pod查看調(diào)度事件是最快的排查方式事件里會(huì)明確寫(xiě)出為什么節(jié)點(diǎn)不可用。不要靠猜直接看調(diào)度器給出的事件信息。7.3 容器內(nèi)看不到/dev/davinci設(shè)備這個(gè)問(wèn)題的鍋基本在 Runtime。如果 Pod 請(qǐng)求了 NPU 資源調(diào)度和分配都成功了但容器內(nèi)沒(méi)有設(shè)備先確認(rèn)以下配置如果是 containerdconfig.toml里是否加了 ascend runtime。如果是 Docker/etc/docker/daemon.json里runtimes是否配置了ascendDocker 是否重啟。Pod 創(chuàng)建時(shí)是否實(shí)際上用了默認(rèn) runtime 而不是 ascend runtime。有些環(huán)境里 device-plugin 分配了設(shè)備但 Runtime 沒(méi)有生效設(shè)備自然進(jìn)不到容器。容器鏡像里是否真的存在/dev/davinci*的掛載位置。設(shè)備文件由 Runtime 在啟動(dòng)時(shí)創(chuàng)建在容器內(nèi)和鏡像無(wú)關(guān)但如果沒(méi)有 Runtime 介入容器內(nèi)自然沒(méi)有。排查時(shí)可以先在容器內(nèi)執(zhí)行l(wèi)s /dev/davinci*如果提示 No such device再去宿主機(jī)上檢查 Runtime 配置效率最高。7.4 CANN 算子報(bào)錯(cuò)與版本不匹配這是所有問(wèn)題里最隱蔽的一類(lèi)。訓(xùn)練時(shí)算子報(bào)錯(cuò)或者無(wú)法識(shí)別的設(shè)備類(lèi)型搜索結(jié)果會(huì)指向 CANN 兼容性問(wèn)題。昇騰的版本矩陣非常嚴(yán)格尤其是 torch_npu、CANN、驅(qū)動(dòng)固件三者之間。排查思路是npu-smi info # 看驅(qū)動(dòng)和固件版本 cat /usr/local/Ascend/ascend-toolkit/latest/version.cfg # 看 CANN 版本 pip show torch-npu # 看 torch_npu 版本三者對(duì)不上直接去昇騰社區(qū)查配套表。出現(xiàn)這類(lèi)問(wèn)題不要浪費(fèi)時(shí)間猜原因版本矩陣是明規(guī)則照著改就完事了。7.5 安全與權(quán)限相關(guān)的幾個(gè)坑最后說(shuō)幾個(gè)實(shí)際部署中容易忽略的安全問(wèn)題。昇騰驅(qū)動(dòng)和 CANN 的工具鏈很多需要 root 權(quán)限容器里跑訓(xùn)練時(shí)如果鏡像內(nèi)沒(méi)有普通用戶可以加securityContext.runAsUser: 0臨時(shí)解決但生產(chǎn)環(huán)境建議在鏡像里創(chuàng)建專(zhuān)用用戶結(jié)合 PSP/Pod Security Admission 限制 root 權(quán)限。Kubernetes Dashboard 這類(lèi)管理組件必須配合 RBAC 最小權(quán)限使用。不要圖省事給 dashboard service account 綁定cluster-admin否則一旦 Dashboard 被未授權(quán)訪問(wèn)整個(gè)集群就危險(xiǎn)了?？梢栽诿臻g級(jí)別授予只讀權(quán)限或者使用臨時(shí) token 登錄。集群網(wǎng)絡(luò)層面也要限制 Dashboard 只允許內(nèi)網(wǎng)訪問(wèn)不建議直接暴露 NodePort 到公網(wǎng)。最后再分享幾個(gè)實(shí)戰(zhàn)中的小習(xí)慣昇騰 NPU 接入 Kubernetes 這套流程跑通之后維護(hù)成本主要在版本升級(jí)和節(jié)點(diǎn)擴(kuò)容上。我個(gè)人的經(jīng)驗(yàn)是每次有新的驅(qū)動(dòng)或 CANN 版本發(fā)布先在測(cè)試節(jié)點(diǎn)上完整跑一遍“驅(qū)動(dòng) CANN Runtime device-plugin 訓(xùn)練驗(yàn)證”確認(rèn)沒(méi)有問(wèn)題再推到生產(chǎn)節(jié)點(diǎn)千萬(wàn)不要直接在線上批量升級(jí)。節(jié)點(diǎn)擴(kuò)容時(shí)如果新節(jié)點(diǎn)加入集群后 device-plugin 的資源沒(méi)有顯示先不要急著重啟 kubelet檢查一下新節(jié)點(diǎn)的驅(qū)動(dòng)是否安裝、是否和已有集群節(jié)點(diǎn)版本一致。昇騰設(shè)備在集群內(nèi)保持版本統(tǒng)一很重要混用驅(qū)動(dòng)版本雖然短期能跑但后續(xù)大規(guī)模訓(xùn)練時(shí)容易出現(xiàn)隱性故障。另外一個(gè)小細(xì)節(jié)給 NPU 節(jié)點(diǎn)設(shè)置資源預(yù)留時(shí)要留出 CPU 和內(nèi)存給 device-plugin、exporter 本身體面運(yùn)行否則節(jié)點(diǎn)資源緊張時(shí)基礎(chǔ)組件的 Pod 可能被驅(qū)逐影響設(shè)備上報(bào)和監(jiān)控采集。調(diào)度器層面可以通過(guò)在 device-plugin 的 DaemonSet 里設(shè)置tolerations和priorityClassName來(lái)規(guī)避這類(lèi)問(wèn)題。這套部署方案目前在我們 CubeStudio 環(huán)境里已經(jīng)穩(wěn)定運(yùn)行了一段時(shí)間支撐了從單卡推理到多卡 swift Megatron 訓(xùn)練的各種負(fù)載。希望這份實(shí)操記錄能幫你少走一些彎路。 昇騰NPU接入Kubernetes：從驅(qū)動(dòng)到device-plugin的完整實(shí)戰(zhàn)
把昇騰 NPU 接進(jìn) Kubernetes這句話聽(tīng)起來(lái)就是一行需求但實(shí)際上背后藏著一整條軟件鏈驅(qū)動(dòng)、CANN、Ascend Docker Runtime、device-plugin再加上監(jiān)控。任何一個(gè)環(huán)節(jié)沒(méi)對(duì)上NPU 在容器里就是“看不見(jiàn)、摸不著、調(diào)度不了”。最近在 CubeStudio 這套環(huán)境里完整跑了一遍昇騰基礎(chǔ)部署從裸機(jī)裝驅(qū)動(dòng)一直到 K8s 里跑通多卡訓(xùn)練中間踩了不少坑也把整條鏈路的邏輯徹底捋順了。這篇就按實(shí)操順序把步驟、原理和排查經(jīng)驗(yàn)一次講清楚適合正在做昇騰 NPU 容器化接入、或者準(zhǔn)備在企業(yè) K8s 集群里納管異構(gòu)算力的朋友參考。1. 昇騰 NPU 接入 Kubernetes 的整體思路1.1 容器要“看見(jiàn)” NPU繞不開(kāi)這三件事很多人第一次接觸這個(gè)需求時(shí)會(huì)覺(jué)得K8s 里調(diào)度 CPU、內(nèi)存這么成熟把 NPU 加進(jìn)去不就是多一種資源嗎實(shí)際上沒(méi)那么簡(jiǎn)單。Kubernetes 默認(rèn)認(rèn)識(shí)的資源只有 CPU 和內(nèi)存GPU 是依靠 device-plugin 以 Extended Resource 的形式上報(bào)給 kubelet再由調(diào)度器感知和分配的。昇騰 NPU 走的是同一個(gè)機(jī)制但底下的硬件和軟件棧比 GPU 更特殊一點(diǎn)。要讓容器真正用上昇騰 NPU必須解決三件事。第一件是系統(tǒng)層面能不能看見(jiàn)設(shè)備。昇騰 NPU 在宿主機(jī)上體現(xiàn)為/dev/davinci0、/dev/davinci1這類(lèi)設(shè)備節(jié)點(diǎn)外加一個(gè)/dev/davinci_manager管理設(shè)備。這些設(shè)備由驅(qū)動(dòng)程序創(chuàng)建驅(qū)動(dòng)沒(méi)裝好一切免談。第二件是容器層面能不能訪問(wèn)設(shè)備。即使宿主機(jī)能看到設(shè)備容器默認(rèn)是隔離的你必須在創(chuàng)建容器時(shí)把設(shè)備文件、驅(qū)動(dòng)目錄、CANN 相關(guān)庫(kù)都掛載進(jìn)去并且配置好運(yùn)行時(shí)環(huán)境。這一步在昇騰體系里由 Ascend Docker Runtime 自動(dòng)完成。第三件是調(diào)度層面能不能按卡分配。K8s 調(diào)度器不知道davinci0是什么東西需要 device-plugin 把節(jié)點(diǎn)上的 NPU 資源數(shù)量上報(bào)給 kubelet并負(fù)責(zé)在 Pod 啟動(dòng)時(shí)把具體的設(shè)備列表交出去。三件事環(huán)環(huán)相扣任何一層斷了都會(huì)表現(xiàn)為“資源有了但容器里用不了”或者“節(jié)點(diǎn)上明明有卡但調(diào)度不上去”。1.2 軟件棧分工驅(qū)動(dòng)、CANN、Runtime 與 device-plugin 各管一段整條鏈路可以拆成四個(gè)軟件角色它們各管一段職責(zé)非常清晰但都是缺一不可的。表格里列一下方便對(duì)照組件作用出問(wèn)題時(shí)的典型現(xiàn)象固件與驅(qū)動(dòng)初始化 NPU 硬件創(chuàng)建/dev/davinci*設(shè)備節(jié)點(diǎn)提供npu-smi工具宿主機(jī)npu-smi info報(bào)錯(cuò)找不到設(shè)備CANN Toolkit提供算子庫(kù)、圖編譯、運(yùn)行時(shí)等開(kāi)發(fā)能力類(lèi)似 CUDA 在 NVIDIA 體系里的位置訓(xùn)練時(shí)報(bào)算子不兼容、庫(kù)文件找不到Ascend Docker RuntimeDocker/containerd 創(chuàng)建容器時(shí)自動(dòng)注入 NPU 設(shè)備、驅(qū)動(dòng)庫(kù)和 CANN 環(huán)境變量容器內(nèi)沒(méi)有/dev/davinci*npu-smi無(wú)法執(zhí)行device-plugin向 kubelet 上報(bào)huawei.com/Ascend910等擴(kuò)展資源支持調(diào)度與設(shè)備分配節(jié)點(diǎn)資源數(shù)為 0Pod 調(diào)度失敗或分配不到設(shè)備以我實(shí)際部署的感受來(lái)說(shuō)最容易翻車(chē)的不是驅(qū)動(dòng)本身而是 Runtime 和 device-plugin 之間的配合。因?yàn)?Runtime 管的是“容器起來(lái)時(shí)設(shè)備在不在”device-plugin 管的是“這個(gè) Pod 被調(diào)度到節(jié)點(diǎn)后容器該用哪張卡”。如果只裝了 device-plugin 沒(méi)配 Runtime調(diào)度能成功但容器進(jìn)去發(fā)現(xiàn)/dev/davinci0不存在訓(xùn)練直接啟動(dòng)失敗而且報(bào)錯(cuò)信息還很不直觀。1.3 為什么用 CubeStudio 來(lái)做這套基礎(chǔ)部署CubeStudio 在我們的環(huán)境里是一個(gè)統(tǒng)一管理昇騰算力資源和部署流程的平臺(tái)它把所有碎片化的操作收斂成了可復(fù)用的流程。剛剛接觸昇騰 K8s 接入時(shí)可以完全靠手搓命令但如果集群規(guī)模變大、節(jié)點(diǎn)變多每次都去 SSH 到每臺(tái)機(jī)器上裝驅(qū)動(dòng)、改配置顯然不現(xiàn)實(shí)。CubeStudio 的價(jià)值在于把“節(jié)點(diǎn)納管 - 驅(qū)動(dòng)安裝 - Runtime 配置 - device-plugin 部署 - 監(jiān)控接入”串成一條標(biāo)準(zhǔn)的部署流水線任何新節(jié)點(diǎn)加入后能快速?gòu)?fù)制環(huán)境。當(dāng)然平臺(tái)只是把操作標(biāo)準(zhǔn)化了底層每一步的原理還是得搞清楚。下面所有實(shí)操內(nèi)容都是我在裸機(jī)環(huán)境下先手工驗(yàn)證過(guò)一遍再固化成 CubeStudio 里的部署流程的。接下來(lái)按順序拆解。2. 環(huán)境準(zhǔn)備與版本配套檢查2.1 硬件形態(tài)與操作系統(tǒng)選擇昇騰 NPU 的產(chǎn)品形態(tài)比較多。如果是 Atlas 300I/300T 推理卡通常是 PCIe 插卡插在通用服務(wù)器上如果是 Atlas 800 訓(xùn)練服務(wù)器一般是整機(jī)交付里面有多張昇騰芯片。不管哪種形態(tài)對(duì) Kubernetes 接入來(lái)說(shuō)看到的都是/dev/davinci*設(shè)備只是數(shù)量不同。操作系統(tǒng)方面昇騰官方支持的主要是 Ubuntu、openEuler、CentOS 等常見(jiàn)發(fā)行版但要注意 CPU 架構(gòu)。昇騰服務(wù)器大多是aarch64ARM 架構(gòu)也有少數(shù) x86 平臺(tái)驅(qū)動(dòng)包和 CANN 包都是分架構(gòu)的下載時(shí)一定要選對(duì)。我第一次部署時(shí)誤下了 x86 的 CANN 包在 aarch64 機(jī)器上直接提示架構(gòu)不匹配浪費(fèi)了不少時(shí)間。Kubernetes 版本建議選 1.26 以上的穩(wěn)定版因?yàn)樾掳?K8s 對(duì)擴(kuò)展資源的調(diào)度、設(shè)備插件的接口更成熟。如果集群還是用 Docker cri-dockerd 的舊模式或者已經(jīng)切換到 containerdRuntime 的配置方式會(huì)略有不同這個(gè)后面會(huì)單獨(dú)說(shuō)。2.2 版本配套關(guān)系是最大的隱形坑昇騰軟件體系的版本配套關(guān)系非常嚴(yán)格這是新手最容易踩的坑。驅(qū)動(dòng)、固件、CANN 三者必須滿足官方配套表的要求不是說(shuō)“驅(qū)動(dòng)是最新的就行”。比如某張訓(xùn)練卡固件需要 X 版本驅(qū)動(dòng)需要 Y 版本CANN 需要 Z 版本三者搭錯(cuò)一個(gè)輕則告警重則設(shè)備直接掛掉。我整理了部署前必查的幾項(xiàng)信息硬件型號(hào)npu-smi info能夠輸出芯片型號(hào)、固件版本、驅(qū)動(dòng)版本前提是驅(qū)動(dòng)已經(jīng)裝好。固件版本如果卡是全新的需要先刷固件再裝驅(qū)動(dòng)。CANN 版本工具包分為cann-toolkit、cann-kernels等一定要和驅(qū)動(dòng)版本、昇騰芯片匹配。torch_npu / MindSpore 版本后續(xù)要跑訓(xùn)練框架的話框架版本和 CANN 版本也要對(duì)齊。昇騰社區(qū)官網(wǎng)有“軟件配套表”里面有非常詳細(xì)的版本矩陣。我的建議是先確定要用什么訓(xùn)練框架PyTorch 還是 MindSpore再根據(jù)框架要求的 CANN 版本反推驅(qū)動(dòng)和固件版本這樣最不容易出錯(cuò)。2.3 安裝前三條硬檢查在開(kāi)始安裝之前我會(huì)強(qiáng)制自己在每臺(tái)節(jié)點(diǎn)上做三件事。第一確認(rèn)系統(tǒng)干凈。如果有舊版驅(qū)動(dòng)殘留直接用./Ascend-hdk-*.run --uninstall卸載干凈或者用npu-smi info看看是否已經(jīng)能識(shí)別設(shè)備。強(qiáng)行覆蓋安裝偶爾能成功但容易留下版本殘留。第二確認(rèn)內(nèi)核頭文件齊全。昇騰驅(qū)動(dòng)安裝時(shí)會(huì)編譯內(nèi)核模塊需要當(dāng)前內(nèi)核對(duì)應(yīng)的 kernel-devel 或 linux-headers 包。很多節(jié)點(diǎn)裝完系統(tǒng)后內(nèi)核升級(jí)過(guò)但頭文件沒(méi)跟上驅(qū)動(dòng)裝到一半就報(bào)編譯失敗。第三確認(rèn) BIOS 和 PCIe 狀態(tài)。用lspci | grep -i ascend或lspci | grep -i huawei看設(shè)備是否存在如果看不到設(shè)備先排查硬件插槽、PCIe 鏈路而不是急著裝軟件。這三條檢查五分鐘就能做完但能省下后面半小時(shí)的排錯(cuò)時(shí)間。3. 驅(qū)動(dòng)與 CANN 安裝實(shí)操3.1 安裝固件和驅(qū)動(dòng)在昇騰網(wǎng)站上按硬件型號(hào)和操作系統(tǒng)下載好固件包和驅(qū)動(dòng)包之后安裝命令很簡(jiǎn)單都是.run包執(zhí)行。以 Atlas 訓(xùn)練卡為例命令大致是# 安裝固件 ./Ascend-hdk-910b-firmware_6.3.3_linux-aarch64.run --full --quiet # 安裝驅(qū)動(dòng) ./Ascend-hdk-910b-npu-driver_23.0.rc3_linux-aarch64.run --full --quiet注意不同型號(hào)的包名不一樣910b只是示例。--full表示完整安裝--quiet表示靜默模式不給交互提示。裝完驅(qū)動(dòng)之后執(zhí)行npu-smi info如果能看到類(lèi)似下面的輸出說(shuō)明驅(qū)動(dòng)和固件已經(jīng)正常工作------------------------------------------------------------------------------------ | npu-smi 23.0.rc3 Version: 23.0.rc3 | -------------------------------------------------------------------------------------- | NPU Name | Health | Power(W) Temp(C) Hugepages-Usage(page)| | Chip | Bus-Id | AICore(%) Memory-Usage(MB) HBM-Usage(MB) | | 0 | OK | ...如果這里就報(bào)錯(cuò)先不要繼續(xù)往后走一定是驅(qū)動(dòng)或固件有問(wèn)題。3.2 驗(yàn)證驅(qū)動(dòng)并安裝 CANN Toolkit驅(qū)動(dòng)裝好之后npu-smi能看到卡只能說(shuō)明設(shè)備節(jié)點(diǎn)有了。接下來(lái)要裝 CANN Toolkit這是讓上層框架PyTorch、MindSpore能夠調(diào)用 NPU 算力的關(guān)鍵。CANN 的安裝包同樣是.run格式./Ascend-cann-toolkit_8.0.RC1_linux-aarch64.run --install安裝完成之后需要把環(huán)境變量加到 shell 配置里CANN 的set_env.sh腳本會(huì)幫你一次性配好所有路徑source /usr/local/Ascend/ascend-toolkit/set_env.sh建議把這一行寫(xiě)到/etc/profile或每個(gè)用戶的.bashrc里否則每次登錄都要手動(dòng) source。對(duì)容器場(chǎng)景來(lái)說(shuō)這個(gè)環(huán)境變量實(shí)際上不是由宿主機(jī)傳遞的而是由 Ascend Docker Runtime 在容器啟動(dòng)時(shí)注入的所以宿主機(jī)的環(huán)境變量配置主要用于裸機(jī)驗(yàn)證。3.3 驅(qū)動(dòng)、CANN 裝完后先做一次裸機(jī)驗(yàn)證很多人裝完 CANN 就直接跳到 K8s 環(huán)節(jié)這是不對(duì)的。至少要花五分鐘在宿主機(jī)上確認(rèn)“裸機(jī)可以調(diào)用 NPU”。最簡(jiǎn)單的驗(yàn)證是跑一個(gè) Python 腳本確認(rèn) torch_npu 能正常裝載并識(shí)別設(shè)備import torch import torch_npu print(torch.npu.device_count()) print(torch.npu.get_device_name(0))如果輸出正常的設(shè)備數(shù)量和名稱(chēng)說(shuō)明驅(qū)動(dòng)、CANN、torch_npu 三者已經(jīng)打通。這時(shí)候再去接容器化和 K8s排錯(cuò)范圍會(huì)小很多。我踩過(guò)一個(gè)教訓(xùn)當(dāng)時(shí)直接上了容器出了問(wèn)題排查了半天最后發(fā)現(xiàn)是宿主機(jī)裸機(jī)環(huán)境下 CANN 版本和 torch_npu 不匹配。如果先做裸機(jī)驗(yàn)證問(wèn)題在第一步就暴露了。4. Ascend Docker Runtime 接入容器運(yùn)行時(shí)4.1 Ascend Docker Runtime 到底做了什么昇騰的 Ascend Docker Runtime 在角色上很像 NVIDIA Container Toolkit。它的原理是Docker 創(chuàng)建容器時(shí)可以通過(guò)--runtime參數(shù)指定一個(gè)自定義 OCI Runtime這個(gè) Runtime 在真正啟動(dòng)容器進(jìn)程之前會(huì)把宿主機(jī)上的/dev/davinci*設(shè)備、驅(qū)動(dòng)目錄、CANN 庫(kù)目錄以及環(huán)境變量注入到容器里。所以它本質(zhì)上不是“讓 NPU 變快”的組件而是“讓容器看見(jiàn) NPU”的組件。如果沒(méi)配置 Runtime即使設(shè)備節(jié)點(diǎn)存在容器內(nèi)的 namespace 也看不到這些設(shè)備文件自然無(wú)法訪問(wèn)。安裝 Ascend Docker Runtime 很簡(jiǎn)單把包解壓到宿主機(jī)目錄然后配置 Docker。解壓后的目錄通常包含一個(gè)ascend-docker-runtime可執(zhí)行文件這就是我們要掛到 Docker 里的 Runtime。4.2 Docker 運(yùn)行時(shí)配置對(duì)于使用 Docker 作為容器運(yùn)行時(shí)的情況需要修改/etc/docker/daemon.json。這里有個(gè)細(xì)節(jié)昇騰官方提供的安裝腳本有時(shí)候會(huì)直接幫你把配置寫(xiě)好但也有時(shí)候只解壓文件。手動(dòng)配置的話格式如下{ runtimes: { ascend: { path: /usr/local/Ascend/Ascend-Docker-Runtime/ascend-docker-runtime, runtimeArgs: [] } } }配置完成后重啟 Dockersystemctl restart docker docker info | grep -A5 Runtimes如果配置正確docker info的 Runtimes 列表里會(huì)出現(xiàn)ascend。在測(cè)試階段建議先手動(dòng)跑一個(gè)容器看看設(shè)備是否注入成功docker run --rm --runtimeascend -it \ ascendhub.huawei.com/public/ascend-mindspore:latest \ npu-smi info容器里能看到 NPU 信息說(shuō)明 Runtime 生效了。4.3 containerd 場(chǎng)景下的配置如果你的 K8s 集群用的是 containerd現(xiàn)在主流版本基本都是不能只配 Docker還需要把昇騰 Runtime 接入 containerd。containerd 的配置在/etc/containerd/config.toml需要在 CRI 插件下面增加 runtime 配置。大致的配置段如下實(shí)際操作時(shí)版本不同格式會(huì)稍有差異[plugins.io.containerd.grpc.v1.cri.containerd.runtimes.ascend] runtime_type io.containerd.runc.v2 runtime_path /usr/local/Ascend/Ascend-Docker-Runtime/ascend-docker-runtime改完以后重啟 containerdsystemctl restart containerd這里要特別提醒K8s 1.24 版本之后默認(rèn)不再支持 Docker 作為運(yùn)行時(shí)除非額外部署 cri-dockerd所以新集群幾乎都是 containerd配置好 containerd 的 Runtime 是必須做的一步。有些部署文檔只寫(xiě)了 Docker 而沒(méi)寫(xiě) containerd照著做就會(huì)卡在容器起不來(lái)。4.4 驗(yàn)證容器內(nèi) NPU 是否可見(jiàn)Runtime 配完后除了用docker run --runtimeascend驗(yàn)證還要驗(yàn)證 containerd 環(huán)境下是否也能自動(dòng)注入?？梢酝ㄟ^(guò)crictl工具創(chuàng)建一個(gè)測(cè)試容器或者直接跳到下一步用 K8s 的 Pod 來(lái)驗(yàn)證。我的經(jīng)驗(yàn)是越早驗(yàn)證容器層后面 device-plugin 出問(wèn)題時(shí)就越容易定位是調(diào)度問(wèn)題還是運(yùn)行時(shí)問(wèn)題。有一個(gè)細(xì)節(jié)要留神如果容器內(nèi)的鏡像沒(méi)有安裝npu-smi工具即使設(shè)備注入成功你也無(wú)法用npu-smi info檢驗(yàn)。所以驗(yàn)證鏡像要選昇騰官方帶工具的鏡像或者自己在基礎(chǔ)鏡像里拷貝一份驅(qū)動(dòng)下的npu-smi可執(zhí)行文件。5. device-plugin 部署與資源調(diào)度驗(yàn)證5.1 Extended Resource 機(jī)制K8s 怎么知道節(jié)點(diǎn)有 NPUK8s 官方留給異構(gòu)設(shè)備接入的標(biāo)準(zhǔn)接口是 device plugin 框架。device-plugin 是一個(gè)運(yùn)行在節(jié)點(diǎn)上的 gRPC 服務(wù)kubelet 啟動(dòng)時(shí)會(huì)去/var/lib/kubelet/device-plugins/目錄下尋找 Unix socket然后通過(guò)這個(gè) socket 和 device-plugin 通信。device-plugin 需要做兩件事第一向 kubelet 上報(bào)這個(gè)節(jié)點(diǎn)上有多少?gòu)?NPU 卡這個(gè)數(shù)字會(huì)體現(xiàn)在節(jié)點(diǎn)的allocatable里第二當(dāng) Pod 被調(diào)度到該節(jié)點(diǎn)后kubelet 會(huì)拿著 Pod 請(qǐng)求的資源數(shù)量問(wèn) device-plugin 要具體的設(shè)備 IDdevice-plugin 返回/dev/davinci0、/dev/davinci1這樣的設(shè)備列表和對(duì)應(yīng)的驅(qū)動(dòng)掛載信息。昇騰體系里擴(kuò)展資源的名稱(chēng)一般是huawei.com/Ascend910或者h(yuǎn)uawei.com/Ascend310取決于芯片型號(hào)。Pod 的 YAML 里只要寫(xiě)上resources: requests: huawei.com/Ascend910: 1 limits: huawei.com/Ascend910: 1調(diào)度器在看到這類(lèi)資源請(qǐng)求時(shí)就會(huì)自動(dòng)把 Pod 分配到有對(duì)應(yīng)資源的節(jié)點(diǎn)上。5.2 部署 Ascend device-plugin昇騰的 device-plugin 是以 DaemonSet 形式部署的也就是說(shuō)每個(gè)節(jié)點(diǎn)上跑一個(gè) agent負(fù)責(zé)上報(bào)本節(jié)點(diǎn)設(shè)備、響應(yīng) kubelet 的分配請(qǐng)求。部署前確認(rèn)幾件事節(jié)點(diǎn)上已經(jīng)配好 Ascend Docker Runtime或 containerd Runtime。節(jié)點(diǎn)驅(qū)動(dòng)已經(jīng)正常npu-smi info能看到設(shè)備。給節(jié)點(diǎn)打上標(biāo)簽方便調(diào)度和篩選例如kubectl label node node-name acceleratorhuawei-ascenddevice-plugin 的 YAML 大致如下具體鏡像名和掛載路徑以官方文檔為準(zhǔn)apiVersion: apps/v1 kind: DaemonSet metadata: name: ascend-device-plugin namespace: kube-system spec: selector: matchLabels: app: ascend-device-plugin template: metadata: labels: app: ascend-device-plugin spec: hostNetwork: true containers: - name: device-plugin image: ascendhub.huawei.com/public/ascend-k8sdeviceplugin:latest imagePullPolicy: IfNotPresent securityContext: privileged: true volumeMounts: - name: device-plugins mountPath: /var/lib/kubelet/device-plugins - name: ascend-driver mountPath: /usr/local/Ascend/driver volumes: - name: device-plugins hostPath: path: /var/lib/kubelet/device-plugins - name: ascend-driver hostPath: path: /usr/local/Ascend/driver這里需要解釋一下為什么要掛載/usr/local/Ascend/driver。device-plugin 需要訪問(wèn)宿主機(jī)驅(qū)動(dòng)里的某些模塊來(lái)獲取設(shè)備狀態(tài)和分配信息如果不掛載插件可能能啟動(dòng)但拿不到設(shè)備列表。部署完成后查看節(jié)點(diǎn)資源kubectl describe node node-name | grep -A5 huawei.com/Ascend910如果一切正常capacity和allocatable里會(huì)顯示對(duì)應(yīng)的卡數(shù)量。如果這里為 0多半是 device-plugin 的 Pod 有問(wèn)題去看日志。5.3 跑一個(gè)測(cè)試 Pod 走通全鏈路節(jié)點(diǎn)資源上報(bào)成功之后創(chuàng)建測(cè)試 Pod 驗(yàn)證整條鏈路。昇騰官方的推理或訓(xùn)練鏡像體積比較大但勝在環(huán)境齊全。我在 CubeStudio 環(huán)境里用的驗(yàn)證 YAML 大致是apiVersion: v1 kind: Pod metadata: name: ascend-test spec: restartPolicy: OnFailure containers: - name: ascend-test image: ascendhub.huawei.com/public/ascend-mindspore:latest command: [sleep, 3600] resources: requests: huawei.com/Ascend910: 1 limits: huawei.com/Ascend910: 1 securityContext: runAsUser: 0創(chuàng)建后進(jìn)入容器執(zhí)行kubectl exec -it ascend-test -- npu-smi info容器內(nèi)能正常顯示 NPU 信息說(shuō)明從驅(qū)動(dòng)到 Runtime 再到 device-plugin 的整條鏈路已經(jīng)打通。這時(shí)候如果直接用昇騰官方鏡像跑一段訓(xùn)練代碼比如用 MindSpore 跑 LeNet或者用 torch_npu 跑一個(gè)矩陣乘法能真實(shí)看到算力調(diào)用。5.4 用 Kubernetes Dashboard 發(fā)布測(cè)試服務(wù)在實(shí)際交付的時(shí)候很多運(yùn)維同學(xué)習(xí)慣用 Kubernetes Dashboard 來(lái)管理服務(wù)和 Pod而不是每次敲kubectl apply。這里有一個(gè)典型的使用場(chǎng)景想通過(guò) Dashboard 創(chuàng)建一個(gè)新的 Pod 作為新服務(wù)發(fā)布。具體操作路徑是這樣的在 Dashboard 的 Namespace 里選擇對(duì)應(yīng)命名空間進(jìn)入“工作負(fù)載 - Pod”點(diǎn)擊右上角創(chuàng)建按鈕可以直接粘貼 YAML也可以走表單。如果你走表單需要手動(dòng)填鏡像地址和資源請(qǐng)求但 Dashboard 的舊版本表單在“資源請(qǐng)求”里不一定支持huawei.com/Ascend910這種自定義資源所以穩(wěn)妥的做法是直接選“從 YAML 創(chuàng)建”把上面那份測(cè)試 Pod 的 YAML 粘貼進(jìn)去。另外要強(qiáng)調(diào)一點(diǎn)Dashboard 本身是一個(gè)高權(quán)限管理組件千萬(wàn)不要把它暴露到公網(wǎng)。企業(yè)內(nèi)部建議通過(guò) ingress 加認(rèn)證、或用 kubectl proxy 方式訪問(wèn)利用 KubeConfig 的 token 鑒權(quán)。之前安全圈通報(bào)過(guò)不少 Kubernetes 未授權(quán)訪問(wèn)漏洞很多就是 Dashboard 或 API Server 直接暴露在公網(wǎng)沒(méi)有開(kāi)啟 RBAC 限制。Kubernetes 只要配置了合理的 RBAC給 Dashboard 賬號(hào)只授予需要的 namespace 的只讀或指定權(quán)限就能避免大多數(shù)風(fēng)險(xiǎn)。6. 監(jiān)控體系搭建NPU 狀態(tài)可視化6.1 快速排查容器內(nèi)看 npu-smi接入 K8s 之后最基礎(chǔ)的監(jiān)控還是npu-smi。這個(gè)工具在宿主機(jī)可以看整機(jī)的卡在容器內(nèi)只能看到分配給當(dāng)前 Pod 的設(shè)備。如果容器內(nèi)執(zhí)行npu-smi info只看到一張卡而宿主機(jī)上明明有四張卡這是正常的因?yàn)?Runtime 只把分配給 Pod 的卡注入到了容器里。一條非常實(shí)用的命令是持續(xù)刷新當(dāng)前設(shè)備狀態(tài)watch -n 1 npu-smi info在訓(xùn)練過(guò)程中可以觀察 AICore 利用率、HBM 占用率、溫度、功耗這幾個(gè)指標(biāo)。利用率長(zhǎng)期低于 30%說(shuō)明算子下發(fā)或者數(shù)據(jù)讀取有瓶頸HBM 接近滿說(shuō)明 batch size 或者模型尺寸需要調(diào)整。6.2 Prometheus 導(dǎo)出器采集 NPU 指標(biāo)生產(chǎn)環(huán)境不可能靠人肉watch npu-smi需要把指標(biāo)接入 Prometheus 和 Grafana。昇騰的監(jiān)控方案有兩類(lèi)一類(lèi)是官方提供的 exporter另一類(lèi)是自己寫(xiě)腳本基于驅(qū)動(dòng)接口采集。官方 exporter 的部署方式一般是 DaemonSet在每個(gè) NPU 節(jié)點(diǎn)上跑一個(gè)指標(biāo)導(dǎo)出器暴露/metrics接口給 Prometheus 抓取。指標(biāo)包括 NPU 溫度、HBM 使用量、AICore 利用率、芯片功耗等。如果你暫時(shí)找不到合適的官方 exporter也可以用 Python 腳本每隔 5 秒解析一次npu-smi info的輸出轉(zhuǎn)成 Prometheus metrics 格式這不是最優(yōu)雅的方案但能快速解決問(wèn)題。Prometheus 采集端的配置只需要在scrape_configs里增加一個(gè) job選擇帶有ascend-exporter標(biāo)簽的節(jié)點(diǎn)scrape_configs: - job_name: ascend-npu kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_label_app] action: keep regex: ascend-exporter打上標(biāo)簽、配置完 Prometheus再到 Grafana 里導(dǎo)入一個(gè) NPU 相關(guān)的 dashboard很快就能看到全集群 NPU 的實(shí)時(shí)狀態(tài)。我自己習(xí)慣把“卡健康狀態(tài)”“平均利用率”“溫度告警”放在一個(gè)面板上運(yùn)維同事看板子不需要懂昇騰細(xì)節(jié)也能快速定位問(wèn)題。6.3 訓(xùn)練場(chǎng)景的深層次監(jiān)控與性能分析Prometheus 監(jiān)控解決的是“節(jié)點(diǎn)活著嗎、卡忙不忙”的問(wèn)題但真實(shí)訓(xùn)練場(chǎng)景里還需要更深的性能數(shù)據(jù)。比如在跑 swift Megatron 大規(guī)模模型訓(xùn)練時(shí)經(jīng)常出現(xiàn)“卡利用率不錯(cuò)但整體吞吐上不去”的情況這時(shí)候必須看通信和算子層面的 profile。CANN 自帶的 msprof 工具可以抓取 NPU 算子耗時(shí)和通信耗時(shí)。在容器里執(zhí)行類(lèi)似msprof --output/tmp/profiling python train.py跑一小段時(shí)間后分析輸出的op_statistic和timeline能看到每個(gè)算子耗時(shí)、AICore 利用率、HCCS 通信等待時(shí)間等。這一步對(duì)于我們后期做分布式訓(xùn)練調(diào)優(yōu)非常有價(jià)值尤其是多卡并行時(shí)通信時(shí)間占比過(guò)高的話需要檢查單卡 batch size、梯度同步策略、是否啟用了混合精度等設(shè)置。還有一個(gè)小技巧用torch_npu跑 PyTorch 時(shí)torch.npu.synchronize()可以用來(lái)做計(jì)時(shí)基準(zhǔn)避免異步執(zhí)行導(dǎo)致的時(shí)間測(cè)量不準(zhǔn)。這個(gè)在評(píng)估單卡算子性能時(shí)很關(guān)鍵否則你會(huì)以為算子很快其實(shí)根本沒(méi)跑完。7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄7.1 device-plugin 上報(bào)資源為 0先看 device-plugin 的 Pod 日志常見(jiàn)報(bào)錯(cuò)是拿不到設(shè)備列表。這時(shí)候按順序檢查npu-smi info在宿主機(jī)上是否正常。device-plugin 是否掛載了/usr/local/Ascend/driver。節(jié)點(diǎn)是否打上了 device-plugin 需要匹配的標(biāo)簽。如果用的是 containerd 而不是 Docker要確認(rèn) device-plugin 的存活探針和 kubelet 通信正常。有個(gè)容易忽略的點(diǎn)device-plugin 是通過(guò) kubelet 的 socket 通信的如果 kubelet 啟動(dòng)時(shí)加了--feature-gatesDevicePluginsfalse老版本有這個(gè)參數(shù)或者 socket 目錄權(quán)限不對(duì)插件注冊(cè)不會(huì)成功。新版本 K8s 里DevicePlugins默認(rèn)開(kāi)啟一般不會(huì)遇到但排查時(shí)值得確認(rèn)。7.2 Pod 調(diào)度失敗提示節(jié)點(diǎn)資源不足明明kubectl describe node里顯示有 NPU 資源但 Pod 一直 Pending。大概率是以下原因Pod 請(qǐng)求的資源名和節(jié)點(diǎn)上報(bào)的資源名不一致。比如節(jié)點(diǎn)上報(bào)的是huawei.com/Ascend910而 Pod 寫(xiě)的是huawei.com/Ascend910B調(diào)度器自然認(rèn)為資源不存在。資源請(qǐng)求值超過(guò)了節(jié)點(diǎn)可用值。比如節(jié)點(diǎn)只剩 1 張卡而 Pod 一次性申請(qǐng) 2 張。節(jié)點(diǎn)被打了taintPod 沒(méi)有對(duì)應(yīng)的容忍。用kubectl describe pod查看調(diào)度事件是最快的排查方式事件里會(huì)明確寫(xiě)出為什么節(jié)點(diǎn)不可用。不要靠猜直接看調(diào)度器給出的事件信息。7.3 容器內(nèi)看不到/dev/davinci設(shè)備這個(gè)問(wèn)題的鍋基本在 Runtime。如果 Pod 請(qǐng)求了 NPU 資源調(diào)度和分配都成功了但容器內(nèi)沒(méi)有設(shè)備先確認(rèn)以下配置如果是 containerdconfig.toml里是否加了 ascend runtime。如果是 Docker/etc/docker/daemon.json里runtimes是否配置了ascendDocker 是否重啟。Pod 創(chuàng)建時(shí)是否實(shí)際上用了默認(rèn) runtime 而不是 ascend runtime。有些環(huán)境里 device-plugin 分配了設(shè)備但 Runtime 沒(méi)有生效設(shè)備自然進(jìn)不到容器。容器鏡像里是否真的存在/dev/davinci*的掛載位置。設(shè)備文件由 Runtime 在啟動(dòng)時(shí)創(chuàng)建在容器內(nèi)和鏡像無(wú)關(guān)但如果沒(méi)有 Runtime 介入容器內(nèi)自然沒(méi)有。排查時(shí)可以先在容器內(nèi)執(zhí)行l(wèi)s /dev/davinci*如果提示 No such device再去宿主機(jī)上檢查 Runtime 配置效率最高。7.4 CANN 算子報(bào)錯(cuò)與版本不匹配這是所有問(wèn)題里最隱蔽的一類(lèi)。訓(xùn)練時(shí)算子報(bào)錯(cuò)或者無(wú)法識(shí)別的設(shè)備類(lèi)型搜索結(jié)果會(huì)指向 CANN 兼容性問(wèn)題。昇騰的版本矩陣非常嚴(yán)格尤其是 torch_npu、CANN、驅(qū)動(dòng)固件三者之間。排查思路是npu-smi info # 看驅(qū)動(dòng)和固件版本 cat /usr/local/Ascend/ascend-toolkit/latest/version.cfg # 看 CANN 版本 pip show torch-npu # 看 torch_npu 版本三者對(duì)不上直接去昇騰社區(qū)查配套表。出現(xiàn)這類(lèi)問(wèn)題不要浪費(fèi)時(shí)間猜原因版本矩陣是明規(guī)則照著改就完事了。7.5 安全與權(quán)限相關(guān)的幾個(gè)坑最后說(shuō)幾個(gè)實(shí)際部署中容易忽略的安全問(wèn)題。昇騰驅(qū)動(dòng)和 CANN 的工具鏈很多需要 root 權(quán)限容器里跑訓(xùn)練時(shí)如果鏡像內(nèi)沒(méi)有普通用戶可以加securityContext.runAsUser: 0臨時(shí)解決但生產(chǎn)環(huán)境建議在鏡像里創(chuàng)建專(zhuān)用用戶結(jié)合 PSP/Pod Security Admission 限制 root 權(quán)限。Kubernetes Dashboard 這類(lèi)管理組件必須配合 RBAC 最小權(quán)限使用。不要圖省事給 dashboard service account 綁定cluster-admin否則一旦 Dashboard 被未授權(quán)訪問(wèn)整個(gè)集群就危險(xiǎn)了?？梢栽诿臻g級(jí)別授予只讀權(quán)限或者使用臨時(shí) token 登錄。集群網(wǎng)絡(luò)層面也要限制 Dashboard 只允許內(nèi)網(wǎng)訪問(wèn)不建議直接暴露 NodePort 到公網(wǎng)。最后再分享幾個(gè)實(shí)戰(zhàn)中的小習(xí)慣昇騰 NPU 接入 Kubernetes 這套流程跑通之后維護(hù)成本主要在版本升級(jí)和節(jié)點(diǎn)擴(kuò)容上。我個(gè)人的經(jīng)驗(yàn)是每次有新的驅(qū)動(dòng)或 CANN 版本發(fā)布先在測(cè)試節(jié)點(diǎn)上完整跑一遍“驅(qū)動(dòng) CANN Runtime device-plugin 訓(xùn)練驗(yàn)證”確認(rèn)沒(méi)有問(wèn)題再推到生產(chǎn)節(jié)點(diǎn)千萬(wàn)不要直接在線上批量升級(jí)。節(jié)點(diǎn)擴(kuò)容時(shí)如果新節(jié)點(diǎn)加入集群后 device-plugin 的資源沒(méi)有顯示先不要急著重啟 kubelet檢查一下新節(jié)點(diǎn)的驅(qū)動(dòng)是否安裝、是否和已有集群節(jié)點(diǎn)版本一致。昇騰設(shè)備在集群內(nèi)保持版本統(tǒng)一很重要混用驅(qū)動(dòng)版本雖然短期能跑但后續(xù)大規(guī)模訓(xùn)練時(shí)容易出現(xiàn)隱性故障。另外一個(gè)小細(xì)節(jié)給 NPU 節(jié)點(diǎn)設(shè)置資源預(yù)留時(shí)要留出 CPU 和內(nèi)存給 device-plugin、exporter 本身體面運(yùn)行否則節(jié)點(diǎn)資源緊張時(shí)基礎(chǔ)組件的 Pod 可能被驅(qū)逐影響設(shè)備上報(bào)和監(jiān)控采集。調(diào)度器層面可以通過(guò)在 device-plugin 的 DaemonSet 里設(shè)置tolerations和priorityClassName來(lái)規(guī)避這類(lèi)問(wèn)題。這套部署方案目前在我們 CubeStudio 環(huán)境里已經(jīng)穩(wěn)定運(yùn)行了一段時(shí)間支撐了從單卡推理到多卡 swift Megatron 訓(xùn)練的各種負(fù)載。希望這份實(shí)操記錄能幫你少走一些彎路。