修正在 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。

適用於 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 屬性的輸出傳回空字串，請遵循下列指示來修補您的叢集：

1. 將下列組態複製到名為 patchBody.json 的檔案：

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

   重要

   如果您的叢集是 AKS 管理叢集，該值應該設定為 aks_management。 如果是工作負載叢集，它應該設定為 aks_workload。

2. 從您上述取得的 JSON 輸出中，複製連線的叢集標識碼。 它應該會以下欄格式顯示為長字串：

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

3. 執行下列命令來修補您的叢集。 此值 <cc_arm_id> 應該是步驟 2 中取得的識別碼：

   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 已正確設定。

徵兆：

• 在 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 時，都會嘗試登入 cloudagent，並將憑證儲存在暫存記憶體磁碟區中，這會在 Pod 重新啟動時清除。 因此，每次重新啟動 Pod 時，都會終結憑證，並嘗試進行新的登入嘗試。

登入嘗試會啟動更新例程，這會在憑證即將到期時更新憑證。 CAPH Pod 會決定憑證是否可用，是否需要登入。 如果憑證可用，則不會嘗試登入，假設更新例程已經存在。

不過，在容器重新啟動時，不會清除暫存目錄，因此檔案仍會保存，而且不會進行登入嘗試，導致更新例程無法啟動。 這會導致憑證到期。

若要減輕此問題，請使用下列命令重新啟動 CAPH Pod：

kubectl delete pod pod-name

執行 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 狀態中。

若要重現

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位址的目前配置。

若要瞭解虛擬網路中目前使用的IP位址，請使用下列步驟：

1. 若要取得群組，請執行下列命令：

Get-MocGroup -location MocLocation

2. 若要取得目前使用的IP位址清單，以及可用或已使用的虛擬IP位址清單，請執行下列命令：

Get-MocNetworkInterface -Group <groupName> | ConvertTo-Json -depth 10

3. 使用下列命令來檢視目前使用中的虛擬 IP 位址清單：

Get-MocLoadBalancer -Group <groupName> | ConvertTo-Json -depth 10

預先檢查期間，叢集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 時，部署可能會因設定錯誤發生的位置而在不同的程式時間點逾時。 您應該檢閱錯誤訊息，以判斷原因及其發生位置。

例如，在下列錯誤中，發生錯誤設定的點在 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. 如果連線逾時，則數據路徑可能會中斷。 如需詳細資訊，請參閱 檢查 Proxy 設定。 或者，傳回路徑可能會中斷，因此您應該檢查防火牆規則。

NTP 時間相依的應用程式可以在逾時同步時觸發數百個 False 警示。如果叢集是在 Proxy 環境中執行，您的節點集區可能無法透過 Proxy 或防火牆與預設 NTP 伺服器通訊， time.windows.com。

因應措施

若要解決此問題，請更新每個 nodepool 節點上的 NTP 伺服器設定，以同步處理時鐘。 這麼做也會設定每個應用程式Pod中的時鐘。

必要條件

• 每個 nodepool 節點中可存取之 NTP 伺服器的位址。
• 存取工作負載叢集 kubeconfig 檔案。
• 存取管理叢集 kubeconfig。

步驟

1. 使用工作負載叢集 kubeconfig 執行下列kubectl命令，以取得其中節點的清單：

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

2. 執行下列 kubectl 命令，將先前命令中的節點名稱與工作負載叢集的 nodepool 節點相互關聯。 記下上一個命令輸出中相關的IP位址。

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

3. 使用先前步驟的輸出，針對需要更新其 NTP 組態的每個 nodepool 節點執行下列步驟：

   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 伺服器，請執行下列命令，將 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 
      

   4. 重新啟動 timesync 服務：

      sudo systemctl restart systemd-timesyncd.service
      

   5. 確認 NTP 伺服器可供存取：

      sudo timedatectl timesync-status
      

   6. 確認時鐘顯示正確的時間：

      date
      

4. 執行步驟 3.f 中的命令，確定每個 nodepool 節點都會顯示相同的時間。

5. 如果您的應用程式未自動更新其時間，請重新啟動其 Pod。

下一步

• 疑難排解概觀
• 安裝問題和錯誤
• 記憶體已知問題