了解节点更新的各个阶段 - Amazon EKS
设置阶段扩展阶段升级阶段缩减阶段
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

帮助改进此页面

要帮助改进本用户指南，请选择位于每个页面右侧窗格中的在 GitHub 上编辑此页面链接。

了解节点更新的各个阶段

Amazon EKS 托管 Worker 节点升级策略有四个不同的阶段，将在以下各节中介绍。

设置阶段

设置阶段有以下步骤：

  1. 为与节点组关联的自动扩缩组创建新的 Amazon EC2 启动模板版本。新的启动模板版本使用目标 AMI 或自定义启动模板版本进行更新。

  2. 对自动扩缩组进行更新，以便使用最新的启动模板版本。

  3. 使用节点组的 updateConfig 属性确定要并行升级的节点最大数量。最大不可用的配额为 100 个节点。原定设置值为一个节点。有关更多信息，请参阅《Amazon EKS API 参考》中的 updateConfig 属性。

扩展阶段

升级托管节点组中的节点时，已升级的节点将在与正在升级的节点在相同可用区中启动。为了保证这一点，我们使用 Amazon EC2 的可用区重新平衡。有关更多信息，请参阅 Amazon EC2 Auto Scaling 用户指南的可用区重新平衡。为了满足此要求，将为托管节点组中的每个可用区启动最多两个实例。

扩展阶段有以下步骤：

  1. 它增加自动扩缩组的最大大小和所需大小，增加幅度为以下两者中的较大者：

    • 部署自动扩缩组可用区数量的最多两倍。

    • 升级不可用的最大值。

      例如，如果节点组有五个可用区，maxUnavailable 为 1，则升级过程可以启动最多 10 个节点。但是如果 maxUnavailable 为 20（或者任何高于 10 的值），则该过程将启动 20 个新节点。

  2. 扩展 Auto Scaling 组后，将检查节点组中是否存在使用最新配置的节点。只有在满足以下标准时，此步骤才会成功：

    • 在节点所在的每个可用区中启动至少一个新节点。

    • 每个新节点都应该处于 Ready 状态。

    • 新节点应该有应用 Amazon EKS 的标签。

      以下是常规节点组中的 Worker 节点上应用 Amazon EKS 的标签：

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      以下是自定义启动模板或 AMI 节点组中的 Worker 节点上应用 Amazon EKS 的标签：

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      • eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId

      • eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion

  3. 将节点标记为不可调度，避免调度新的容器组（pod）。它还使用 node.kubernetes.io/exclude-from-external-load-balancers=true 标记节点，以便在终止节点之前从负载均衡器中移除节点。

下面是导致这一阶段 NodeCreationFailure 出现错误的已知原因：

可用区中容量不足

可用区可能没有请求的实例类型的容量。建议在创建托管节点组时配置多种实例类型。

账户的 EC2 实例限制

可能需要使用服务配额增加账户可以同时运行的 Amazon EC2 实例数量。有关更多信息，请参阅适用于 Linux 实例的 Amazon Elastic Compute Cloud 用户指南中的 EC2 Service Quotas。

自定义用户数据

自定义用户数据有时会中断引导过程。这种情况可能导致节点不启动 kubelet，或者节点上没有获得预期的 Amazon EKS 标签。有关更多信息，请参阅 指定 AMI。

使节点不正常或未就绪的任何更改

节点磁盘压力、内存压力和类似情况可能导致节点无法进入 Ready 状态。

每个节点的引导时间最多不超过 15 分钟

如果任何节点引导和加入集群的时间超过 15 分钟，则会导致升级超时。这是从需要新节点开始到新节点加入集群为止测量的引导新节点的总运行时间。升级托管节点组时，时间计数器会在自动扩缩组的大小增加后启动。

升级阶段

升级阶段有两种行为方式，具体取决于更新策略。更新策略分为默认策略和最小策略这两种。

建议在大多数情况下使用默认策略。该策略会在终止旧节点之前创建新节点，这样就能在升级阶段保持可用容量。在资源或成本受限的情况下，例如使用 GPU 等硬件加速器，最小策略非常有用。该策略会在创建新节点之前终止旧节点，这样总容量永远不会超过配置的数量。

默认更新策略包含如下步骤：

  1. 增加自动扩缩组中的节点数量（所需数量），导致该节点组创建更多节点。

  2. 它随机选择一个需要更新的节点，最多为该节点组配置的最大不可用性。

  3. 耗尽节点的容器组（pod）。如果容器组（pod）在 15 分钟内没有离开节点并且没有强制标志，则升级阶段将失败并显示 PodEvictionFailure 错误。对于这种情况，您可以使用 update-nodegroup-version 请求应用强制标志来删除容器组（pod）。

  4. 在每个容器组（pod）被驱逐后封锁节点并等待 60 秒钟。这样做是为了防止服务控制器向此节点发送任何新请求，并将此节点从活动节点列表中删除。

  5. 它向封锁节点的自动扩缩组发送终止请求。

  6. 它重复以前的升级步骤，直到节点组中没有使用早期版本启动模板部署的节点。

最小更新策略包括如下步骤：

  1. 它随机选择一个需要更新的节点，最多为该节点组配置的最大不可用性。

  2. 耗尽节点的容器组（pod）。如果容器组（pod）在 15 分钟内没有离开节点并且没有强制标志，则升级阶段将失败并显示 PodEvictionFailure 错误。对于这种情况，您可以使用 update-nodegroup-version 请求应用强制标志来删除容器组（pod）。

  3. 在每个容器组（pod）被驱逐后封锁节点并等待 60 秒钟。这样做是为了防止服务控制器向此节点发送任何新请求，并将此节点从活动节点列表中删除。

  4. 它向封锁节点的自动扩缩组发送终止请求。自动扩缩组会创建一个新节点来替代缺失的容量。

  5. 它重复以前的升级步骤，直到节点组中没有使用早期版本启动模板部署的节点。

升级期间的 PodEvictionFailure 错误

下面是导致这一阶段 PodEvictionFailure 出现错误的已知原因：

积极的 PDB

积极的 PDB 在容器组（pod）上定义，或者有多个 PDB 指向同一个容器组（pod）。

容忍所有污点的部署

一旦每个容器组（pod）被逐出，预计该节点将为空，因为该节点在前面的步骤中受到污染。但是，如果部署容忍每个污点，则该节点更有可能是非空的，导致容器组（pod）驱逐失败。

缩减阶段

缩减阶段将自动扩缩组的最大大小和所需大小减小一，返回更新开始之前的值。

如果升级工作流确定 Cluster Autoscaler 在工作流缩减阶段扩展节点组，则会立即退出，而不会使节点组恢复原始大小。