Azure Kubernetes 服务 (AKS)群集的升级选项和建议

AKS 标准版仍可用于需要更深入地手动控制升级机制、网络选择或节点池行为的方案。

本文介绍了 AKS 升级的技术基础，包括两个 AKS 标准版的升级选项、常见方案和建议。

本文介绍的内容

此技术参考涵盖：

• 手动与自动升级路径，以及何时使用每个路径。
• 具有特定建议的常见升级方案。
• 针对性能和尽量减少干扰的优化技术。
• 验证过程和升级前检查。

相关指南：

• 有关面向生产的 AKS 升级策略的详细信息，请参阅 AKS 生产升级策略。
• 有关有状态工作负荷升级模式，请参阅 有状态工作负荷升级模式。
• 有关方案主导的指南，请参阅 AKS 升级方案：选择路径。
• 如果你不熟悉 AKS 升级，请从 升级方案中心 开始获取指导性帮助。

快速导航

升级操作模型

AKS 标准版可让你直接控制升级排序和优化。 由您选择和管理：

• 手动或自动升级配置。
• 升级通道选择。
• 节点池和激增机制。
• 围绕维护时段和工作负荷中断预算的操作过程。

升级选项

执行手动升级

主要适用于 AKS 标准或专用操作工作流。

通过手动升级，可以控制群集何时升级到新的 Kubernetes 版本。 这些升级可用于测试、分阶段推出和目标版本采用。

• 升级 AKS 群集
• 通过 Azure Kubernetes Fleet Manager 更新多个 AKS 群集
• 升级节点映像
• 自定义节点突增升级
• 处理节点 OS 更新

配置自动升级

对于 AKS 标准版，自动升级有助于将群集保留在受支持的版本上，同时保留对策略和计划的控制。

• 自动升级 AKS 群集
• 通过 Azure Kubernetes Fleet Manager 自动升级多个 AKS 群集
• 使用计划内维护来计划和控制升级
• 在 API 兼容性中断时自动停止 AKS 集群升级（预览版）
• 自动升级 AKS 群集节点操作系统映像
• 使用 GitHub Actions 自动应用安全更新到 AKS 节点

跨多个可用性区域的节点池的特殊注意事项

AKS 在节点池中使用最佳工作区域均衡。 在升级激增期间，虚拟机规模集中激增节点的区域提前未知，这可能会暂时导致区域配置不均衡。 AKS 在升级后删除激增节点，并还原原始区域平衡。

若要保持区域均衡，请将激增设置为三个节点的倍数。 使用Azure本地冗余存储磁盘的永久性卷声明受区域限制，如果激增节点位于其他区域中，可能会导致停机。 使用 Pod 中断预算 (PDB) 在排出期间保持高可用性。

优化升级以提高性能并最大程度地减少中断

结合 计划内维护时段、 最大激增、 PDB、 节点耗尽超时和 节点浸泡时间 ，以提高成功、低中断升级的可能性。

在 AKS 标准版中，直接调整升级控制设置：

• 计划内维护时段：在低流量期间计划自动升级。 至少使用四个小时。
• 最大激增：更高的值会加快升级速度，但可能会中断工作负荷。 将 33% 用于生产。
• 最大不可用：用于容量受限时。
• Pod 中断预算：设置为在升级期间限制 Pod 的停机时间。 为您的服务进行验证。
• 节点排出超时：配置 Pod 逐出等待持续时间。 默认值为 30 分钟。
• 节点浸泡时间：错开升级以最大程度地减少停机时间。 默认为 0 分钟。

升级过程中使用的验证

AKS 执行升级前验证，以确保群集运行状况：

• API 中断性变更： 检测已弃用的 API。
• Kubernetes 升级版本： 确保有效的升级路径。
• PDB 配置： 检查配置错误的 PDB（例如 maxUnavailable=0）。
• 配额： 确认有足够的配额来容纳激增节点。
• 子网： 验证足够的 IP 地址。
• 证书/服务主体： 检测过期的凭据。
• 托管资源锁检查： 检查托管群集资源组上是否已应用资源锁。

这些检查适用于整个 AKS。 在 AKS Standard 中，它们是操作工作流的一部分。

