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

# 集群版本回滚的最佳实践
<a name="rollback-cluster-upgrades"></a>

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

有关先决条件的详细信息、分步过程和 API 参考，请参阅[将集群回滚到之前的 Kubernetes 版本](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html)。

## 了解责任共担模型如何应用于回滚
<a name="understand-how-the-shared-responsibility-model-applies-to-rollback"></a>

当您启动集群版本回滚时，Amazon EKS 会设法回滚控制平面。数据平面、插件和应用程序兼容性由您负责。以下概述了职责：
+  **Amazon EKS 管理：**回滚 Kubernetes API 服务器和控制平面组件。对于自动模式集群，Amazon EKS 还管理回滚工作节点。
+  **您负责：**回滚托管节点组、自管理节点和混合节点。您还必须验证附加组件的兼容性，并确保您的应用程序、自定义控制器和第三方工具在以前的版本中正常运行。

有关升级的分担责任模型的更多信息，请参阅[了解分担责任模型如何应用于集群升级](cluster-upgrades.md)。

## 计划升级时要考虑回滚
<a name="plan-upgrades-with-rollback-in-mind"></a>

如果您的升级工作流程旨在保持回滚窗口处于打开状态，则版本回滚效果最好。
+  **单独升级控制平面和数据平面（非自动模式集群）。**对于使用托管节点组或自我管理节点的集群，请考虑先升级控制平面，并在升级工作节点之前留出一段烘焙期。当节点保持开启状态时 N-1，kubelet 版本的偏差洞察力将保持在 PASSING 状态。这样可以保持回滚路径畅通，而无需先回滚节点。
+  **将插件升级到交叉兼容版本。**在升级控制平面之前，请确保所有插件（托管和自我管理）都与当前和目标 Kubernetes 版本兼容。这样可以清楚地了解升级和回滚的附加组件兼容性。
  + 使用 Amazon EKS 托管插件，从自动检查附加组件版本兼容性的回滚准备情况见解中受益。
  + 避免自行管理托管插件（例如，覆盖 EKS 附加组件生命周期之外的版本）。在回滚期间，Insights 会将托管插件配置视为真实来源，不会检测到您引入的版本偏差。
+  **避免在烘焙期间使用特定于版本的 API。**如果您在 7 天窗口内创建的资源使用仅在新版本中可用的 API 或功能，则必须在回滚之前将其删除。在您确信升级稳定之前，请限制采用仅限新版本的 API。
+  **尽早升级，而不是以后升级。**有了回滚功能，您可以放心地在新版本发布后不久进行升级，而不必等到延长的支持截止日期。尽早升级可让您有更多时间进行验证，并减少延期支持费用。
+  **请注意扩展支持回滚限制。**如果您的集群在扩展支持结束时自动升级，则无法回滚到之前的版本。如果您在标准支持结束时自动升级，则可以回滚，但必须先将升级策略更改为`EXTENDED`。

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

## 在回滚之前，请查看回滚准备情况见解
<a name="review-rollback-readiness-insights-before-rolling-back"></a>

Amazon EKS 在集群见解中的`ROLLBACK_READINESS`类别下显示了时间点回滚准备情况见解。这些检查是评估回滚安全性的主要工具。
+  **升级后立即查看见解。**不要等到出问题了。升级后，请查看回滚准备情况见解，以便了解当前的回滚状态。
+  **主动解决错误洞察。**如果数据在升级后不久显示错误状态，请在 7 天窗口仍处于打开状态时尽早解决问题。等待的时间越长，集群状态出现差异和出现新拦截器的可能性就越大。
+  **了解见解涵盖哪些内容和不涵盖哪些内容。**Insights 会检查 Amazon EKS 托管插件版本、API 使用情况、版本偏差和集群运行状况。他们不检查自我管理的插件、自定义控制器或应用程序级兼容性。对自行管理的插件（例如，集群自动扩缩器、入口控制器、自定义运算符、监控代理）维护自己的兼容性验证。

有关洞察检查和状态行为的完整列表，请参阅[将集群回滚到之前的 Kubernetes 版本](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html)。

## 为回滚准备非自动模式节点
<a name="prepare-non-auto-mode-nodes-for-rollback"></a>

