View a markdown version of this page

集群版本回滚的最佳实践 - Amazon EKS
了解责任共担模型如何应用于回滚计划升级时要考虑回滚在回滚之前，请查看回滚准备情况见解为回滚准备非自动模式节点管理 Amazon EKS 自动模式中断控制以进行回滚监控回滚进度处理基础设施即代码 (IaC) 托管的集群使用回滚作为安全网，而不是常规工作流程回滚减少了对蓝绿色升级的需求相关资源

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

集群版本回滚的最佳实践

借助 Amazon Elastic Kubernetes Service（Amazon EKS）版本回滚，您可以在就地升级后的 7 天内将集群的 Kubernetes 控制平面恢复到之前的次要版本。本页介绍在升级工作流程中规划、执行和操作回滚的最佳实践。

有关先决条件的详细信息、分步过程和 API 参考，请参阅将集群回滚到之前的 Kubernetes 版本。

了解责任共担模型如何应用于回滚

当您启动集群版本回滚时，Amazon EKS 会设法回滚控制平面。数据平面、插件和应用程序兼容性由您负责。以下概述了职责：

  • Amazon EKS 管理：回滚 Kubernetes API 服务器和控制平面组件。对于自动模式集群，Amazon EKS 还管理回滚工作节点。

  • 您负责：回滚托管节点组、自管理节点和混合节点。您还必须验证附加组件的兼容性，并确保您的应用程序、自定义控制器和第三方工具在以前的版本中正常运行。

有关升级的分担责任模型的更多信息，请参阅了解分担责任模型如何应用于集群升级。

计划升级时要考虑回滚

如果您的升级工作流程旨在保持回滚窗口处于打开状态，则版本回滚效果最好。

  • 单独升级控制平面和数据平面（非自动模式集群）。对于使用托管节点组或自我管理节点的集群，请考虑先升级控制平面，并在升级工作节点之前留出一段烘焙期。当节点保持开启状态时 N-1，kubelet 版本的偏差洞察力将保持在 PASSING 状态。这样可以保持回滚路径畅通，而无需先回滚节点。

  • 将插件升级到交叉兼容版本。在升级控制平面之前，请确保所有插件（托管和自我管理）都与当前和目标 Kubernetes 版本兼容。这样可以清楚地了解升级和回滚的附加组件兼容性。

    • 使用 Amazon EKS 托管插件，从自动检查附加组件版本兼容性的回滚准备情况见解中受益。

    • 避免自行管理托管插件（例如，覆盖 EKS 附加组件生命周期之外的版本）。在回滚期间，Insights 会将托管插件配置视为真实来源，不会检测到您引入的版本偏差。

  • 避免在烘焙期间使用特定于版本的 API。如果您在 7 天窗口内创建的资源使用仅在新版本中可用的 API 或功能，则必须在回滚之前将其删除。在您确信升级稳定之前，请限制采用仅限新版本的 API。

  • 尽早升级，而不是以后升级。有了回滚功能，您可以放心地在新版本发布后不久进行升级，而不必等到延长的支持截止日期。尽早升级可让您有更多时间进行验证，并减少延期支持费用。

  • 请注意扩展支持回滚限制。如果您的集群在扩展支持结束时自动升级，则无法回滚到之前的版本。如果您在标准支持结束时自动升级，则可以回滚，但必须先将升级策略更改为EXTENDED。

有关包括弃用政策、发行说明和附加组件兼容性在内的一般升级规划指南，请参阅集群升级最佳实践。

在回滚之前，请查看回滚准备情况见解

Amazon EKS 在集群见解中的ROLLBACK_READINESS类别下显示了时间点回滚准备情况见解。这些检查是评估回滚安全性的主要工具。

  • 升级后立即查看见解。不要等到出问题了。升级后，请查看回滚准备情况见解，以便了解当前的回滚状态。

  • 主动解决错误洞察。如果数据在升级后不久显示错误状态，请在 7 天窗口仍处于打开状态时尽早解决问题。等待的时间越长，集群状态出现差异和出现新拦截器的可能性就越大。

  • 了解见解涵盖哪些内容和不涵盖哪些内容。Insights 会检查 Amazon EKS 托管插件版本、API 使用情况、版本偏差和集群运行状况。他们不检查自我管理的插件、自定义控制器或应用程序级兼容性。对自行管理的插件（例如，集群自动扩缩器、入口控制器、自定义运算符、监控代理）维护自己的兼容性验证。

有关洞察检查和状态行为的完整列表，请参阅将集群回滚到之前的 Kubernetes 版本。

为回滚准备非自动模式节点

对于使用托管节点组、自我管理节点或 AWS Fargate 的集群，您有责任确保工作节点与目标回滚版本兼容。

  • 托管节点组。在回滚控制平面之前，必须将托管节点组回滚到先前版本。在之前的 Kubernetes 版本中使用该UpdateNodegroupVersion操作。回滚会遵循您配置的更新设置（maxUnavailable更新策略）。

  • Self-managed 和混合节点。在回滚控制平面之前，请更新您的节点 AMI 或配置以使用之前的 Kubernetes 版本。

  • Fargate。Fargate 工作节点不支持版本回滚。在启动回滚之前，请删除运行与控制平面相同版本的 Fargate pod，或者用于--force绕过版本偏差洞察（在替换 pod 之前，这可能会导致意外行为）。

