AmazonEKS新增升级后7天内回滚Kubernetes版本的功能

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）”、分批部署、自动化签核，以及更长的升级周期等方式来兜底。对 AWS 社区来说，EKS 的回滚功能一直是个呼声很高的需求，开发人员也曾围绕各种替代方案展开过讨论。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 版本均支持回滚。