对于使用托管节点组、自我管理节点或 AWS Fargate 的集群，您有责任确保工作节点与目标回滚版本兼容。
+  **托管节点组。**在回滚控制平面之前，必须将托管节点组回滚到先前版本。在之前的 Kubernetes 版本中使用该`UpdateNodegroupVersion`操作。回滚会遵循您配置的更新设置（`maxUnavailable`更新策略）。
+  **Self-managed 和混合节点。**在回滚控制平面之前，请更新您的节点 AMI 或配置以使用之前的 Kubernetes 版本。
+  **Fargate。**Fargate 工作节点不支持版本回滚。在启动回滚之前，请删除运行与控制平面相同版本的 Fargate pod，或者用于`--force`绕过版本偏差洞察（在替换 pod 之前，这可能会导致意外行为）。

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

## 管理 Amazon EKS 自动模式中断控制以进行回滚
<a name="manage-amazon-eks-auto-mode-disruption-controls-for-rollback"></a>

对于运行 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 自动模式集群](https://docs.aws.amazon.com/eks/latest/userguide/rollback-automode-nodes.html)。

## 监控回滚进度
<a name="monitor-rollback-progress"></a>

在回滚期间，使用以下方法来跟踪状态并检测问题：
+  **DescribeUpdate 操作。**用于检查`describe-update`回滚操作的当前状态（`InProgress`、、`Successful``Failed`、`Cancelled`）。要跟踪取消进度，请检查响应中的`cancellation`对象。
+  **集群见解。**Amazon EKS 在继续控制平面回滚之前（自动模式的节点回滚完成后）会重新检查见解。监控可能出现的新错误见解。
+  **集群状态。**对于自动模式集群，集群状态`ACTIVE`在节点回滚期间保持不变，`UPDATING`仅在控制平面回滚期间更改为。不要仅仅依靠集群状态来知道正在进行回滚，请使用。`DescribeUpdate`
+  **节点版本。**对于自动模式，请检查节点 Kubernetes 版本以跟踪节点替换进度。对于托管节点组，监控节点组的更新状态。

## 处理基础设施即代码 (IaC) 托管的集群
<a name="handle-infrastructure-as-code-iac-managed-clusters"></a>

基础设施即代码 (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 堆栈更新失败，自动堆栈恢复到以前的模板版本不会启动集群版本回滚。您必须明确启动版本回滚。

## 使用回滚作为安全网，而不是常规工作流程
<a name="use-rollback-as-a-safety-net-not-a-routine-workflow"></a>

版本回滚旨在帮助您从升级后问题中恢复。与您现有的升级实践结合使用时，它效果最好。
+  **回滚是对测试的补充，它不能取代它。**继续使用集群见解、非生产环境中的升级前测试和分阶段部署。Rollback 可以处理测试无法发现的情况，即只有在生产中才会出现的问题。
+  **Rollback 减少了将手动备份和快照程序作为主要安全机制的需求。**有了本机回滚功能，您无需在升级期间仅依赖 etcd 快照或自定义回滚脚本进行灾难恢复。
+  **洞察力是尽力而为、即时的。**当你触发回滚时，Amazon EKS 会对其进行评估。检查后所做的更改（例如，使用新 API 创建资源）不会被捕获，并且可能会在回滚完成后导致问题。
+  **回滚并不能保证应用程序恢复。**Amazon EKS 可以安全地恢复控制平面，但您的应用程序、配置和依赖关系由您负责对照以前的版本进行验证。

## 回滚减少了对蓝绿色升级的需求
<a name="rollback-reduces-the-need-for-blue-green-upgrades"></a>

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

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

## 相关资源
<a name="related-resources"></a>
+  [将集群回滚到之前的 Kubernetes 版本](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html) 
+  [回滚 Amazon EKS 自动模式集群](https://docs.aws.amazon.com/eks/latest/userguide/rollback-automode-nodes.html) 
+  [群集升级的最佳实践](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) 
+  [集群见解](https://docs.aws.amazon.com/eks/latest/userguide/cluster-insights.html) 
+  [EKS 上的 Kubernetes 版本生命周期](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)