超额配置更新简介

本文档简要介绍了标准滚动更新,然后详细介绍了超额配置更新这种特殊类型的滚动更新。与标准滚动更新相比,超额配置更新可让您配置更新速度。借助超额配置更新,您还可以对工作负载的中断性更新施加一些控制。

如需了解如何为 GKE on AWS 启用和配置超额配置更新,请参阅配置节点池的超额配置更新

标准滚动更新的工作原理

对节点池的一些更新(例如,修改节点池的注释时)不需要重启节点,因此不会引起滚动更新。如果 GKE on AWS 可以将更改应用于节点池,而无需重启或重新创建资源,则它便不会重启或重新创建资源,以避免服务中断。

但是,对 GKE on AWS 中节点池的大多数更新通常需要终止现有节点并使用更新后的设置启动新节点。终止现有节点的过程可能会中断工作负载。

默认情况下,GKE on AWS 会执行标准滚动更新。此方法一次更新一个节点,并且使用“创建前终止”方法替换节点:先终止节点,然后启动新的更新节点。这样可以最大限度地减少中断,因为在任何给定时刻,只有一个节点被终止和替换。

GKE on AWS 在标准滚动更新期间执行的步骤如下:

  1. 从节点池中选择节点并将其标记为不可用,确保没有新的 Pod 在上面启动 - 此操作称为封锁
  2. 将活跃 Pod 从封锁节点重新迁移到集群中的其他可用节点。如果其他节点有足够的容量,则可以容纳被逐出的 Pod。否则,在标准滚动更新期间保持活跃状态的集群自动扩缩器会启动扩容并预配其他节点,以确保有足够的容量来调度逐出的 Pod。如需了解在此过程中保护工作负载的措施,请参阅调整大小期间的工作负载保护
  3. 终止封锁节点。
  4. 将被封锁的节点替换为更新后的设置。
  5. 在新操作节点上执行健康检查。如果节点池未通过健康检查,则会被标记为 DEGRADED 状态。可通过执行 gcloud container aws node-pools describe 命令来查看此状态。当节点池标记为 DEGRADED 时,可能无法在该池中的节点上调度新的 Pod。
  6. 继续按节点逐一更新,直到池中的所有节点都更新为止。

超额配置更新的工作原理

在 GKE on AWS 中,标准滚动方法一次更新一个节点。 超额配置更新是滚动更新的一种形式,可让您同时更新多个节点。因此,超额配置更新比标准滚动更新速度更快。但是,同时更新多个节点可能会中断工作负载。为缓解此问题,超额配置更新提供了调整工作负载中断级别的选项。

超额配置更新与标准滚动更新的区别在于节点的替换方式。标准滚动更新使用“创建前终止”策略替换节点。根据您选择的设置,超额配置更新可以使用“终止前创建”策略、“创建前终止”策略,甚至是两者的组合。

集群自动扩缩器在超额配置更新中的作用比在标准滚动更新中更重要,因此在超额配置更新期间,它在 GKE on AWS 执行的以下一系列操作中占有重要地位:

  1. 创建新的自动扩缩组:GKE on AWS 使用 update 命令指定的修改来预配新节点,并将这些新节点分配给新的 AWS 自动扩缩组 (ASG)。
  2. 集群自动扩缩器行为:超额配置更新开始后,系统会为新的自动扩缩组激活集群自动扩缩器。原始自动扩缩组的集群自动扩缩器已停用。这样可以确保所有扩缩操作都仅以新组为目标。
  3. 节点替换:根据超额配置更新参数,使用不同的节点替换策略:
    • “终止前创建”:当 max-surge-update 参数设置为大于零的值时,会激活此策略。它会在新的 ASG 中生成新节点,然后再终止原始 ASG 中的旧节点,以尽量减少服务中断。
    • “创建前终止”:当 max-surge-update 参数设置为零且 max-unavailable-update 参数的值大于零时,将触发此方法。先终止原始 ASG 中的节点,然后在新 ASG 中创建新节点。
  4. 节点池大小调整:更新期间,节点池大小(即新旧 ASG 中的节点数之和)可能会在更新开始前节点池中存在的原始节点数上下浮动。具体而言,GKE on AWS 的目标是将总节点数维持在 (original_count - max-unavailable-update) 到 (original_count + max-surge-update) 的范围内。最终,旧 ASG (original_count) 中的节点将被替换为新 ASG 中更新后的节点。如果集群自动扩缩器检测到 Pod 无法调度但保持在 min-nodesmax-nodes 定义的限制范围内,则可能会在新的 ASG 中启动更多节点。

以下示例说明了此流程

