針對 AKS Arc 中的 Kubernetes 管理和工作負載叢集問題進行疑難解答

執行 Remove-ClusterNode 命令時，節點會從故障轉移叢集收回，但如果 之後未執行 Remove-AksHciNode ，該節點仍會存在於 CloudAgent 中。

由於節點已從叢集移除，但不是從 CloudAgent 中移除，如果您使用 VHD 來建立新的節點，則會出現「找不到檔案」錯誤。 發生此問題的原因是 VHD 位於共用記憶體中，且移除的節點無法存取它。

若要解決此問題，請從叢集移除實體節點，然後遵循下列步驟：

1. 執行 Remove-AksHciNode 以從 CloudAgent 取消註冊節點。
2. 執行例行維護，例如重新製作機器映像。
3. 將節點新增回叢集。
4. 執行 Add-AksHciNode 以向 CloudAgent 註冊節點。

使用大型叢集時， Get-AksHciLogs 命令可能會擲回例外狀況、無法列舉節點，或不會產生 c：\wssd\wssdlogs.zip輸出檔。

這是因為 PowerShell 命令會壓縮檔案 'Compress-Archive'，其輸出檔案大小限制為 2 GB。

升級或相應增加工作負載叢集之後，憑證更新 Pod 現在會處於當機循環狀態，因為 Pod 預期來自檔案位置 /etc/Kubernetes/pki的憑證紋身 YAML 檔案。

此問題可能是因為控制平面 VM 中存在的組態檔，而非背景工作節點 VM 中。

若要解決此問題，請手動將憑證紋身 YAML 檔案從控制平面節點複製到所有背景工作節點。

1. 將工作負載叢集上控制平面 VM 的 YAML 檔案複製到主電腦的目前目錄：

ssh clouduser@<comtrol-plane-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp /etc/kubernetes/pki/cert-tattoo-kubelet.yaml ~/
sudo chown clouduser cert-tattoo-kubelet.yaml
sudo chgrp clouduser cert-tattoo-kubelet.yaml
(Change file permissions here, so that `scp` will work)
scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\

1. 將 YAML 檔案從主計算機複製到背景工作節點 VM。 複製檔案之前，您必須將 YAML 檔案中的電腦名稱變更為您要複製的節點名稱（這是工作負載叢集控制平面的節點名稱）。

scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml

3. 如果 YAML 檔案中的擁有者和群組資訊尚未設定為根目錄，請將資訊設定為根目錄：

ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the certificate file to the correct location)
sudo chown root cert-tattoo-kubelet.yaml
sudo chgrp root cert-tattoo-kubelet.yaml

4. 對所有背景工作節點重複步驟 2 和 3。

Aks-Hci PowerShell 命令在建立 Kubernetes 節點之前，不會驗證主機伺服器上的可用記憶體。 此問題可能會導致記憶體耗盡和未啟動的虛擬機。

此失敗目前未正常處理，且部署將會停止回應，而不會顯示明確的錯誤訊息。 如果您有停止回應的部署，請開啟 事件檢視器，並檢查 Hyper-V 相關的錯誤訊息，指出沒有足夠的記憶體啟動 VM。

執行 Get-AksHciCluster 以確認 Windows Admin Center 中 AKS Arc 安裝的狀態時，輸出會顯示錯誤：「找不到版本 1.0.3.10818 的版本」。不過，執行 Get-AksHciVersion 時，它會顯示已安裝相同的版本。 此錯誤表示組建已過期。

若要解決此問題，請執行 Uninstall-AksHci，然後執行新的 AKS Arc 組建。

使用叢集管理工具將 VM 從一個節點（節點 A）移至 Azure 本機叢集中的另一個節點（節點 B），VM 可能無法在新節點上啟動。 將 VM 移回原始節點之後，它也不會從該處啟動。

發生此問題的原因是清除第一個移轉的邏輯會以異步方式執行。 因此，Azure Kubernetes Service 的「更新 VM 位置」邏輯會在節點 A 上的原始 Hyper-V 上尋找 VM，並加以刪除，而不是將其取消註冊。

