Azure Kubernetes 服务 （AKS） 群集升级的工作原理

Azure Kubernetes 服务 (AKS)执行滚动升级，以最大程度地减少对正在运行的工作负荷的中断。

先决条件

AKS 中的滚动升级行为

AKS 采用滚动方式升级节点池，在替换节点或重建节点映像期间保持容量。 在所有 AKS 群集模式下，此行为都是相同的。

概括而言，AKS：

  1. 根据升级设置添加临时激增容量。
  2. 封锁和清空节点以移动工作负荷。
  3. 将节点重新映像或替换到目标版本。
  4. 在完成后删除临时激增容量。

滚动升级示例

此示例演示如何将一个双节点集群从 Kubernetes 1.30 升级到 1.31，并将 maxSurge 设置为 1。

步骤 1：初始设置

集群启动时有两个节点运行版本 1.30，每个节点都托管着应用程序 Pod。

展示初始集群配置的示意图：两个运行 1.30 版本的节点，每个节点都承载应用 Pod，以及一个新创建的激增节点。

  • 节点 1：Pod A、Pod B
  • 节点 2：Pod C、Pod D
  • 激增节点：空（守护程序集和新 Pod 除外）

步骤 2：隔离，排空第一个节点

AKS 封锁节点 1 以防止新的 Pod 计划，然后清空现有 Pod。

图示节点 1 被标记为不可调度并进行排空，Pod 被驱逐并在其他可用节点上替换。

  • Pod A →在激增节点上被逐出并替换
  • Pod B → Node 2 上逐出并替换

步骤 3：升级第一个节点

节点 1 被恢复到 Kubernetes 版本 1.31，而 Pod 在其他节点上继续运行。

显示节点 1 已重装为 1.31 版本、而应用程序 Pod 继续在节点 2 和突增节点上运行的示意图。

  • 节点 1：升级到 v1.31
  • 节点 2：Pod B、Pod C、Pod D
  • 激增节点：Pod A

步骤 4：隔离并排空第二个节点

AKS 对节点 2 重复此过程，Pod 被驱逐，调度器将其重新分配到适当的可用节点。

示意图显示节点 2 被设为不可调度并清空，其上的 Pod 被逐出，并在已升级的节点 1 和扩容节点上重新创建。

  • Pod C、B →已逐出并在节点 1 上替换
  • Pod D 被逐出并在 Surge 节点上替换
  • 节点 2：已封锁并重新映像到 v1.31

步骤 5：删除激增节点

升级所有永久节点后，将封锁、清空和删除激增节点。

该图显示了被排空并删除的激增节点，以及被逐出并在已升级的永久节点上替换的 Pod。

  • Pod A →已被逐出并在节点 1 上被替换
  • Pod D →在节点 2 上被驱逐并被替换
  • 激增节点：已删除

最终状态

所有节点现在都在运行 Kubernetes 版本 1.31，Pod 已在整个集群中调度。

  • 节点 1 （v1.31）：Pod A、Pod C
  • 节点 2 （v1.31）：Pod B、Pod D

限制性 Pod 中断预算 （PDB） 行为

如果限制严格的 PDB 阻止逐出，节点清空可能会被延迟或无法进行。 AKS 可以使用不透支的 Cordon 节点行为继续升级其他符合条件的节点，具体取决于配置的行为。 在解决阻止条件之前，阻止的节点可能保留在旧版本上。

限制性 PDB 示例

此示例展示了将一个双节点集群从 Kubernetes 1.30 升级到 1.31 的过程，其中 maxSurge 设置为 2，并且有一个 PDB 阻止了第一个节点的 drain 操作。

步骤 1：使用限制性 PDB 进行初始设置

群集从运行版本 1.30 的两个节点开始，PDB 保护 Pod A 免受逐出。

此图显示了初始集群，其中包含两个节点、一个激增节点，以及一个用于保护 Pod A 免遭驱逐的 Pod 中断预算。

  • 节点 1：Pod A（受 PDB 保护）、Pod B
  • 节点 2：Pod C、Pod D
  • 激增节点：新建的 2 个节点
  • PDB：防止 Pod A 逐出

