Kubernetes 社区讨论了 cgroup v2 的迁移。cgroups 是 Linux 内核的资源管理特性，Kubernetes 用它给容器分配 CPU 和内存。v1 到 v2 的变化不只是版本号，资源模型本身被重做了。
v1 的根本问题
cgroup v1 按资源类型分了多个独立层级树——cpu、memory、blkio 各自一棵树。同一个进程可以在不同树里属于不同节点，导致资源归属不一致，控制器之间无法协同。这在实践中表现为：内存回收时无法准确判断 CPU 侧的配额状态，反过来也一样。
v2 的统一层级
v2 只有一棵统一的树，所有控制器挂在同一层级上。这让跨资源的协同成为可能——内核可以基于统一视图做决策，比如 PSI（压力失速信息）驱动的回收。
对 Kubernetes 用户的影响
第一，内存 OOM 行为改善。v2 下内核能更准确地判断是整组超限还是单进程超限，减少误杀。
第二，PSI 支持让基于压力的内存回收成为可能。以前只能等 cgroup 达到 limit 才触发 OOM，现在可以在压力出现时就感知并响应。这在运行内存密集型负载时差异明显。
第三，CPU 的权重模型变了。v1 用 cpu.shares，v2 用 cpu.weight，映射关系非线性，老的 share 值需要换算。
迁移检查清单
容器运行时版本、kubelet 的 cgroupDriver 设置、节点操作系统的 cgroup 挂载方式、监控系统的指标采集路径（很多老 exporter 只认 v1 的 stats 文件路径）、以及任何直接读写 cgroup 文件的自建工具。
最容易忽略的一项
监控系统。v1 和 v2 的 stats 文件位置和字段都有变化，指标面板可能照常显示但读的是错的。迁移后要重新核对一次指标含义。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。