跨多个群集安全地更新 Kubernetes 和节点映像

适用于： ✔️车队经理 ✔️中心群集的车队经理

管理大量群集的平台管理员通常会在以安全且可预测的方式暂存多个群集的更新（例如升级节点 OS 映像或 Kubernetes 版本）时遇到问题。 为了应对这一难题，Azure Kubernetes Fleet Manager 允许你使用更新运行跨多个群集协调更新。

更新运行过程由阶段、组和策略组成。 您可以手动运行更新以执行一次性更新，或使用自动升级配置文件自动执行持续的定期更新。 所有更新运行任务（无论是手动还是自动）都遵循群集维护窗口。

了解更新运行过程

更新运行表示应用于 AKS 群集集合的更新。 它由更新目标和序列组成。 更新目标描述所需的更新。 例如，升级到特定的 Kubernetes 版本或在所有群集上应用一致的节点映像。

若要在使用更新运行时获得最佳结果，请务必了解以下概念。

• 更新策略：描述由各个阶段和群集组组成的可重用更新序列。 群集会根据为其分配的更新组或成员标签，出现在某个阶段中的某个组里。 有关详细信息，请参阅 了解更新策略。

  • 更新阶段：更新策略分为按顺序应用的更新阶段。 例如，测试环境群集位于第一个更新阶段，而生产环境群集则进入第二个更新阶段。 更新阶段包含一个或多个更新组。 可以使用其他控制，例如最大并发性、等待时间和审批入口，以便更好地控制更新阶段执行。

  • 更新组：每个更新阶段都包含一个或多个更新组，这些更新组选择要更新的群集。 通过使用集群的“更新组”属性，或在预览版中使用成员标签进行基于标签的匹配，将成员集群分配给更新组。 更新阶段中的更新组会并行更新。

  注意

  每个更新阶段的最大更新组数为 50。

  • 更多流量控制：还提供了更多控制选项，以便更灵活地控制一组集群的更新速度：

    • 最大并发性（预览版）：使用 最大并发 配置来更改并行升级的群集数。 可以在阶段级别和组级别配置此行为。

    • 允许的最大失败数（预览版）：使用 允许的最大失败 配置来控制在停止更新运行之前允许的成员群集升级失败数。 可以在阶段级别和组级别配置此行为。

    • 门控：暂停更新过程，直到其条件得到满足。

      • 审批入口（预览版）：可在每个阶段或组之前或之后配置。 审批会暂停更新过程，使您或您设置的自动化系统能够检查是否可以继续。 你或自动化授予批准后，更新过程将继续。

      • 计划启动门（预览版）：可在每个阶段或组之前进行配置。 计划的启动门将更新运行暂停到指定的日期和时间。 到达预定时间后，该关卡会自动完成；您也可以随时手动将其完成，以继续后续流程。

• 自动升级配置文件：在 AKS 提供新的 Kubernetes 或节点映像版本时，自动创建并启动更新运行。 有关详细信息，请参阅 了解自动升级配置文件。

更新运行选项

更新运行可以应用三种类型的升级：

• 升级控制平面和节点的 Kubernetes 版本。 此升级包括升级节点映像。
• 仅升级群集控制平面的 Kubernetes 版本。
• 仅升级节点映像。

可以指定要升级到的目标 Kubernetes 版本，但不能选择目标节点映像版本。 系统根据首选项自动选择目标节点映像版本：

• 最新：在升级该群集时，请使用每个群集Azure区域中可用的最新节点映像。 因此，不同的映像版本可以跨机队使用，具体取决于群集所在的Azure区域以及其升级实际启动时间。
• 一致：启动更新运行时，选取当前在此运行中的群集所在的所有Azure区域中可用的映像版本。 因此，在所有群集中使用一致的映像版本。

选择 “最新 ”以使用较新的映像版本并最大程度地降低安全风险。 选择 “一致 ”以提高可靠性，方法是在早期阶段使用和验证群集中的这些映像，然后再在后续群集中使用它们。

更新运行状态

若要了解更新运行的生命周期，需要了解每个状态、可以执行的操作以及状态的计算方式。

