Amazon EKS 增加版本回滚后，Kubernetes 升级手册该改一遍了。过去很多平台团队升级控制面时，心里都知道缺一条原生退路，只能靠蓝绿集群、快照、暂停窗口和一堆人工检查来兜底。现在 EKS 给了一个更直接的选择，控制面升级后可以回到前一个小版本。
这不是让升级变随意。恰好相反，回滚能力会逼团队把升级步骤拆得更清楚。
回滚窗口要写进变更单
AWS 文档里写得很具体，回滚要在升级完成后的 7 天内发起，只能回到前一个小版本。集群必须是原地升级上来的，创建时就在当前版本的集群不能回滚。这个限制很实际，也很容易被值班团队忘掉。
所以变更单里要多几项。升级完成时间、可回滚目标版本、窗口截止时间、回滚负责人、是否涉及扩展支持费用。别等事故来了再查文档，那个时候每一分钟都很贵。
先观察控制面，再动数据面
AWS 博客里给出的建议很接地气，把控制面升级和数据面升级分开，中间留出观察期。这样做看起来慢，但它能保留回滚空间。控制面刚升上去时，先看 API server、控制器、核心插件和关键业务的行为，别马上批量滚动节点。
如果节点已经跟着升到了新版本，回滚就要处理 kubelet 版本偏差。Auto Mode 集群由 EKS 管一部分数据面回滚，托管节点组、自管节点、混合节点仍然要平台团队自己安排。这个差别要写清楚。
Insights 只能帮你发现一部分风险
EKS Rollback Readiness Insights 会检查 API 兼容、字段变化、集群健康、kubelet 和 kube-proxy 版本偏差、托管插件兼容。对 Auto Mode，还会看 NodePool 中断预算、PDB 和 do-not-disrupt 标记。
这些检查很有用，但别把它当成免死牌。AWS 文档也说了，自管插件、自定义 AMI、业务控制器、第三方工具的兼容性还是客户自己负责。平台团队要把 ingress、service mesh、监控 agent、存储插件、证书控制器放进自己的升级前检查。
不要轻易用 force
文档允许在部分 insight 异常时使用 force 绕过检查，但这个按钮不该出现在日常流程里。它只适合明确知道风险来源、已经接受后果的场景。更稳的处理是修掉 ERROR 或 UNKNOWN，再刷新 insights，再发起回滚。
还有一个容易踩坑的点，force 不能绕过所有前置条件。7 天窗口、创建版本限制、连续回滚限制、部分 EKS 功能兼容限制仍然会拦住请求。Auto Mode 的中断预算和 Pod 保护也不会因为 force 消失。
把回滚做成演练，不要只写在文档里
真正可用的回滚流程，要能在非生产集群里跑通。平台团队至少要演练这些动作，列出 ROLLBACK_READINESS insights，处理一个插件不兼容，回滚一个托管节点组，发起控制面回滚，查询 update 状态，验证核心服务。
优易云在给客户做运维平台时，会把这类动作放进发布看板。谁执行了哪一步，系统返回什么结果，下一步由谁确认，都留痕。Kubernetes 升级不是凭勇气过河，手册和自动化要一起工作。
升级策略可以更积极，但不能更粗糙
EKS 版本回滚降低了控制面升级的心理压力，也减少了部分蓝绿兜底成本。可它没有替团队验证业务兼容性，也没有替自管节点和插件负责。平台团队可以更快推进受支持版本，但升级管道必须更细。
一个靠谱的升级管道应该包含预检、控制面升级、观察期、数据面升级、插件验证、回滚演练和费用检查。少一项，事故就会从那一项钻出来。
