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

使用 Azure CLI 创建和预配群集

本文介绍如何使用 Azure 命令行接口 (AzCLI) 创建群集。 本文档还演示如何检查状态、更新或删除群集。

先决条件

  • 验证 Azure 区域中是否存在网络结构控制器和群集管理器
  • 验证是否已成功预配网络结构

API 指南和指标

API 指南提供有关资源提供程序、资源模型和 API 的信息。

从日志记录数据生成的指标在 Azure Monitor 指标中可用。

限制

  • 命名 - 可在此处找到命名规则。

创建群集

基础结构群集资源表示群集管理器中平台的本地部署。 其他所有特定于平台的资源在其生命周期内都依赖于它。

应在此本地部署之前创建网络结构。 每个运营商关系本地实例都与网络结构一对一关联。

使用 Azure CLI 创建群集:

az networkcloud cluster create --name "$CLUSTER_NAME" --location "$LOCATION" \
  --extended-location name="$CL_NAME" type="CustomLocation" \
  --resource-group "$CLUSTER_RG" \
  --analytics-workspace-id "$LAW_ID" \
  --cluster-location "$CLUSTER_LOCATION" \
  --network-rack-id "$AGGR_RACK_RESOURCE_ID" \
  --rack-sku-id "$AGGR_RACK_SKU"\
  --rack-serial-number "$AGGR_RACK_SN" \
  --rack-location "$AGGR_RACK_LOCATION" \
  --bare-metal-machine-configuration-data "["$AGGR_RACK_BMM"]" \
  --storage-appliance-configuration-data '[{"adminCredentials":{"password":"$SA_PASS","username":"$SA_USER"},"rackSlot":1,"serialNumber":"$SA_SN","storageApplianceName":"$SA_NAME"}]' \
  --compute-rack-definitions '[{"networkRackId": "$COMPX_RACK_RESOURCE_ID", "rackSkuId": "$COMPX_RACK_SKU", "rackSerialNumber": "$COMPX_RACK_SN", "rackLocation": "$COMPX_RACK_LOCATION", "storageApplianceConfigurationData": [], "bareMetalMachineConfigurationData":[{"bmcCredentials": {"password":"$COMPX_SVRY_BMC_PASS", "username":"$COMPX_SVRY_BMC_USER"}, "bmcMacAddress":"$COMPX_SVRY_BMC_MAC", "bootMacAddress":"$COMPX_SVRY_BOOT_MAC", "machineDetails":"$COMPX_SVRY_SERVER_DETAILS", "machineName":"$COMPX_SVRY_SERVER_NAME"}]}]'\
  --managed-resource-group-configuration name="$MRG_NAME" location="$MRG_LOCATION" \
  --network fabric-id "$NF_ID" \
  --cluster-service-principal application-id="$SP_APP_ID" \
    password="$SP_PASS" principal-id="$SP_ID" tenant-id="$TENANT_ID" \
  --subscription "$SUBSCRIPTION_ID" \
  --secret-archive "{key-vault-id:$KVRESOURCE_ID, use-key-vault:true}" \
  --cluster-type "$CLUSTER_TYPE" --cluster-version "$CLUSTER_VERSION" \
  --tags $TAG_KEY1="$TAG_VALUE1" $TAG_KEY2="$TAG_VALUE2"

群集操作的参数

