编辑

通过

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

  • 常见问题解答

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

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

将路径名称与其中空格一起使用时，云代理可能无法成功启动。

使用 Set-AksHciConfig 指定路径名包含空格字符（例如 D:\Cloud Share\AKS HCI）的 -imageDir、-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 “distribution” 属性

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 本地部署上两个 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 本地部署 AKS 时，部署在各个点超时

在 Azure 本地部署 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 本地节点可以解析下载 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. kubectl使用工作负荷群集 kubeconfig 运行以下命令，获取其中节点的列表：

    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 配置的每个节点池节点运行以下步骤：

    1. 通过 SSH 连接到 nodepool 节点 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 服务器，请运行以下命令，将时间同步配置文件中的 NTP 服务器设置为可从 nodepool 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. 重启时间同步服务：

      sudo systemctl restart systemd-timesyncd.service

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

      sudo timedatectl timesync-status

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

      date

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

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

后续步骤