Kubernetes v1.37 发布前该看什么：cgroup v1 弃用、升级窗口与回滚清单

Kubernetes v1.37 计划在 2026 年 8 月 26 日发布。跑生产集群不用先着急决定要不要立刻升级，优先先排查节点是否还依赖 cgroup v1、kube-proxy 是否使用 ipvs，以及静态 Pod 和 SELinux 卷挂载有没有触碰新的规则边界。目前公开的预览公告内容仍可能调整，升级窗口要以最终正式版 changelog 和你自己集群的验收结果为准。

如果集群已经用了 cgroup v2、kube-proxy 跑的是 iptables 或 nftables 模式，而且没有静态 Pod 直接引用 Secret/ConfigMap，可以先切小范围节点做升级验证；还在依赖 cgroup v1 的节点不要直接切生产流量。

这次升级先分清“已确定”和“计划中”

Kubernetes 官方 v1.37 预览内容明确分了两类信息：一类是已经进入发布准备流程的弃用项和行为变更，另一类是最终版本还可能调整的待确认计划项。官方发布页当前仍把 1.36.2 列为最新稳定补丁版本，v1.37 暂时标记为待发布版本。所以新闻里提到的预计发布时间不能直接当成确定变更日期写到审批单里，真正的上线依据必须以正式版本说明和集群实际验收结果为准。

这也决定了合理的升级顺序：先全量做完兼容性排查，挑一个非核心节点池做试升级，最后再安排存量工作负载迁移。控制面升级成功只能说明 API Server 和相关控制器正常运行，不能替代节点、网络、存储和安全策略的全链路检查。

四类候选动作怎么选

仍是 cgroup v1：先迁移，不要把参数覆盖当方案

v1.37 预览说明提到，自 v1.35 起 kubelet 的 failCgroupV1 默认值就是 true；继续使用 cgroup v1 的节点需要显式覆盖，否则 kubelet 初始化会失败。把它暂时设为 false 可以争取迁移窗口，但这只是短期过渡，因为原地 Pod 调整和分级内存保护等能力依赖 cgroup v2。

stat -fc %T /sys/fs/cgroup
grep cgroup /proc/filesystems
kubectl get nodes -o wide

这些命令只能辅助定位当前环境状态，不能光靠输出结果就断言整集群完全兼容。还要把节点操作系统、容器运行时、kubelet 配置和云厂商提供的节点镜像一起列入变更核对清单，换另一台灰度节点后重新走一遍全量检查。

kube-proxy 是 ipvs：先评估迁移，再接受警告

官方预览把 ipvs 模式划为弃用方向：v1.37 启动时就会弹出弃用警告，计划在 v1.40 默认关闭该模式，v1.43 完全移除。这不代表升级到 v1.37 之后现有服务立刻失效，但后续再新增 ipvs 相关依赖的收益会越来越低。

kubectl -n kube-system get configmap kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep 'mode:'

如果输出是 ipvs，不要只改 ConfigMap 后重启 DaemonSet。应该在灰度节点确认 Service、NodePort、会话保持和监控指标，再按节点池逐步切换。iptables 或 nftables 的具体选择要看内核、规则规模和现有运维能力。

静态 Pod 引用了 Secret 或 ConfigMap：先改清单

v1.37 会禁止静态 Pod 通过 configMapRef 或 secretRef 读取 API 资源，过去能工作的配置属于 bug 行为，不应继续依赖。静态 Pod 由节点本地清单直接拉起，正确做法是把必要配置以节点文件、挂载文件或其他明确的节点级交付方式提供，并在升级前做一次冷启动验证。

启用了 SELinux：把共享卷列为专项验收

SELinuxMount 计划在 v1.37 进入 GA 阶段并默认开启，不过只有 CSI 驱动主动适配支持这个能力时才会实际生效。官方提示，多个挂载不同 SELinux 标签的 Pod 共享同一个节点卷时，新的挂载行为可能和旧的递归重标记逻辑不一样；已经开启 SELinux 的集群要单独做专项验收，没开 SELinux 的集群不会受到这项变动影响。

