Kubernetes 1.38 进入发布周期：KubeCon NA 当周，代码冻结定在 11 月 16 日
Kubernetes 1.38 的发布周期表已经把 11 月的关键节点排定。
1. 时间线
| 时间 | 里程碑 |
|---|---|
| 11 月 4–5 日 | 特性博客冻结（Week 10） |
| 11 月 6 日 | 代码冻结例外申请截止 |
| 11 月 9–12 日 | KubeCon NA（Week 11） |
| 11 月 16–17 日 | 代码与测试冻结（Week 12） |
对上游贡献者来说，11 月 16 日是硬边界：之后只有例外流程能进 1.38。
2. 为什么把冻结放在 KubeCon 之后
会议周（11 月 9–12 日）期间，社区的主要精力在会场，代码评审与 CI 注意力都会下降。把冻结放在会议之后一周，给了一个缓冲：会上聊出来的问题还有时间落地。
这也是 Kubernetes 近年固定的节奏——KubeCon 与发布周期对齐，避免"会开完了、版本也冻了"的尴尬。
3. 同期的一个小版本
k3s 在 11 月 3 日发布了 v1.37.2+k3s1，把 Kubernetes 更新到 v1.37.2，并同步了 containerd、runc、Traefik、CoreDNS 等组件版本。
对边缘与轻量集群的用户，这个版本比 1.38 的日程更有即时意义：它是已经可用的稳定更新，而 1.38 还在候选阶段。
4. 该做什么
准备跟进 1.38 的团队，现在可以做的事有三件：把弃用 API 的扫描跑一遍（pluto 或 kubent 这类工具），确认没有用到计划移除的 API；在测试集群部署 1.38 的 alpha/beta 版本观察控制器行为；把 CNI、CSI 与 ingress 控制器的兼容矩阵对一遍。
用托管服务的团队，等云厂商的版本公告比追上游更实际，但要提前知道哪些自建组件会卡住升级。
小结
1.38 的节奏已经清晰：11 月中旬冻结，之后进入 RC 与正式发布阶段。真正需要行动的不是"记住发布日期"，而是在冻结之前把不兼容项清掉。
KubeCon NA 与发布周期重叠，也意味着这一周的讨论会直接影响 1.39 的方向——想提特性的，现在就该准备提案。
数据来源与检索时间
检索时间 2026-11-10。
| 来源 | URL | 对应数据 |
|---|---|---|
| Kubernetes 发布信息页 | https://www.k8s.dev/resources/release/ | v1.38 周期：11-04/05 特性博客冻结、11-06 例外申请截止、11-09 至 11-12 KubeCon NA、11-16/17 代码与测试冻结 |
| k3s 发布说明 v1.37.X | https://docs.k3s.io/release-notes/v1.37.X | v1.37.2+k3s1 于 2026-11-03 发布，Kubernetes v1.37.2，同步 containerd/runc/Traefik/CoreDNS 等版本 |
核验说明
- 时间线取自 Kubernetes 官方发布页；k3s 版本号与组件版本取自其发布说明。
- 未做：没有部署 1.38 的任何版本，也没有核对各云厂商的托管版本计划；"把冻结放在 KubeCon 之后"的原因分析属推断。