步骤 2：尝试清空第一个节点（已阻止）

AKS 封锁节点 1，但由于 PDB 限制，无法清空 Pod A。

此图显示：节点 1 已被设为不可调度，但由于 Pod 干扰预算的限制，节点清空被阻止；Pod A 卡住，Pod B 被驱逐到扩容节点。

  • 节点 1：封锁并标记为已隔离（Pod A 停滞）
  • Pod B → 在激增节点 1 上被逐出并替换，而激增节点 2 暂时未被使用
  • 状态：节点 1 升级被阻止

步骤 3：进入第二个节点

隔离节点 1 后，AKS 将继续升级节点 2。

此图显示节点 1 仍处于隔离状态，同时节点 2 被成功封锁并腾空，Pod 被迁移到激增节点。

  • 节点 1：保持隔离状态（v1.30）
  • 节点 2：已成功封锁和排出
  • Pod C →在激增节点 2 上逐出并替换
  • Pod D →在 Surge Node 2 上被逐出并替换

步骤 4：升级第二个节点

节点 2 已成功重新映像到 Kubernetes 版本 1.31。

此图显示节点 2 已成功升级到版本 1.31，而节点 1 与 Pod A 一起仍被隔离。

  • 节点 1：仍使用 Pod A 隔离（v1.30）
  • 节点 2：已升级到 v1.31
  • 激增节点 1：Pod B
  • 激增节点 2：Pod C、Pod D

步骤 5：一个激增节点成为永久替代节点，另一个则被移除

由于节点 1 保持隔离状态，因此激增节点 1 将成为运行 v1.31 的永久替换，而激增节点 2 将被删除。

示意图显示，激增节点成为运行 1.31 版本的永久替代节点，而节点 1 仍保持隔离状态。

  • 节点 1：隔离（v1.30） - 需要手动干预
  • Pod C、Pod D →从激增节点 2 中逐出，并在节点 2 上替换
  • 激增节点 1 （v1.31）：Pod B （现已永久）
  • 激增节点 2 （v1.31）：已删除

最终状态

升级完成后，有一个隔离节点需要手动干预。

  • 节点 1：使用 Pod A 隔离（v1.30） - 客户必须手动解决 （请参阅 解决无法排空的节点)
  • 节点 2 （v1.31）：正常运行
  • 以前的激增节点（v1.31）：现在永久更换

重要

隔离节点（节点 1）仍由客户负责处理。 您必须选择以下选项之一：

  • 调整 PDB 以允许逐出 Pod A。
  • 手动删除 Pod A。
  • 修复阻止条件后删除并重新创建节点。

PDB 阻止的升级的关键注意事项

  • 不可驱逐节点行为：将节点池设置为 Cordon 以启用此隔离机制。
  • 客户责任：隔离节点需要手动干预才能解决。
  • 群集容量：激增节点变为永久性节点，可能会影响群集容量规划。
  • 监视：通过 Azure Monitor 或 kubectl 跟踪隔离的节点，以确保及时解决。

Tip

若要完全避免隔离方案，可以使用 自动 PDB 管理 来自动纵向扩展部署副本，以便在耗尽开始之前满足 PDB 约束。 这样，逐出无需阻止即可继续，无需手动隔离解决。

蓝绿节点池升级（手动控制）

Blue-Green 升级提供了一种更受控的升级方法，方法是在迁移工作负载之前手动创建一组完整的新节点池。 此手动方法可让你完全控制升级过程和时间。

有关详细信息，请参阅AKS 中的蓝绿节点池升级。

何时使用 Blue-Green 升级

手动蓝绿节点池升级是一种适用于特定需求的高级策略，例如明确的迁移检查点、自定义验证门或严格受控的切换。

如果需要，请使用手动 Blue-Green：

  • 由操作员控制的迁移阶段。
  • 提交前的自定义验证和验收条件。
  • 与内部运行手册关联的明确回滚流程。