若要解決此問題，請先確定 VM 已在新的節點上成功啟動，再將其移回原始節點。

使用 PowerShell 建立具有靜態 IP 位址的叢集，然後嘗試增加工作負載叢集中的背景工作節點數目時，安裝會卡在「控制平面計數為 2，仍在等候所需的狀態：3。」經過一段時間後，會出現另一則錯誤訊息：「錯誤：等候條件逾時」。

當 Get-AksHciCluster 執行時，它會顯示控制平面節點已建立和布建，且處於就緒狀態。 不過，當執行時 kubectl get nodes ，它會顯示已建立控制平面節點，但尚未布建且未處於 就緒 狀態。

如果您收到此錯誤，請使用 Hyper-V 管理員或 PowerShell 確認 IP 位址已指派給已建立的節點：

(Get-VM |Get-VMNetworkAdapter).IPAddresses |fl

然後，確認網路設定，以確保集區中還剩足夠的IP位址來建立更多VM。

、Update-AksHciCertificates、 Update-AksHciClusterCertificates和與管理叢集的所有互動等Update-AksHci命令可以傳回「錯誤：您必須登入伺服器（未經授權）。」

kubeconfig 檔案過期時，可能會發生此錯誤。 若要檢查它是否已過期，請執行下列腳本：

$kubeconfig= $(get-kvaconfig).kubeconfig
$certDataRegex = '(?ms).*client-certificate-data:\s*(?<CertData>[^\n\r]+)'
$certDataMatch = Select-String -Path $kubeconfig -Pattern $certDataRegex
$certData = $certDataMatch.Matches[0].Groups['CertData'].Value
$certObject = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$certObject.Import([System.Convert]::FromBase64String($certData))
$expiryDate = $certObject.GetExpirationDateString()
$expiryDate

如果此腳本顯示早於目前日期的日期，則 kubeconfig 檔案已過期。

若要減輕此問題，請將管理控制平面 VM 內的 admin.conf 檔案複製到 Azure 本機主機：

• 透過 SSH 連線到管理控制平面 VM：

  • 取得管理控制平面 VM IP：

    get-clusternode | % {Get-vm -computerName $_ } | get-vmnetworkadapter | select Name, IPAddresses
    

  • 透過 SSH 連線到它：

    ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<mgmt-control-plane-ip>
    

• 將檔案複製到 clouduser 位置：

  cp /etc/kubernetes/admin.conf /home/clouduser/admin.conf
  

• 授與 clouduser 的存取權：

  sudo chown clouduser:clouduser admin.conf
  

• [選擇性]建立 kubeconfig 檔案的備份：

  mv $(Get-KvaConfig).kubeconfig "$((Get-KvaConfig).kubeconfig).backup"
  

• 複製檔案：

  scp -i (get-mocconfig).sshPrivateKey clouduser@10.64.92.14:~/admin.conf $(Get-KvaConfig).kubeconfig
  

當您檢查 Hyper-V 管理員時，可以安全地忽略管理叢集的高 CPU 和記憶體需求。 它們與布建工作負載叢集時的計算資源使用量尖峰有關。

增加管理叢集的記憶體或CPU大小並沒有明顯改善，而且可以放心忽略。

如果您遵循下列步驟，您將會看到此問題：

1. 建立 Kubernetes 叢集。
2. 將叢集調整為兩個以上的節點。
3. 執行下列命令來移除節點：

kubectl delete node <node-name>

4. 執行下列命令，以傳回節點的清單：

kubectl get nodes

已移除的節點不會列在輸出中。 5.以系統管理許可權開啟 PowerShell 視窗，然後執行下列命令：

get-vm

拿掉的節點仍會列出。

此失敗會導致系統無法辨識節點遺失，因此不會啟動新的節點。

如果您未使用管理或工作負載叢集超過 60 天，憑證就會過期，而且您必須更新它們，才能升級 AKS Arc。當 AKS 叢集未在 60 天內升級時，KMS 外掛程式令牌和憑證都會在 60 天內到期。 叢集仍可正常運作。 不過，由於超過 60 天，您必須呼叫 Microsoft 支援才能升級。 如果叢集在此期間之後重新啟動，它將會保持非功能狀態。