参数名称 说明
CLUSTER_NAME 群集的资源名称
LOCATION 在其中部署了群集的 Azure 区域
CL_NAME Azure 门户中的群集管理器自定义位置
CLUSTER_RG 群集资源组名称
LAW_ID 群集的 Log Analytics 工作区 ID
CLUSTER_LOCATION 群集的本地名称
AGGR_RACK_RESOURCE_ID 聚合器机架的 RackID
AGGR_RACK_SKU 聚合器机架的机架 SKU *请参阅 Operator Nexus 网络云 SKU
AGGR_RACK_SN 聚合器机架的机架序列号
AGGR_RACK_LOCATION 聚合器机架的机架物理位置
AGGR_RACK_BMM 仅用于单机架部署,多机架部署为空
SA_NAME 存储设备的设备名称
SA_PASS 存储设备管理员密码
SA_USER 存储设备管理员用户
SA_SN 存储设备序列号
COMPX_RACK_RESOURCE_ID CompX 机架的 RackID;在 compute-rack-definitions 中对每个机架重复
COMPX_RACK_SKU CompX 机架的机架 SKU;在 compute-rack-definitions 中对每个机架重复*请参阅 Operator Nexus 网络云 SKU
COMPX_RACK_SN CompX 机架的机架序列号;在 compute-rack-definitions 中对每个机架重复
COMPX_RACK_LOCATION CompX 机架的机架物理位置;在 compute-rack-definitions 中对每个机架重复
COMPX_SVRY_BMC_PASS CompX Rack ServerY 基板管理控制器 (BMC) 密码;对 compute-rack-definitions 中的每个机架和机架中的每个服务器重复
COMPX_SVRY_BMC_USER CompX Rack ServerY BMC 用户,对 compute-rack-definitions 中的每个机架和机架中的每个服务器重复
COMPX_SVRY_BMC_MAC CompX Rack ServerY BMC MAC 地址,对 compute-rack-definitions 中的每个机架和机架中的每个服务器重复
COMPX_SVRY_BOOT_MAC CompX Rack ServerY boot 网络适配卡 (NIC) MAC 地址;对 compute-rack-definitions 中的每个机架和机架中的每个服务器重复
COMPX_SVRY_SERVER_DETAILS CompX Rack ServerY 详细信息,对 compute-rack-definitions 中的每个机架和机架中的每个服务器重复
COMPX_SVRY_SERVER_NAME CompX Rack ServerY 名称;对 compute-rack-definitions 中的每个机架和机架中的每个服务器重复
MRG_NAME 群集托管资源组名称
MRG_LOCATION 群集 Azure 区域
NF_ID 对网络结构的引用
SP_APP_ID 服务主体应用 ID
SP_PASS 服务主体密码
SP_ID 服务主体 ID
TENANT_ID 订阅租户 ID
SUBSCRIPTION_ID 订阅 ID
KV_RESOURCE_ID 密钥保管库 ID
CLUSTER_TYPE 群集类型:Single 或 MultiRack
CLUSTER_VERSION 群集的网络云 (NC) 版本
TAG_KEY1 传递给“群集创建”的可选 tag1
TAG_VALUE1 传递给“群集创建”的可选 tag1 值
TAG_KEY2 传递给“群集创建”的可选 tag2
TAG_VALUE2 传递给“群集创建”的可选 tag2 值

群集标识

从 2024-07-01 API 版本开始,客户可将托管标识分配到群集。 系统分配的托管标识和用户分配的托管标识均受支持。

在创建或更新操作期间,可以通过提供以下参数将托管标识分配给群集:

  • --mi-system-assigned - 启用系统分配的托管标识。 添加后,此时只能通过 API 调用删除该标识。
  • --mi-user-assigned - 要添加的用户分配的托管标识的空格分隔资源 ID。 添加后,此时只能通过 API 调用删除该标识。

使用 Azure 资源管理器模板编辑器创建群集

创建群集的另一种方法是使用 ARM 模板编辑器。

若要以这种方式创建群集,需要提供模板文件 (cluster.jsonc) 和参数文件 (cluster.parameters.jsonc)。 可以使用以下两个文件查找 8 机架 2M16C SKU 群集的示例:

cluster.jsonccluster.parameters.jsonc

注意

若要获取正确的格式,请复制原始代码文件。 cluster.parameters.jsonc 文件中的值特定于客户,可能不是完整列表。 更新特定环境的值字段。

  1. 在 Web 浏览器中导航到 Azure 门户,然后登录。
  2. 在 Azure 门户搜索栏中搜索“部署自定义模板”,然后从可用服务中选择它。
  3. 在编辑器中单击“生成自己的模板”。
  4. 单击“加载文件”。 找到 cluster.jsonc 模板文件并上传它。
  5. 单击“ 保存”。
  6. 单击“编辑参数”。
  7. 单击“加载文件”。 找到 cluster.parameters.jsonc 参数文件并上传它。
  8. 单击“ 保存”。
  9. 选择正确的订阅。
  10. 搜索资源组,查看它是否已经存在。 如果不存在,创建新的资源组。
  11. 确保所有实例详细信息都正确。
  12. 单击“查看 + 创建”。

