Azure Kubernetes 服务（AKS）群集的升级选项和建议

2025-08-15

本文介绍 Azure Kubernetes 服务（AKS）群集升级的技术基础，包括升级选项和常见方案。有关根据需求定制的深入指南，请使用本文末尾的基于方案的导航路径。

本文介绍的内容

此技术参考提供了全面的 AKS 升级基础知识，

手动和自动升级选项以及何时使用每个选项。
具有特定建议的常见升级方案。
针对性能和最小中断的优化技术。
容量、排水故障和计时问题的故障排除指南。
验证过程和升级前检查。

此中心最适合帮助你了解升级机制、排查问题、优化升级设置以及了解技术实现。

有关详细信息，请参阅以下相关文章：

若要升级生产 AKS 群集，请参阅 AKS 生产升级策略。
若要获取具有有状态工作负荷的 AKS 群集的升级模式，请参阅有状态工作负荷升级模式。
若要使用方案中心帮助你选择正确的 AKS 升级方法，请参阅 AKS 升级方案：选择路径。

如果你不熟悉 AKS 升级，请从升级方案中心开始，获取基于方案的引导式帮助。

你的情况	建议的路径
生产群集需要升级	生产升级策略
数据库/有状态工作负荷	有状态工作负荷模式
首次升级或基本群集	基本 AKS 群集升级
多个环境或机群	升级方案中心
节点池或 Windows 节点	节点池升级
仅限特定节点池	单节点池升级

升级选项

执行手动升级

通过手动升级，可以控制群集何时升级到新的 Kubernetes 版本。这些升级对于测试或面向特定版本非常有用：

配置自动升级

自动升级使群集保持受支持的版本并保持最新状态。如果要自动执行设置，请使用这些升级：

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

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

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

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

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

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

升级设置	如何使用额外的节点	预期行为
`maxSurge=5`、`maxUnavailable=0`	5 个激增节点	升级时会激增五个节点。
`maxSurge=5`、`maxUnavailable=0`	0-4 个激增节点	由于激增节点不足，升级失败。
`maxSurge=0`、`maxUnavailable=5`	无	5 个现有节点会耗尽升级。

注释

在升级之前，请检查 API 中断性变更并查看 AKS 发行说明，以避免中断。

升级过程中使用的验证

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

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

这些检查有助于最大程度地减少升级失败，并尽早了解问题。

常见升级方案和建议

方案 1：容量约束

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

阻止或解决的建议

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

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

升级需要排出节点（逐出 Pod）。排水系统可能会失效，如果：

Pod 终止速度缓慢（长时间关闭挂钩或永久性连接）。
严格的 PDB 块逐出 Pod。

示例错误消息：

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... failed with Too Many Requests error. This error is often caused by a restrictive PDB policy. See https://aka.ms/aks/debugdrainfailures. Original error: Cannot evict pod as it would violate the pod's disruption budget. PDB debug info: ... blocked by pdb ... with 0 unready pods.

阻止或解决的建议

在 PDB 中设置 maxUnavailable ，允许逐出至少一个 Pod。
增加 Pod 副本，使中断预算可以容忍逐出。
用于 undrainableNodeBehavior 允许升级继续进行，即使某些节点无法清空：
- 计划（默认值）： 删除节点和激增更换，以减少容量。
- Cordon （建议）： 节点被封锁并标记为 kubernetes.azure.com/upgrade-status=Quarantined。
  - 示例命令：
```
az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon
```
    以下示例输出显示更新的不可排出的节点行为：
```
"upgradeSettings": {
"drainTimeoutInMinutes": null,
"maxSurge": "1",
"nodeSoakDurationInMinutes": null,
"undrainableNodeBehavior": "Cordon"
}
```

允许的最大阻止节点数（预览版）

使用“允许的最大阻止节点数”（预览版）功能可以指定在升级或类似作期间允许多少个节点无法清空（阻塞的节点）。仅当设置了不可透支的节点行为属性时，此功能才有效。否则，该命令将返回错误。

注释

如果未显式设置允许的最大阻止节点数，则默认为最大激增值。如果未设置最大激增，则默认值通常是 10%，因此允许的最大阻止节点数也默认为 10%。

先决条件

使用此功能需要 Azure CLI aks-preview 扩展版本 18.0.0b9 或更高版本。

示例命令：

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

如果工作负荷需要更多时间，则延长排空超时时间。（默认值为 30 分钟。
在过渡阶段测试 PDB、监视升级事件，并使用蓝绿部署来部署关键工作负载。有关详细信息，请参阅 AKS 群集的蓝绿部署。

验证无法透支的节点

被阻止的节点为 Pod 取消计划，并标有标签 "kubernetes.azure.com/upgrade-status: Quarantined"。
在升级时出现排出节点故障时，验证任何受阻节点上的标签：
```
kubectl get nodes --show-labels=true
```

解析无法透支的节点

移除负责任的 PDB：
```
kubectl delete pdb <pdb-name>
```
删除kubernetes.azure.com/upgrade-status: Quarantined标签：
```
kubectl label nodes <node-name> <label-name>
```

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

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

完成此步骤后，可以通过执行任何更新作来协调群集状态，而无需 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 值（限制并行度）。
高浸泡时间（节点升级之间的等待间隔过久）。
清空故障（请参阅节点排出失败）。

阻止或解决的建议

maxUnavailable=1用于maxSurge=33%生产。
maxUnavailable=2用于maxSurge=50%开发/测试。
使用 OS 安全修补程序进行快速、有针对性的修补（避免完整节点重新映像）。
启用 undrainableNodeBehavior 以避免升级阻止程序。

方案 4：IP 耗尽

激增节点需要更多 IP。如果子网接近容量，则节点预配可能会失败（例如， Error: SubnetIsFull）。此方案常见于 Azure 容器网络接口、高 maxPods节点计数或大型节点计数。

阻止或解决的建议

确保子网有足够的 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 升级过程很好地集成：

kube-no-trouble （kubent）：在升级之前扫描已弃用的 API。
Trivy：容器映像和 Kubernetes 配置的安全扫描。
Sonobuoy：Kubernetes 一致性测试和群集验证。
kube-bench：针对 Internet 安全标准中心的安全基准检查。
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 支持与升级相关的问题。

选择升级路径

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

准备好执行了吗？

如果有...	然后转到...
生产环境	生产升级策略：零停机升级的经过战斗测试的模式
数据库或有状态应用	有状态工作负荷模式：数据持久性的安全升级模式
多个环境	升级方案中心：复杂设置的决策树
基本群集	升级 AKS 群集：分步升级群集

仍在决定？

将升级方案中心用于考虑以下事项的引导决策树：

停机时间容差
环境复杂性
风险配置文件
时间线约束

下一个任务

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

通过

Azure Kubernetes 服务 （AKS） 群集的升级选项和建议

本文介绍的内容

快速导航

升级选项

执行手动升级

配置自动升级

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

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

升级过程中使用的验证

常见升级方案和建议

方案 1：容量约束

阻止或解决的建议

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

阻止或解决的建议

允许的最大阻止节点数（预览版）

先决条件

验证无法透支的节点

解析无法透支的节点

方案 3：升级速度缓慢

阻止或解决的建议

方案 4：IP 耗尽

阻止或解决的建议

常见问题

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

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

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

选择升级路径

准备好执行了吗？

仍在决定？

下一个任务

其他资源

Azure Kubernetes 服务（AKS）群集的升级选项和建议