托管节点更新行为 - Amazon EKS
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

托管节点更新行为

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

设置阶段

设置阶段有以下步骤:

  1. 为与您的节点组关联的 Auto Scaling 组创建新的 Amazon EC2 启动模板版本。新的启动模板版本使用目标 AMI 或客户提供的启动模板版本进行更新。

  2. 对弹性缩放组进行更新以使用最新启动模板版本。

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

扩展阶段

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

扩展阶段有以下步骤:

  1. 增加 Auto Scaling 组的最大大小和所需大小,增加幅度为以下两者中的较大者:

    • 部署 Auto Scaling 组可用区数量的最多两倍。

    • 升级不可用的最大值。

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

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

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

    • 每个新节点都应该处于 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. 在没有最新标签的节点组的每个节点应用 eks.amazonaws.com/nodegroup=unschedulable:NoSchedule 污点。这样可以防止已在先前失败更新中更新了的节点被污染。

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

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

  • 客户达到账户的 EC2 实例限制 - 可能需要使用 Service Quotas 增加账户可以同时运行的 Amazon EC2 实例数量。有关更多信息,请参阅适用于 Linux 实例的 Amazon Elastic Compute Cloud 用户指南中的 EC2 Service Quotas

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

  • 任何导致节点运行状况不佳或未准备就绪的更改 - 节点磁盘压力、内存压力和类似的情况可能导致节点不进入 Ready 状态。

升级阶段

升级阶段有以下步骤:

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

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

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

  4. 向封锁节点的弹性缩放组发送终止请求。

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

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

  • 积极的 PDB - 激进式 PDB 在容器上定义,或者有多个 PDB 指向同一个 Pod。

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

缩减阶段

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

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