重要概念

  • 蓝色节点池：运行当前 Kubernetes 版本的现有节点池。
  • 绿色节点池：创建运行目标 Kubernetes 版本的新节点池。
  • 手动控制：管理迁移过程的各个方面。
  • 验证检查点：决定何时继续、暂停或回滚。

蓝绿升级的优势

  • 完全控制：确切地决定每个步骤何时发生。
  • 自定义验证：实现自己的验证条件和计时。
  • 逐步迁移：按照首选速度移动工作负荷。
  • 轻松回滚：原始节点保持可用状态，直到删除它们。

蓝绿升级的关键注意事项

  • 手动工作：需要在整个过程中进行主动管理。
  • 配额要求：在升级期间需要 2 倍的节点容量。
  • 规划：记录验证标准和回滚流程。

手动 Blue-Green 升级过程示例

此示例演示如何使用 Blue-Green 部署将双节点群集从 Kubernetes 1.30 手动升级到 1.31。

步骤 1：创建绿色节点池

首先，在现有节点池旁边手动创建具有目标 Kubernetes 版本的新节点池。

显示 Blue-Green 初始设置的示意图，其中 Blue 节点池运行版本 1.30，新创建的 Green 节点池运行版本 1.31。

  • 蓝色节点池 （v1.30）：Pod A、Pod B、Pod C、Pod D（现有）
  • 绿色节点池（v1.31）：空（由你手动创建）
  • 你的操作：az aks nodepool add 使用新的 Kubernetes 版本

步骤 2：手动封锁蓝色节点

封锁蓝色节点，以防止新的 Pod 计划，同时保持现有 Pod 的运行。

  • 您的操作：kubectl cordon 在每个蓝色节点上
  • 蓝色节点：已隔离，未调度新的 Pod
  • 绿色节点：准备好接收工作负载

步骤 3：手动清空蓝色节点（受控速度）

可以通过手动逐个或批量清空节点来控制迁移速度。

该图显示：蓝色节点被排空，其上的 Pod 被逐出并在绿色节点池上替换；第二个蓝色节点也被排空，剩余的 Pod 迁移到绿色节点池。

  • 您的操作：kubectl drain 在选定的蓝色节点上
  • Pod 迁移：Pod 自动迁移到绿色节点
  • 验证：在继续操作之前验证绿色节点上的工作负荷

步骤 4：验证和决定

迁移工作负载后，验证绿色节点上的应用程序性能。

显示验证阶段的图示，其中所有工作负载均运行在绿色节点池上，而蓝色节点池仍可用于回滚。

在此阶段，可以：

  • 监视：检查应用程序指标和日志
  • 测试：在绿色节点池上运行验证测试
  • 决定：确认使用绿色或回滚到蓝色

步骤 5：提交或回滚

根据你的验证，你可以手动完成升级或回滚。

选项 A - 提交（成功）：

显示成功提交后蓝色节点池被删除、绿色节点池成为主节点池的示意图。

  • 您的操作：使用 az aks nodepool delete 删除蓝色节点池
  • 结果：绿色节点池变为主节点池

选项 B - 回滚（检测到的问题）：

此图显示了回滚过程：工作负载返回到蓝色节点池，并删除绿色节点池。

  • 你的操作：使用kubectl uncordon取消封锁蓝色节点，使用kubectl drain腾空绿色节点，并使用az aks nodepool delete删除绿色节点池
  • 结果：工作负载返回到 Blue 节点

升级规划的生产注意事项

  • 激增 （maxSurge） 配置：控制在升级期间创建的激增节点数。 较高的值可加快升级速度，但消耗的资源更多。
  • Pod 中断预算（PDB）：配置 PDB 以确保升级过程中的应用程序可用性。
  • 节点池升级：每个节点池独立升级。 相应地规划升级策略。
  • 容量和配额：在升级窗口之前验证临时和稳定状态容量要求。
  • 监视和警报：在升级开始之前设置监视和警报。

相关内容

  • Last updated on