编辑

Share via

修复在 AKS Arc 中配置网络时的已知问题和错误

  • 常见问题解答

适用于：Azure Stack HCI 上的 AKS、Windows Server 上的 AKS 使用本主题可帮助你排查和解决与 AKS Arc 相关的网络问题。

错误：“无法在故障转移群集中启动云代理通用群集服务。 群集资源组处于“失败”状态。

使用包含空格的路径名称时，云代理可能无法成功启动。

使用 Set-AksHciConfig 指定路径名包含空格字符（例如 D:\Cloud Share\AKS HCI）的 、-workingDir、-cloudConfigLocation 或 -nodeConfigLocation 参数时，云代理群集服务将无法启动，并显示以下（或类似）错误消息：

Failed to start the cloud agent generic cluster service in failover cluster. The cluster resource group os in the 'failed' state. Resources in 'failed' or 'pending' states: 'MOC Cloud Agent Service'

若要解决此问题，请使用不包含空格的路径，例如 C:\CloudShare\AKS-HCI。

连接 Arc 的群集具有空的 JSON“分布”属性

Azure Arc for Kubernetes 连接的群集可以将 JSON 属性 distribution 的值设置为空字符串。 对于连接 AKS Arc 的群集，此值在初始安装期间设置，在部署的生存期内永远不会更改。

若要重现此问题，请打开Azure PowerShell窗口并运行以下命令：

az login
az account set --subscription <sub_id>
az connectedk8s show -g <rg_name> -n

下面是此命令的示例输出：

{
"agentPublicKeyCertificate": <value>
"agentVersion": "1.8.14",
"azureHybridBenefit": "NotApplicable",
"connectivityStatus": "Connected",
"distribution": "",
"distributionVersion": null,
"id": "/subscriptions/<subscription>/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",
"identity": {
  "principalId": "<principal id>",
  "tenantId": "<tenant id>",
  "type": "SystemAssigned"
},
"infrastructure": "azure_stack_hci",
"kubernetesVersion": "1.23.12",
"lastConnectivityTime": "2022-11-04T14:59:59.050000+00:00",
"location": "eastus",
"managedIdentityCertificateExpirationTime": "2023-02-02T14:24:00+00:00",
"miscellaneousProperties": null,
"name": "mgmt-cluster",
"offering": "AzureStackHCI_AKS_Management",
"privateLinkScopeResourceId": null,
"privateLinkState": "Disabled",
"provisioningState": "Succeeded",
"resourceGroup": "<resource group>",
"systemData": {
  "createdAt": "2022-11-04T14:29:17.680060+00:00",
  "createdBy": "<>",
  "createdByType": "Application",
  "lastModifiedAt": "2022-11-04T15:00:01.830067+00:00",
  "lastModifiedBy": "64b12d6e-6549-484c-8cc6-6281839ba394",
  "lastModifiedByType": "Application"
},
"tags": {},
"totalCoreCount": 4,
"totalNodeCount": 1,
"type": "microsoft.kubernetes/connectedclusters"
}

解决此问题

如果 JSON distribution 属性的输出返回空字符串，请按照以下说明修补群集：

  1. 将以下配置复制到名为 patchBody.json 的文件中：

    {
   "properties": {
     "distribution": "aks_management"
   }
}

    重要

    如果群集是 AKS 管理群集，则 值应设置为 aks_management。 如果是工作负荷群集，则应将其设置为 aks_workload。

  2. 从上面获取的 JSON 输出中，复制连接的群集 ID。 它应显示为采用以下格式的长字符串：

    "/subscriptions/<subscription >/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",

  3. 运行以下命令来修补群集。 该值 <cc_arm_id> 应为在步骤 2 中获取的 ID：

    az rest -m patch -u "<cc_arm_id>?api-version=2022-10-01-preview" -b "@patchBody.json"

  4. 通过运行 az connectedk8s show -g <rg_name> -n <cc_name> 检查群集是否已成功修补，以确保 JSON 属性 distribution 已正确设置。