常见升级方案和建议

方案 1：容量约束

如果群集受产品层或区域容量的限制，则无法预配激增节点时升级可能会失败。 这种情况常见于专用产品层（如 GPU 节点）或资源有限的区域中。 如果 SKUNotAvailable 设置得太高而无法满足可用容量要求，则可能会出现 AllocationFailed、OverconstrainedAllocationRequest 或 maxSurge 等错误。

• 使用maxUnavailable进行升级，以使用现有节点而不是激增新节点。 有关详细信息，请参阅 升级期间自定义不可用的节点。
• 降低 maxSurge 以降低额外的容量需求。 更多信息，请参阅自定义节点激增升级。
• 对于仅限安全的更新，请使用不需要激增节点的安全修补程序重置映像。 有关详细信息，请参阅 Azure Kubernetes 服务 中 Linux 节点的安全和内核更新。

方案 2：节点排出故障和 PDB

升级需要排出节点（逐出 Pod）。 当 Pod 终止速度缓慢或严格的 Pod 中断预算（PDB） 阻止 Pod 驱逐时，排空可能会失败。

示例错误：

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... Cannot evict pod as it would violate the pod's disruption budget.

AKS 标准指南

选项 1：强制升级，绕过 PDB 约束

仅在 PDB 阻止关键升级且无法解决时才使用强制升级。 此操作会绕过 PDB 保护机制，并可能在升级期间导致服务完全不可用。

要求：Azure CLI 2.79.0+ 或 AKS API 版本 2025-09-01+

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until yyyy-mm-ddT13:00:00Z

选项 2：处理不透支节点，同时处理 PDB

使用这种保守的方法来维护 PDB，并防止升级失败。

配置无法排空的节点行为：

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 30

行为选项：

• 调度（默认）：删除被阻塞的节点，并快速补充替换节点。
• Cordon（推荐）：封锁节点，并将其标记为 kubernetes.azure.com/upgrade-status=Quarantined。

最大受阻节点数：

• 指定可容忍的无法排空节点的数量
• undrainable-node-behavior需要设置
• 如果未指定，则maxSurge默认为该值（通常为 10%）
• 与最大激增类似，如果计算值高于当前操作中要升级的节点数，则改用剩余要升级的节点数

包含最大阻止节点的示例配置

az aks nodepool update \
  --cluster-name jizenMC1 \
  --name nodepool1 \
  --resource-group jizenTestMaxBlockedNodesRG \
  --max-surge 1 \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 5

选项 3：自动 PDB 管理（预览版）

使用自动 PDB 管理扩展主动解决 PDB 阻止的排空，无需绕过 PDB 保护，也不需要手动清理隔离节点。 自动 PDB 管理能够检测 PDB 何时阻止从已隔离节点上驱逐 Pod，并临时增加部署的副本数，以满足中断预算要求。 排空完成后，会将副本数恢复到其原始数量。

自动 PDB 管理还可以为没有 PDB 的部署自动创建 PDB，确保工作负荷在升级耗尽期间受到保护。 有关安装和配置的详细信息，请参阅在 AKS 升级期间自动管理 Pod 中断预算。

防止排水故障的建议

• 在 PDB 中设置 maxUnavailable 以允许至少一个 pod 逐出
• 增加 Pod 副本以满足中断预算要求
• 如果工作负载需要更多时间，则延长排空超时时间。 （默认值为 30 分钟。
• 使用 自动 PDB 管理 在清空操作期间自动执行 PDB 创建和副本缩放。
• 在过渡阶段测试 PDB、监视升级事件，并使用蓝绿部署来部署关键工作负载。 有关详细信息，请参阅 AKS 群集的蓝绿部署。

验证无法疏导的节点

• 已受阻的节点未为 Pod 安排，并标有标签 "kubernetes.azure.com/upgrade-status: Quarantined"。

• 在升级时出现排出节点故障时，验证任何受阻节点上的标签：

  kubectl get nodes --show-labels=true
  

解析无法清空的节点

1. 移除负责任的 PDB：

   kubectl delete pdb <pdb-name>
   

2. 删除kubernetes.azure.com/upgrade-status: Quarantined标签：

   kubectl label nodes <node-name> kubernetes.azure.com/upgrade-status-
   