若要解決此問題，請執行下列步驟：

1. 手動輪替令牌來修復管理叢集憑證 ，然後重新啟動 KMS 外掛程式和容器。
2. 執行Repair-MocLogin來mocctl修復憑證。
3. 手動輪替令牌來修復工作負載叢集憑證 ，然後重新啟動 KMS 外掛程式和容器。

如果 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.

大型叢集的部署可能會在兩小時後逾時。 不過，這是靜態逾時。

當作業在背景中執行時，您可以忽略這個逾時專案。 kubectl get nodes使用 命令來存取您的叢集並監視進度。

在幾天后嘗試在 Azure 本機部署上啟動 AKS 時， Kubectl 未執行其任何命令。 金鑰管理服務 （KMS） 外掛程式記錄顯示錯誤訊息 rpc error:code = Unauthenticated desc = Valid Token Required_. After running [Repair-AksHciCerts](./reference/ps/repair-akshcicerts.md) to try to fix the issue, a different error appeared: _failed to repair cluster certificates。

如果 API 伺服器關閉，Repair-AksHciClusterCerts Cmdlet 就會失敗。 如果 Azure 本機上的 AKS 尚未升級 60 天以上，當您嘗試重新啟動 KMS 外掛程式時，將不會啟動。 此失敗也會導致 API 伺服器失敗。

若要修正此問題，您必須手動輪替令牌，然後重新啟動 KMS 外掛程式和容器，以取得 API 伺服器備份。 若要達成此目標，請執行下列步驟：

1. 執行下列命令來輪替權杖：

   $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
   

2. 使用下列命令將令牌複製到 VM。 ip下列命令中的設定是指 AKS 主機控制平面的 IP 位址。

   $ scp -i (Get-AksHciConfig).Moc.sshPrivateKey .\cloudlogin.yaml clouduser@<ip>:~/cloudlogin.yaml $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> sudo mv cloudlogin.yaml /opt/wssd/k8s/cloudlogin.yaml
   

3. 重新啟動 KMS 外掛程式和容器。

   若要取得容器識別碼，請執行下列命令：

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container ls | grep 'kms'"
   

   輸出應該會出現下列欄位：

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   輸出應看似此範例：

   4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
   

4. 最後，執行下列命令重新啟動容器：

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container kill <Container ID>"
   

在 Azure 本機安裝的 AKS 上，使用 Windows Admin Center 擴充功能 1.82.0 版，管理叢集是使用 PowerShell 設定的，而且嘗試使用 Windows Admin Center 部署工作負載叢集。 其中一部計算機已安裝 PowerShell 模組 1.0.2 版，而其他計算機則已安裝 PowerShell 模組 1.1.3。 嘗試部署工作負載叢集失敗，並出現「找不到符合參數名稱 』nodePoolName' 的參數」錯誤。此錯誤可能是因為版本不符而發生。 從 PowerShell 1.1.0 版開始， -nodePoolName <String> 參數已新增至 New-AksHciCluster Cmdlet，而且根據設計，使用 Windows Admin Center 擴充功能 1.82.0 版時，此參數現在為必要參數。

要解決此問題，請按照以下作業執行：

• 使用 PowerShell 將工作負載叢集手動更新為 1.1.0 版或更新版本。
• 使用 Windows Admin Center 將叢集更新為 1.1.0 版或最新的 PowerShell 版本。

如果使用 Windows Admin Center 部署管理叢集，因為它已安裝最新的 PowerShell 模組，則不會發生此問題。

當您在 Azure 本機上部署 AKS，然後執行 kubectl get pods時，位於相同節點的 Pod 會卡在 終止 狀態中。 計算機會拒絕 SSH 連線，因為節點可能遇到高記憶體需求。 發生此問題的原因是 Windows 節點已過度布建，且核心元件沒有保留。

若要避免這種情況，請將CPU和記憶體的資源限制和資源要求新增至Pod規格，以確保節點不會過度布建。 Windows 節點不支援根據資源限制收回，因此您應該估計容器將使用多少，然後確定節點有足夠的 CPU 和記憶體數量。 您可以在系統需求中找到詳細資訊。

