Kubernetes 1.37 起 cgroup v1 节点直接起不来：一份可执行的迁移清单

从 Kubernetes 1.37（2026 年 8 月 26 日）开始，kubelet 在 cgroup v1 节点上不再启动，除非管理员显式设置临时的 failCgroupV1: false。Kubernetes 1.34 已于 10 月 27 日结束支持，1.38 计划在 12 月 16 日移除 cgroup v1 代码。还没动的集群，下一次升级就会直接卡住。

为什么必须换到 v2

cgroup v1 是多个独立层级，每个资源控制器一套，行为在不同发行版之间不一致。v2 统一成单一层级，带来三个真实收益：

• 内存 QoS 有了两级模型。v1 只有硬限制，要么装得下要么被 OOM 杀掉。v2 的 memory.high 会在触发 OOM 之前先限流并回收。
• 容器级 OOM 处理。kubelet 在 v2 节点上默认给每个容器 cgroup 设置 memory.oom.group，OOM 时整组进程一起被杀，不会留下半死不活的多进程容器。
• 每 cgroup 的 PSI 指标。1.36 起 GA，可以监控单个租户或命名空间的压力，在 OOM 之前告警。v1 没有对应能力。

迁移怎么做

先查节点：读 /sys/fs/cgroup 看是不是 cgroup2fs，或者看 /proc/filesystems 里有没有 cgroup2。再确认内核启动参数没有 systemd.unified_cgroup_hierarchy=0。然后逐项排查依赖：老版本容器运行时、把 cgroup 路径写死的监控采集器、依赖 v1 目录结构的自研脚本。

顺序别搞反

先在测试集群把 kubelet、容器运行时、监控三件套升到支持 v2 的版本，再切节点。生产上按节点池灰度，别一次性全切。failCgroupV1: false 只能买时间，方向已经定了。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

迁移清单里最容易漏的是依赖cgroup v1目录结构的自研脚本和监控采集器，这两个不上报错但会静默采到空数据。另外内存QoS那条值得展开：v2的memory.high是先限流再回收，v1只有硬阈值直接OOM，行为差别在内存紧张时才暴露，压测一定要做内存压力场景，别只做CPU。

迁 1.30 节点时最痛的不是 kubelet 起不来，是运行时：cgroupfs driver 的 docker 得先切 systemd，否则节点起来了 pod 也起不来。建议先在灰度节点把 failCgroupV1 设 false 跑一周，看内存压力下 eviction 对不对再动生产。