Amazon EKS 新增 Kubernetes 版本回滚：7 天窗口与 Auto Mode 注意事项
Amazon EKS 现在支持 Kubernetes 版本回滚：集群升级后，如果在七天内发现兼容性或依赖问题，可以将控制面退回升级前的 Kubernetes 次要版本，不需要重建集群。
这项功能解决的是 Kubernetes 控制面升级长期存在的“单向门”问题。原生 Kubernetes 并没有通用的控制面版本回滚机制，因此许多团队只能依靠长时间观察期、分批升级和人工审批来降低风险。EKS 的版本回滚为升级增加了一条明确的恢复路径，尤其适合管理大量集群或对变更恢复有严格要求的团队。
不过，它不是 Kubernetes 通用能力，也不是整个集群的备份恢复机制。最重要的区别是：所有 EKS 集群都支持控制面回滚，但节点回滚的明确支持范围是 EKS Auto Mode。
这项功能具体能回滚什么
| 项目 | 说明 |
|---|---|
| 回滚对象 | 所有 EKS 集群的 Kubernetes 控制面；EKS Auto Mode 还支持托管节点回滚。 |
| 版本跨度 | 一次只能回滚一个 Kubernetes 次要版本，例如从 1.35 回到 1.34，不能任意跨版本跳转。 |
| 发起窗口 | 升级完成后的七天内。 |
| 版本范围 | 集群运行的 Kubernetes 版本需要处于 EKS 标准支持或延长支持范围内。 |
| 区域与费用 | AWS 称该功能已在提供 EKS 的全部商业 AWS 区域推出，不收取额外回滚费用，但标准 EKS 和计算资源费用仍会照常产生。 |
回滚的目标是此前在集群中运行过的版本，而不是某种临时模拟版本。也就是说，从 Kubernetes 1.34 升级到 1.35 后，如果发现问题，可以在窗口期内返回 1.34。AWS 将这种方式定位为对现有升级流程的“撤销”能力，而不是通过重新创建集群来恢复。
回滚前，先检查节点和附加组件依赖
EKS 会通过 Cluster Insights 评估集群是否具备回滚条件，并提示可能影响操作的问题。公告提到的检查项目包括节点版本兼容性和 EKS 附加组件依赖关系。
建议先处理这些提示，再决定是否继续。EKS 也提供了 --force 参数，用于在管理员已经完成风险评估、希望跳过检查时继续操作。但跳过检查只会绕过就绪性评估，并不会自动解决节点或附加组件的兼容性问题。
这里还需要区分控制面和节点。AWS 公告明确说明，控制面回滚适用于所有 EKS 集群，而节点回滚适用于 EKS Auto Mode。因此，对于普通托管节点组或自管理节点，不应默认认为控制面回滚会同步完成节点降级；节点版本、附加组件以及相关依赖需要按照实际架构单独核对。
EKS Auto Mode 的回滚为什么更复杂
EKS Auto Mode 同时管理计算、网络和存储基础设施。对这类集群来说，版本回滚不仅涉及控制面，也涉及托管节点，二者需要配合处理。
节点回滚会遵守工作负载设置的 PodDisruptionBudget（PDB）。PDB 用于限制同一时间可以被驱逐或中断的 Pod 数量，因此节点上的工作负载越难迁移，回滚过程可能持续越久。默认情况下，EKS 不会为了加快回滚而绕过 PDB。
如果节点回滚耗时过长，EKS 提供了取消接口，可以中止正在进行的节点回滚。管理员随后可以调整中断预算、重新安排操作，或选择其他处理路径。修改或移除 PDB 可能加快节点迁移，但也会降低工作负载的可用性保护，应在了解业务影响后进行。
通过控制台发起回滚的基本流程
- 选择集群：在 Amazon EKS 控制台打开近期完成 Kubernetes 版本升级的集群，并确认仍处于七天回滚窗口内。
- 查看回滚入口：进入集群配置页面，检查当前版本、可回滚的此前版本以及剩余回滚时间。
- 检查 Cluster Insights：阅读节点版本兼容性、附加组件依赖等提示，优先处理可能阻止回滚的问题。
- 确认并发起：在确认目标版本和风险后启动回滚。若使用支持的 API 或命令行调用方式，具体参数、权限要求和命令格式应以 EKS 正式文档为准。
- 观察回滚过程：持续关注控制面状态、节点状态、Pod 驱逐情况以及关键业务指标。对于 Auto Mode，还要观察 PDB 是否导致节点回滚停滞。
AWS 公告中的一个示例显示，控制面回滚耗时约 20 分钟，接近一次常规升级。但这只是公告示例，不能作为所有生产集群的时长承诺；Auto Mode 节点回滚还会受到 PDB 和工作负载配置影响。
回滚完成后仍需验证哪些内容
版本回滚主要改变 Kubernetes 控制面的版本，不应被当作应用发布撤销或数据恢复机制。它不会替代对 Kubernetes 资源、应用配置和持久化数据进行独立备份，也不会自动撤销升级期间发生的业务变更。
回滚完成后，至少应确认以下内容：
- 控制面是否已经恢复到目标 Kubernetes 次要版本；
- 节点是否处于预期版本并保持 Ready 状态；
- EKS 附加组件及其依赖是否与回滚后的控制面兼容；
- 关键工作负载、服务发现、网络和存储功能是否正常；
- 准入控制、控制器和其他依赖 Kubernetes API 的组件是否能够继续工作。
对于非 Auto Mode 集群，尤其要单独检查普通托管节点组、自管理节点和附加组件的版本关系。对于 Auto Mode 集群，如果节点回滚因 PDB 长时间无法推进，可以使用取消接口停止操作，再根据业务可用性要求调整中断预算后重新安排。
适合把它当成什么，不适合把它当成什么
这项功能适合作为 Kubernetes 控制面升级的短期安全网：在升级后的观察窗口内发现问题时，可以返回此前运行过的版本，避免立即重建集群或在故障状态下仓促排查。
但它不能替代升级前的兼容性评估、分阶段发布和业务验证。准备使用时，应提前确认目标版本仍在 EKS 支持范围内，了解节点与附加组件的处理方式，并在非生产环境验证工作负载在回滚过程中的行为。AWS 公告未在材料中列出具体 API、命令行语法和权限要求，正式实施前还需要查阅对应的 EKS 文档。