在不断发展的 Kubernetes 容器编排领域，变化是常态。其中一项最重要的变革就是从 cgroup v1 过渡到 cgroup v2。如果您正在管理 Kubernetes 集群，这不仅仅是一个技术细节，而是一项影响资源管理、安全性和整体性能的根本性变革。

Kubernetes 1.35 带来了一个不小的变化：kubelet 默认拒绝在 cgroup v1 节点上启动。这可不是简单的功能弃用，而是整个 Linux 生态在资源管理架构上的一次集体转向。

生态系统的连锁反应

这次变化特殊在哪？它不是某个项目的孤立决定，而是整个生态在同步行动:

• systemd v256 开始默认拒绝 cgroup v1，v258 会完全移除支持。
• RHEL 9.4 废弃 cgroup v1，RHEL 10 只支持 v2。
• Fedora 的时间表更激进：41/42 版本默认不启动 v1，43 会完全移除。
• Ubuntu 22.04 LTS 及更高版本默认使用 cgroup v2。
• Debian Trixie 使用 systemd 257，默认不支持 v1。

这种同步性背后有技术原因。cgroup v1 的混合层级架构在设计上就存在复杂性问题：每个资源控制器（CPU、内存、IO）都有独立的层级树，同一个进程在不同控制器中可能处于不同位置。这种设计在容器密度增加、资源管理需求变复杂后，维护成本越来越高。

cgroup v2 的统一层级架构从根本上解决了这个问题。所有资源控制器在同一个层级树中管理，进程在所有控制器中的位置一致。这不仅简化了管理，还让内核能做更多优化。systemd 作为现代 Linux 发行版的核心组件，与 cgroup 紧密集成，它的转向直接影响了整个生态。