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

Azure Kubernetes 服务（AKS）执行滚动升级，以最大程度地减少对正在运行的工作负荷的中断。 本文介绍如何在群集中升级节点的分步过程。

先决条件

• 了解 Kubernetes 升级最佳做法
• 熟悉 Pod 中断预算

滚动升级过程

在滚动升级期间，AKS 会创建临时激增节点，以在升级现有节点时维护群集容量。 以下示例演示如何将双节点群集从 Kubernetes 1.30 升级到 1.31，并 maxSurge 设置为 1。

步骤 1：初始设置

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

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

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

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

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

步骤 3：升级第一个节点

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

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

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

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

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

步骤 5：删除激增节点

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

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

最终状态

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

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

注意事项

• MaxSurge 设置：控制升级期间创建的激增节点数。 较高的值可加快升级速度，但消耗的资源更多。
• Pod 中断预算：配置 PDB 以确保应用程序在升级过程中的可用性。
• 节点池升级：每个节点池独立升级。 相应地规划升级策略。

使用限制性 Pod 中断预算进行升级行为

当限制性 PDB 阻止节点耗尽时，AKS 可以使用无法透支的 Cordon 节点行为来继续升级过程。 此示例演示如何将双节点集群从 Kubernetes 1.30 升级到 1.31，并 maxSurge 设置为 2，PDB 会阻止第一个节点的排空操作。

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

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

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

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

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

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

步骤 3：进入第二个节点

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

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

步骤 4：升级第二个节点

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

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

步骤 5：一个激增节点在删除另一个节点时变为永久替换。

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

• 节点 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）：现在永久更换

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

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

Blue-Green 节点池升级（手动）

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

重要概念

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

手动 Blue-Green 升级过程示例

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

步骤 1：创建绿色节点池

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

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

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

隔离蓝色节点，以防止新 Pod 的安排，同时保持现有 Pod 的运行。

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

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

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

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

步骤 4：验证和决定

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

在此阶段，可以：

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

步骤 5：提交或回滚

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

选项 A - 提交（成功）：

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

选项 B - 撤销（发现问题）：

• 您的操作：
  1. 使用 kubectl uncordon 解除隔离蓝色节点
  2. 使用 kubectl drain 卸载绿色节点
  3. 使用 az aks nodepool delete 删除绿色节点池
• 结果：工作负荷返回到蓝色节点

手动 Blue-Green 升级命令

# Step 1: Create green node pool
az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name greennodepool \
    --kubernetes-version 1.31 \
    --node-count 2

# Step 2: Cordon blue nodes
kubectl cordon <blue-node-1>
kubectl cordon <blue-node-2>

# Step 3: Drain blue nodes (with your preferred options)
kubectl drain <blue-node-1> --ignore-daemonsets --delete-emptydir-data
kubectl drain <blue-node-2> --ignore-daemonsets --delete-emptydir-data

# Step 4: Validate (your custom validation process)

# Step 5A: Commit - Delete blue node pool
az aks nodepool delete \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name bluenodepool

# Step 5B: Roll back - Return to blue nodes
kubectl uncordon <blue-node-1>
kubectl uncordon <blue-node-2>
kubectl drain <green-node-1> --ignore-daemonsets --delete-emptydir-data
kubectl drain <green-node-2> --ignore-daemonsets --delete-emptydir-data
az aks nodepool delete \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name greennodepool

手动 Blue-Green 升级的优点

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

重要注意事项

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

后续步骤

• 升级 AKS 群集
• 配置升级设置
• 群集升级的最佳做法
• 设置群集自动升级