WSSDAgent 服务在启动时停滞，无法连接到云代理

症状：

  • 在 AKS Arc 中启用了代理。WSSDAgent 服务停滞在 starting 状态。 如下所示：
  • Test-NetConnection -ComputerName <computer IP/Name> -Port <port> 从节点代理失败到云代理在系统 (正常运行，即使 wssdagent 无法启动)
  • Curl.exe 从代理失败的节点上向云代理重现问题并卡住： curl.exe https://<computerIP>:6500
  • 若要解决此问题，请将 --noproxy 标志传递给 curl.exe。 Curl 从 wssdcloudagent 返回错误。 这是预期的，因为 curl 不是 GRPC 客户端。 发送 --noproxy 标志时，Curl 不会卡在等待。 因此，返回错误被视为成功) ：
curl.exe --noproxy '*' https://<computerIP>:65000

代理设置很可能已更改为主机上有故障的代理。 AKS Arc 的代理设置是从主机上的父进程继承的环境变量。 仅当新服务启动或旧服务更新或重新启动时，才会传播这些设置。 可能是在主机上设置了错误的代理设置，并在更新或重新启动后传播到 WSSDAgent，这导致 WSSDAgent 失败。

需要通过更改计算机上的环境变量来修复代理设置。 在计算机上，使用以下命令更改变量：

  [Environment]::SetEnvironmentVariable("https_proxy", <Value>, "Machine")
  [Environment]::SetEnvironmentVariable("http_proxy", <Value>, "Machine")
  [Environment]::SetEnvironmentVariable("no_proxy", <Value>, "Machine")

重新启动计算机，以便服务管理器和 WSSDAgent 选取固定代理。

CAPH Pod 无法续订证书

发生此错误的原因是，每次启动 CAPH Pod 时，都会尝试登录到 cloudagent，并将证书存储在临时存储卷中，这将在 Pod 重启时清除。 因此，每次重启 Pod 时，都会销毁证书并尝试新的登录。

登录尝试将启动一个续订例程，该例程会在证书即将过期时续订证书。 如果证书可用，CAPH Pod 决定是否需要登录名。 如果证书可用，则不会尝试登录，前提是续订例程已存在。

但是，在容器重启时，临时目录不会清理，因此文件仍会保留，并且不会进行登录尝试，从而导致无法启动续订例程。 这会导致证书过期。

若要缓解此问题，请使用以下命令重启 CAPH Pod：

kubectl delete pod pod-name

Set-AksHciConfig 失败并出现 WinRM 错误，但显示 WinRM 配置正确

运行 Set-AksHciConfig 时，可能会遇到以下错误：

WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
Powershell remoting to TK5-3WP08R0733 was not successful.
At C:\Program Files\WindowsPowerShell\Modules\Moc\0.2.23\Moc.psm1:2957 char:17
+ ...             throw "Powershell remoting to "+$env:computername+" was n ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Powershell remo...not successful.:String) [], RuntimeException
    + FullyQualifiedErrorId : Powershell remoting to TK5-3WP08R0733 was not successful.

大多数时候，发生此错误是因为用户安全令牌更改（由于组成员身份更改）、密码更改或密码过期。 在多数情况下，可以通过从计算机注销并重新登录来修正该问题。 如果错误仍然存在，可以通过Azure 门户创建支持票证。

AKS Arc 群集停滞在“ScalingControlPlane”预配状态

此问题会导致 AKS Arc 群集长时间保持 ScalingControlPlane 状态。

重现步骤

Get-AksHciCluster -Name <cluster name> | select *

