升级 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。
  • 若要执行升级操作，需要Azure Kubernetes 服务参与者角色或等效权限。
  • 升级到 Kubernetes 版本 1.30 和 1.27 LTS 版本时，Beta API 默认处于禁用状态。

警告

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

AKS 升级类型的概述

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

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

小窍门

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

Kubernetes 版本升级规则

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

如果升级满足版本偏斜要求和验证检查，LTS 群集可以在迁移到 AKS 提供的更高 LTS 版本时跳过次要版本。 有关详细信息，请参阅在群集升级期间是否可以跳过多个 AKS 版本？

从 Kubernetes 1.28 开始，控制平面在节点池之前最多可以有三个次要版本。 例如，如果控制平面为 1.35.x，则节点池可以位于 1.32.x、 1.33.x、 1.34.x 或 1.35.x。 有关当前约束，请参阅 AKS 版本倾斜策略。

检查是否有可用的 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 控制平面

Important

启用 群集自动升级 后，无法执行仅控制平面升级。 群集自动升级始终将控制平面和所有节点池一起升级。

  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 --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

AKS 控制平面升级常见问题（常见问题解答）

仅升级控制平面是否也会升级节点池？

否。 仅限控制平面的升级不会更改节点池。 集群自动升级的工作方式有所不同：它不支持仅升级控制平面，而是会同时升级控制平面和所有节点池。

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

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

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

升级持续时间因群集状态和Azure条件而异。 使用az aks show或Get-AzAksCluster监控provisioningState。 当预配状态为 Succeeded时，升级已完成。

解决控制平面升级问题

没有可用的升级

对于不受支持的群集，使用 az aks get-upgrades 检查 AKS 是否提供符合条件的受支持目标。 如果目标可用，请执行完整群集升级。 此恢复路径下不支持仅升级控制平面。

如果没有可用的目标，则群集可能已在最新受支持的版本中。 如果群集正在运行不受支持的版本，请创建具有支持版本的新群集并迁移工作负荷。

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

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

kubent

该命令会扫描当前 kubeconfig 上下文可访问的资源，以查找已弃用的 Kubernetes API 版本。 输出会按 Kubernetes 版本对结果进行分组，并按KIND、NAMESPACENAME和API_VERSION标识每个受影响的资源。 更新每个列出的资源的源清单，以便在升级之前使用受支持的 API 版本。

相关内容

  • Last updated on