crun容器运行时中systemd cgroup驱动下的设备访问控制问题分析

问题背景

在Kubernetes环境中使用crun容器运行时配合systemd cgroup驱动时，发现GPU设备访问权限问题。具体表现为当尝试在容器中使用NVIDIA GPU时，容器内进程无法访问/dev/nvidiactl设备，出现权限被拒绝的错误。

问题根源分析

经过深入调查，发现问题源于crun在systemd cgroup驱动下的设备访问控制机制存在冗余设计。具体表现为：

1. 双重设备过滤机制：

   • crun会通过systemd的scope单元创建第一个设备过滤器（使用DevicePolicy和DeviceAllow选项）
   • 同时crun还会在容器子cgroup中直接创建第二个eBPF设备过滤器

2. NVIDIA容器工具链的工作方式：

   • libnvidia-container会查找并修改容器的cgroup_device过滤器
   • 它只修改子cgroup中的eBPF过滤器，而忽略systemd创建的过滤器
   • 由于systemd的过滤器仍然生效，导致设备访问被拒绝

技术细节解析

crun的设备控制实现

crun通过两条路径实现设备访问控制：

1. systemd路径：

   • 通过DBus API与systemd交互
   • 在scope单元中设置DevicePolicy和DeviceAllow
   • 最终由systemd生成eBPF过滤器

2. 直接eBPF路径：

   • crun直接操作cgroup文件系统
   • 在容器子cgroup中加载自定义eBPF程序
   • 完全绕过systemd的管理

与runc的差异

相比之下，runc的实现更为简洁：

• 仅通过systemd scope单元设置设备访问规则
• 不创建额外的子cgroup和eBPF过滤器
• 使得libnvidia-container能够正确识别和修改设备权限

解决方案

目前有以下几种可行的解决方案：

1. 使用run.oci.systemd.subgroup注解：

   • 设置run.oci.systemd.subgroup=""
   • 使crun行为与runc一致，不创建子cgroup
   • 但需注意systemd可能随时更新eBPF过滤器

2. 修改crun源码：

   • 移除systemd路径的设备控制代码
   • 仅保留直接eBPF路径的实现
   • 需要重新编译和部署crun

3. 配置容器访问所有设备：

   • 在容器配置中放宽设备访问权限
   • 可能带来安全隐患，不推荐生产环境使用

最佳实践建议

对于需要使用GPU加速的容器环境，推荐采用以下方案：

1. 在Kubernetes Pod定义中添加注解：

   annotations:
     run.oci.systemd.subgroup: ""
   

2. 监控systemd scope单元的状态变化，确保设备访问权限不会意外丢失

3. 考虑在容器启动脚本中添加设备访问检查逻辑，及时发现权限问题

技术展望

从项目维护者的反馈来看，未来crun可能会默认采用不创建子cgroup的行为，这将从根本上解决此类问题。在此之前，用户需要根据实际需求选择合适的临时解决方案。

对于容器运行时开发者而言，这个案例也提醒我们需要谨慎设计多层次的资源控制机制，避免出现权限控制的冲突和冗余。