一个版本从发布那天起，倒计时就已经写好了。Kubernetes 1.34 的终点是 2026年10月27日，它的最后一个补丁是 9月15日发布的 1.34.12。到了那天，release-1.34 分支的 cherry pick 很快关闭，这个分支不会再有新的补丁版本。
项目不再把 1.34 里的缺陷当成自己欠谁的修复。最后一个维护版本和下一个维护版本之间的间隔，会一直拉大下去。
这个十四个月的窗口并不是临时定的。按项目的年度支持 KEP，每个次要版本拿到大约十四个月：十二个月标准支持期，加两个月维护模式，然后生命周期结束。日期都落在每月28日，因为每个月都有28号，日历上看起来像一套固定图案。
时钟从发布日开始走，所以版本一上线，结束日期就看得见。盯着集群上游版本的人有十四个月的通知期，不必等一纸公告。项目也提醒，发布时间线可能随缺陷修复的严重程度浮动。
最后两个月的维护模式本来就是更窄的一套规则。补丁发布页面把它描述为一个两个月窗口，期间发布经理可以针对一份明确清单切出额外版本：
- 带 CVE 编号的漏洞，由安全响应委员会给出建议；
- 依赖问题，包括基础镜像更新；
- 核心组件的严重问题。
不在这几类里的 bug，只能等版本升级。
截至 2026年10月23日，还有三个分支在收补丁，各自的最新补丁和结束日期都列在发布页上：
- 1.37：最新 1.37.1，2026年9月15日发布，2027年10月28日关闭；
- 1.36：最新 1.36.5，同日发布，2027年6月28日关闭；
- 1.35：最新 1.35.9，同日发布，2027年2月28日关闭。
1.34 在10月27日离开这份名单。它身后的 1.33 已于 2026年6月28日关闭，停在 1.33.13；1.32 于 2026年2月28日关闭，停在 1.32.13。发布页把后果写得很直白：生命周期结束的版本不再收到安全更新和缺陷修复。
不过这个日期是一份承诺，也带着有记录的例外史。1.26.15 在 2024年3月发布，晚于 1.26 的结束日期，为的是接上一个修复了若干 Go CVE 的新版 Go。1.25.16 在 2023年11月跟上，晚于其结束日期，修的是 CVE-2023-5528。1.24.17 在 2023年8月到来，那时该分支已经关闭，修的是 CVE-2023-3676 和 CVE-2023-3955。
这些记录勾勒出例外的形状：语言工具链或集群本身的严重漏洞，仍可能从已关闭的分支里拉出一个补丁。但没人该按这个来排期。例外版本只在项目判断风险足够时才会出现。
维护模式的第二类问题会溢出集群之外，就是依赖问题，包括基础镜像更新。还在收维护版本的分支，能拿到重新构建、底层系统库已打补丁的基础镜像；分支一关，项目就不再提供这些重建。
后果会传到扫描流水线。项目在9月重建过的镜像，底子仍是9月的基础镜像，只要镜像还留在仓库里，读镜像元数据的扫描器就会一直报告基础镜像里的内容。修复工作转移到运维方自己的重建流程，有自己的负责人和自己的排期。
从关闭分支升走的路径是固定的。项目的月度补丁日历仍是参照点：它瞄准每月发布节点，提醒时间线可能随修复严重程度浮动，并允许其间出现计划外的关键版本。把升级订在计划中的月度发布旁边，目标版本和它的补丁就落在同一个变更窗口里。
中间版本各自带着弃用项，所以升级计划要按顺序读发布说明。从 1.34 走到 1.37 的团队要读三套说明，删掉后续版本移除的东西，在最终版本的预发集群上验证清单，再动生产。
小平台团队的做法可以很朴素。先从 API 拉出每个集群及其版本的清单，逐条对照 1.37.1、1.36.5 和 1.35.9，把 1.34 及更老的标成未完成。然后选一个目标版本，拿清单去测。如果集群挂载持久卷，v1.37 的卷相关变更值得单独测一遍，存储行为正是升级变成事故的地方。
接着把变更排进补丁窗口，一次升一个集群，记下每个集群事后实际报告的版本。这份登记表就是让下一个结束日期变成日历事项的东西：1.35 在 2027年2月28日关闭，今天记下版本的团队，到时候会看见它来。
日期是提前几年公布的。要做的事就是一张清单、一次测试、一个变更窗口，每个次要版本重复一遍。
热门跟贴