View a markdown version of this page

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

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

集群版本回滚最佳实践

通过亚马逊弹性Kubernetes服务（亚马逊 EKS）版本回滚，您可以在就地升级后的7天内将集群的Kubernetes控制平面恢复到之前的次要版本。本页介绍在升级工作流程中规划、执行和实施回滚的最佳实践。

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

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

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

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

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

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

计划升级时要考虑回滚

当您的升级工作流程设计为保持回滚窗口处于打开状态时，版本回滚效果最佳。

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

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

    • 使用 Amazon EKS 托管插件可从回滚就绪情况洞察中获益，这些洞察会自动检查插件版本兼容性。

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

  • 避免在烘焙期间使用特定版本的 API。如果您创建的资源在 7 天时段内使用仅在新版本中可用的 API 或功能，则必须先将其删除，然后才能回滚。限制仅限新版本的 API 的采用，直到您确信升级是稳定的。

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

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

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

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

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

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

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

  • 了解见解的作用和不涵盖的内容。见解会检查 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 会重新检查见解。监控可能出现的新错误见解。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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