待处理状态

• 更新运行：如果当前阶段处于 Pending 状态。
• 更新阶段：如果该阶段中的所有更新组都处于 Pending 状态或尚未开始，或者该阶段具有 Pending 门。
• 更新组：如果组中的所有群集都处于 Pending 状态或尚未启动，或者具有 Pending 门控。 群集移动到 Pending后，更新运行将尝试升级组中的下一个群集。 如果所有成员均为 Pending，则该组将移至 Pending。 更新过程会等待某个阶段中的所有组都完成后，再进入下一阶段。
• 成员群集：出于以下任何原因，可以在消息字段中查看。
  • 维护窗口未开放。 消息指示下次开启时间。
  • 所需的 Kubernetes 版本或节点映像版本在该群集所在的 Azure 区域中尚不可用。 该消息链接到 AKS 发布跟踪器，以检查发布状态。

已跳过状态

• 更新运行情况：系统检测到所有阶段Skipped。
• 更新阶段：用户将阶段或阶段 Skipped中的所有组标记为 。
• 更新组：用户将组或组 Skipped中的所有群集标记为 。
• 成员群集：出于以下任何原因，可以在消息字段中查看。
  • 用户明确跳过了群集、组或阶段。
  • 群集已处于目标 Kubernetes 版本（如果更新运行模式为 Full 或 ControlPlaneOnly），且所有节点池均处于目标节点映像版本。
  • 当选择一致的节点映像时，无法找到某个节点池的目标映像版本。 这种情况可能会在更新运行开始后添加具有新虚拟机 (VM) SKU 的新节点池时发生。

失败状态

失败状态从群集级联而来，如下所示。 摘要错误消息显示群集升级失败的原因。

• 更新运行：当前组中至少有一个群集失败。
• 更新阶段：阶段中某个组中至少有一个群集失败。
• 更新组：组中至少有一个群集失败。
• 成员群集：升级失败，群集状态设置为 Failed。

配置 允许的最大失败数时，失败阈值会影响更新组、更新阶段和更新运行的状态。 它不会影响单个成员群集的状态。 如果成员群集升级失败，其状态仍设置为 Failed。

• 如果组或阶段的失败计数超过配置的 maxAllowedFailures 阈值，组或阶段将标记为 Failed 摘要错误消息，并且更新运行将停止进度。 如果未配置 maxAllowedFailures（或将其设置为 0），则单次失败就会导致整个运行过程停止。
• 如果失败次数在 maxAllowedFailures 阈值范围内，则更新过程将继续对后续成员进行升级。 有关详细信息，请参阅 允许的最大失败数。

已完成状态

Completed状态表示更新运行已达到终端生命周期状态。 使用 允许的最大故障时， Completed 表示当机队经理决定是否继续计划工作时，配置的失败阈值不会超过。 它不能保证最小成功率或正常结果。 始终检查 FailureCount、成员状态和失败消息。

计划内维护时段

更新运行会遵循你在 AKS 群集级别设置的计划维护时段。

AKS 群集支持两个不同的维护时段-一个用于 Kubernetes（控制平面）升级，一个用于节点映像升级。 维护时段定义了可以向群集应用更新的时间段，但并不是更新的触发器。

机群管理器更新运行遵循 AKS 维护时段，如下所示：

更新操作会根据计划的维护按以下顺序优先升级集群：

1. 具有开放的正在进行的维护窗口的群集。
2. 在接下来的四小时内打开维护时段的群集。
3. 没有维护窗口的集群。
4. 具有已关闭维护窗口的群集。

了解自动升级配置文件

使用自动升级配置文件，在 AKS 提供新的 Kubernetes 版本或节点映像版本时自动触发更新运行。

在自动升级配置文件中，您可以配置：

• 一个 通道 （快速、 稳定、 TargetKubernetesVersion、 NodeImage），用于确定应用于群集的更新类型。
• 一个 UpdateStrategy ，用于配置群集的升级顺序。 如果未提供策略，则群集会按顺序逐个更新。
• NodeImageSelectionType （最新、一致）用于指定升级 Kubernetes 版本时如何选择节点映像。

