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

使用 Azure CLI 升级群集的运行时

2025-06-10

本操作指南介绍了安装与运营商关系交互所需的 Azure CLI 和扩展所需的步骤。

先决条件

安装最新版本的相应 CLI 扩展。
需要最新的 networkcloud CLI 扩展。可以按照此处列出的步骤安装它。
订阅访问权限以运行 Azure 运营商关系网络结构 (NF) 和网络云 (NC) CLI 扩展命令。
收集以下信息：
- 订阅 ID (SUBSCRIPTION)
- 群集名称 (CLUSTER)
- 资源组 (CLUSTER_RG)
目标群集必须处于运行状态，且所有控制平面节点都必须健康运行。

检查当前运行时版本

在升级之前验证当前群集运行时版本：如何检查当前群集运行时版本。

查找可用的运行时版本

通过 Azure 门户

若要查找可用的可升级运行时版本，请导航到 Azure 门户中的目标群集。在群集的概述窗格中，导航到 “可用升级版本 ”选项卡。

从 “可用升级版本 ”选项卡中，我们可以看到当前可用于升级的不同群集版本。运营商可以从列出的目标运行时版本中进行选择。选择后，继续升级群集。

通过 Azure CLI

可通过 Azure CLI 检索可用的升级：

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A8 availableUpgradeVersions

在输出中，可以找到 availableUpgradeVersions 属性并查看 targetClusterVersion 字段：

  "availableUpgradeVersions": [
    {
      "controlImpact": "True",
      "expectedDuration": "Upgrades may take up to 4 hours + 2 hours per rack",
      "impactDescription": "Workloads will be disrupted during rack-by-rack upgrade",
      "supportExpiryDate": "2023-07-31",
      "targetClusterVersion": "3.3.0",
      "workloadImpact": "True"
    }
  ],

如果没有可用的群集升级，则列表为空。

使用群集配置运行时升级的计算阈值参数 `updateStrategy`

以下 Azure CLI 命令用于配置运行时升级的计算阈值参数：

az networkcloud cluster update --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--update-strategy strategy-type="<strategyType>" threshold-type="<thresholdType>" \
threshold-value="<thresholdValue>" max-unavailable="<maxNodesOffline>" \
wait-time-minutes="<waitTimeBetweenRacks>" \
--subscription "<SUBSCRIPTION>"

所需参数：

strategy-type：定义更新策略。使用的设置是 Rack（逐个机架）或 PauseAfterRack（在每个机架启动前暂停以等待用户）。默认值为 Rack。若要使用 PauseAfterRack 策略执行群集运行时升级，请按照 Upgrade Cluster Runtime 中概述的步骤执行 PauseAfterRack 策略。
threshold-type：确定阈值的评估方式，按策略定义的单位应用。使用的设置为 PercentSuccess OR CountSuccess。默认值为 PercentSuccess。
threshold-value：用于评估更新的数字阈值。默认值为 80。

可选参数：

max-unavailable：可以脱机的最大工作器节点数，即一次升级的机架。默认值为 32767。
wait-time-minutes：更新机架之前的延迟或等待期。默认值为 15。

以下示例适用于使用 Rack-by-Rack 策略的客户，其成功百分比为 60%，暂停 1 分钟。

az networkcloud cluster update --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" \
threshold-value=60 wait-time-minutes=1 \
--subscription "<SUBSCRIPTION>"

