在cgroup v1环境下使用systemd作为Kubernetes cgroup驱动是否有风险？

结论先行：cgroup v1环境中确实可以用systemd作为cgroup驱动，你测试环境运行正常是合理的，但存在以下潜在风险：

• cgroup层级冲突隐患：systemd本身会主导系统的cgroup层级创建，Kubernetes用systemd驱动时会在systemd的层级下生成子cgroup。若系统内其他systemd管理的服务也操作cgroup，可能引发层级嵌套混乱，导致资源限制失效、进程OOM清理异常等问题。
• 资源控制行为差异：部分cgroup v1的资源特性（如内存swap限制、CPU cpuset绑定）在systemd驱动下的表现和cgroupfs驱动不一致。比如systemd的OOM策略会和Kubernetes的资源限制逻辑叠加，可能出现Pod资源限制达不到预期的情况。
• 排查复杂度提升：systemd驱动下的cgroup路径基于systemd单元命名（如/sys/fs/cgroup/systemd/kubepods.slice/...），不像cgroupfs那样按Pod/容器层级直观划分。遇到资源类问题时，需要同时熟悉systemd和Kubernetes的cgroup逻辑，排查难度更高。
• 长期版本适配风险：你当前使用的Kubelet 1.23、containerd 1.5.9虽能兼容，但Kubernetes后续版本会逐步弱化cgroup v1的支持，针对systemd驱动在v1环境的维护力度也会降低，未来升级可能出现兼容性问题。

如果你的集群负载不复杂，且已经验证过核心业务的运行稳定性，短期内可以继续使用该配置，但长期建议逐步迁移到cgroup v2 + systemd驱动的组合——这是官方推荐的标准配置，兼容性和稳定性更有保障。

内容的提问来源于stack exchange，提问作者Wolphy