快速通道

快速通道始终是最新的支持 AKS 的 Kubernetes 次要版本。 AKS 发布新的 Kubernetes 次要版本时，群集次要版本会自动更改。

示例：

• 支持的最新次要版本为 1.30。 1.30 次要范围中的任何修补程序版本都被视为快速通道更新。
• 已发布新的 1.31 次要 Kubernetes 版本。 1.30 将转移到稳定通道。 以前从 1.30 接收更新的任何群集都会更新到 1.31 的最新修补程序，该修补程序现在是快速通道。

稳定通道

稳定通道始终是 快速 通道之前的次要版本。 有时，人们将 Stable 称为 “N-1”，其中 “N” 是最新（快速通道）支持的 Kubernetes 次要版本。 AKS 发布新的 Kubernetes 次要版本时，群集次要版本会自动更改。

示例：

• 支持的最新次要 Kubernetes 版本为 1.30。 1.29 次要范围中的任何修补程序版本都将被视为稳定通道更新。
• 已发布新的 1.31 次要 Kubernetes 版本。 稳定通道会将 1.30 次要版本范围内的任何补丁版本视为更新。 以前从 1.29 接收更新的任何群集都会更新到 1.30 的最新修补程序。

TargetKubernetesVersion 通道

TargetKubernetesVersion 通道可让你控制何时将群集移动到下一个 Kubernetes 次要版本。 您必须以“{major}.{minor}”格式指定目标 Kubernetes 版本（例如“1.33”）。 当修补程序可用时，Fleet Manager 会自动将群集升级到指定目标 Kubernetes 版本的最新修补程序版本。 在更新自动升级配置文件的目标 Kubernetes 版本之前，Fleet Manager 不会升级到下一个次要版本。

示例：

• 你可以使用 TargetKubernetesVersion 通道创建自动升级配置文件，并将目标 Kubernetes 版本指定为“1.30”。 发布了新的修补程序版本 1.30.5。 系统会自动创建一个目标版本为 1.30.5 的更新运行项。
• 使用 TargetKubernetesVersion 通道创建自动升级配置文件，指定目标 Kubernetes 版本“1.29”，并在自动升级配置文件中启用 LongTermSupport （LTS）。 支持的最新社区次要版本为“1.33”。 发布了新的修补程序版本 1.29.5。 系统会自动创建一个目标版本为 1.29.5 的更新运行。 如果生成的更新运行包括未启用 LTS 的群集，它将失败。

次要版本跳过的行为

如果存在多个次要 Kubernetes 版本差异（例如：1.28 到 1.30），则自动升级不会在次要 Kubernetes 版本之间移动群集。 当管理员具有一组不同的 Kubernetes 版本时，首先使用一个或多个 更新运行 将群集引入一组一致的版本控制版本，以便配置 Stable 或 Rapid 通道更新确保将来保持一致性。

NodeImage 通道

成员群集节点每周定期使用包含安全修复和错误修复的虚拟硬盘 (VHD) 进行更新。 根据维护时段和激增设置，对新 VHD 的更新具有中断性。 选择此选项时不会产生额外的 VHD 成本。 节点映像升级可支持已弃用的修补程序版本，只要次要 Kubernetes 版本仍受支持。 节点映像经过 AKS 测试并完全托管，且应用了安全部署策略。

不同操作系统上的节点会根据与这些操作系统对齐的节点映像版本进行更新。

示例：

• 群集包含节点，其 NodeImage 为 AKSWindows-2022-containerd，版本为 20348.2582.240716。 发布了新的 NodeImage 版本 20348.2582.240916，并且群集节点会自动升级到版本 20348.2582.240916。

理解节点镜像升级和快照

当群集具有 从节点池快照创建的代理池时，节点映像升级的结果取决于机群管理器更新运行节点映像选择。

了解更新策略

管理员可以通过使用一系列更新阶段和组生成可重用的更新策略来控制群集的更新顺序。 用户可以配置审批和暂停应在那些阶段和组中何时发生。 整个配置都可以保存为更新策略，并且可以独立于更新运行任务或自动升级配置进行管理，以便按需重复使用这些策略。

