K8s 1.30 正式停止维护：停在旧版本意味着每个新 CVE 都无解

Kubernetes 1.30 在 10 月底停止维护。华为云 CCE 与字节跳动 VKE 均自 2026 年 10 月 30 日 00:00 起停止对 1.30 集群的维护：现有集群仍可运行，但不再有安全更新、漏洞修复与技术支持，也无法用该版本新建集群。

EOL 的真实成本

不是「还能跑」就没事。容器编排层是集群的根，一个未修补的提权漏洞在多租户场景里等价于逃逸跳板。而且越往后拖，跨版本升级的路径越长，风险越大。

跨版本跳跃有必经停靠点

Kubernetes 不支持大跨度升级，1.28 到 1.33 必须逐个小版本走。每个中间版本都要过一遍 API 废弃检查、工作负载回归、插件兼容验证。计划要按周算，不是按天。

升级前必须先扫的三类东西

一是废弃 API 的实际调用，用 kubent 或 pluto 扫一遍清单和 Helm chart；二是 CNI、CSI、Ingress 这些带特权权限的插件版本是否支持目标版本；三是自建 operator 和 webhook，它们最容易在版本升级后挂掉。

这周该做的动作

做一次全量集群版本盘点。把每个集群的版本、EOL 日期、责任人列成一张表。停在 1.30 及更早的集群，风险敞口从现在开始单调上升，没有任何补丁能救。

顺带一句

K8s 的发布节奏是每年三个小版本，每个版本维护约 14 个月。这个节奏意味着任何超过一年的升级计划都会踩到 EOL。把版本治理做成常态流程，比每次救火便宜得多。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

逐个小版本走最容易被低估，1.28 到 1.33 中间要过四个版本，每个都要扫废弃 API 并验证 CNI、CSI 插件。计划按周算不是按天算，我们已经把升级排到年底了。

跨版本升级的必经停靠点这条是真话。我们 1.24 到 1.28 走了整整一年，每次只升一个小版本，中间还得处理被弃用的 API，时间主要耗在业务方适配而不是集群本身。建议把 1.30 到 1.33 的路径提前排进季度计划，别等出 CVE 才想起升，那时候窗口期根本不够。

我们集群是托管版，版本号还停在 1.30，控制台一直提示可升级但没敢动。想请教升级该先动控制面还是节点，另外自建的 Prometheus 和 ingress 会不会受影响，要不要先在测试集群演练一遍。