为什么现在必须关注 cgroup v2

cgroup 负责限制和统计容器的 CPU、内存与 I/O。Kubernetes 对 cgroup v2 的支持早已稳定，而 cgroup v1 正在退出：从 Kubernetes 1.35 开始，failCgroupV1 默认开启，仍使用 v1 的节点可能无法启动 kubelet。

cgroup v2 带来的变化

• 使用统一层级，接口和资源继承关系更一致。
• 支持更完善的内存保护与 Memory QoS。
• 提供 PSI 压力指标，帮助发现 CPU、内存和 I/O 争用。
• 更适合 rootless 容器的控制器委托。
• OOM 时可以按容器进程组处理，减少半失效状态。

快速检查

在节点执行：

stat -fc %T /sys/fs/cgroup/

返回 cgroup2fs 表示正在使用 cgroup v2。

还应确认：

• Linux 内核至少满足官方支持要求，使用 Memory QoS 时优先选择更新内核。
• containerd 或 CRI-O 支持 cgroup v2。
• kubelet 与容器运行时使用一致的 systemd cgroup 驱动。
• 监控程序、JVM、Node.js 和自动 CPU 配额工具能识别 v2。

迁移方法

不要直接在全部节点上修改启动参数。先新增一个 cgroup v2 节点池，部署代表性工作负载，观察资源限制、OOM、监控指标和存储性能，然后逐步 drain 旧节点。

如果必须临时继续使用 v1，可以评估 failCgroupV1 的兼容开关，但它只是迁移缓冲，不应成为长期方案。官方计划继续移除 v1 支持。

常见故障

迁移后 CPU 权重数值可能变化，依赖具体 cgroup 文件路径的脚本也可能失效。排查时要从 Kubernetes 资源声明、CRI、OCI runtime、systemd scope 一直核对到 cgroupfs，而不是只看 kubectl 中的配置。

原始资料：Kubernetes cgroup v2 官方指南