使用成员标签对群集进行分组（预览版）

成员标签可用于使用 Kubernetes 样式的标签选择器对群集进行分组和配置更新序列。 这样，你可以为成员群集分配多个标签，并将它们用于不同的策略，而不是限制为每个群集的单个更新组。 可以通过在策略的两个层面上配置 memberSelector 来将群集与其成员标签进行分组：

• 阶段级别：为整个阶段选择群集。 如果未定义任何组，则所有匹配的群集都会形成单个隐式组。 当还定义了组时，阶段级选择器在应用组级别匹配之前充当预筛选。
• 组级别：为阶段内的特定组选择群集，从而启用具有不同并发限制的并行子集。

memberSelector 使用使用标准 Kubernetes 标签选择器语法分析的基于字符串的标签选择器。 支持的运算符包括：=、、、==!=、innotin、 exists和!exists。

有关分配成员标签和使用 memberSelector 策略的说明，请参阅 使用成员选择器创建更新策略。

最大并发性（预览版）

Maximum concurrency 是更新策略的可选设置，用于控制可同时升级的群集数。 可以在两个级别设置 Maximum concurrency ：

• 阶段级别：定义可在阶段中的所有组同时升级的最大群集数。 充当舞台的全局上限。
• 组级别：定义可在特定组中并发升级的最大群集数。

最大并发性接受两种值形式：

• 固定整数：例如， "3" 将并发限制为正好三个群集。
• 百分比：例如， "25%" 将并发限制为群集的百分比。 对于阶段级设置，该百分比是从阶段中的所有群集计算的。 对于组级设置，该百分比是从该组中的群集计算的。 百分比在运行时计算，向下舍入，并强制实施最小解析值为 1。

并发控制建议

如果要使用安全性进行升级（速度较低，但不太可能以多个损坏的群集结尾）：请将最大并发性设置为较小的值。 如果您想快速升级（速度更快，但更有可能导致多个集群损坏），请将最大并发设置为更大的值。

阶段限制与组限制之间的相互作用

阶段级最大并发数始终是总体的上限。 即使单个组允许更高的并发性，阶段限制也优先。 由于阶段级别限制、组大小或成员特定的条件，组级并发可能低于配置。

示例 1：固定限制

结果：总计最多四个群集，每个组最多包含两个群集。

示例 2：阶段限制组

结果：只有两个群集同时进行总升级，因为阶段限制优先。

示例 3：基于百分比的发布

一个阶段有 20 个群集，分属两个组：A 组（8 个群集）和 B 组（12 个群集）。

结果：总计最多可以同时进行 5 个升级，按各自的限制跨组分布。

允许的最大失败数（预览版）

Maximum allowed failures 是一个可选的更新策略设置，用于控制机群管理器在多群集更新期间如何响应故障。

默认情况下，更新遵循快速失败模式——单个集群发生故障就会停止后续更新。 配置 maximum allowed failures时，更新运行将变为容错状态，并且更新会继续跨群集，直到达到指定的故障阈值。

此设置在早期错误检测和维护部署势头之间提供了故意平衡。 在两个级别设置 maximum allowed failures ：

• 阶段级别：定义阶段中所有组中允许的最大成员升级失败次数，然后再将阶段标记为失败。
• 组级别：定义特定组中允许的最大成员升级失败次数，然后再将该组标记为失败。

Maximum allowed failures 接受两种值形式：

• 固定整数：例如，在将组或阶段标记为失败之前， "3" 最多允许三个成员群集失败。
• 百分比：例如，"25%" 允许最多 25% 的成员集群发生故障。 对于阶段级设置，该百分比是从阶段中的所有群集计算的。 对于组级设置，该百分比是从该组中的群集计算的。 在创建更新运行时，会采用向上取整来计算百分比，例如，5 个群集的 25% 结果为 2。

