问题现象描述

在Atlas 800 推理服务器（型号 3000）（Arm），操作系统CentOS 7.6上，使用K8s（版本1.12）进行NPU相关业务调度。配置K8s的参数 --kube-reserved=cpu=2,memory=250Mi --cpu-manager-policy=static --feature-gates=CPUManager=true，开启K8s的绑核，绑核后执行npu-smi info，报错如下所示。

原因分析

默认情况下kubelet创建的Pod都是通过CFS配额的方式来分配使用物理机的CPU资源。cpu manager启动时，如果显示none cpu manager policy，就直接返回；如果是static cpu manager则会启动一个gorouting做reconcile。

• 在reconcileState方法中，cm会不停的通过GetCPUSetOrDefault方法获取容器的cpu set，并更新容器的cpu set。
• GetCPUSetOrDefault方法根据containerID获取cpu set，如果Pod是一个guaranteed pod，返回该容器的cpu set；否则返回default值。default值得含义是：“除了guaranteed pod分配走的CPU core外，其余的CPU core都在default值里”，因此所有的容器在运行过程中都会定时、动态的更新cpu set值。

Ascend Docker Runtime将昇腾驱动库的so文件和NPU设备信息通过文件挂载的方式挂载到容器中，并添加cgroup访问权限。而挂载的过程中，没有将这部分信息同步给Docker Engine。RunC在update过程中调用device Set方法，根据容器的cgroup config中的内容重新调整device相关的文件，在这个过程中，就会丢失挂载时添加的cgroup访问权限。

解决措施

Ascend Device Plugin插件自身可以进行（/dev/davinciX /dev/davinci_manager /dev/devmm_svm）挂载，使用Ascend Device Plugin挂载覆盖Ascend Docker Runtime挂载，可以保证cgroup访问权限不丢失。用户可以修改Ascend Device Plugin驱动参数“-useAscendDocker=false”，再重新安装Ascend Device Plugin。