CRI-O容器运行时在cgroup v1环境下的设备权限问题分析

问题背景

CRI-O作为Kubernetes的轻量级容器运行时，在1.30.7版本升级后出现了设备权限问题。具体表现为在Rocky Linux 8和AlmaLinux 8等基于RHEL 8的系统上，容器启动时会报错"writing file devices.allow: Operation not permitted"，导致所有Pod(包括kube-api等系统Pod)都无法正常启动。

问题根源

经过技术分析，这个问题主要源于以下几个方面：

1. cgroup版本兼容性问题：RHEL 8系列默认使用cgroup v1，而CRI-O 1.30.7版本开始对crun运行时(默认容器运行时)的依赖增强，crun已逐渐将cgroup v1标记为"deprecated"(不推荐使用)状态。

2. 设备控制组权限限制：在cgroup v1环境下，crun尝试写入devices.allow文件时遇到权限问题，这是crun对cgroup v1支持度下降的表现。

3. 版本迭代影响：该问题不仅出现在1.30.7版本，在测试中发现1.31.2版本同样存在此问题，表明这是CRI-O与底层运行时在cgroup支持策略上的一个持续性变化。

解决方案

对于遇到此问题的用户，有以下几种解决方案：

1. 降级CRI-O版本：暂时降级到1.30.6版本可以解决问题，但这只是临时方案。

2. 切换到cgroup v2：这是推荐的长效解决方案，通过修改grub配置启用cgroup v2：

   grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=1"
   

   然后重启系统即可。

3. 切换默认运行时：如果不便升级cgroup，可以将CRI-O的默认运行时从crun改为runc，因为runc对cgroup v1的支持更为完善。

技术建议

1. 生产环境规划：对于仍在使用RHEL 8系列的生产环境，建议评估升级到cgroup v2的可行性，这是Kubernetes生态的未来方向。

2. 版本选择策略：在混合环境中，如果需要保持cgroup v1，应考虑锁定CRI-O版本或明确指定使用runc运行时。

3. 兼容性测试：在升级CRI-O版本前，建议在测试环境中验证cgroup相关功能，特别是设备控制相关的Pod。

总结

这个问题反映了容器生态向cgroup v2迁移的趋势。虽然CRI-O团队表示尚未正式放弃对cgroup v1的支持，但底层运行时的变化已经带来了兼容性挑战。对于运维团队来说，制定合理的升级策略和运行环境标准化方案，是避免此类问题的关键。