本文介绍 Azure Kubernetes 服务 (AKS) 群集升级的技术基础,包括升级选项和常见方案。 有关根据需求定制的深入指南,请使用本文末尾的基于方案的导航路径。
本文介绍的内容
此技术参考提供了全面的 AKS 升级基础知识,
- 手动和自动升级选项以及何时使用每个选项。
- 具有特定建议的常见升级方案。
- 针对性能和最小中断的优化技术。
- 容量、排水故障和计时问题的故障排除指南。
- 验证过程和升级前检查。
此中心最适合帮助你了解升级机制、排查问题、优化升级设置以及了解技术实现。
有关详细信息,请参阅以下相关文章:
- 若要升级生产 AKS 群集,请参阅 AKS 生产升级策略。
- 若要获取具有有状态工作负荷的 AKS 群集的升级模式,请参阅 有状态工作负荷升级模式。
- 若要使用方案中心帮助你选择正确的 AKS 升级方法,请参阅 AKS 升级方案:选择路径。
如果你不熟悉 AKS 升级,请从 升级方案中心 开始,获取基于方案的引导式帮助。
快速导航
你的情况 | 建议的路径 |
---|---|
生产群集需要升级 | 生产升级策略 |
数据库/有状态工作负荷 | 有状态工作负荷模式 |
首次升级或基本群集 | 基本 AKS 群集升级 |
多个环境或机群 | 升级方案中心 |
节点池或 Windows 节点 | 节点池升级 |
仅限特定节点池 | 单节点池升级 |
升级选项
执行手动升级
通过手动升级,可以控制群集何时升级到新的 Kubernetes 版本。 这些升级对于测试或面向特定版本非常有用:
配置自动升级
自动升级使群集保持受支持的版本并保持最新状态。 如果要自动执行设置,请使用这些升级:
- 自动升级 AKS 群集
- 通过 Azure Kubernetes Fleet Manager 自动升级多个 AKS 群集
- 使用计划内维护来计划和控制升级
- 自动升级 AKS 群集节点操作系统映像
- 使用 GitHub作自动将安全更新应用于 AKS 节点
跨多个可用性区域的节点池的特殊注意事项
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),以最大程度地降低生产风险。 - 在整个过程中监视升级事件和群集运行状况。