浅谈在 Kubernetes 中接入昇腾 NPU：ascend-device-plugin-daemonset 解析

当大家在kube-system命名空间里看到ascend-device-plugin-daemonset-xxxxx时，这意味着：

你的 Kubernetes 集群，已经从“纯 CPU / GPU”迈入了“AI 异构算力集群”的范畴。

本文将围绕Ascend NPU 在 Kubernetes 中是如何被感知、注册和调度的这一核心问题，结合真实运维场景，给大家依次介绍：

• ascend-device-plugin-daemonset 是什么
• 它在 Kubernetes 中扮演什么角色
• 它是如何工作的
• 与 NVIDIA GPU device-plugin 的异同
• 实际运维中必须掌握的检查与排障方法

ascend-device-plugin-daemonset

ascend-device-plugin-daemonset是昇腾 NPU 在 Kubernetes 中的 Device Plugin 实现。

它的作用是把宿主机上的/dev/davinci*昇腾 NPU 设备，注册为 Kubernetes 可调度资源。

如果读者朋友熟悉 NVIDIA GPU，那可以直接类比：

• nvidia-device-plugin-daemonset
• ↔
• ascend-device-plugin-daemonset

本质是同一套 Kubernetes Device Plugin 机制。

一、为什么 Kubernetes “看不见” NPU / GPU？

这是理解 device-plugin 的前提。

1. Kubernetes 的默认认知范围

Kubernetes 原生只理解三类资源：CPU、Memory 和 Storage【通过 CSI（Container Storage Interface）】

它并不知道GPU、NPU 等，这些都属于“非标准、厂商相关的异构硬件”。

2. Device Plugin 机制的出现

为了解决这个问题，Kubernetes 引入了Device Plugin Framework：

• 由厂商或平台方实现一个device-plugin

• 运行在节点上

• 通过 kubelet 的标准接口：

  • 上报设备数量
  • 上报可分配资源
  • 管理设备分配

Ascend device-plugin，就是这套机制在昇腾 NPU 场景下的具体实现。

二、ascend-device-plugin-daemonset 到底在干什么？

从工程视角看，它主要完成三件关键事情。

1️⃣ 在每个 NPU 节点上运行一个 Pod（DaemonSet）

ascend-device-plugin-daemonset └── Pod on node-1 └── Pod on node-2 └── Pod on node-3 └── Pod on node-4

为什么用DaemonSet？

• NPU 是节点级硬件
• 每个有 NPU 的节点，都必须有一个 device-plugin 实例
• DaemonSet 天然就是 “一节点一 Pod” 的模型

2️⃣ 扫描宿主机上的昇腾设备

device-plugin 容器会以特权模式运行，并访问宿主机设备文件：

/dev/davinci0 /dev/davinci1 /dev/davinci2 ... /dev/davinci_manager

这些设备文件由：

• Ascend firmware
• Ascend driver

在宿主机上创建。

👉如果这些文件不存在，device-plugin 再正常也没用。

3️⃣ 向 kubelet 注册 NPU 资源

device-plugin 通过 kubelet 的标准 device-plugin socket 接口：

/var/lib/kubelet/device-plugins/

向 kubelet 注册类似资源：

huawei.com/Ascend910 huawei.com/Ascend910B

于是 Kubernetes 层面就“知道”：

某个 Node 上，有多少张 Ascend NPU 可以被调度。

三、业务 Pod 是如何“使用” Ascend NPU 的？

一旦 device-plugin 正常工作，NPU 就变成了 Kubernetes 的一种资源。

业务 Pod 只需要在 spec 中声明：

resources:limits:huawei.com/Ascend910:1

Kubernetes 调度器会保证：

• Pod 只会调度到有可用 NPU 的节点
• 对应 NPU 被独占或按插件规则分配
• 其它 Pod 不会抢占这张卡

👉对业务来说，NPU ≈ CPU / Memory 一样的资源声明体验。

四、为什么能够“看到”它？

① 最近刚接入 Ascend AI 能力（最常见）

比如我们做了其中之一：

• 安装了 Ascend firmware / driver
• 部署了 MindIE
• 部署了 Ascend 版大模型推理服务
• 手动执行过：

kubectl apply -f ascend-device-plugin-daemonset.yaml

② 它是 NPU 节点专属的系统组件

kubectl get pods -n kube-system

我们会看到它，是因为：

• kube-system本来就存放集群级基础组件
• device-plugin 必须放在 kube-system
• DaemonSet 只会在带 Ascend NPU 的节点上起

③ 平台已经帮我们“预装”了

在很多运营商 / AI 平台 / 行业云环境中：

• Ascend driver
• Ascend device-plugin

往往是平台交付的一部分。

④ 它不像业务 Pod 那样“显眼”

这个 Pod：

• 不暴露服务
• 不对外提供 API
• 不在业务 namespace
• 不在 Deployment / Job 中

👉 但没有它，任何 NPU 业务 Pod 都起不来。

五、与 NVIDIA GPU device-plugin 的对比

结论只有一句：

机制完全一致，只是硬件和资源名不同。

六、常用的 6 个检查点

1️⃣ DaemonSet 是否存在

kubectl get ds -n kube-system ascend-device-plugin-daemonset

2️⃣ Pod 是否在每个 NPU 节点 Running

kubectl get pods -n kube-system -o wide|grepascend

3️⃣ 查看 device-plugin 日志

kubectl logs -n kube-system<ascend-device-plugin-pod>

重点关注日志关键词：

• Found device /dev/davinci0
• Registered resource huawei.com/Ascend910

4️⃣ Node 是否成功注册 NPU 资源

kubectl describenode<node-name>|grep-A10 Ascend

正常情况下应看到：

Capacity: huawei.com/Ascend910: 8 Allocatable: huawei.com/Ascend910: 8

5️⃣ 实际验证 Pod 申请 NPU

resources:limits:huawei.com/Ascend910:1

Pod 能 Running，说明整条链路打通。

6️⃣ Pod Pending 时优先检查什么？

1. ascend-device-plugin Pod 本身没跑起来
2. Ascend 驱动 / firmware 未正确安装
3. 宿主机上/dev/davinci*不存在

七、总结

ascend-device-plugin-daemonset 是“昇腾 NPU 与 Kubernetes 之间的翻译官”。

• 没有它：

  • Kubernetes 看不见 NPU
  • Pod 无法申请 Ascend 资源

• 有了它：

  • NPU 变成可调度资源
  • AI 推理 / 训练容器才能在 K8S 中规范运行

当我们真正理解它的工作方式时，也就理解了：

Kubernetes 如何一步步演进为 AI 异构算力操作系统。