升级 Azure Operator Nexus Kubernetes 集群

2025-09-19

本文提供有关如何升级操作员 Nexus Kubernetes 群集以获取最新功能和安全更新的说明。 Kubernetes 群集生命周期的一部分涉及对最新的 Kubernetes 版本执行定期升级。请务必应用最新的安全版本或升级以获取最新功能。本文介绍如何检查、配置和应用 Kubernetes 群集的升级。

局限性

群集默认升级过程是一种横向扩展方法，这意味着至少添加了一个额外的节点（或最大激增中配置的节点数）。如果容量不足，升级将无法成功。
当新的 Kubernetes 版本可用时，租户群集不会进行自动升级。当群集中的所有网络功能都准备好支持新的 Kubernetes 版本时，用户应启动升级。有关详细信息，请参阅升级群集。
操作员 Nexus 提供群集范围的升级，确保所有节点池的一致性。不支持升级单个节点池。此外，当新版本可用时，节点映像会作为群集升级的一部分进行升级。
对代理节点进行的自定义将在群集升级期间丢失。建议将这些自定义 DaemonSet 设置放在其中，而不是手动更改节点配置，以便在升级后保留它们。
在群集升级过程中，对核心加载项配置的修改将还原到默认加载项配置。避免自定义加载项配置（例如 Calico 等），以防止潜在的升级失败。如果加载项配置还原遇到问题，可能会导致升级失败。
升级操作员 Nexus Kubernetes 群集时，无法跳过 Kubernetes 次要版本。必须按主版本号按顺序执行所有升级。例如，允许 在 1.14.x ->1.15.x 或 1.15.x ->1.16.x 之间进行升级，但不允许 使用 1.14.x ->1.16.x 。如果版本落后于多个主要版本，则应执行多个顺序升级。
群集创建期间必须设置最大激增和/或最大不可用值。创建群集后，无法更改这些值。有关详细信息，请参阅upgradeSettings“创建 Azure 操作员 Nexus Kubernetes 群集”。

先决条件

部署在 Azure 订阅的资源组中的 Azure 运营商 Nexus Kubernetes 群集。
如果使用 Azure CLI，本文要求运行最新的 Azure CLI 版本。如果需要安装或升级，请参阅安装 Azure CLI
所需的 az-cli 扩展的最低版本：networkcloud2.0.b3
了解版本捆绑概念。有关详细信息，请参阅 Nexus Kubernetes 版本捆绑包。

检查是否有可用的升级

使用以下步骤检查哪些 Kubernetes 版本可用于群集：

使用 Azure CLI

以下 Azure CLI 命令返回群集的可用升级：

az networkcloud kubernetescluster show --name <NexusK8sClusterName> --resource-group <ResourceGroup> --output json --query availableUpgrades

示例输出：

[
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.4-4"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.6-1"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.26.3-1"
  }
]

使用 Azure 门户

登录到 Azure 门户。
访问你的 Operator Nexus Kubernetes 集群。
在 “概述”下，选择“ 可用升级 ”选项卡。

选择要升级到的版本

可用的升级输出指示有多个版本可供选择进行升级。在此特定方案中，当前群集在版本 v1.25.4-3. 上运行，因此，可用的升级选项包括 v1.25.4-4 和最新的修补程序版本 v1.25.6-1. 。此外，还提供了新的次要版本。

你可以灵活地升级到任何可用版本。建议的措施是执行升级到最新可用的major-minor-patch-versionbundle版本。

注释

版本的输入格式为 major.minor.patch 或 major.minor.patch-versionbundle。版本输入必须是可用的升级版本之一。例如，如果群集的当前版本为 1.1.1-1，则有效版本输入为 1.1.1-2 或 1.1.1-x。虽然 1.1.1 是有效的格式，但它不会触发任何更新，因为当前版本已经 1.1.1。若要启动更新，可以使用版本捆绑包指定完整版本，例如 1.1.1-2。但是，1.1.2和1.2.x是有效的输入，并且将使用适用于1.1.2或1.2.x的最新版本捆绑包。

升级群集

在群集升级过程中，操作员 Nexus 执行以下作：

