openFuyao NPU-Operator故障排查
内容提要
openFuyao NPU-Operator故障排查：ascend-device-plugin容器反复CrashLoopBackOff，日志显示dcmi获取卡数量为0。排查发现宿主机能识别NPU卡，容器内却识别不到。最终定位为非裸金属虚拟机场景，需在镜像中安装systemd。通过修改Dockerfile安装systemd并重建镜像后，节点成功显示NPU资源。
延伸解读
故障现象与初步排查
ascend-device-plugin 容器反复 CrashLoopBackOff，日志显示 dcmi 获取卡数量为 0。宿主机能识别 NPU 卡，但容器内 /dev 下无 davinci 设备，且驱动目录挂载正常。这表明问题可能出在容器环境而非硬件。
深入诊断与关键发现
通过编写测试程序，在宿主机和容器内分别调用 dcmi 接口，发现宿主机能获取卡列表，容器内返回 0。进一步检查发现容器内缺少 systemd，导致 dcmi 初始化失败。这指向非裸金属虚拟机场景的特定需求。
解决方案与镜像定制
根据官方文档，虚拟机场景下需在镜像中安装 systemd。修改 Dockerfile，添加 RUN apt-get update && apt-get install -y systemd 等命令，并设置 STOPSIGNAL SIGRTMIN+3。使用 nerdctl 构建新镜像并替换后，节点成功显示 NPU 资源。
经验总结与注意事项
该问题表明，在非裸金属环境部署 Ascend Device Plugin 时，必须确保镜像包含 systemd。npu-operator 同样适用此修复。排查时，可借助 dcmi 测试程序和 strace 跟踪，对比宿主机与容器行为，快速定位环境差异。
Q&A
ascend-device-plugin 容器一直 CrashLoopBackOff，日志显示 dcmi 获取卡数量为 0，可能是什么原因？
可能是在非裸金属的虚拟机场景下部署，容器内缺少 systemd 导致 dcmi 无法识别 NPU 卡。
在虚拟机场景下部署 Ascend Device Plugin，需要如何修改镜像？
需要在镜像中安装 systemd，推荐在 Dockerfile 中加入 RUN apt-get update && apt-get install -y systemd 命令。
如何验证 NPU 资源已经成功被节点识别？
在节点上执行 kubectl describe node <节点名>，如果在 Capacity 中看到 huawei.com/Ascend310P 等 NPU 资源即表示成功。
为什么宿主机能识别 NPU 卡，但容器内却识别不到？
因为容器内缺少必要的系统服务（如 systemd），导致 dcmi 库无法正常初始化并获取卡列表。
构建包含 systemd 的镜像时，Dockerfile 中 STOPSIGNAL SIGRTMIN+3 有什么作用？
STOPSIGNAL SIGRTMIN+3 用于告诉容器运行时在停止容器时发送正确的信号，避免使用 systemd 时出现 30 秒超时强杀的问题。
npu-operator 是否也存在同样的问题？如何解决？
是的，npu-operator 有同样的问题，按照相同的方法修改镜像（安装 systemd）即可。