机群管理器仅根据失败的成员更新数来评估 maxAllowedFailures。 它不评估成功率，并且不需要任何最小成功成员数。 如果存在此设置， Completed 则表示在机队管理器做出计划决策时，未超过配置的故障阈值。 Completed 这并不意味着这次发布是顺利的或成功的。

示例：已完成，成功率为 0%

假设一个组有四个成员，并 group.maxAllowedFailures 设置为 "4"。 如果全部四个成员更新都失败，该组仍可被标记为 Completed。 这一结果是预期且有意为之的，并非缺陷，因为四次失败等于配置的容错值，因此未超过阈值。 换句话说，即使其 100% 的成员都失败了，一个组也可以是 Completed。

仅当该行为符合推出预期时，才使用此类阈值。

仔细选择阈值

• 绝对数值易于理解，但在小群体中可能会产生违反直觉的结果。 例如，在双成员组中允许出现 "2" 次失败，这意味着即使两个成员都没有成功，该组仍可完成 Completed。
• 百分比值在不同组大小之间具有更好的适应性，因此建议大多数用户使用。
• 避免将 maxAllowedFailures 设为成员总数，除非你是有意想要这种实际上“永远不会因成员故障而失败”的行为。 如果这种行为是有意的，100% 通常比固定数字具有更清晰的扩展性。
• 对小规模组别要格外谨慎，因为一次失败就可能占整个推广中的很大比例。
• 随着车队的增长，重新评估阈值。 对于 5 个群集而言，感觉安全的值对于 500 个群集来说可能过于严格或过于宽松。

了解失败次数

字段 FailureCount 是报告指标。 统计成员更新失败的次数。 它们不是比率或百分比，它们与配置的强制阈值不同。

• UpdateRun.FailureCount：此次运行中所有阶段和所有组的成员更新失败总数。
• Stage.FailureCount：该阶段内所有组的成员更新失败总数。
• Group.FailureCount：该组中失败的成员更新总数。

在确定推出结果是否可接受之前，请始终查看这些计数以及成员级状态、条件和失败消息。

为什么 FailureCount 会超过 maxAllowedFailures

maxAllowedFailures 控制机队经理是否继续计划新工作的决策。 这不是最终报告的失败次数的硬上限。

如果通过 maxConcurrency 允许并行更新成员，那么在 Fleet Manager 检测到已超过阈值并停止调度更多工作之前，多个成员可能会几乎同时发生故障。 因此，它可能且预期 FailureCount 大于配置的 maxAllowedFailures 值。

阶段和组失败限制如何相互作用

单独评估组级别和阶段级别 maxAllowedFailures ：

• 每个组根据自己的阈值跟踪自己的故障计数。
• 这些组失败也会同样汇总到该阶段的 FailureCount 中。
• 如果超出任一阈值，机队经理将停止为该段计划新工作。
• 已启动的成员更新仍可能完成，这可能会在作出停止决定后增加最终报告的 FailureCount。

阶段级别 maxAllowedFailures 充当阶段中故障容忍度的总体上限。 即使单个组允许更高的故障计数，阶段限制也优先。 如果组的失败次数超过其自身的 maxAllowedFailures，那么无论阶段级别的设置如何，该组都会被标记为失败。

示例 1：固定故障限制

结果：组 A 可容忍最多两次失败，B 组最多可以容忍三个故障。 如果整个阶段的总失败超过 5，则阶段会失败。

示例 2：基于百分比的容差

一个阶段在两个组中共有 19 个群集：A 组有 7 个群集，B 组有 12 个群集。

建议和非建议的用途

在升级大型机群、预期会出现一些暂时性失败，或者发布进度比严格的快速失败行为更重要时，请使用更高或基于百分比的阈值。

对于安全关键型发布、严格受控的生产环境阶段，或任何必须在首次失败后停止并进行检查的情况，请使用 0 或非常小的值。

后续步骤

• 如何：使用 Azure Kubernetes Fleet Manager 更新运行升级多个群集。
• 如何：使用 Azure Kubernetes Fleet Manager 自动升级多个群集。
• 指南：监控 Azure Kubernetes Fleet Manager 的更新过程。
• 多群集更新常见问题解答。