托管 Kubernetes 的一个隐性成本是版本支持窗口。三家主流云各支持一个次版本约 14 个月，之后行为分化，但共同点是：要么加钱，要么被动升级。
现状对照
截至 10 月 26 日，1.32 与 1.33 在 EKS、GKE、AKS 上都已经过了标准支持。
1.34 是下一个：AKS 在 2026 年 11 月结束社区支持，EKS 在 12 月 2 日，GKE 在 2027 年 1 月 25 日。
三家之后的处理不一样
EKS 默认把集群转入扩展支持，控制面费用从每小时 0.10 美元涨到 0.60 美元，每个集群每月多约 365 美元。可以把升级策略设成 STANDARD，让它在标准支持结束时自动帮你升控制面。
GKE 在 Rapid、Regular、Stable 渠道上会在版本离开支持时自动升级，Extended 渠道则保留到扩展支持结束，但要额外付费。
AKS 在社区支持结束后，平台会在宽限期后自行升级；要用长期支持必须显式开启并单独计费。
为什么日历比看起来重要
三家都是一次升一个次版本。1.32 要升到 1.34 得走两步，到 1.35 得走三步，每一步都有各自的附加组件与 API 检查。
每次升版都会移除或变更 API。真正让团队翻车的不是控制面升级本身，是工作负载里用了被移除的 API，或者附加组件版本不匹配。这些必须在升级前扫出来。
一份可执行的准备工作
先盘点所有集群版本，标出已经过期和三个月内到期的。再把每个集群里用的 API 资源做一次清单，对照目标版本的移除列表。然后确认附加组件（CNI、CSI、Ingress、监控）有对应版本。最后，先在非生产集群走一遍完整升级，把问题清单固化。
别把自动升级当省事
自动升级只是把决策延后，不是消除。等到平台替你升的时候，出问题的时间点由别人决定。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。