3. （可选）删除阻止的节点：

   az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>
   

4. 完成此步骤后，可以通过执行任何更新操作来协调群集状态，而无需如中 az aks所示的可选字段。 或者，可以将节点池缩放为与升级的节点计数相同的节点数。 此操作可确保节点池恢复到其预期的原始大小。 AKS 优先删除受阻节点。 此命令还会将群集预配状态恢复为 Succeeded。 在以下示例中， 2 是已升级的节点总数。

   # Update the cluster to restore the provisioning status
   az aks update --resource-group <resource-group-name> --name <cluster-name>
   
   # Scale the node pool to restore the original size
   az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2
   

方案 3：升级速度缓慢

保守设置或节点级问题可能会延迟升级，这会影响你保持最新修补程序和改进的能力。

升级速度缓慢的常见原因包括：

• 低 maxSurge 值或 maxUnavailable 值（限制并行度）。

• 高浸泡时间（节点升级之间的等待间隔过久）。

• 清空故障（请参阅 节点清空失败）。

• 使用 maxSurge=33% 和 maxUnavailable=1 进行生产。

• 使用maxSurge=50%和maxUnavailable=2进行开发/测试。

• 使用 OS 安全修补程序进行快速、有针对性的修补（避免完整节点重新映像）。

• 启用 --undrainable-node-behavior 以避免升级阻止程序。

方案 4：IP 耗尽

激增节点需要更多 IP。 如果子网接近容量，则节点预配可能会失败（例如， Error: SubnetIsFull）。 此场景常见于 Azure 容器网络接口、高流量，或节点数量较多的情况下。

• 确保子网有足够的 IP 用于所有节点、激增节点和 Pod。 公式为 Total IPs = (Number of nodes + maxSurge) * (1 + maxPods).

• 回收未使用的 IP 或展开子网（例如，从 /24 到 /22）。

• 如果无法进行子网扩展，则降低 maxSurge 。

  az aks nodepool update \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name> \
    --max-surge 10%
  

• 使用Azure Monitor或自定义警报监视 IP 使用情况。

• 减少 maxPods 每个节点，清理孤立的负载均衡器 IP，并为大规模群集规划子网大小。

常见问题

是否可以使用开源工具进行验证？

是的。 许多开源工具与 AKS 升级过程很好地集成：

• Trivy：容器映像和 Kubernetes 配置的安全扫描。
• Sonobuoy：Kubernetes 一致性测试和群集验证。
• kube-bench：根据国际互联网安全中心标准进行安全基准检查。
• Polaris：验证 Kubernetes 最佳做法。
• kubectl-neat：清理 Kubernetes 清单，以便进行验证。

如何在升级之前验证 API 兼容性？

使用 kubent 等工具运行弃用检查：

# Install and run API deprecation scanner
kubectl apply -f https://github.com/doitintl/kube-no-trouble/releases/latest/download/knt-full.yaml

# Check for deprecated APIs in your cluster
kubectl run knt --image=doitintl/knt:latest --rm -it --restart=Never -- \
  -c /kubeconfig -o json > api-deprecation-report.json

# Review findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

AKS 升级与其他 Kubernetes 平台有何不同？

AKS 提供了多种独特的优势：

• Azure 原生与 Azure 流量管理器、Azure 负载均衡器 及网络的集成。
• Azure Kubernetes Fleet Manager 用于协调多群集升级。
• 没有手动节点管理的自动节点映像修补。
• 配额、网络和凭据的内置验证。
• Azure 技术支持有关升级的相关问题。

选择升级路径

本文提供了技术基础。 现在，选择基于方案的路径。

准备好执行了吗？

还在犹豫？

使用升级方案中心来获取一个引导的决策树，考虑以下事项：

• 停机时间容差
• 环境复杂性
• 风险概况
• 时间线约束

最终建议

• 请始终检查 API 破坏性变更，并验证工作负载与目标 Kubernetes 版本的兼容性。
• 在过渡环境中测试升级设置（例如 maxSurge， maxUnavailable和 PDB），以最大程度地降低生产风险。
• 在整个过程中监视升级事件和群集运行状况。