托管节点更新行为 - Amazon EKS

帮助改进此页面

想为本用户指南做出贡献? 滚动到页面底部,然后选择在 GitHub 上编辑此页面。您的贡献有助于我们的用户指南为每个人提供更充分的参考。

托管节点更新行为

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

设置阶段

设置阶段有以下步骤:

  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. 扩展自动扩缩组后,将检查节点组中是否存在使用最新配置的节点。只有在满足以下标准时,此步骤才会成功:

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

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

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

      以下是常规节点组中的工作节点上应用 Amazon EKS 的标签:

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

      • eks.amazonaws.com/nodegroup=$nodeGroupName

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

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

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      • eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId

      • eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion

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

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

可用区中容量不足

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

账户的 EC2 实例限制

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

自定义用户数据

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

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

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

升级阶段

升级阶段有以下步骤:

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

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

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

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

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

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

积极的 PDB

积极的 PDB 在 Pod 上定义,或者有多个 PDB 指向同一个 Pod。

容忍所有污点的部署

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

缩减阶段

缩减阶段将 Auto Scaling 组的最大大小和所需大小减小一,返回更新开始之前的值。

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