如需更好地了解超额配置更新的工作原理,请查看以下示例。假设您有一个包含 5 个节点的节点池,然后运行以下命令:

  gcloud container aws node-pools update production-node-pool
      --cluster my-cluster \
      --location us-west1 \
      --max-surge-update 2 \
      --max-unavailable-update 1 \
      --node-version 1.27.6-gke.700

在此示例中,max-surge-update 设置为 2,max-unavailable-update 设置为 1,您将提供一个新的节点池版本(也就是说,您将更改在节点池中的节点上运行的 GKE 版本)。

运行此命令会触发超额配置更新,GKE on AWS 会执行以下操作:

  1. 再创建 2 个节点,因为 max-surge-update 的值等于 2。
  2. 将这 2 个额外的节点分配给新的 AWS 自动扩缩组。
  3. 在这些原始节点正常运行后,从原始自动扩缩组中移除节点。GKE on AWS 最多可以关闭 3 个节点(max-surge-updatemax-unavailable-update 的组合值),但可确保在任何时候都只有一个节点不可用(因为 max-unavailable-update 值为 1)。
  4. 重复这些步骤,直到节点池中的所有节点都更新到新的 GKE 版本。

在此更新期间,节点池包含 4 到 7 个操作节点。

运行超额配置更新之前的注意事项

在运行超额配置更新之前,请注意以下事项:

  • 此超额配置步骤中额外创建的实例可能会超出您的 AWS 实例配额限制。如果您没有足够的配额,并且无法预配这些额外的实例,更新可能会失败。
  • 如果 max-unavailable-update 设置为 0,则在 Pod 被逐出并重新调度到较新节点上时,工作负载可能仍会中断。
  • 可以同时更新的最大节点数等于 max-surge-updatemax-unavailable-update 的总和,限制为 20。

根据您的需求选择合适的超额配置设置

虽然标准滚动更新通常使用“创建前终止”方法,但超额配置更新更加灵活。根据配置,超额配置更新可以遵循“终止前创建”策略、“创建前终止”策略或两者的组合。本部分介绍了不同的配置,帮助您为工作负载选择最佳方法。

下表显示了三种示例设置,并说明了它们对更新速度以及工作负载的潜在中断的影响:

名称 说明 配置
平衡设置(默认) 平衡、缓慢但中断次数最少。 maxSurge=1,maxUnavailable=0
快速更新,无需额外资源 快速、无超额配置资源、中断次数最多。 maxSurge=0,maxUnavailable=20
快速更新,中断次数较少 快速、超额配置资源最多、中断次数较少。 maxSurge=20,maxUnavailable=0

以下部分介绍了表中的每项设置。

平衡设置(默认)

使用超额配置更新最简单的方法是使用默认配置 max-surge-update=1max-unavailable-update=0。此配置在更新期间仅向节点池添加 1 个超额配置节点,并且按照“终止前创建”方法,每次仅更新 1 个节点。与标准的非超额配置滚动更新(等效于 max-surge-update=0max-unavailable-update=1)相比,此方法的中断次数更少,可在更新期间加快 Pod 重启,并且在其进程中更加保守。

请务必注意,采用平衡设置可能会产生额外的费用,因为更新期间添加了临时超额配置节点。与没有超额配置节点的方法相比,额外的节点在活跃时会产生费用,略微增加了总体费用。

快速更新,无需额外资源

对于能够承受中断的工作负载,可能更适合采用快速更新方法。配置 max-surge-update=0max-unavailable-update=20 可以实现此目的。使用此配置时,可以同时更新 20 个节点,而无需添加任何超额配置节点。此更新方法遵循“创建前终止”方法。由于该过程没有引入额外的超额配置节点,因此该方法也是最具成本效益的,从而避免与临时节点关联的额外费用。

快速更新,中断次数较少

如果您的工作负载对中断很敏感,您可以使用以下设置加快更新速度:max-surge-update=20max-unavailable-update=0。此配置以“终止前创建”的方式并行更新 20 个节点。

但如果您已为工作负载设置 PodDisruptionBudgets (PDB),则更新的整体速度可能会受到限制。这是因为 PDB 会限制在任何给定时刻可以排空的 Pod 数量。虽然 PDB 的配置可能会有所不同,但如果为节点池上运行的一个或多个工作负载创建一个 maxUnavailable 等于 1 的 PDB,则系统一次只能逐出这些工作负载的一个 Pod,从而限制整个更新的并行性。

如前所述,在更新过程开始时启动多个超额配置节点可能会导致费用暂时增加,尤其是与在更新期间不额外添加节点或添加更少节点的配置相比。

后续步骤

如需了解如何为 GKE on AWS 启用和配置超额配置更新,请参阅配置节点池的超额配置更新