Amazon EKS 近期推出了对 Kubernetes 版本回滚的支持。在升级后 7 天内，若出现问题，运维人员可以将集群的控制平面回滚至之前的 Kubernetes 版本。该功能为团队提供了一道安全保障，使其能够从出现问题的更新中快速恢复，从而降低了就地升级集群的风险。
在回滚 Kubernetes API 服务器和控制平面组件的同时，EKS 会保留所有的 etcd 数据、工作负载和持久卷。根据文档说明，对于运行 EKS 自动模式的集群，EKS 会在回滚控制平面之前自动回滚处于自动模式的工作节点，并提供加速或取消该过程的选项。
在解释“为何长期以来 Kubernetes 控制平面升级都是一条单行道”时，亚马逊云科技高级解决方案架构师 Micah Walter 写道：
由于 Kubernetes 每年发布三个次要版本，管理着数百个集群的团队——尤其是在受监管的环境中——往往会完全推迟升级，因为他们不确定一旦出现问题能否恢复系统。结果就是集群停留在旧版本上，无法获得安全补丁，并最终面临支持期限到期的困境。
与亚马逊云科技专有的容器编排工具 Amazon ECS 不同，EKS 是一项托管的 AWS 服务，负责运行和维护 Kubernetes 控制平面，从而让开发人员能够部署和运维容器化应用程序。
回滚操作每次仅涉及一个次要版本，这与 EKS 的增量升级路径相一致。EKS 会运行集群分析来检查回滚准备情况，并在继续操作之前提示节点版本不匹配或存在附加组件依赖关系等问题。使用 --force 参数可以跳过这些检查。
开源 Kubernetes 之前没有提供控制平面回滚功能，虽然 KEP-4330 通过添加模拟版本实现了回滚，但这一限制导致企业不得不采用诸如“预热期（bake periods）”、分批部署、自动化签核以及漫长的升级周期等变通方案。EKS 的回滚功能是 AWS 社区长期以来一直存在的一个诉求，开发人员之前曾经讨论过各种变通方案。Uniphore 高级云与 DevOps 负责人 Ismail Baig 评论道：
亚马逊云科技刚刚为 EKS 团队提供了我们多年来一直呼吁的功能：原生 Kubernetes 回滚功能……在此之前，团队只能采用两种变通方案，而且成本都很高：蓝/绿集群部署会在升级期间使基础设施成本翻倍；手动快照不仅消耗大量的工程工时，还无法保证操作能够顺利完成。
亚马逊云科技并不是首个在托管 Kubernetes 集群中添加回滚功能的云服务提供商：虽然 Azure AKS 仅提供部分支持（仅限于节点池回滚），但 GKE 在 1 .33 版本中引入了控制平面次要版本回滚功能，该功能基于谷歌与社区共同开发的上游 Kubernetes 能力。Walter 补充道：
为了让你能够掌控这一过程，我们引入了一个取消 API，允许你在任何时候停止节点回滚。如果你认为回滚耗时过长，或者希望调整策略，可以取消操作并调整中断预算以加快进度，或者选择其他解决方案。
The Duckbill Group 首席云经济学家 Corey Quinn 在其新闻通讯中写道：
Kubernetes 升级终于有了“撤销”按钮。此前，为了避免陷入“单向门”的困境，运维团队会花数年时间构建“预热期”，并制定长达数月的升级流程。
在 LinkedIn 上，Tnker DevOps 工程师 Ashref Gamoudi 补充道：
亚马逊云科技刚刚解决了每位 Kubernetes 工程师最大的担忧之一。
目前，在所有提供 EKS 的区域，Kubernetes 版本回滚功能均已经上线，而且不需要额外的费用。控制平面回滚适用于所有 EKS 集群，而节点回滚则仅限于运行 EKS 自动模式的集群。EKS 提供标准支持和扩展支持的 Kubernetes 版本均支持回滚。
原文链接：https://www.infoq.com/news/2026/07/eks-version-rollback/