将具有指定 Kubernetes 版本的新控制平面节点添加到群集。
添加新节点后，封锁并清空其中一个旧的控制平面节点，确保其上运行的工作负荷正常移动到其他正常的控制平面节点。
清空旧控制平面节点后，会将其删除，并将新的控制平面节点添加到群集。
此过程重复，直到群集中的所有控制平面节点都已升级。
如果通过激增升级工作节点（默认值）：
- 对于群集中的每个代理池，请使用指定的 Kubernetes 版本添加新的工作节点（或根据最大激增配置添加配置的节点数）。同时升级多个代理池。
- 封锁并清空其中一个旧的工作器节点，以最大程度地减少对正在运行的应用程序的中断。如果使用最大激增，它会在指定的缓冲区节点数的同时封锁和清空尽可能多的工作节点。
- 清空旧工作器节点后，会将其删除，并将包含新 Kubernetes 版本的新工作器节点添加到群集（或最大激增中配置的节点数）
如果在没有增加节点的情况下升级工作节点：
- 对群集中的每个代理池，在替换为具有指定 Kubernetes 版本的新工作节点之前，一个旧的工作节点（或由最大不可用配置的多个节点）会被封锁、清空并删除。可同时升级多个代理池。
- 在升级期间，集群容量会暂时减少，因为从旧工作节点排出的 Pod 不会立即迁移到新节点。如果容量不足，这可能会导致 Pod 进入挂起状态。因此，设计群集以满足应用程序容量要求至关重要，尤其是在无激增升级期间。
此过程将重复，直到群集中的所有工作器节点都已升级。

注释

如果作系统（OS）映像版本和 Kubernetes 版本在版本捆绑包之间保持不变，群集升级不会创建新节点并替换旧节点。这是预期行为，因为升级可能仅包括对 Addon 版本的更新，而不是新的 OS 或 K8s 版本。由于不涉及滚动升级，节点没有隔离和驱逐，因此不会发生 Pod 中断。

重要

确保任何PodDisruptionBudgets（PDB）都允许至少将一个Pod副本同时移动，否则清空/逐出操作将失败。如果清空作失败，升级作也会失败，以确保应用程序不会中断。请更正导致操作停止的原因（如 PDB 不正确、缺少配额等），然后重试该操作。还可以为每个工作节点池配置排空超时时间，之后即使 Pod 尚未完成排空，也会删除该节点。这可以防止错误配置的 PDB 阻止升级。清空超时设置配置为秒，默认值为 1800。

使用 networkcloud kubernetescluster update 命令升级群集。

az networkcloud kubernetescluster update --name myNexusK8sCluster --resource-group myResourceGroup --kubernetes-version v1.26.3

使用 show 命令确认升级成功。

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output json --query kubernetesVersion

以下示例输出显示群集现在运行 v1.26.3：

"v1.26.3"

确保群集正常运行。

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output table

以下示例输出显示群集正常：

Name                 ResourceGroup          ProvisioningState    DetailedStatus    DetailedStatusMessage             Location
------------------   ---------------------  -------------------  ----------------  --------------------------------  --------------
myNexusK8sCluster    myResourceGroup        Succeeded            Available         Cluster is operational and ready  southcentralus

自定义节点扩容或不可用状态的升级

默认情况下，操作员 Nexus 配置升级时会增加一个额外的工作节点。最大激增设置的默认值为一个，操作员 Nexus 可以通过在现有应用程序的封锁/排空前创建额外的节点来替换旧版节点来最大程度地减少工作负荷中断。可以为每个节点池自定义最大浪涌值，以权衡升级速度和升级中断。增加最大跃升值时，升级过程会更快完成。如果为最大激增设置大值，则升级过程中可能会遇到中断。

例如，最大突增值为 100% 提供最快的升级过程（使节点数量翻倍），但也会导致节点池中的所有节点同时被耗尽。你可能希望在测试环境中使用较高的值，比如这样的值。对于生产节点池，我们建议将最大增长设置为 33%。

通过激增进行升级并不总是合适的，例如在资源约束环境中。升级还可以在没有扩展的情况下进行，首先移除工作节点，然后进行替换。这意味着不需要额外资源，但会导致容量减少，从而使 Pod 可能无法调度到节点。此类型的升级是通过 “最大不可用” 设置来控制每个节点池的。默认情况下，最大不可用数设置为 0。这表示最多 0 个节点不可用，即默认情况下不会发生这种类型的升级。

API 接受整数值和百分比值来表示最大激增和最大不可用。整数（如 5）表示五个节点可能激增/变得不可用。值为 50% 表示池中当前节点计数的一半的激增/不可用值。

最大激增或最大不可用之一必须至少为 1（或 1%），否则集群将无法升级。百分比值将向上舍入到最近的节点计数。最大激增和最大不可用可以设置为最多 100%。如果最大激增值高于要升级的所需节点数，则要升级的节点数将用于最大激增值。

可以同时设置最大激增和最大不可用，在这种情况下，升级将通过激增和不可用的混合方式进行。

重要

标准 Kubernetes 工作负荷在从正在消除的节点中排出时，会自动切换到新节点。请记住，操作员 Nexus Kubernetes 服务无法为非标准 Kubernetes 行为做出工作负载承诺。

后续步骤

详细了解 Nexus Kubernetes 版本捆绑包。

反馈

此页面是否有帮助？