當您在 AKS 主機管理叢集上使用下列 Azure 原則時，叢集自動調整可能會失敗：“Kubernetes 叢集不應該使用預設命名空間。這是因為在 AKS 主機管理叢集上實作的原則會封鎖在預設命名空間中建立自動調整程式設定檔。 若要修正此問題，請選擇下列其中一個選項：

• 卸載 AKS 主機管理叢集上的 Azure 原則 擴充功能。 在這裡深入瞭解如何卸載 Azure 原則 擴充功能。
• 變更 Azure 原則的範圍，以排除 AKS 主機管理叢集。 在這裡深入瞭解 Azure 原則 範圍。
• 將 AKS 主機管理叢集的原則強制執行模式設定為「已停用」。 在這裡深入了解強制模式。

這是 Azure 本機 7 月更新的 AKS 已知問題（1.0.2.10723 版）。 發生此錯誤的原因是 CloudAgent 服務在系統中多個叢集共用磁碟區之間散發虛擬機時逾時。

若要解決此問題，您應該 升級至 Azure 本機版本上最新的 AKS。

如果您在具有零 Linux 或 Windows 節點的 Azure 本機上布建 AKS 叢集，當您執行 Get-AksHciCluster 時，輸出會是空字串或 Null 值。

Null 是零個節點的預期傳回。

當您關閉管理或工作負載叢集超過四天時，憑證會過期，且叢集無法連線。 憑證會因為安全性原因每隔 3-4 天輪替一次而過期。

若要重新啟動叢集，您必須先手動修復憑證，才能執行任何叢集作業。 若要修復憑證，請執行下列 Repair-AksHciClusterCerts 命令：

Repair-AksHciClusterCerts -Name <cluster-name> -fixKubeletCredentials

相應放大工作負載叢集時，對應的Linux和Windows VM會新增為背景工作節點，但未設定為高可用性 VM。 執行 Get-ClusterGroup 命令時，新建立的 Linux VM 未設定為叢集群組。

這是已知的問題。 重新啟動之後，將 VM 設定為高可用性的功能有時會遺失。 目前的因應措施是在每個 Azure 本機節點上重新啟動 wssdagent 。 這隻適用於執行向外延展作業時建立節點集區所產生的新 VM，或在重新啟動 wssdagent 節點上的 之後建立新的 Kubernetes 叢集時產生。 不過，您必須手動將現有的 VM 新增至故障轉移叢集。

當您相應減少叢集時，高可用性叢集資源在 VM 移除時處於失敗狀態。 此問題的因應措施是手動移除失敗的資源。

部署在 Azure VM 中的 AKS 叢集先前正常運作，但在 AKS 主機關閉數天之後， Kubectl 命令無法運作。 執行 Kubectl get nodes 或 Kubectl get services 命令之後，會出現此錯誤訊息： Error from server (InternalError): an error on the server ("") has prevented the request from succeeding。

發生此問題的原因是 AKS 主機已關閉超過四天，導致憑證過期。 憑證通常會在四天的迴圈中輪替。 執行 Repair-AksHciClusterCerts 以修正憑證到期問題。

在具有靜態 IP 位址和 Windows 節點的工作負載叢集中，節點中的所有 Pod（包括 daemonset Pod）都會卡在 ContainerCreating 狀態中。 嘗試使用 SSH 連線到該節點時，連線失敗併發生 Connection timed out 錯誤。

若要解決此問題，請使用 Hyper-V 管理員或故障轉移叢集管理員來關閉該節點的 VM。 5 到 10 分鐘之後，節點應該已重新建立，且所有 Pod 都會執行。

當 kubelet 承受磁碟壓力時，它會收集未使用的容器映射，其中可能包含暫停映像，而發生這種情況時，ContainerD 無法提取映像。

若要解決此問題，請執行下列步驟：

1. 使用 SSH 連線到受影響的節點，然後執行下列命令：

sudo su

2. 若要擷取映像，請執行下列命令：

crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

下一步

• 疑難排解概觀
• 網路問題與錯誤
• 記憶體已知問題