通过

升级 Azure Kubernetes 服务 （AKS） 群集控制平面

Azure Kubernetes 服务 （AKS） 群集由两个主要组件组成： 由 Azure 管理的控制平面 以及 运行工作负荷的节点池。 本文重点介绍如何独立升级控制平面，这样就可以为 API 服务器功能采用新的 Kubernetes 版本，同时单独管理节点池升级。

在您开始之前

  • 如果你使用的是 Azure CLI，本文要求 Azure CLI 2.34.1 或更高版本。 使用az --version命令查找版本。 如果需要安装或升级，请参阅 安装 Azure CLI。
  • 如果使用的是 Azure PowerShell，本文要求使用 Azure PowerShell 5.9.0 或更高版本。 使用 Get-InstalledModule -Name Az cmdlet 查找版本。 如果需要进行安装或升级，请参阅安装 Azure PowerShell。
  • 执行升级操作需要具有 Microsoft.ContainerService/managedClusters/agentPools/write 权限的 RBAC 角色。 有关 Azure RBAC 角色的详细信息，请参阅 Azure 资源提供程序操作。
  • 从 Kubernetes 版本 1.30 和 1.27 LTS 版本开始，升级到它们时，默认禁用 beta API。

警告

在升级之前，请确保有足够的计算配额。 如果配额较低，升级可能会失败。

AKS 升级类型的概述

下表概述了三种类型的 AKS 升级，其中突出显示了其范围和用例：

升级类型 Scope 用例
仅限控制平面 API 服务器，etcd，控制器管理器，计划程序 在升级工作负载之前测试新的 Kubernetes API
完整群集 控制平面和所有节点池 标准升级，使群集保持最新
仅节点池 特定节点池 控制平面升级后的分阶段推出

小窍门

首先升级控制平面后，可以先验证 Kubernetes API 兼容性，然后再影响正在运行的工作负荷。 有关节点池升级策略，请参阅 “配置滚动升级”。

Kubernetes 版本升级规则

升级受支持的 AKS 群集时，不能跳过 Kubernetes 次要版本。 必须按小版本号的顺序执行所有升级。 例如，允许 在 1.28.x ->1.29.x 或 1.29.x ->1.30.x 之间进行升级。 不允许使用 1.28.x ->1.30.x 。

控制平面在节点池之前最多可以有两个次要版本。 例如，如果控制平面为 1.30.x，则节点池可以位于 1.28.x、 1.29.x 或 1.30.x。

检查是否有可用的 AKS 升级

小窍门

若要随时了解最新的 AKS 版本和更新，请参阅 AKS 发布跟踪器。

使用 az aks get-upgrades 命令检查 AKS 群集的可用 Kubernetes 版本。

az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output table

以下示例输出显示当前版本为 1.28.9，可用版本在 upgrades 下列出：

Name     ResourceGroup          MasterVersion    Upgrades
-------  ---------------        ---------------  --------------
default  <resource-group-name>  1.28.9           1.29.2, 1.29.4

仅更新 AKS 控制平面

  1. 使用az aks upgrade命令并配合--control-plane-only标志来升级控制平面。 以下示例将控制平面升级到 Kubernetes 版本 1.29.4：

    az aks upgrade \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --kubernetes-version 1.29.4 \
    --control-plane-only

  2. 使用 az aks show 命令确认控制平面升级成功。

    az aks show --resource-group <resource-group-name> --name <cluster-name> --output table

    以下示例输出显示控制平面现在运行 1.29.4：

    Name            Location    ResourceGroup          KubernetesVersion    ProvisioningState    Fqdn
------------    ----------  ---------------        -------------------  -------------------  ------------------------------------------------
<cluster-name>  chinanorth3      <resource-group-name>  1.29.4               Succeeded            <cluster-name>-dns-123abcd4.hcp.chinanorth3.cx.prod.service.azk8s.cn

  3. 使用 [az aks nodepool list][az-aks-nodepool-list] 命令验证节点池版本是否保持不变。

    az aks nodepool list --resource-group <resource-group-name> --cluster-name <cluster-name> --query "[].{Name:name,Version:orchestratorVersion}" --output table

    在输出中，节点池仍应显示以前的 Kubernetes 版本。

升级完整的 AKS 群集

注释

在完整群集升级期间，AKS 先升级控制平面，然后按顺序升级每个节点池。 有关节点池升级的更多控制，请参阅 “配置滚动升级”。

使用 az aks upgrade 命令升级完整的群集（控制平面和所有节点池）。 以下示例将群集升级到 Kubernetes 版本 1.29.4：

az aks upgrade \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --kubernetes-version 1.29.4

常见问题 (FAQ)

为什么在我只升级控制平面时，我的节点池也被升级了？

AKS 可能会在控制平面升级的同时触发滚动节点池升级，使群集保持合规且正常运行。 通常是在以前的节点升级失败或节点处于混合版本时进行这样的升级。

是否可以在控制平面之前升级节点池？

否。 控制平面版本必须始终等于或大于任何节点池版本。 必须先升级控制平面。

控制平面升级需要多长时间？

控制平面升级通常在 5-15 分钟内完成，具体取决于群集配置和 Azure 区域负载。 节点池升级需要更长的时间，因为它们涉及排空和重建镜像节点。

解决控制平面升级问题

没有可用的升级

如果 az aks get-upgrades 没有显示可用的升级，您的群集可能是：

  • 已经是最新支持的版本了。
  • 在需要迁移的不受支持的版本上。

对于不支持的版本，请使用受支持的版本创建新的群集并迁移工作负载。

由于已弃用的 API，升级失败

在升级之前，请使用 kube-no-trouble（kubent）等工具检查已弃用的 API：

kubent

在升级之前，更新清单以使用支持的 API 版本。

相关内容

  • Last updated on