你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
升级 Azure Kubernetes 服务 (AKS) 群集
AKS 群集生命周期的一部分涉及到定期升级到最新的 Kubernetes 版本。 必须应用最新的安全版本，或者通过升级来获取最新功能。 本文介绍如何检查、配置升级，以及如何将升级应用到 AKS 群集。
对于使用多个节点池或 Windows Server 节点的 AKS 群集，请参阅升级 AKS 中的节点池。 若要在不执行 Kubernetes 群集升级的情况下升级特定节点池，请参阅升级特定节点池。
注意
如尚未升级到最新版本，任何升级操作（无论是手动执行还是自动执行）都将升级节点映像版本。 最新版本取决于完整的 AKS 版本，可通过访问 AKS 发布跟踪器来确定。
注意
执行升级操作需要 Microsoft.ContainerService/managedClusters/agentPools/write RBAC 角色。 有关 Azure RBAC 角色的详细信息，请参阅 [Azure 资源提供程序操作]
准备阶段
- 如果使用的是 Azure CLI，本文要求运行 Azure CLI 2.34.1 或更高版本。 运行
az --version即可查找版本。 如果需要进行安装或升级，请参阅安装 Azure CLI。 - 如果使用的是 Azure PowerShell，本教程要求运行 Azure PowerShell 5.9.0 或更高版本。 运行
Get-InstalledModule -Name Az即可查找版本。 如果需要进行安装或升级，请参阅安装 Azure PowerShell。
警告
AKS 群集升级会触发节点的隔离和排空。 如果可用计算配额较低，则升级可能会失败。 有关详细信息，请参阅增加配额
检查是否有可用的 AKS 群集升级
若要检查哪些 Kubernetes 版本可用于群集，请使用 az aks get-upgrades 命令。 下面的示例会检查 myResourceGroup 中到 myAKSCluster 的可用升级 ：
az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table
注意
升级受支持的 AKS 群集时，不能跳过 Kubernetes 次要版本。 所有升级都必须按主版本号依次执行。 例如，允许 1.14.x>1.15.x 或 1.15.x>1.16.x 之间进行升级，但不允许 1.14.x>1.16.x 之间的升级。
仅当从不受支持的版本升级回受支持的版本时，才可以跳过多个版本 。 例如，可从不受支持的 1.10.x 升级到受支持的 1.15.x（如果可用）。 从跳过两个或更多次要版本的不支持版本执行升级时，执行升级时不保证任何功能，并且不在服务级别协议和有限保修范围内。 如果版本明显过期，建议重新创建群集。
以下示例输出表明，群集可升级到版本 1.19.1 和 1.19.3 ：
Name ResourceGroup MasterVersion Upgrades
------- --------------- --------------- --------------
default myResourceGroup 1.18.10 1.19.1, 1.19.3
以下示例输出表示 appservice-kube 扩展与 Azure CLI 版本不兼容（至少需要版本 2.34.1）：
The 'appservice-kube' extension is not compatible with this version of the CLI.
You have CLI core version 2.0.81 and this extension requires a min of 2.34.1.
Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.
如果收到此输出，则需要更新 Azure CLI 版本。 az upgrade 命令为版本 2.11.0 中新增，不能在 2.11.0 之前的版本中使用。 可以通过重新安装 Azure CLI 来更新旧版本，如安装 Azure CLI 中所述。 如果 Azure CLI 版本为 2.11.0 或更高版本，则将收到一条消息以运行 az upgrade 将 Azure CLI 升级到最新版本。
如果 Azure CLI 已更新并收到以下示例输出，则表示没有可用升级：
ERROR: Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.
如果没有可用升级，请使用受支持的 Kubernetes 版本创建新群集，并将工作负载从现有群集迁移到新群集。 如果 az aks get-upgrades 显示没有可用升级，则不支持将群集升级到较新的 Kubernetes 版本。
自定义节点激增升级
重要
节点激增需要的订阅配额对应于为每个升级操作请求的最大激增计数。 例如，具有 5 个节点池（每个池有 4 个节点）的群集总共包含 20 个节点。 如果每个节点池的最大激增值为 50%，则额外需要 10 个节点（2 个节点/池 * 5 个池）的计算和 IP 配额才能完成升级。
如果使用 Azure CNI，则还需要验证子网中是否有可用 IP 来满足 Azure CNI 的 IP 要求。
默认情况下，AKS 会将升级配置为使用一个额外节点进行激增。 最大激增设置的默认值为 1，这样会使 AKS 能够在隔离/排出现有应用程序之前创建一个额外的节点来替换旧版本的节点，从而最大限度地减少工作负荷中断。 可以为每个节点池自定义最大激增值，以便在升级速度与升级中断之间进行权衡。 通过增大最大激增值，升级过程可以更快地完成，但是，设置大的最大激增值可能会导致升级过程中出现中断的情况。
例如，最大激增值为 100% 时，可以让升级过程尽可能快（将节点计数加倍），但也会导致节点池中的所有节点同时被耗尽。 对于测试环境，你可能希望使用这样的较高的值。 对于生产节点池，建议将 max_surge 设置为 33%。
AKS 可以接受整数值和百分比值作为最大激增值。 整数值，例如 5，指示要激增五个额外的节点。 值为“50%”指示激增值为池中当前节点计数的一半。 最大激增百分比值的最小值可以为 1%，最大值可以为 100%。 百分比值将向上舍入到最近的节点计数。 如果最大激增值高于要升级的所需节点数，则要升级的节点数将用于最大激增值。
在升级过程中，最大激增值最小可以为 1，最大为节点池中的节点数。 你可以设置较大的值，但用于最大激增的最大节点数不会高于升级时池中的节点数。
重要
节点池中的最大激增设置是永久性的。 后续的 Kubernetes 升级或节点版本升级都将使用此设置。 你可以随时更改节点池的最大激增值。 对于生产节点池，建议将 max-surge 设置为 33%。
请使用以下命令为新的或现有的节点池设置最大激增值。
# Set max surge for a new node pool
az aks nodepool add -n mynodepool -g MyResourceGroup --cluster-name MyManagedCluster --max-surge 33%
# Update max surge for an existing node pool
az aks nodepool update -n mynodepool -g MyResourceGroup --cluster-name MyManagedCluster --max-surge 5
升级 AKS 群集
如果有一系列适用于 AKS 群集的版本，则可使用 az aks upgrade 命令进行升级。 在升级过程中，AKS 将：
- 向运行指定 Kubernetes 版本的群集添加新的缓冲区节点（或最大电涌中配置的节点数）。
- 隔离和排空旧节点之一，最大程度地减少对正在运行的应用程序的中断。 如果使用的是最大电涌，它将隔离和排空数量与指定缓冲区节点数相同的节点。
- 旧节点在完全排空时，会重置映像以接收新版本，并且会成为下一个要升级的节点的缓冲区节点。
- 此过程会重复进行，直至群集中的所有节点都已升级完毕。
- 在此过程结束时，将删除上一个缓冲区节点，从而维持现有的代理节点计数和区域均衡。
注意
如果未指定补丁，群集会自动升级到指定的次要版本的最新 GA 补丁。 例如，将 --kubernetes-version 设置到 1.21 会导致群集升级到 1.21.9。
通过别名次要版本升级时，仅支持更高的次要版本。 例如，从 1.20.x 升级到 1.20 不会触发升级到最新的 GA 1.20 补丁，但升级到 1.21 会触发升级到最新的 GA 1.21 补丁。
az aks upgrade \
--resource-group myResourceGroup \
--name myAKSCluster \
--kubernetes-version KUBERNETES_VERSION
升级群集需要几分钟时间，具体取决于有多少节点。
重要
确保任何 PodDisruptionBudgets (PDB) 都允许一次至少移动 1 个 Pod 副本，否则排空/逐出操作将失败。
如果排空操作失败，则根据设计，升级操作将失败，以确保应用程序不会中断。 请消除导致操作停止的原因（PDB 错误、缺少配额等），然后重试该操作。
若要确认升级是否成功，请使用 az aks show 命令：
az aks show --resource-group myResourceGroup --name myAKSCluster --output table
以下示例输出表明群集现在运行 1.19.1：
Name Location ResourceGroup KubernetesVersion ProvisioningState Fqdn
------------ ---------- --------------- ------------------- ------------------- ----------------------------------------------
myAKSCluster eastus myResourceGroup 1.19.1 Succeeded myakscluster-dns-379cbbb9.hcp.eastus.azmk8s.io
查看升级事件
升级群集时，每个节点上可能会发生以下 Kubernetes 事件：
- 激增 - 创建激增节点。
- 排出 - 正在从节点逐出 Pod。 每个 Pod 有 30 秒超时来完成逐出。
- 更新 - 节点更新已成功或失败。
- 删除 - 删除了激增节点。
使用 kubectl get events 在运行升级时显示默认命名空间中的事件。 例如：
kubectl get events
下面的示例输出显示了在升级过程中列出的其中一些事件。
...
default 2m1s Normal Drain node/aks-nodepool1-96663640-vmss000001 Draining node: [aks-nodepool1-96663640-vmss000001]
...
default 9m22s Normal Surge node/aks-nodepool1-96663640-vmss000002 Created a surge node [aks-nodepool1-96663640-vmss000002 nodepool1] for agentpool %!s(MISSING)
...
设置自动升级通道
除了手动升级群集之外，还可以在群集上设置自动升级通道。 有关详细信息，请参阅自动升级 AKS 群集。
跨多个可用性区域的节点池的特殊注意事项
AKS 在节点组中使用尽力区域均衡。 在升级激增期间，虚拟机规模集中的激增节点区域无法提前预知。 这可能会在升级过程中暂时导致区域配置不均衡。 但是，AKS 会在完成升级后删除激增节点，并保留原来的区域均衡。 如果希望在升级过程中使区域保持均衡，请将激增节点增加到 3 的倍数。 然后，虚拟机规模集将跨可用性区域来平衡节点，并实现最大限度的区域均衡。
如果你具有 Azure LRS 磁盘支持的 PVC，它们将绑定到特定区域，并且如果激增节点与 PVC 的区域不匹配，可能无法立即恢复。 当升级操作继续排出节点但 PV 绑定到区域时，这可能会导致应用程序停机。 若要处理这种情况并保持高可用性，请在应用程序上配置 Pod 中断预算。 这使 Kubernetes 可在升级的排出操作期间遵从可用性要求。
后续步骤
本文演示了如何升级现有的 AKS 群集。 若要详细了解如何部署和管理 AKS 群集，请参阅相关教程系列。