Status                : {ProvisioningState, Details}
ProvisioningState     : ScalingControlPlane
KubernetesVersion     : v1.22.6
PackageVersion        : v1.22.6-kvapkg.0
NodePools             : {nodepoolA, nodepoolB}
WindowsNodeCount      : 0
LinuxNodeCount        : 1
ControlPlaneNodeCount : 1
ControlPlaneVmSize    : Standard_D4s_v3
AutoScalerEnabled     : False
AutoScalerProfile     :
Name                  : <cluster name>

此问题已在最新的 AKS Arc 版本中修复。 建议将 AKS Arc 群集更新到最新版本。

若要缓解此问题，请联系支持人员手动修补控制平面节点的状态，以便通过 kubectl 从计算机状态中删除条件 MachineOwnerRemediatedCondition 。

找不到工作负载群集

如果 Azure Stack HCI 部署上的两个 AKS 的 IP 地址池相同或重叠，则可能找不到工作负载群集。 如果部署两个 AKS 主机并同时对两者使用相同的AksHciNetworkSetting配置，则 PowerShell 和 Windows Admin Center 可能无法找到工作负载群集，因为 API 服务器将在两个群集中分配相同的 IP 地址，从而导致冲突。

收到的错误消息将如下所示。

A workload cluster with the name 'clustergroup-management' was not found.
At C:\Program Files\WindowsPowerShell\Modules\Kva\0.2.23\Common.psm1:3083 char:9
+         throw $("A workload cluster with the name '$Name' was not fou ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (A workload clus... was not found.:String) [], RuntimeException
    + FullyQualifiedErrorId : A workload cluster with the name 'clustergroup-management' was not found.

注意

群集名称将有所不同。

若要解决此问题，请删除其中一个群集，并创建一个新的 AKS 群集网络设置，该设置具有与其他群集不重叠的网络。

Get-AksHCIClusterNetwork 不显示 IP 地址的当前分配

运行 Get-AksHciClusterNetwork 命令将获得所有虚拟网络配置的列表。 但是，该命令不会显示 IP 地址的当前分配。

若要查看虚拟网络中当前使用的 IP 地址，请执行以下步骤：

  1. 若要获取组，请运行以下命令：
Get-MocGroup -location MocLocation
  1. 若要获取当前使用的 IP 地址的列表以及可用或已使用的虚拟 IP 地址的列表，请运行以下命令：
Get-MocNetworkInterface -Group <groupName> | ConvertTo-Json -depth 10
  1. 使用以下命令查看当前使用的虚拟 IP 地址的列表：
Get-MocLoadBalancer -Group <groupName> | ConvertTo-Json -depth 10

“群集 IP 地址 x.x.x.x”失败

预检查期间，群集 IP 地址显示为“失败”。 此预检查测试所有 IPv4 地址和 DNS 网络名称是否都联机且可访问。 例如，IPv4 或网络名称失败可能会导致此测试失败。

若要解决此问题，请执行以下步骤：

  1. 运行以下命令：

    Get-ClusterGroup -name "Cluster Group" | Get-ClusterResource

  2. 确保所有网络名称和 IP 地址都处于联机状态。

  3. 运行以下两个命令：

    Stop-ClusterResource -name "Cluster IP Address x.x.x.x"

    然后

    Start-ClusterResource -name "Cluster IP Address x.x.x.x"

使用配置错误的网络部署 Azure Stack HCI 上的 AKS 时，部署在不同时间点超时

在 Azure Stack HCI 上部署 AKS 时，部署可能会在过程的不同点超时，具体取决于错误配置发生的位置。 应查看错误消息，确定原因及其发生位置。

例如，在下面的错误中，发生配置错误的点在 Get-DownloadSdkRelease -Name "mocstack-stable" 中：

$vnet = New-AksHciNetworkSettingSet-AksHciConfig -vnet $vnetInstall-AksHciVERBOSE: 
Initializing environmentVERBOSE: [AksHci] Importing ConfigurationVERBOSE: 
[AksHci] Importing Configuration Completedpowershell : 
GetRelease - error returned by API call: 
Post "https://msk8s.api.cdp.microsoft.com/api/v1.1/contents/default/namespaces/default/names/mocstack-stable/versions/0.9.7.0/files?action=generateDownloadInfo&ForegroundPriority=True": 
dial tcp 52.184.220.11:443: connectex: 
A connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond.At line:1 char:1+ powershell -command
{ Get-DownloadSdkRelease -Name "mocstack-stable"}

这表示物理 Azure Stack HCI 节点可以解析下载 URL msk8s.api.cdp.microsoft.com 的名称，但该节点无法连接到目标服务器。

若要解决此问题，需要确定连接流中发生中断的位置。 下面是尝试从物理群集节点解决问题的一些步骤：

  1. Ping 目标 DNS 名称：ping msk8s.api.cdp.microsoft.com。
  2. 如果收到响应且没有超时，则表示基本网络路径正常运行。
  3. 如果连接超时，则可能是数据路径中发生了中断。 有关详细信息，请参阅检查代理设置。 或者，可能是返回路径中发生了中断，因此应检查防火墙规则。

NTP 时间相关的应用程序触发数百个错误警报

NTP 时间相关的应用程序在时间同步时可能会触发数百个错误警报。如果群集在代理环境中运行，则节点池可能无法通过代理或防火墙与默认 NTP 服务器 （time.windows.com）通信。

解决方法

若要解决此问题，请更新每个节点池节点上的 NTP 服务器配置以同步时钟。 这样做也会在每个应用程序 Pod 中设置时钟。

先决条件

  • 可在每个节点池节点中访问的 NTP 服务器的地址。
  • 对工作负载群集 kubeconfig 文件的访问权限。
  • 访问管理群集 kubeconfig。

步骤

  1. 使用工作负载群集 kubeconfig 运行以下命令kubectl，获取其中节点的列表：

    kubectl --kubeconfig <PATH TO KUBECONFIG> get nodes -owide

  2. 运行以下命令 kubectl ，将上一命令中的节点名称与工作负载群集的节点池节点相关联。 记下上一命令输出中的相关 IP 地址。

    kubectl --kubeconfig (Get-KvaConfig).kubeconfig get machine -l cluster.x-k8s.io/cluster-name=<WORKLOAD_CLUSTER_NAME>

  3. 使用前面步骤的输出，对需要更新 NTP 配置的每个 nodepool 节点运行以下步骤：

    1. 通过 SSH 连接到节点池节点 VM：

      ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<NODEPOOL_IP>

    2. 验证配置的 NTP 服务器是否无法访问：

      sudo timedatectl timesync-status

      如果输出如下所示，则 NTP 服务器无法访问，需要对其进行更改：

      Server: n/a (time.windows.com)
Poll interval: 0 (min: 32s; max 34min 8s)
Packet count: 0

    3. 若要更新 NTP 服务器，请运行以下命令，将 timesync 配置文件中的 NTP 服务器设置为可从节点池 VM 访问的服务器：

      # make a backup of the config file
sudo cp /etc/systemd/timesyncd.conf ~/timesyncd.conf.bak

# update the ntp server
NTPSERVER="NEW_NTP_SERVER_ADDRESS"
sudo sed -i -E "s|^(NTP=)(.*)$|\1$NTPSERVER|g" /etc/systemd/timesyncd.conf

# verify that the NTP server is updated correctly - check the value for the field that starts with "NTP="
sudo cat /etc/systemd/timesyncd.conf

    4. 重启 timesync 服务：

      sudo systemctl restart systemd-timesyncd.service

    5. 验证 NTP 服务器是否可访问：

      sudo timedatectl timesync-status

    6. 验证时钟是否显示正确的时间：

      date

  4. 通过运行步骤 3.f 中的 命令，确保每个 nodepool 节点显示相同的时间。

  5. 如果应用程序未自动更新其时间，请重启其 Pod。

后续步骤