生产 K8s 升级时 cgroup v1→v2 切换的落地成本：值不值得跟版本升级绑在一起做？

背景 我负责一个 10 节点生产集群（16C64G，CentOS 7.9 + kernel 3.10，K8s 1.26.4，containerd 1.6.24，cgroup v1，CNI Calico 路由模式），跑 30+ 个 Java/Go 无状态服务 + 3 个有状态（MySQL 主从、Redis Sentinel、ZooKeeper）。安全团队要求 Q3 前升到 K8s 1.28+（1.26 已 EOL），同时 containerd 1.7 起对 cgroup v2 的支持更完整，我们内部有人建议"趁这次升级一起把 cgroup v2 切了，省得以后再动一次节点"。

现象 / 卡点 cgroup v1→v2 切换不是改个配置文件就完事的：

1. 底层是 CentOS 7.9（kernel 3.10），内核本身不支持 cgroup v2，必须先把 OS 升到 RHEL 8/9 或 Rocky 9（kernel 5.14+）——这意味着 10 台节点要逐台重装系统、迁移数据、重建容器运行时，窗口期至少 2-3 周；
2. 我们有一批老服务（2020 年的 Java 8 订单服务）用了自研的 cgroup 路径读取逻辑（直接读 /sys/fs/cgroup/memory/ 下的文件）做内存自保护，切到 v2 后路径结构完全不同（unified hierarchy），这些代码要改；
3. 监控栈是 node-exporter + cAdvisor，cAdvisor 在 v2 下的 memory 指标语义有细微变化（memory.high 软限制 vs memory.max 硬限制），告警阈值要重新校准；
4. 最让我犹豫的是：K8s 1.28 本身在 cgroup v1 下跑得好好的，不切 v2 并不会阻塞升级。那"顺便切 v2"的收益到底是什么？

已尝试的排查与结果

• 在 1 台测试节点上做了 Rocky 9 + cgroup v2 + K8s 1.28.5 的全链路验证，K8s 本身没问题，但那个老 Java 8 服务的 cgroup 自保护模块直接 panic 了（路径不存在）；
• 查了 containerd 1.7 release notes，v1 仍被支持，没有 EOL 时间表；
• 问了一个同事的生产集群（K8s 1.29，cgroup v1），他明确说"能不动就不动，v1 又不是不能用"；
• 算了一笔账：10 台节点逐台重装 + 老服务改造 + 监控重校准 + 回归测试，保守估计 3-4 人周 + 至少 2 次变更窗口，如果只做 K8s 1.26→1.28 滚动升级（不动 OS），2 人周 + 1 次窗口就够。

期望得到的答案形态

1. 各位在实际项目里，cgroup v1→v2 切换是跟 K8s 大版本升级绑在一起做的，还是单独排期做的？绑在一起做有没有踩过"两个变更叠加导致故障面翻倍"的坑？
2. 你们切换后，cgroup v1 时代的老代码（自研 cgroup 路径读取、监控 agent、sidecar 里的内存探测）适配工作量大概是什么量级？有没有比较通用的抽象层可以屏蔽 v1/v2 差异？
3. 纯收益角度：cgroup v2 相比 v1，在你们的生产场景里，最明显的实际收益是什么（memory.high 软限制？cpu.max 粒度？统一 hierarchy 简化监控？）——如果收益不足以覆盖切换成本，你们的判断依据是什么？
4. 有没有人踩过"切了 v2 之后某个组件（containerd / Calico / 某个 CRI 插件）出兼容性问题"的坑？具体是什么组件、什么版本、怎么绕的？

欢迎带着具体 OS 版本、K8s 版本、踩坑细节来答，"建议升 v2"这种泛泛之论就不必了。