验证更新：

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A5 updateStrategy

  "updateStrategy": {
    "maxUnavailable": 32767,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 60,
      "waitTimeMinutes": 1

在此示例中，如果某个机架上有不到 60% 的预配计算节点未能成功预配（逐个机架），群集升级将无限期等待，直到满足条件。如果成功预配了 60 个% 个或多个计算节点，群集部署将转到下一个计算节点机架。如果机架中故障过多，则必须修复硬件，然后才能继续升级。

以下示例描述了客户采用“逐个机架”策略，阈值类型 CountSuccess 为每个机架 10 个节点，暂停时间 1 分钟。

az networkcloud cluster update --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--update-strategy strategy-type="Rack" threshold-type="CountSuccess" \
threshold-value=10 wait-time-minutes=1 \
--subscription "<SUBSCRIPTION>"

验证更新：

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A5 updateStrategy

  "updateStrategy": {
    "maxUnavailable": 32767,
      "strategyType": "Rack",
      "thresholdType": "CountSuccess",
      "thresholdValue": 10,
      "waitTimeMinutes": 1

在此示例中，如果某个机架中有少于 10 个计算节点预配失败（按机架逐个计算），则群集升级会无限期地等待，直到满足条件。如果成功预配了 10 个或更多个计算节点，群集部署将转到下一个计算节点机架。如果机架中故障过多，则必须修复硬件，然后才能继续升级。

注意

update-strategy 在群集运行时升级启动后无法更改。 如果设置了低于 100% 的阈值，则可能无法升级任何不正常的节点，但“群集”状态仍可能指示升级成功。要排查裸机的问题，请参阅排查 Azure 运营商关系服务器问题

使用 CLI 升级群集运行时

若要执行运行时升级，请使用以下 Azure CLI 命令：

az networkcloud cluster update-version --cluster-name "<CLUSTER>" \
--target-cluster-version "<versionNumber>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>"

运行时升级是一个漫长的过程。升级过程首先会升级管理节点，然后逐个机架按顺序为工作器节点升级。管理服务器分为两个组。运行时升级现在将利用两个管理组，而不是一个组。引入此功能后，管理服务器上运行的组件可以通过应用关联规则来确保运行时升级期间的复原能力。对于此版本，每个 CSN 将通过在每个管理组中放置一个实例来利用此功能。没有客户与此功能交互。管理节点上可能会显示其他标签来标识组。当每个机架中 80% 的工作节点和每个组中 50% 的管理节点成功升级时，都会视为升级经完成。当机架中的工作器节点正在升级的过程中，工作负荷可能会受到影响，但所有其他机架中的工作负荷不会受到影响。建议根据此实现设计考虑工作负载的放置。

升级所有节点需要几个小时，具体取决于群集中的机架数量。由于升级过程的长度，应定期检查群集的详细状态，了解升级的当前状态。若要检查升级的状态，请观察群集的详细状态。可以通过门户或 az CLI 完成此检查。

若要通过 Azure 门户查看升级状态，请导航到目标群集资源。在群集的 “概述 ”屏幕中，提供详细状态以及详细的状态消息。

当 detailedStatus 设置为 Updating 并且 detailedStatusMessage 显示升级进度时，群集升级正在进行中。 detailedStatusMessage 中显示的升级进度的一些例子包括 Waiting for control plane upgrade to complete...、Waiting for nodepool "<rack-id>" to finish upgrading... 等等。

当 detailedStatus 设置为 Running 且 detailedStatusMessage 显示消息 Cluster is up and running 时，群集升级已完成

若要通过 Azure CLI 查看升级状态，请使用 az networkcloud cluster show。

az networkcloud cluster show --cluster-name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>"

输出应包含目标群集的信息，并且群集的详细状态和状态消息应该存在。有关升级进度的更详细见解，可以检查每个机架中各个节点的状态。裸机角色下的参考部分中提供了检查状态的示例。

常见问题

识别停滞/卡住的群集升级

在运行时升级期间，升级可能无法继续前进，但详细状态反映升级仍在进行中。 由于运行时升级可能需要很长时间才能成功完成，因此当前未指定任何设置的超时长度。因此，建议定期检查群集的详细状态和日志，以确定升级是否无限期地尝试升级。

我们可以通过查看群集的日志、详细消息和详细状态消息来确定 indefinitely attempting to upgrade 情况。如果发生超时，我们会发现群集持续无限地进行同一协调，而不会前进。在此处，我们建议检查群集日志或配置的 LAW，以查看是否存在故障或导致进度不足的特定升级。

识别裸机升级停滞/卡住

在裸机预配故障排除中提供了有关确定工作器节点预配问题的指南。

硬件故障不需要升级重新执行

如果在升级期间发生硬件故障，则只要满足计算和管理/控制节点的设定阈值，运行时升级就会继续。修复或替换计算机后，它会预配当前平台运行时的 OS，其中包含运行时的目标版本。如果在发生故障之前更新了机架，则在重新预配节点时，将使用升级后的运行时版本。如果在硬件故障之前机架规格未更新到升级的运行时版本，则计算机将在修复硬件时使用以前的运行时版本进行预配。当机架开始升级时，计算机随机架一起升级。

运行时升级后，群集会显示“失败”预配状态

在运行时升级期间，群集进入状态 Upgrading。如果运行时升级失败，群集将进入 Failed 预配状态。基础结构组件（例如存储设备）可能会导致升级期间发生故障。在某些情况下，可能需要让 Microsoft 支持部门来诊断失败情况。

通过