帮助改进此页面
想为本用户指南做出贡献? 选择位于每个页面右侧窗格中的在 GitHub 上编辑此页面链接。您的贡献有助于我们的用户指南为每个人提供更充分的参考。
Amazon EKS 托管 Worker 节点升级策略有四个不同的阶段,将在以下各节中介绍。
设置阶段
设置阶段有以下步骤:
-
它为与您的节点组关联的自动扩缩组创建新的 Amazon EC2 启动模板版本。新的启动模板版本使用目标 AMI 或自定义启动模板版本进行更新。
-
它对自动扩缩组进行更新以使用最新的启动模板版本。
-
它使用节点组的
updateConfig
属性确定要并行升级的节点最大数量。最大不可用的配额为 100 个节点。原定设置值为一个节点。有关更多信息,请参阅《Amazon EKS API 参考》中的 updateConfig 属性。
扩展阶段
升级托管节点组中的节点时,已升级的节点将在与正在升级的节点在相同可用区中启动。为了保证这一点,我们使用 Amazon EC2 的可用区重新平衡。有关更多信息,请参阅 Amazon EC2 Auto Scaling 用户指南的可用区重新平衡。为了满足此要求,将为托管节点组中的每个可用区启动最多两个实例。
扩展阶段有以下步骤:
-
它增加自动扩缩组的最大大小和所需大小,增加幅度为以下两者中的较大者:
-
部署自动扩缩组可用区数量的最多两倍。
-
升级不可用的最大值。
例如,如果节点组有五个可用区,
maxUnavailable
为 1,则升级过程可以启动最多 10 个节点。但是如果maxUnavailable
为 20(或者任何高于 10 的值),则该过程将启动 20 个新节点。
-
-
扩展自动扩缩组后,将检查节点组中是否存在使用最新配置的节点。只有在满足以下标准时,此步骤才会成功:
-
在节点所在的每个可用区中启动至少一个新节点。
-
每个新节点都应该处于
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
-
-
它将节点标记为不可调度以避免调度新的 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
状态。
升级阶段
升级阶段有以下步骤:
-
它随机选择一个需要更新的节点,最多为该节点组配置的最大不可用性。
-
它耗尽节点的 Pods。如果 Pods 在 15 分钟内没有离开节点并且没有强制标志,则升级阶段将失败并显示
PodEvictionFailure
错误。对于这种情况,您可以使用update-nodegroup-version
请求应用强制标志来删除 Pods。 -
在每个 Pod 被驱逐后,它封锁节点并等待 60 秒钟。这样做是为了防止服务控制器向此节点发送任何新请求,并将此节点从活动节点列表中删除。
-
它向封锁节点的自动扩缩组发送终止请求。
-
它重复以前的升级步骤,直到节点组中没有使用早期版本启动模板部署的节点。
下面是导致这一阶段 PodEvictionFailure
出现错误的已知原因:
- 积极的 PDB
-
积极的 PDB 在 Pod 上定义,或者有多个 PDB 指向同一个 Pod。
- 容忍所有污点的部署
-
一旦每个 Pod 被逐出,预计该节点将为空,因为该节点在前面的步骤中受到污染
。但是,如果部署容忍每个污点,则该节点更有可能是非空的,导致 Pod 驱逐失败。
缩减阶段
缩减阶段将自动扩缩组的最大大小和所需大小减小一,返回更新开始之前的值。
如果升级工作流确定 Cluster Autoscaler 在工作流缩减阶段扩展节点组,则会立即退出,而不会使节点组恢复原始大小。