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

从 Azure CLI 升级群集运行时

项目
12/19/2024

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

先决条件

必须安装 Azure CLI。
需要 networkcloud CLI 扩展。如果未安装 networkcloud 扩展，则可以按照此处列出的步骤安装它。
对 Azure 门户的访问权限，以便升级目标群集。
必须通过 az login 登录到与目标群集相同的订阅
目标群集必须处于运行状态，所有控制平面节点都处于正常状态，并且计算节点的 80+% 处于运行状态和正常状态。

检查当前运行时版本

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

查找可用的运行时版本

通过 Azure 门户

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

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

通过 Azure CLI

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

az networkcloud cluster show --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--subscription <subscriptionID>

在输出中，可以找到 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 "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value="<thresholdValue>" max-unavailable=<maxNodesOffline> /
wait-time-minutes=<waitTimeBetweenRacks> /
--subscription <subscriptionID>

所需参数：

strategy-type：定义更新策略。这可以是（"Rack"逐个机架）或"PauseAfterRack"（一次升级一个机架，等待确认，然后继续升级下一个机架。默认值为 Rack。要使用“PauseRack”策略执行群集运行时升级，请按照使用暂停机架策略升级群集运行时中所述的步骤进行操作
threshold-type：确定阈值的评估方式，按策略定义的单位应用。这可以是 "PercentSuccess" 或 "CountSuccess"。默认值为 PercentSuccess。
threshold-value：用于评估更新的数字阈值。默认值为 80。

可选参数：

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

以下示例描述了客户采用“逐个机架”策略，成功率和暂停时间分别为 60% 和 1 分钟。

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value=60 wait-time-minutes=1 /
--subscription <subscriptionID>

验证更新：

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 60,
      "waitTimeMinutes": 1

在此示例中，如果每个机架上有低于 60% 的预配计算节点未能成功预配（按逐个机架统计），群集部署将视为失败。如果 60% 或以上的计算节点成功预配，就可以继续对下一个机架的计算节点进行群集部署。

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

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="CountSuccess" /
threshold-value=10 wait-time-minutes=1 /
--subscription <subscriptionID>

验证更新：

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "CountSuccess",
      "thresholdValue": 10,
      "waitTimeMinutes": 1

在此示例中，如果每个机架上有不足 10 个预配计算节点未能成功预配（按逐个机架统计），群集部署将视为失败。如果 10 个或以上的计算节点成功预配，就可以继续对下一个机架的计算节点进行群集部署。

注意

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

使用 CLI 升级群集运行时

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

az networkcloud cluster update-version --cluster-name "<clusterName>" /
--target-cluster-version "<versionNumber>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

运行时升级是一个漫长的过程。升级过程首先会升级管理节点，然后逐个机架按顺序为工作器节点升级。如果每个机架 80% 的工作器节点和 100% 的管理节点已成功升级，则升级被视为已成功。当机架中的工作器节点正在升级的过程中，工作负载可能会受到影响，但所有其他机架中的工作负载不会受到影响。建议根据此实现设计考虑工作负载的放置。

升级所有节点需要几个小时，具体取决于群集中的机架数量。由于升级过程的长度，应定期检查群集的详细状态，了解升级的当前状态。若要检查升级的状态，请观察群集的详细状态。可以通过门户或 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 "<clusterName>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

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

常见问题

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

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

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

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

如果在升级期间发生硬件故障，则只要满足计算和管理/控制节点的设定阈值，运行时升级就会继续。修复或替换计算机后，它会预配当前平台运行时的 OS，其中包含运行时的目标版本。

如果发生硬件故障，并且运行时升级失败，因为计算和控制节点未满足阈值，则可能需要重新执行运行时升级。具体取决于故障发生的时间以及机架中各个服务器的状态。如果在发生故障之前更新了机架，则在重新预配节点时，将使用升级后的运行时版本。如果在硬件故障之前机架规格未更新到升级后的运行时版本，则会使用以前的运行时版本预配计算机。若要升级到新的运行时版本，请提交新的群集升级请求。仅升级具有以前运行时版本的节点。在上一个升级操作中成功的主机不会升级。

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

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

通过