TRAE-AI编程
Kubernetes 1.37.0 已于 2026 年 8 月 26 日发布，随后在 9 月 15 日推送了补丁版本 1.37.1。新手真正要回答的不是"新特性怎么用"，而是三件事：你现在用的版本还在不在官方支持窗口里、升级会不会触发版本偏差、你有没有可以回滚的演练环境。本文先带你核对官方发布时间与支持窗口，再把"学习、测试、生产"三种场景分开判断，最后给一份能照着执行的检查清单与回退边界。文中命令以 kubeadm 部署的集群为例，全部标注为预期结果、未在本机执行，请先在测试环境跑通。
先看结论
- 纯学习环境：可以装，而且建议装最新的 1.37.x。 学习环境不承担业务，装最新版能少踩已经修掉的坑，跟教程演练也更容易对齐。
- 测试或预发集群：建议升，但必须逐级升。 kubeadm 不支持跨 minor 跳级，1.35 要先到 1.36 再到 1.37。
- 生产集群：先看支持窗口再决定。 官方只维护最近三个 minor 版本（当前是 1.35、1.36、1.37），1.34 已于 2026 年 10 月 27 日停止支持。如果你还停在 1.34 或更早，那才是真正要排期的事。
- "新特性"本身不是升级理由。 对绝大多数团队，升级的收益来自支持窗口和安全补丁，而不是某个具体特性。
一、先核对发布日期与官方变化
动手之前先把三个事实核对清楚，别凭印象做决定。第一是发布时间：1.37.0 的发布日是 2026-08-26，官方在 2026-07-31 的"抢先看"博客里公布过计划日期，1.37.1 补丁则发布于 2026-09-15。第二是支持窗口：Kubernetes 项目只维护最近三个 minor 分支，1.37 的停止支持时间是 2027-10-28，1.19 及之后的版本大约有一年的补丁支持期。第三是变化清单：具体新特性以官方 CHANGELOG 与发布说明为准，本文不逐条转述；任何一条特性在落到你的集群之前，都要先在非生产环境验证一遍。
版本号本身也值得看一眼。Kubernetes 采用 x.y.z 语义化版本，y 是 minor（功能版本），z 是 patch（补丁版本）。补丁版本可以放心跟，minor 版本才需要评估，这是新手最容易搞混的一点——看到 1.37.1 就犹豫，其实它只是 1.37.0 的补丁，不包含新功能。
如果你还不熟悉这套对象模型与命令行，可以先跟一遍 Kubernetes 教程，把 Pod、Deployment、Service 的关系跑通，再回来看升级这件事，判断会清晰很多。
二、这次变化会影响谁
按角色分开看，结论差别很大。只在学习 Kubernetes 的人，影响几乎为零，你要关心的是本地集群能不能跑起来、kubectl 客户端版本与服务端对不对得上；维护测试集群的人，影响集中在升级路径上，测试集群的价值就是提前暴露不兼容，所以它反而应该比生产更早升；维护生产集群的人，影响落在支持窗口和版本偏差上，集群里 kube-apiserver、kubelet、kubectl 之间允许的偏差有明确上限，升级顺序也有讲究。
顺带纠正一个常见误解：版本新不等于更稳定。一个新 minor 刚发布时，生态组件（CNI 网络插件、CSI 存储插件、Ingress Controller、各类 Operator）往往还没跟上。只要你的集群真正依赖的组件没有声明兼容 1.37，就先别动。这也是很多团队刻意比官方发布晚一两个月再跟的原因——不是保守，是等生态。
从性能与适用边界上说，升级带来的实际收益通常来自这三处：新版本对大规模集群的调度与 API 响应优化、内核与容器运行时新特性的支持、以及不再需要为旧版本打 workaround 补丁。反过来，代价是一次不可避免的控制面重启和业务 Pod 迁移窗口，这两项必须提前算进停机预算。
三、新手该不该现在跟进：三种情况分开判断
把判断口径列成一张表，对着自己的情况直接查：
| 你的情况 | 建议 | 理由 |
|---|---|---|
| 本机或学习环境 | 直接装 1.37.x | 无业务风险，收益是少踩旧版本已修的坑 |
| 单机测试集群 | 升，先演练再执行 | 提前暴露组件不兼容 |
| 生产集群且当前 ≥1.35 | 排期升，不必抢第一波 | 支持窗口还长，先等生态组件跟上 |
| 生产集群且当前 ≤1.34 | 尽快排期 | 已出支持窗口，不再有安全补丁 |
| 只写 YAML 不碰集群 | 不用升 | 先确认 kubectl 与集群的版本偏差即可 |
这里补一条容易被忽略的边界：kubectl 客户端与集群的版本偏差允许在正负一个 minor 之内。也就是说，用 1.36 的 kubectl 去操作 1.37 的集群是可以的，反过来也行；但如果你的 kubectl 还停在 1.33，某些新 API 的字段就会莫名其妙地报错，而报错信息通常不会直接告诉你"版本太旧"。所以即使集群不升，客户端也建议保持在相邻版本。
四、升级或试用前的检查清单（含验证与回退）
下面这份清单按"检查现状 → 确认可升级 → 执行 → 验证 → 回退"排列。命令均为 kubeadm 集群的通用写法，结果标注为预期结果（未在本机执行），请在测试环境先完整跑一遍再上生产。
1. 先看清楚现状
kubectl version --short
kubectl get nodes -o wide
预期输出里能看到客户端与服务端的版本号；kubectl get nodes -o wide 会列出每个节点的 Kubernetes 版本、内网地址和容器运行时，这一步用来确定你到底从哪个版本出发。
2. 确认能不能升
kubeadm upgrade plan预期结果是列出可升级到的目标版本和需要手动升级的组件。常见失败分支是提示目标版本不可用、或者要求逐级升级——根因是 kubeadm 不允许跨 minor 跳级，必须 1.35 → 1.36 → 1.37 依次执行。遇到这种情况不要试图一次跳过去，先补齐中间版本。
3. 排空节点再升级控制面
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
kubeadm upgrade apply v1.37.1
kubectl uncordon <node-name>
drain 把节点上的工作负载迁走并标记为不可调度，uncordon 恢复调度。失败分支：如果存在不受控制器管理的裸 Pod，drain 会卡住并报错，需要先清理这些 Pod，或改用 --force（会丢数据，慎用）。
4. 验证结果
kubectl get nodes
kubectl -n kube-system get pods预期结果是所有节点回到 Ready 状态，kube-system 下核心 Pod 全部 Running。只要有一个节点 NotReady，就停下来排查，不要继续升级下一个节点——这是升级流程里唯一不能妥协的暂停点。
5. 回退边界
kubeadm 没有一键降级。 真正的回退手段是升级前的 etcd 快照，以及控制面节点的配置备份。所以在执行 upgrade apply 之前，先确认你对 etcd 做过备份并能恢复，这是整个流程里唯一不能省的一步。没有备份就没有回退，这不是保守，是底线。
集群运维这一步涉及的组件较多，命令记不全很正常，可以对照 Kubernetes 集群运维 的集群管理章节逐条核。
总结
Kubernetes 1.37.0 于 2026-08-26 发布、1.37.1 于 2026-09-15 发布，这些是可以核对的官方事实；而"要不要现在跟进"取决于你的环境类型，不取决于版本号。学习环境直接装最新版，测试集群先演练再逐级升，生产集群先看支持窗口与生态组件兼容性，停在 1.34 及更早的集群则应尽快排期。真正决定成败的不是新特性，而是升级前的 etcd 备份和升级后的节点状态核验。
常见问题
Q：我刚学 Kubernetes，该从 1.37 开始学吗？
可以。学习环境和生产环境是两回事，本机用 kind、minikube 或单机 kubeadm 装的集群不承担业务，装 1.37.x 能少遇到旧版本已知问题。需要注意的是别把学习环境的操作习惯直接带到生产集群。
Q：1.37.1 和 1.37.0 差别大吗？
1.37.1 是补丁版本，按语义化版本约定只包含修复，不引入新功能。补丁版本通常可以放心跟，真正需要评估的是 minor 版本（从 1.36 到 1.37）这一步。
Q：生产集群停在 1.34 会有什么后果？
1.34 已于 2026-10-27 停止支持，之后不再有官方安全补丁。官方只维护最近三个 minor 分支（当前为 1.35、1.36、1.37），所以这类集群应该尽快排期升级，优先级高于追新版本。
Q：新特性是不是越早用越好？
不是。特性在官方发布说明里标记为 GA 才适合进生产，处于 alpha 或 beta 的特性可能需要显式开启特性开关，且后续版本仍可能变更。对新手来说，先把稳定功能用对，比抢先体验更有价值。
延伸学习
- 同类"新版本到底该不该升"的判断思路，可以参考 TypeScript 7 升级决策 这篇笔记里的取舍方式。
- 新特性落地前怎么评估适用场景，ES2023新特性 这篇笔记给出了逐条核对的做法。
- 新语言、新版本涌现时怎么判断投入时机，仓颉编程语言 这篇笔记提供了另一个视角。
