通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

跨多个成员群集更新 Kubernetes 和节点映像

  • 项目

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

更新运行由阶段、组和策略组成，可以手动应用一次性更新，也可以使用自动升级配置文件自动应用持续的常规更新。 所有更新运行（手动或自动化）均遵循成员群集维护时段。

了解更新运行

下图显示了包含两个更新阶段的升级运行，其中每个阶段包含两个带两个成员群集的更新组。 在第一阶段和第二阶段之间配置等待期。

该图显示了包含两个更新阶段的升级运行，每个更新阶段包含两个更新组，更新组具有两个成员群集。

  • 更新运行：更新运行表示应用于 AKS 群集的集合（包括更新目标和序列）的更新。 更新目标描述了所需的更新（例如，升级到 Kubernetes 版本 1.28.3）。 更新序列使用阶段和组表示，描述了将更新应用到多个成员群集的确切顺序。 如果未指定，则会按顺序更新所有成员群集。 可以停止和启动更新运行。
  • 更新阶段：更新运行分为多个阶段，按顺序逐步应用。 例如，第一个更新阶段可能会更新测试环境成员群集，第二个更新阶段随后将更新生产环境成员群集。 可以指定等待时间，以延迟应用后续更新阶段。
  • 更新组：每个更新阶段都包含一个或多个更新组，这些更新组用于选择要更新的成员群集。 更新组还用于对成员群集更新的应用进行排序。 在更新阶段中，更新将并行应用于所有不同的更新组；在更新组中，成员群集按顺序更新。 舰队的每个成员群集只能是一个更新组的一部分。
  • 更新策略：更新策略使用阶段和组描述了更新序列，并允许重用更新运行配置，而不是在每个运行中重复定义序列。 更新策略不包括所需的 Kubernetes 或节点映像版本。

目前，成员群集上支持的更新操作是升级。 有三种类型的升级可供选择：

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

可以指定要升级到的目标 Kubernetes 版本，但无法指定确切的目标节点映像版本。 这是因为最新的可用节点映像版本可能因群集的 Azure 区域而异（有关详细信息，请查看 AKS 版本跟踪器）。

系统会根据首选项自动选择目标节点映像版本：

  • Latest：在群集升级开始时，使用群集所在 Azure 区域中可用的最新节点映像。 因此，可以使用不同的映像版本，具体取决于群集所在的 Azure 区域以及其升级实际开始时间。
  • Consistent：在更新运行启动时，它会跨此运行中成员群集的 Azure 区域选取最新的常见映像版本，以便跨群集使用相同的一致映像版本。

应选择 Latest 以使用较新的映像版本并最大程度地降低安全风险，并选择 Consistent 以便通过在早期阶段使用这些映像并在后续群集中使用这些映像来提高可靠性。

计划内维护

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

在更新运行中（对于逐个或阶段类型更新运行），更新运行按以下顺序对群集的升级进行优先级排序：

  1. 维护时段持续开启的成员。
  2. 维护时段在接下来的四小时内开启的成员。
  3. 无维护时段的成员。
  4. 维护时段已关闭的成员。

更新运行状态

