你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

升级 Azure 运营商关系 Kubernetes 群集

项目
08/22/2024

本文说明了如何升级运营商关系 Kubernetes 群集以获取最新功能和安全更新。 Kubernetes 群集生命周期的一部分涉及定期升级到最新的 Kubernetes 版本。必须应用最新的安全版本，或者通过升级来获取最新功能。本文介绍如何检查、配置升级，以及如何将升级应用到 Kubernetes 群集。

限制

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

先决条件

部署在 Azure 订阅的资源组中的 Azure 运营商关系 Kubernetes 群集。
如果使用的是 Azure CLI，则本文要求运行最新的 Azure CLI 版本。如果需要进行安装或升级，请参阅安装 Azure CLI
networkcloud az-cli 扩展版本所需的最低要求：2.0.b3
了解版本捆绑包概念。有关详细信息，请参阅关系 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 门户。
导航到运营商关系 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 的最新版本捆绑包。

升级群集

在群集升级过程中，运营商关系执行以下操作：

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

注意

如果操作系统 (OS) 映像版本和 Kubernetes 版本在版本捆绑包之间保持不变，则群集升级不会创建新节点和替换旧节点。这是预期行为，因为升级可能仅包括对加载项版本的更新，而不包括新的 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

自定义节点激增或不可用升级

默认情况下，运营商关系将升级配置为使用一个额外的工作器节点激增。最大激增设置的默认值为 1，这样会使运营商关系能够在隔离/排出现有应用程序之前创建额外的节点以替换旧版本的节点，从而最大限度地减少工作负载中断。可以为每个节点池自定义最大激增值，从而在升级速度与升级中断之间进行权衡。增加最大激增值后，升级过程会更快完成。如果为最大激增设置较大的值，可能会在升级过程中遇到中断。

例如，最大激增值为 100% 时，可以让升级过程尽可能快（将节点计数加倍），但也会导致节点池中的所有节点同时被耗尽。对于测试环境，可能希望使用类似的较高的值。对于生产节点池，建议将 max_surge 设置为 33%。

通过激增进行升级并不总是合适的，例如在资源约束环境中就不合适。升级还可以在不使用激增的情况下继续，即首先删除工作器节点，然后将其替换。这意味着不需要额外的资源，但会导致在某些时段的容量减少，即可能无法将 Pod 计划到某个节点。此类型的升级通过最大不可用设置按节点池进行控制。默认情况下，最大不可用值设置为 0。这表示最多 0 个节点不可用，即默认情况下不会发生这种类型的升级。

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

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

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

重要

标准 Kubernetes 工作负载在从即将拆除的节点中排空时，会本机循环到新节点。请记住，运营商关系 Kubernetes 服务无法为非标准 Kubernetes 行为做出工作负载承诺。

后续步骤

详细了解关系 Kubernetes 版本捆绑包。

通过