Kubernetes v1.37 发布后：新集群升级时如何拆分稳定特性与兼容风险

Kubernetes v1.37（代号 Garhwal）已在 2026 年 8 月 26 日发布。新集群要不要马上采用，关键不在于把 Stable、Beta、Alpha 特性全部抄一遍，而在于先把“能直接依赖的能力”和“需要隔离验证的变化”分开，再用一套可回退的验收证据收尾。

这次发布更适合按三层能力来读

官方发布说明仍然沿用 Stable、Beta、Alpha 三种成熟度。对团队来说，成熟度不是“好用/不好用”的评分，而是改变上线策略的信号：Stable 可以进入默认方案，Beta 需要在目标版本上做回归，Alpha 则应当被当作实验能力管理。

这也是 v1.37 这类版本最容易被误读的地方。版本号升级不等于所有新字段都能立刻写进生产清单，更不等于旧控制器、云厂商插件和策略组件会同步完成兼容。

升级前先画出自己的兼容压力

一个新集群通常同时包含 kube-apiserver、kubelet、容器运行时、CNI、CSI、Ingress 或 Gateway 控制器，以及 admission webhook。真正的风险往往藏在组合里：单看 Kubernetes 核心组件没有问题，接上旧版本插件后才出现字段被忽略、Webhook 超时或 Pod 无法挂载。

可以先做一张版本矩阵，至少记录控制面、节点、运行时、网络插件、存储插件和策略组件的当前版本、目标版本、官方支持范围与回滚方式。这里别急着改配置，先把“谁负责兼容”写清楚。

组件                 当前版本       目标版本       验收证据
control plane        v1.36.x        v1.37.x        API discovery 无异常
node/kubelet         v1.36.x        v1.37.x        节点 Ready 且无压力回退
CNI/CSI/controller   供应商版本     兼容版本       网络与挂载回归通过

把稳定能力和实验能力放进不同的发布轨道

Stable：进入基线，但仍要验证旧资源

稳定特性可以进入集群基线，但上线前仍要检查 CRD、Webhook 和控制器是否使用了已变化的 API 行为。基线验收不只看新对象能否创建，还要看旧 Deployment、Job、Service 和 PVC 是否能按原有方式滚动更新。

Beta：单独建立灰度命名空间

Beta 能力适合放在专用命名空间，用一套最小工作负载确认字段、事件和指标是否符合预期。灰度期间保留原方案，让业务流量可以切回；不要把 Beta 字段直接复制到所有 Helm values 或公共模板。

Alpha：保留实验开关和退出路径

Alpha 能力要记录启用条件、影响的控制器和关闭后的恢复动作。实验完成后，清理测试资源并确认关闭开关不会留下不可解析的对象或卡住的 finalizer。

一次升级验收至少要覆盖四条真实路径

发布当天的版本字符串只能证明组件启动了，不能证明集群可用。我更建议把验收拆成四个小场景：一个普通 Deployment 的滚动发布、一次 admission 拒绝、一个跨节点网络请求和一个持久卷挂载。每个场景都保存事件、控制器日志和最终状态。

1. 先执行 API discovery，确认核心资源与扩展资源都能返回；再观察 kube-apiserver、scheduler、controller-manager 的错误计数。
2. 发布一个带 readinessProbe 的测试 Deployment，确认新 Pod 能调度、启动、滚动替换，旧副本不会无故消失。
3. 用一条明确会被策略拒绝的测试清单验证 admission webhook，记录拒绝原因、响应时间和恢复动作。
4. 让测试 Pod 跨节点访问 Service，并挂载一块测试 PVC；网络和存储都通过后，再把灰度命名空间接入业务流量。

哪些信号说明应该暂停采用

如果插件的兼容列表没有覆盖目标版本，或者升级后出现 API discovery 错误、Webhook 大量超时、节点反复 NotReady、PVC 挂载失败，就先暂停扩容。这个结果先别下结论为“v1.37 有问题”，应当把失败组件、事件时间线和回退结果分离记录。

回退也要有边界：控制面版本、节点版本和数据面插件不能随意交叉降级；涉及 CRD 或持久化数据时，先确认旧版本是否能读取已经写入的新字段。没有可验证的回退路径，就不要把实验特性当成升级理由。

给新集群的落地判断清单

• 是否保存了当前资源清单、插件版本和关键指标基线？
• Stable、Beta、Alpha 是否分别对应默认、灰度、实验三种发布轨道？
• 是否用真实工作负载验证了 API、调度、网络、存储和策略链路？
• 失败时能否说清楚回退到哪个版本、由谁执行、如何确认恢复？

相关问题

Kubernetes 小版本升级能直接跳过灰度吗？

不建议。至少应在与生产插件相同的测试集群完成一次版本矩阵和四条真实路径验收。

只升级控制面、不升级节点可以吗？

要以官方版本偏差策略和发行版支持范围为准，不能只凭过去的经验判断。

如何判断新特性值得采用？

看它是否解决当前的明确压力，并且有稳定等级、插件兼容证据、可观测指标和退出路径四项支撑。

Kubernetes v1.37 的发布信息值得关注，但采用动作应该从自己的版本矩阵和回退证据开始。先把成熟能力纳入基线，再把 Beta 与 Alpha 放到可隔离、可观察、可撤回的轨道，升级才不会变成一次全量押注。