適用於：Azure Stack HCI 上的 AKS、Windows Server 上的 AKS 使用本主題可協助您針對 AKS Arc 的網路相關問題進行疑難解答和解決。
錯誤：「無法啟動故障轉移叢集中的雲端代理程式一般叢集服務。 叢集資源群組處於「失敗」狀態。
在雲端代理程式中使用路徑名稱並包含空格時，可能無法順利啟動。
當使用 Set-AksHciConfig 指定 -imageDir、-workingDir、-cloudConfigLocation 或 -nodeConfigLocation 參數 (具包含空格字元的路徑名稱，例如 D:\Cloud Share\AKS HCI)，雲端代理程式叢集服務將無法啟動，並顯示下列 (或相似) 錯誤訊息：
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「散發」屬性
適用於 Kubernetes 連線的 Azure Arc 叢集可以將 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 屬性的輸出傳回空字串，請遵循下列指示來修補您的叢集：
將下列組態複製到名為 patchBody.json 的檔案：
{ "properties": { "distribution": "aks_management" } }重要
如果您的叢集是 AKS 管理叢集，此值應該設定為
aks_management。 如果是工作負載叢集，它應該設定為aks_workload。從您上述取得的 JSON 輸出中，複製已連線的叢集標識碼。 它應該會以下欄格式顯示為長字串：
"/subscriptions/<subscription >/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",執行下列命令來修補您的叢集。 此值
<cc_arm_id>應該是步驟 2 中取得的識別碼：az rest -m patch -u "<cc_arm_id>?api-version=2022-10-01-preview" -b "@patchBody.json"執行 以確認您的叢集已成功修補
az connectedk8s show -g <rg_name> -n <cc_name>，以確定 JSON 屬性distribution已正確設定。
WSSDAgent 服務在啟動時停滯，且無法連線到雲端代理程式
徵兆：
- 在 AKS Arc 中啟用 Proxy。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
Proxy 設定可能已變更為主機上的錯誤 Proxy。 AKS Arc 的 Proxy 設定是繼承自主機上父進程的環境變數。 這些設定只會在新的服務啟動或舊服務更新或重新啟動時傳播。 在更新或重新啟動之後，可能會在主機上設定錯誤的 Proxy 設定，而且它們會在更新或重新啟動後傳播到 WSSDAgent，這會導致 WSSDAgent 失敗。
您必須藉由變更電腦上的環境變數來修正 Proxy 設定。 在機器上，使用下列命令變更變數：
[Environment]::SetEnvironmentVariable("https_proxy", <Value>, "Machine")
[Environment]::SetEnvironmentVariable("http_proxy", <Value>, "Machine")
[Environment]::SetEnvironmentVariable("no_proxy", <Value>, "Machine")
將機器重新啟動，讓服務管理員和 WSSDAgent 挑選固定的 Proxy。
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 叢集停滯在「調整方案」布建狀態
此問題會導致 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 位址，請使用下列步驟：
- 若要取得群組，請執行下列命令：
Get-MocGroup -location MocLocation
- 若要取得目前使用中的 IP 位址清單，以及可用或已使用的虛擬 IP 位址清單，請執行下列命令：
Get-MocNetworkInterface -Group <groupName> | ConvertTo-Json -depth 10
- 使用下列命令來檢視目前正在使用的虛擬 IP 位址清單：
Get-MocLoadBalancer -Group <groupName> | ConvertTo-Json -depth 10
“Cluster IP Address x.x.x.x” 失敗
叢集IP位址會在預先檢查期間顯示為「失敗」。 此預先檢查會測試所有 IPv4 位址和 DNS 網路名稱是否在在線且可連線。 例如，失敗的 IPv4 或網路名稱可能會導致此測試失敗。
若要解決此問題，請執行下列步驟：
執行以下命令：
Get-ClusterGroup -name "Cluster Group" | Get-ClusterResource確定所有網路名稱和IP位址都處於在線狀態。
執行下列兩個命令：
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，但節點無法連線至目標伺服器。
若要解決此問題，您必須判斷在連線流程中發生連線中斷的位置。 下列是嘗試從實體叢集節點解決問題的一些步驟：
- Ping 目的地 DNS 名稱：ping
msk8s.api.cdp.microsoft.com。 - 如果您收到回應而未逾時，則基本網路路徑會正常運作。
- 如果連線逾時，則資料路徑可能會出現中斷情形。 如需詳細資訊，請參閱檢查 Proxy 設定。 或者，傳回路徑中可能會出現中斷情形，您應檢查防火牆規則。
NTP 時間相依觸發程式數百個 False 警示的應用程式
NTP 時間相依的應用程式可以在逾時同步時觸發數百個誤判警示。如果叢集是在 Proxy 環境中執行，您的 nodepools 可能無法透過 Proxy 或防火牆與預設 NTP 伺服器 通訊，time.windows.com。
因應措施
若要解決此問題，請更新每個 nodepool 節點上的 NTP 伺服器組態，以同步處理時鐘。 這麼做也會設定每個應用程式Pod中的時鐘。
必要條件
- 每個 nodepool 節點中可存取之 NTP 伺服器的位址。
- 存取工作負載叢集 kubeconfig 檔案。
- 存取管理叢集 kubeconfig。
步驟
使用工作負載叢集 kubeconfig 執行下列
kubectl命令，以取得其中節點的清單：kubectl --kubeconfig <PATH TO KUBECONFIG> get nodes -owide執行下列
kubectl命令，將上一個命令中的節點名稱與工作負載叢集的節點集區節點相互關聯。 記下上一個命令輸出中的相關IP位址。kubectl --kubeconfig (Get-KvaConfig).kubeconfig get machine -l cluster.x-k8s.io/cluster-name=<WORKLOAD_CLUSTER_NAME>使用先前步驟的輸出，針對需要更新 NTP 組態的每個 nodepool 節點執行下列步驟：
透過 SSH 連線到 nodepool 節點 VM：
ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<NODEPOOL_IP>確認已設定的 NTP 伺服器無法連線：
sudo timedatectl timesync-status如果輸出看起來像這樣，則 NTP 伺服器無法連線，而且必須變更：
Server: n/a (time.windows.com) Poll interval: 0 (min: 32s; max 34min 8s) Packet count: 0若要更新 NTP 伺服器，請執行下列命令，將 timesync 配置檔中的 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重新啟動 timesync 服務：
sudo systemctl restart systemd-timesyncd.service確認 NTP 伺服器可供存取：
sudo timedatectl timesync-status確認時鐘顯示正確的時間：
date
執行步驟 3.f 中的 命令，確定每個 nodepool 節點都會顯示相同的時間。
如果您的應用程式不會自動更新其時間，請重新啟動其 Pod。