群集验证

成功创建运营商关系群集后,系统会在订阅中创建 Azure 资源。 cluster create 成功后会返回群集 ID、群集预配状态和部署状态。

查看群集的状态:

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

当资源的 provisioningState 显示 "provisioningState": "Succeeded" 时,表示群集创建完成

群集登录

可在以下位置查看群集创建日志:

  1. 查看 Azure 门户资源/资源组活动日志。
  2. 在 Azure CLI 命令行中传递 --debug 标志。

设置部署阈值

在群集部署之前,可以为其设置两种类型的部署阈值。 它们是 compute-deployment-thresholdupdate-strategy

--compute-deployment-threshold - 此验证阈值表示,环境硬件验证期间所允许的计算节点故障数量或比例

如果未设置 compute-deployment-threshold,那么默认采用如下设置:

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

如果客户请求的 compute-deployment-threshold 不同于 80% 的默认比例,则可以运行以下群集更新命令。

以下示例是针对客户请求类型为“PercentSuccess”且成功率为 97% 的情况。

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--compute-deployment-threshold type="PercentSuccess" grouping="PerCluster" value=97 /
--subscription <subscriptionID>

验证更新

az networkcloud cluster show --resource-group "<resourceGroup>" --name "<clusterName>" | grep -a3 computeDeploymentThreshold

  "clusterType": "MultiRack",
  "clusterVersion": "<CLUSER_VERSION>",
  "computeDeploymentThreshold": {
    "grouping": "PerCluster",
    "type": "PercentSuccess",
    "value": 97

在此示例中,如果部署的计算节点中通过硬件验证的比例低于 97%,整个群集的部署将视为失败。 注:所有 Kubernetes 控制平面 (KCP) 和 Nexus 管理平面 (NMP) 必须通过硬件验证。 如果部署的计算节点中通过硬件验证的比例达到 97% 或更高,群集部署将会继续进入到下一个阶段,即启动预配阶段。 在计算启动预配期间,会为计算节点使用 update-strategy(见下文)。

--update-strategy - 该策略用于更新集群,并指明了启动预配期间所允许的计算节点故障数量或比例

如果客户请求的 update-strategy 阈值不同于 80% 的默认比例,则可以运行以下群集更新命令。

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

策略类型可以是“Rack”(逐个机架)或“PauseAfterRack”(等待客户响应才能继续)。

阈值类型可以是“PercentSuccess”或“CountSuccess”。

如果未设置 updateStrategy,那么默认采用如下设置:

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

以下示例描述了客户采用 Rack by Rack(逐个机架)策略,成功率和暂停时间分别为 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% 或以上的计算节点成功预配,就可以继续对下一个机架的计算节点进行群集部署。

以下示例描述了客户采用 Rack by Rack(逐个机架)策略,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 个或以上的计算节点成功预配,就可以继续对下一个机架的计算节点进行群集部署。

注意

群集部署开始后无法更改部署阈值。

部署群集

创建群集后,可以触发部署群集操作。 “部署群集”操作会创建启动映像并部署群集。

“部署群集”会启动在群集管理器中发生的一系列事件。

  1. 验证群集/机架属性。
  2. 为临时启动群集生成可启动映像(验证基础结构)。
  3. 与目标启动计算机的智能平台管理接口(IPMI)交互。
  4. 执行硬件验证检查。
  5. 监视群集部署过程。

部署本地群集:

az networkcloud cluster deploy \
  --name "$CLUSTER_NAME" \
  --resource-group "$CLUSTER_RG" \
  --subscription "$SUBSCRIPTION_ID" \
  --no-wait --debug

提示

若要检查 az networkcloud cluster deploy 命令的状态,可以使用 --debug 标志执行它。 这样,你便能够获取用于查询 operationStatuses 资源的 Azure-AsyncOperationLocation 标头。 如需更详细的步骤,请参阅群集部署失败部分。 (可选)可以使用 --no-wait 标志异步运行该命令。

具有硬件验证的群集部署

在群集部署过程中,执行的步骤之一是硬件验证。 硬件验证过程会运行各种测试,并针对通过群集机架定义提供的计算机进行检查。 根据这些检查的结果和任何用户跳过的计算机,确定是否有足够的节点通过和/或可用于满足继续部署所需的阈值。

重要

硬件验证过程会将结果写入群集创建时指定的 analyticsWorkspaceId。 此外,群集对象中提供的服务主体用于对 Log Analytics 工作区数据收集 API 进行身份验证。 此功能仅在新部署期间可见(绿色字段),现有群集无法以追溯方式获取日志。

注意

在群集部署期间会重置 RAID 控制器,以擦除服务器虚拟磁盘中的所有数据。 除非存在附加物理磁盘和/或 RAID 控制器警报,否则通常可以忽略任何基板管理控制器 (BMC) 虚拟磁盘警报。

默认情况下,硬件验证过程会将结果写入配置的群集 analyticsWorkspaceId。 但是,由于 Log Analytics 工作区数据收集和架构评估的性质,引入延迟可能达到几分钟或更久。 因此,即使未能将结果写入 Log Analytics 工作区,群集部署也会继续。 为了帮助解决这个可能的事件,结果也会在群集管理器中记录,以实现冗余。

在提供的群集对象的 Log Analytics 工作区中,会显示一个新的自定义表,它使用群集的名称作为前缀,后缀 *_CL 应会显示。 在 LAW 资源的“日志”部分中,可以针对新的 *_CL 自定义日志表执行查询。

跳过特定裸机的群集部署

--skip-validation-for-machines 参数表示群集中在硬件验证期间应跳过的裸机计算机的名称。 跳过的节点不会被验证,也不会添加到节点池。 此外,跳过的节点不会计入阈值计算使用的总数。

az networkcloud cluster deploy \
  --name "$CLUSTER_NAME" \
  --resource-group "$CLUSTER_RG" \
  --subscription "$SUBSCRIPTION_ID" \
  --skip-validations-for-machines "$COMPX_SVRY_SERVER_NAME"

群集部署失败

若要跟踪异步操作的状态,请在运行时启用 --debug 标志。 指定 --debug 后,可以监视请求的进度。 可以通过检查调试输出,查找对创建请求的 HTTP 响应上的 Azure-AsyncOperationLocation 标头来找到操作状态 URL。 这些标头可以提供 HTTP API 调用中使用的 OPERATION_ID 字段。

OPERATION_ID="aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e*99399E995..."
az rest -m GET -u "https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}/providers/Microsoft.NetworkCloud/locations/${LOCATION}/operationStatuses/${OPERATION_ID}?api-version=2022-12-12-preview"

输出类似于 JSON 结构示例。 当错误代码为 HardwareValidationThresholdFailed 时,错误消息会包含一个未通过硬件验证的裸机列表(例如,COMP0_SVR0_SERVER_NAMECOMP1_SVR1_SERVER_NAME)。 这些名称可用于分析日志以获取更多详细信息。

{
  "endTime": "2023-03-24T14:56:59.0510455Z",
  "error": {
    "code": "HardwareValidationThresholdFailed",
    "message": "HardwareValidationThresholdFailed error hardware validation threshold for cluster layout plan is not met for cluster $CLUSTER_NAME in namespace nc-system with listed failed devices $COMP0_SVR0_SERVER_NAME, $COMP1_SVR1_SERVER_NAME"
  },
  "id": "/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.NetworkCloud/locations/$LOCATION/operationStatuses/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e*99399E995...",
  "name": "aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e*99399E995...",
  "resourceId": "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$CLUSTER_RESOURCE_GROUP/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME",
  "startTime": "2023-03-24T14:56:26.6442125Z",
  "status": "Failed"
}

参阅文章使用 Azure CLI 跟踪异步操作了解另一个示例。 请参阅“BMM 配置故障排除”一文以获取更多信息,当特定计算机验证或部署失败时,这些信息可能会有所帮助。

群集部署验证

在门户上或通过 Azure CLI 查看群集的状态:

az networkcloud cluster show --resource-group "$CLUSTER_RG" \
  --name "$CLUSTER_NAME"

当 detailedStatus 设置为 Deploying 且 detailedStatusMessage 显示部署进度时,群集部署正在进行中。 detailedStatusMessage 中显示的一些部署进度示例为 Hardware validation is in progress.(如果使用硬件验证部署群集)、Cluster is bootstrapping.KCP initialization in progress.Management plane deployment in progress.Cluster extension deployment in progress.waiting for "<rack-ids>" to be ready 等。

Azure 门户的屏幕截图,其中显示群集部署进度 kcp init。

Azure 门户的屏幕截图,其中显示群集部署进度扩展应用程序。

当 detailedStatus 设置为 Running 且 detailedStatusMessage 显示消息 Cluster is up and running 时,群集部署已完成。

Azure 门户的屏幕截图,其中显示群集部署已完成。

查看群集的管理版本:

az k8s-extension list --cluster-name "$CLUSTER_NAME" --resource-group "$MRG_NAME" --cluster-type connectedClusters --query "[?name=='nc-platform-extension'].{name:name, extensionType:extensionType, releaseNamespace:scope.cluster.releaseNamespace,provisioningState:provisioningState,version:version}" -o table --subscription "$SUBSCRIPTION_ID"

群集部署日志记录

可在以下位置查看群集创建日志:

  1. 查看 Azure 门户资源/资源组活动日志。
  2. 在 Azure CLI 命令行中传递 --debug 标志。

Azure 门户的屏幕截图,其中显示群集部署进度活动日志。

通过 API 更新群集标识

可通过 CLI 分配群集托管标识。 可通过 API 调用来完成标识的取消分配。 注意,<APIVersion> 是 API 版本 2024-07-01 或更高版本。

  • 若要删除所有托管标识,请执行:

    az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_RG/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME?api-version=<APIVersion> --body "{\"identity\":{\"type\":\"None\"}}"
    
  • 如果同时添加了用户分配的托管标识和系统分配的托管标识,可通过将 type 更新为 SystemAssigned 来删除用户分配的托管标识:

    az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_RG/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME?api-version=<APIVersion> --body @~/uai-body.json
    

    请求正文 (uai-body.json) 示例:

    {
      "identity": {
          "type": "SystemAssigned"
      }
    }
    
  • 如果同时添加了用户分配的托管标识和系统分配的托管标识,可通过将 type 更新为 UserAssigned 来删除系统分配的托管标识:

    az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_RG/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME?api-version=<APIVersion> --body @~/uai-body.json
    

    请求正文 (uai-body.json) 示例:

    {
      "identity": {
          "type": "UserAssigned",
      	"userAssignedIdentities": {
      		"/subscriptions/$SUB_ID/resourceGroups/$UAI_RESOURCE_GROUP/providers/Microsoft.ManagedIdentity/userAssignedIdentities/$UAI_NAME": {}
      	}
      }
    }
    
  • 如果添加了多个用户分配的托管标识,可通过执行以下操作删除其中一个标识:

    az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_RG/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME?api-version=<APIVersion> --body @~/uai-body.json
    

    请求正文 (uai-body.json) 示例:

    {
      "identity": {
          "type": "UserAssigned",
      	"userAssignedIdentities": {
      		"/subscriptions/$SUB_ID/resourceGroups/$UAI_RESOURCE_GROUP/providers/Microsoft.ManagedIdentity/userAssignedIdentities/$UAI_NAME": null
      	}
      }
    }
    

删除群集

删除群集会删除 Azure 中的资源以及驻留在本地环境中的群集。

注意

如果群集中存在任何租户资源,则在删除这些资源之前,不会删除该租户。

门户的屏幕截图,其中显示了删除由于租户资源而失败。

az networkcloud cluster delete --name "$CLUSTER_NAME" --resource-group "$CLUSTER_RG"