有关 PodDisruptionBudget 确保节点更新期间工作负载可用性的拓扑分布配置指南，请参阅集群升级最佳实践。

管理 Amazon EKS 自动模式中断控制以进行回滚

对于运行 Amazon EKS 自动模式的集群，节点回滚阶段可能是操作中最长的部分。您的中断控制直接决定了完成回滚的速度。

  • 在启动回滚之前，请先查看中断预算。Amazon EKS 为 NodePool 中断预算提供回滚准备情况见解。设置为 0 的预算会触发错误洞察，从而无限期地阻止回滚。限制性预算和 PodDisruptionBudgets （PDB）会触发警告见解，这可能会减缓回滚速度，但允许向前推进。在启动回滚之前，请先解决错误见解。

  • 准备好在回滚期间调整预算。如果回滚所需的时间超过预期，则可以在回滚kubectl过程中调整 NodePool 中断预算和 PDB。增加预算可以实现更多的并发节点更换。

  • 移除阻塞节点上的 “请勿中断” 注释。节点上的karpenter.sh/do-not-disrupt注释会无限期地阻止回滚。将其从应替换的节点中移除。

  • 跟踪节点回滚进度。kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide用于监控哪些节点已被先前版本的 AMI 所取代。

  • CancelUpdate 必要时使用。如果回滚花费的时间太长或导致的问题多于解决的问题，请取消回滚。取消后，节点会聚回当前版本，您可以采取不同的方法。

  • 设置适当的超时时间。使用中的timeoutMinutes参数rollbackConfig以符合您的运营预期。默认值为 720 分钟（12 小时）。对于预算保守的集群，可以考虑增加预算。对于 IaC-managed 群集，请与您的工具的超时时间保持一致。

有关完整的自动模式回滚过程和CancelUpdate操作，请参阅回滚 Amazon EKS 自动模式集群。

监控回滚进度

在回滚期间，使用以下方法来跟踪状态并检测问题：

  • DescribeUpdate 操作。用于检查describe-update回滚操作的当前状态（InProgress、、SuccessfulFailed、Cancelled）。要跟踪取消进度，请检查响应中的cancellation对象。

  • 集群见解。Amazon EKS 在继续控制平面回滚之前（自动模式的节点回滚完成后）会重新检查见解。监控可能出现的新错误见解。

  • 集群状态。对于自动模式集群，集群状态ACTIVE在节点回滚期间保持不变，UPDATING仅在控制平面回滚期间更改为。不要仅仅依靠集群状态来知道正在进行回滚，请使用。DescribeUpdate

  • 节点版本。对于自动模式，请检查节点 Kubernetes 版本以跟踪节点替换进度。对于托管节点组，监控节点组的更新状态。

处理基础设施即代码 (IaC) 托管的集群

基础设施即代码 (IaC) 工具具有超时限制，可能与自动模式回滚持续时间冲突。

  • AWS CloudFormation 支持每种资源最多 36 小时。如果回滚超过此值，则将其 CloudFormation 视为无操作，这可能会使集群处于漂移状态，模板无法反映实际的集群版本。默认回滚超时为 720 分钟（12 小时）。

  • Terraform 的超时时间约 Enterprise/Cloud为 24 小时，但客户端的超时时间各不相同。

  • timeoutMinutes与 IaC 工具的超时保持一致，以防止 IaC 工具在 Amazon EKS 完成回滚之前超时。

  • 考虑 CLI/API 为预算有限的自动模式集群启动回滚，而不是通过 IaC。如果 IaC 层超时，请CancelUpdate直接使用。

  • AWS CloudFormation 堆栈回滚不会触发版本回滚。如果 AWS CloudFormation 堆栈更新失败，自动堆栈恢复到以前的模板版本不会启动集群版本回滚。您必须明确启动版本回滚。

使用回滚作为安全网，而不是常规工作流程

版本回滚旨在帮助您从升级后问题中恢复。与您现有的升级实践结合使用时，它效果最好。

  • 回滚是对测试的补充，它不能取代它。继续使用集群见解、非生产环境中的升级前测试和分阶段部署。Rollback 可以处理测试无法发现的情况，即只有在生产中才会出现的问题。

  • Rollback 减少了将手动备份和快照程序作为主要安全机制的需求。有了本机回滚功能，您无需在升级期间仅依赖 etcd 快照或自定义回滚脚本进行灾难恢复。

  • 洞察力是尽力而为、即时的。当你触发回滚时，Amazon EKS 会对其进行评估。检查后所做的更改（例如，使用新 API 创建资源）不会被捕获，并且可能会在回滚完成后导致问题。

  • 回滚并不能保证应用程序恢复。Amazon EKS 可以安全地恢复控制平面，但您的应用程序、配置和依赖关系由您负责对照以前的版本进行验证。

回滚减少了对蓝绿色升级的需求

以前主要使用蓝绿色集群升级来实现 “还原路径” 的组织现在可以考虑使用版本回滚的就地升级作为替代方案。 In-place 通过回滚进行升级可降低基础架构成本（无重复集群）、一致的集群身份（相同的 API 端点、OpenID Connect (OIDC) 提供程序和弹性网络接口 (ENI)）以及更简单的操作。

Blue-green 当你需要同时更改多个版本、广泛测试工作负载迁移或在验证期间保持完全的流量隔离时，可能仍然是首选。有关更多信息，请参阅 Blue/Green 集群升级最佳实践中的评估集群。