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

项目
12/18/2024

本文涵盖了 AKS 群集的不同升级选项。若要执行基本的 Kubernetes 版本升级，请参阅升级 AKS 群集。

对于使用多个节点池或 Windows Server 节点的 AKS 群集，请参阅升级 AKS 中的节点池。若要在不执行 Kubernetes 群集升级的情况下升级特定节点池，请参阅升级特定节点池。

执行手动升级

你可以执行手动升级，以控制群集何时升级到新的 Kubernetes 版本。若要在升级生产群集之前测试新的 Kubernetes 版本，手动升级非常有用。手动升级还可用于将群集升级到并非最新可用版本的特定 Kubernetes 版本。

若要执行手动升级，请参阅以下文章：

配置自动升级

你可以配置自动升级，以自动将群集升级到最新的可用 Kubernetes 版本。如果要确保群集始终运行最新的 Kubernetes 版本，则自动升级非常有用。自动升级还可用于确保群集始终运行受支持的 Kubernetes 版本。

若要配置自动升级，请参阅以下文章：

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

AKS 在节点组中使用尽力区域均衡。在升级激增期间，虚拟机规模集中激增节点的区域提前未知，这可能会在升级期间暂时导致区域配置不均衡。但是，AKS 会在完成升级后删除激增节点，并保留原来的区域均衡。如果要在升级期间保持区域均衡，可以将激增增加到 三个节点 的倍数，虚拟机规模集通过尽力区域均衡跨可用性区域均衡节点。使用“尽量实现区域均衡”时，规模集会在维持均衡时尝试进行横向收缩和扩展。但是，如果因某个原因而无法实现这一点（例如，某个区域停机，导致规模集无法在该区域创建新 VM），则规模集会允许暂时的不均衡，目的是能够成功地进行横向缩减或扩展。

由 Azure 本地冗余存储 (LRS) 磁盘支持的永久性卷声明 (PVC) 将绑定到特定区域，如果激增节点与该 PVC 的区域不匹配，则可能无法立即恢复。如果区域不匹配，当升级操作继续消耗节点但 PV 绑定到某个区域时，可能会导致应用程序停机。要处理这种情况并维持高可用性，请在应用程序上配置 Pod 中断预算，从而允许 Kubernetes 在排出操作期间遵守可用性要求。

针对无法排出的节点行为进行优化（预览版）

可以配置排出失败的升级过程行为。默认升级行为是 Schedule，包括节点排出故障，它会导致升级操作失败，使未排出的节点处于可计划状态。或者，你可以选择 Cordon 行为，它会跳过未能排出的节点，方法是将其置于隔离状态，并用 kubernetes.azure.com/upgrade-status:Quarantined 标记它们，继续升级剩余节点。此行为可确保所有节点都已升级或隔离。使用此方法可以排查排出故障并正常管理隔离的节点。

如何设置新的 Cordon 行为？

使用 CLI 预览版并安装 aks-preview 扩展 9.0.0b3 或更高版本。

可以使用以下命令更新或安装 aks-preview 扩展：

az extension update --name aks-preview

az extension add --name aks-preview

将节点池不可排出的节点行为更新为 Cordon：

az aks nodepool update --cluster-name $CLUSTER_NAME --name $NODE_POOL_NAME --resource-group $RESOURCE_GROUP --max-surge 1 --undrainable-node-behavior Cordon

以下示例输出显示更新的不可排出的节点行为：

"upgradeSettings": {
    "drainTimeoutInMinutes": null,
    "maxSurge": "1",
    "nodeSoakDurationInMinutes": null,
    "undrainableNodeBehavior": "Cordon"
  }

验证任何被阻止的节点上的标签。使用以下命令在升级时出现排出节点故障：

kubectl get nodes --show-labels=true

被阻止的节点为 Pod 取消计划，并标有标签 "kubernetes.azure.com/upgrade-status: Quarantined"。可以留为被阻止的最大节点数不能超过 Max-Surge 值。

如何移除被阻止的节点？

首先解决导致排出的问题。以下示例移除了负责任的 PDB：

kubectl delete pdb nginx-pdb
poddisruptionbudget.policy "nginx-pdb" deleted.

然后使用 az aks nodepool delete-machines 命令删除被阻止的节点。如果你打算通过移除旧版本中留下的节点来减少节点池占用情况，则此命令非常有用。

az aks nodepool delete-machines --cluster-name MyCluster --machine-names aks-nodepool1-test123-vmss000000 --name nodepool1 --resource-group TestRG

完成此步骤后，可以通过执行任何更新操作来协调群集状态，而无需此处所述的可选字段。

示例命令：

az aks update --resource-group TestRG --name MyCluster

或者，可以将节点池缩放为与升级的节点计数相同的节点数。此操作可确保节点池达到其预期的原始大小。 AKS 优先移除被阻止的节点。此命令还会将群集预配状态还原到 Succeeded。在给定的示例中，2 是已升级的节点总数。

az aks nodepool scale --resource-group TestRG --cluster-name MyCluster --name nodepool1 --node-count 2

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

计划内维护时段、最大激增、Pod 中断预算、节点耗尽超时和节点浸泡时间的组合可以显著增加节点升级在维护时段结束时成功完成的可能性，同时最大程度地减少中断。

借助计划内维护时段，服务团队可安排在预定义时段（通常是低流量时段）自动升级，以最大程度地降低对工作负载的影响。我们建议至少预留四个小时的窗口期。
节点池的最大激增允许在升级过程中请求更多配额，并限制选择同时升级的节点数。较高的最大激增可加快升级过程。建议不要将其设置为 100%，因为这样会同时升级所有节点，可能会导致正在运行的应用程序中断。对于生产节点池，建议的最大激增配额为 33%。
Pod 中断预算是为服务应用程序设置的，限制在自愿中断期间可以关闭的 Pod 数，例如 AKS 控制的节点升级。它可以配置为 minAvailable 副本，表示需要处于活动状态的最小应用程序 Pod 数，或配置为 maxUnavailable 副本，表示可终止的最大应用程序 Pod 数，以确保应用程序的高可用性。请参阅提供的有关配置 Pod 中断预算 (PDB) 的指南。应验证 PDB 值，以确定最适合特定服务的设置。
通过节点池上的节点耗尽超时，可配置升级期间每个节点 pod 逐出和正常终止的等待持续时间。处理长时间运行的工作负载时，此选项非常有用。若指定了节点耗尽超时（以分钟为单位），AKS 会遵循等待 Pod 中断预算的做法。如果未指定，则默认超时为 30 分钟。
节点浸泡时间有助于以受控方式错开节点升级，并且可以最大程度地减少升级期间的应用程序停机时间。可指定等待时间，最好尽可能接近 0 分钟，以检查节点升级之间的应用程序就绪情况。如果未指定，默认值为 0 分钟。 “节点浸泡时间”与节点池中可用的“最大激增”和“节点耗尽超时”属性协同工作，以在升级速度和应用程序可用性方面提供正确的结果。

通过