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

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

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

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

了解更新运行过程

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

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

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

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

  • 更新组：每个更新阶段都包含一个或多个更新组，这些更新组选择要更新的群集。 使用群集的 Update Group 属性将成员群集分配到更新组。 更新阶段中的更新组会并行更新。

  注意

  每个更新阶段的最大更新组数为 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。

计划内维护时段

更新运行遵循在Azure Kubernetes 服务 (AKS)群集级别设置的计划维护时段。

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

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

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

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

了解自动升级配置文件

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

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

• 一个 通道 （快速、 稳定、 TargetKubernetesVersion、 NodeImage、 SecurityPatch （预览版），用于确定应用于群集的更新类型。
• 一个 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 成本。

默认情况下，如果使用此通道，将禁用 Linux 自动升级。 节点映像升级可支持已弃用的修补程序版本，只要次要 Kubernetes 版本仍受支持。 节点映像经过 AKS 测试并完全托管，且应用了安全部署策略。

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

示例：

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

理解节点镜像升级和快照

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

SecurityPatch 通道（预览版）

更新成员群集 Linux 节点，只需每周进行 安全修复 。 Canonical Ubuntu 和 Azure Linux 使 OS 安全修补程序每天可用一次。 Microsoft 会测试这些补丁，并将其打包进节点映像的每周更新中。

此机群管理器自动升级通道通过使用操作系统实时修补来减少干扰，但要求你在订阅中存储已修补的磁盘映像（VHD），以供新预配的节点使用，这会产生少量费用。

使用SecurityPatch时仅更新基于 Linux 的节点，并且会自动跳过基于Windows的节点。

如果您需要随新节点映像（VHD）提供的错误修复，或者希望 Windows 节点具有一致的使用体验，则请选择 NodeImage 通道。

了解更新策略

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

最大并发性（预览版）

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

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

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

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

并发控制建议

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

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

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

示例 1：固定限制

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

示例 2：阶段限制组

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

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

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

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

后续步骤

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