openFuyao NPU-Operator故障排查
内容提要
openFuyao NPU-Operator中ascend-device-plugin容器反复CrashLoopBackOff，日志显示dcmi获取卡数量为0。排查发现宿主机可识别NPU卡，但容器内dcmi_get_card_list返回0。最终定位为非裸金属虚拟机场景，需在镜像中安装systemd并定制镜像，替换后节点可正常显示NPU资源。
延伸解读
故障现象与初步排查
ascend-device-plugin 容器反复 CrashLoopBackOff，日志显示 dcmi 获取卡数量为 0。宿主机可识别 NPU 卡，但容器内 dcmi_get_card_list 返回 0。检查容器内 /dev 目录可见 davinci0 等设备，驱动目录挂载正常，但 dcmi 初始化失败。
深入诊断与根因定位
通过编写测试程序，在宿主机和容器内分别运行，发现宿主机能获取卡列表，容器内返回空。进一步检查发现容器内缺少 systemd 及相关服务，导致 dcmi 无法正常初始化。最终确认是非裸金属虚拟机场景，需要定制镜像。
解决方案与镜像定制
根据官方文档，在虚拟机场景下部署 Ascend Device Plugin，需在镜像中安装 systemd。使用 nerdctl 构建新镜像，Dockerfile 中安装 systemd 并设置 STOPSIGNAL SIGRTMIN+3。替换镜像后，节点可正常显示 NPU 资源。
修复验证与注意事项
修复后，通过 kubectl describe node 可看到 huawei.com/Ascend310P 资源。注意：若容器内不运行 systemd 作为主进程，STOPSIGNAL 可省略；npu-operator 有同样问题，需同样修改。
Q&A
openFuyao NPU-Operator 中 ascend-device-plugin 容器为什么反复 CrashLoopBackOff？
因为容器内 dcmi_get_card_list 返回的卡数量为 0，导致 device plugin 初始化失败，容器不断重启。
在宿主机上能识别 NPU 卡，但容器内 dcmi 获取卡数量为 0，可能是什么原因？
可能是非裸金属虚拟机场景，容器内缺少 systemd 等必要组件，导致 dcmi 无法正确获取卡列表。
如何解决 openFuyao NPU-Operator 在虚拟机场景下 dcmi 获取卡数量为 0 的问题？
需要定制镜像，在 Dockerfile 中安装 systemd，然后替换原有镜像。具体步骤：基于原镜像，替换 apt 源，运行 apt-get update && apt-get install -y systemd systemd-sysv，设置 STOPSIGNAL SIGRTMIN+3，构建新镜像并替换。
在虚拟机场景下部署 Ascend Device Plugin 需要注意什么？
需要在 Ascend Device Plugin 的镜像中安装 systemd，推荐在 Dockerfile 中加入 RUN apt-get update && apt-get install -y systemd 命令。
如何验证 openFuyao NPU-Operator 故障修复成功？
在节点上执行 kubectl describe node，如果能看到 NPU 资源（如 huawei.com/Ascend310P）即表示修复成功。
npu-operator 是否也存在同样的问题？如何修改？
是的，npu-operator 有同样的问题，按照相同的方法修改镜像即可。
