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初始化失败。这表明问题可能出在容器环境与宿主机的差异上。
深入诊断与根因定位
通过编写测试程序，在宿主机和容器内分别运行dcmi_get_card_list，宿主机返回卡列表，容器内返回空。进一步检查发现容器内缺少systemd相关服务，且日志显示dcmi board init成功但device_count=1，而get_card_list却为0。最终定位为非裸金属虚拟机场景，需在镜像中安装systemd定制镜像。
解决方案与验证
根据官方文档，在虚拟机场景下部署Ascend Device Plugin，需在镜像中安装systemd。通过修改Dockerfile，安装systemd并设置STOPSIGNAL，重新构建镜像并替换。替换后节点成功识别NPU资源，kubectl describe node显示huawei.com/Ascend310P资源。npu-operator有同样问题，可同样修改。
Q&A
openFuyao NPU-Operator 中 ascend-device-plugin 容器为什么反复 CrashLoopBackOff？
容器内 dcmi_get_card_list 返回卡数量为 0，导致 device plugin 初始化失败，从而反复崩溃重启。
如何排查 ascend-device-plugin 容器内 NPU 卡识别问题？
可以进入容器执行 ls /dev 查看设备节点，检查 /usr/local/Ascend/driver 驱动挂载，查看容器日志中 dcmi 相关错误，并运行测试程序验证 dcmi_get_card_list 返回值。
非裸金属虚拟机场景下部署 Ascend Device Plugin 需要注意什么？
需要在镜像中安装 systemd，推荐在 Dockerfile 中加入 RUN apt-get update && apt-get install -y systemd 命令，并重新构建镜像替换原有镜像。
如何为 openFuyao NPU-Operator 构建包含 systemd 的定制镜像？
使用 nerdctl 构建，Dockerfile 基于原镜像，替换 apt 源，安装 systemd 和 systemd-sysv，设置 STOPSIGNAL SIGRTMIN+3，然后执行 nerdctl build 命令生成新镜像。
修复后如何确认 NPU 资源已被节点识别？
在节点上执行 kubectl describe node，查看 Capacity 和 Allocatable 中是否出现 huawei.com/Ascend310P 等 NPU 资源。
npu-operator 是否也存在同样的问题？如何解决？
是的，npu-operator 有同样的问题，解决方法相同：构建包含 systemd 的定制镜像并替换原有镜像。