更新运行可能会处于以下任一状态：

  • NotStarted：更新运行尚未启动。
  • 正在运行：更新运行中至少有一个成员群集正在进行升级。
  • Pending：
    • 成员群集：成员群集可能由于以下任一原因（可在消息字段下查看）而处于挂起状态。
      • 维护时段未打开。 消息指示下次开启时间。
      • 目标 Kubernetes 版本在成员所在 Azure 区域中尚不可用。 消息链接到发布跟踪器，以便你可以跨区域检查发布的状态。
      • 目标节点映像版本在成员所在 Azure 区域中尚不可用。 消息链接到发布跟踪器，以便你可以跨区域检查发布的状态。
    • 组：如果组中的所有成员均处于 Pending 状态或未启动，则该组处于 Pending 状态。 当成员移动到 Pending 时，更新运行将尝试升级组中的下一个成员。 如果所有成员均处于 Pending 状态，则组将变为 Pending 状态。 如果某个组处于 Pending 状态，则更新运行将等待该组完成，然后再转到下一阶段以继续执行。
    • 阶段：如果某个阶段下的所有组均处于 Pending 状态或未启动，则该阶段处于 Pending 状态。
    • 运行：如果应当运行的当前阶段处于 Pending 状态，则运行处于 Pending 状态。
  • 已跳过：可以跳过更新运行的所有级别。 跳过可以是由系统或用户启动的。
    • 成员：
      • 你跳过了成员、组或阶段的升级。
      • 成员群集已处于目标 Kubernetes 版本（如果更新运行模式为 Full 或 ControlPlaneOnly）。
      • 成员群集已处于目标 Kubernetes 版本，而且所有节点池都处于目标节点映像版本。
      • 为升级运行选择一致性节点映像时，如果找不到其中一个节点池的目标映像版本，则会跳过该群集的升级。 例如，如果在启动更新运行后添加具有新虚拟机 (VM) SKU 的新节点池，则可能会出现这种情况。
    • 组：
      • 系统检测到所有成员群集均为 Skipped。
      • 你在组级别启动了跳过。
    • 阶段：
      • 系统检测到该阶段的所有组均为 Skipped。
      • 你在阶段级别启动了跳过。
    • 运行：
      • 系统检测到所有阶段均为 Skipped。
  • 已停止：可以停止更新运行的所有级别。 进入已停止状态有两种可能性：
    • 你停止了更新运行，此时更新运行停止跟踪所有操作。 如果更新运行已启动某个操作（例如，正在进行群集升级），则该操作不会因此单个群集中止。
    • 如果在更新运行期间遇到失败（例如群集之一升级失败），则整个更新运行将进入停止状态。 不会对更新运行中的任何后续群集尝试操作。
  • 已失败：群集升级失败会导致以下操作：
    • 将成员群集上的 MemberUpdateStatus 标记为 Failed。
    • 将所有父级（组 -> 阶段 -> 运行）标记为 Failed，并显示摘要错误消息。
    • 停止更新运行继续进行。

注意

可以随时重新运行更新运行，以便重新应用可能已跳过或失败的升级。

了解自动升级配置文件（预览）

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

重要

Azure Kubernetes 舰队管理器预览功能是可选择启用的自助功能。 预览功能是“按现状”和“按可用”提供的，不包括在服务级别协议和有限保证中。 客户支持部门会尽力为 Azure Kubernetes 舰队管理器预览功能提供部分支持。 因此，这些功能并不适合用于生产。

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

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

稳定版通道

稳定通道始终是次要版本 N-1 上支持 AKS 的最新 Kubernetes 修补程序版本，其中 N 是最新支持的次要版本。

示例：

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

快速通道

快速通道始终是最新的支持 AKS 的 Kubernetes 次要版本。

示例：

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

NodeImage 通道

成员群集节点按每周一次的节奏使用包含安全修复和 bug 修复的 VHD 来进行更新。 在维护时段和激增设置之后，对新 VHD 的更新是中断性的。 选择此选项时不会产生额外的 VHD 成本。

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

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

示例：

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

次要版本跳过行为

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

注意

使用自动升级时，请记住以下信息：

  • 自动升级需要版本 1.3.0 或更高版本的舰队 Azure CLI 扩展。

  • 自动升级仅更新到 Kubernetes 的 GA 版本，不会更新到预览版本。

  • 自动升级要求群集的 Kubernetes 版本位于 AKS 支持时段内。

  • 如果群集没有已定义的计划内维护时段，则会在更新运行到达群集时立即升级。

  • 如果想要升级 Kubernetes 版本，则需要通过 Rapid 或 Stable 通道创建 autoupgradeprofile。

  • 如果想要升级 NodeImage 版本，则需要使用 NodeImage 通道创建 autoupgradeprofile。

  • 可以为同一舰队创建多个自动升级配置文件。

后续步骤