EKS支持Kubernetes版本回滚：7天内撤销升级的条件与操作方法
我先依据 AWS 原文梳理回滚机制、适用边界和操作要点，再整理成待审核的文章前半部分。
一句话结论：EKS 的 Kubernetes 版本回滚为升级失败提供了 7 天内的补救窗口，但它主要针对控制面，不能替代对节点组、附加组件和业务数据的升级前检查。
是什么，发生了什么
AWS 在 EKS 中引入 Kubernetes 版本回滚能力：集群升级后，如果控制面升级失败、卡住或出现不符合预期的行为，用户可以在升级发起后的 7 天内，将集群恢复到升级前的 Kubernetes 版本，无须重建集群。该机制的价值在于缩短故障处理路径，避免因一次控制面升级失败而重新创建集群、迁移工作负载。
这里的“回滚”不是完整环境快照恢复。控制面版本可以回到升级前状态，但节点组、托管附加组件以及用户部署的工作负载不会因此自动恢复到升级前版本。升级前后若存在版本偏差，仍需根据兼容性要求单独处理。
使用前需要确认的边界
回滚窗口以升级操作为起点，超过 7 天后不能再依赖该能力撤销版本变更。因此，升级完成后应尽快观察控制面状态、节点注册、关键附加组件和业务健康度，并保留升级前后的版本记录。
具体可回滚的 Kubernetes 版本范围、集群类型及可用区域，应以 EKS 控制台、API 返回结果和当前区域文档为准，不宜仅根据“支持回滚”推断所有集群都适用。执行前还应确认回滚入口是否可见、目标版本是否为升级前版本，以及当前升级任务是否已进入允许回滚的状态。
操作与风险
发现升级异常后，应先查看集群更新事件和控制面状态，再从 EKS 提供的回滚入口发起操作。回滚期间不要重复提交版本更新，也不要贸然删除集群或改动大量工作负载。该过程不会以重建集群的方式处理，持久化数据也不应被当作自动恢复对象；仍需依赖现有备份和灾备方案。
我将补充回滚后的验证、故障处理、适用限制与替代方案，并把无法从原文确认的范围标为发布前核对项。
回滚后的验证与处理
回滚完成后，不要只检查控制面版本。应依次确认集群状态为 ACTIVE、API Server 可访问、节点重新注册，随后检查托管节点组、托管附加组件和关键工作负载的状态。可以对比升级前保存的 Kubernetes 版本、节点镜像、附加组件版本及业务健康指标，确认不存在因版本不匹配引起的持续性故障。
控制面回滚不会自动撤销节点组升级，也不会还原 CoreDNS、 kube-proxy、Amazon VPC CNI 等附加组件的版本。若节点或附加组件已经升级，应依据兼容性矩阵单独调整；不要在控制面尚未稳定时同时进行多项变更。回滚具体耗时取决于集群状态和 AWS 后端处理进度，发布前建议人工验证控制台和 API 返回的实际状态变化。
失败时如何处理
如果回滚入口不可用、操作失败或集群长时间处于更新状态，应先保存更新事件、审计日志和相关错误信息，避免反复提交升级或回滚请求。超过 7 天后，不能把该功能当作通用降级工具；如果控制面仍无法恢复，应按照 AWS 支持流程处理，并准备使用备份恢复、重新创建集群后迁移工作负载等替代方案。
该能力不等同于 etcd、节点文件系统或业务数据快照。持久卷、数据库和集群外部依赖仍需使用各自的备份与灾备机制。回滚期间的计算、存储及其他 AWS 资源费用也不会因控制面版本恢复而自动消失，具体收费应以当前区域价格说明为准。
适用场景与替代方案
这项能力适合处理控制面升级后立即出现的兼容性问题、升级任务异常或关键 API 行为异常，尤其适合作为升级窗口内的快速止损措施。它不适合替代常规升级演练、版本兼容性检查和跨区域灾备。无法回滚或需要恢复更广泛环境时，应优先依据现有备份、基础设施即代码和集群迁移方案执行恢复。
发布前建议核对
- 支持回滚的 Kubernetes 版本范围、集群类型及所在区域。
- 回滚窗口究竟从升级发起、完成还是其他事件时间点开始计算。
- 控制台、API 或 CLI 的实际入口、状态条件及执行时长。
- 节点组、附加组件、持久化数据和计费是否需要单独处理。