升级窗口怎么定才不被发布日牵着走

建议你按「能不能快速撤回流量」来定升级窗口，不用刻板跟着版本发布日期卡时间。下面这些动作可以在正式版本发布前提前做完：

1. 导出所有节点的版本、操作系统、容器运行时和 cgroup 模式，把还依赖 v1 的节点统一标注出来。
2. 统计所有节点的 kube-proxy 模式，留存一份当前配置和核心 Service 的连通性基线结果。
3. 扫描静态 Pod 清单，搜索 secretRef、configMapRef 及其等价字段。
4. 选一台可以安全排空业务的节点，完整记录 Pod 驱逐、挂载、DNS、入口访问和指标采集的全流程结果。
5. 确认备份数据可以正常恢复，回滚流程不是简单重跑一次升级命令，要有明确的节点回滚镜像、控制面回滚方案和流量切换路径。

正式发布前后都要留一份差异记录：哪些变更属于官方最终敲定的内容，哪些是你们自有环境的特殊限制。后续集群再出现相关告警时，就能快速区分是版本自带变动还是历史遗留配置问题。

一份可执行的灰度与回滚清单

灰度通过条件

• 灰度节点的 kubelet 可以正常初始化，事件列表里没有 cgroup 相关兼容性报错。
• 核心工作负载走完一次发布、重启和节点排空流程，资源限制和探针行为都没有异常。
• Service、DNS、入口、存储挂载和 kubectl top 的采集链路均有结果。
• 如果集群在用 SELinux 或 ipvs，对应的专项测试用例全部通过，相关告警规则也已经配置完成。

发现问题时先保流量

遇到新节点启动失败，先停止扩容和继续滚动，不要同时修改多项配置。把问题节点从调度池摘出，保留 kubelet 日志、事件、运行时版本和变更前后的配置，再按既定节点镜像或兼容配置恢复。临时保留 failCgroupV1: false 只能作为明确标注时限的过渡措施，不能当作长期回滚策略。

常见误区

常见的踩坑点主要有四类：第一，直接把「v1.37 计划发布」当成「所有变更都已经最终敲定」；第二，只升级控制面，完全不验证存量节点池；第三，把 ipvs 的弃用警告当成突发故障，又把静态 Pod 的历史旧行为当成永久稳定接口；第四，看到灰度验证成功就直接删掉旧节点镜像和历史备份。升级的风险很少来自新功能本身，大多是没给异常情况留足可观测和可撤回的操作空间。

相关问题

Kubernetes v1.37 什么时候正式发布？

官方 v1.37 预览内容标注的计划发布日期是 2026 年 8 月 26 日；正式发布前这个时间点仍可能调整，实际执行要以 Kubernetes 官方发布页和最终版 changelog 为准。

cgroup v1 能否靠配置继续使用？

预览信息显示 v1.37 仍可通过 failCgroupV1: false 暂时覆盖，但官方把它定位为短期过渡。更稳妥的做法是迁移到 cgroup v2 后再扩大升级范围。

升级前只看节点 Ready 状态够吗？

不够。节点 Ready 状态只能说明节点满足基础运行条件，还要额外验证工作负载重启、网络连通、存储挂载、指标采集和安全策略逻辑；用到 ipvs、SELinux 和静态 Pod 的场景还要补充对应的专项验收用例。

最后的选择

如果集群已经跑在 cgroup v2 上，没有静态 Pod 直接引用 API，且 kube-proxy 的网络行为已经有自动化验收能力，可以把 v1.37 安排进下一次常规小版本升级窗口做灰度。如果仍依赖 cgroup v1，或者没法明确评估 ipvs、SELinux 变动的影响，先做兼容性整改会更稳妥。官方发布新闻给出的只是时间节点和变动方向，要不要最终升级，还是要以节点级的验证结果和可回滚能力作为判断依据。