解決升級 AKS Arc 時的問題

不會移除舊版的 PowerShell。

若要解決此問題，您可以 執行此腳本來卸載舊版 PowerShell。

升級或相應增加目標叢集之後，憑證更新 Pod 現在處於當機循環狀態。 它預期路徑/etc/Kubernetes/pki會有憑證紋身yaml檔案。 組態檔存在於控制平面節點 VM 中，但不存在於背景工作節點 VM 上。

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

1. 將檔案從控制平面 VM 複製到主電腦目前目錄。

   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 works)
   scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\
   

2. 將檔案從主計算機複製到背景工作節點 VM。

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

3. 如果此檔案尚未設定為 root，請將此檔案的擁有者和群組資訊設定回根目錄。

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

4. 針對每個背景工作節點重複步驟 2 和 3。

當叢集未升級超過 60 天時，節點代理程式因令牌過期而無法在節點代理程式重新啟動期間啟動。 此失敗會導致代理程式處於開始階段。 持續嘗試加入 cloudagent 可能會耗盡主機上的埠供應。 下列命令的狀態為 [正在啟動]。

Get-Service wssdagent | Select-Object -Property Name, Status

預期的行為：節點代理程式應該處於開始階段，而此階段會持續嘗試加入雲端代理程式，耗盡埠。

若要解決此問題，請停止 wssdagent 執行。 由於服務處於啟動階段，因此可能會阻止您停止服務。 如果是，請在嘗試停止服務之前先終止進程。

1. 確認 wssdagent 處於啟動階段。

   Get-Service wssdagent | Select-Object -Property Name, Status
   

2. 終止進程。

   kill -Name wssdagent -Force
   

3. 停止服務。

   Stop-Service wssdagent -Force
   

Get-Process -Name wssdagent

PS C:\WINDOWs\system32 Get-process -Name wssdagent 
Get-process : Cannot find a process with the name "wssdaqent". Verify the process name and call the cmdlet again.
At line: 1 char: 1 
+ Get-process -Name wssdagent
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + Categorylnfo          : ObjectNotFound: (wssdagent:String) [Get-Process], ProcessCommandException 
    + FullyQua1ifiedErrorId : NoProcess FoundForGivenName , Microsoft.PowerShell.Commands.Getprocesscommand

1. 在發生此問題的 HCI 叢集每個節點重複步驟 1、2 和 3。

2. 確認 wssdagent 未執行之後，如果 cloudagent 未執行，請啟動 cloudagent。

Start-ClusterGroup -Name (Get-MocConfig).clusterRoleName

1. 確認 cloudagent 已啟動並執行。

   Get-ClusterGroup -Name (Get-MocConfig).clusterRoleName
   

2. 執行下列命令來修正 wssdagent：

   Repair-Moc
   

3. 此命令完成後，wssdagent 應該處於執行中狀態。

   Get-Service wssdagent | Select-Object -Property Name, Status
   

當 AKS-HCI 無法從 5 月版本升級至 6 月版本時，預期 AKS-HCI 應該還原為 5 月版本並繼續運作。 但它會讓MOC代理程式處於停止狀態，而手動嘗試啟動代理程式並不會啟用它們。

重現的步驟

1. 安裝 AKS-HCI PowerShell 模組 1.1.36 版。
2. 升級 AKS-HCI。 如果升級失敗，AKS-HCI 會回復為 5 月，但 MOC 代理程式已關閉。

預期的行為

如果 Aks-Hci 升級失敗，預期 AksHci 會還原為先前的版本，並繼續運作，而不會有任何問題。

徵兆

Aks-Hci 版本與MOC版本不符

• Get-AksHciVersion: 1.0.10.10513
• Get-MocVersion: 1.0.11.10707

Get-MocVersion 與 wssdcloudagent.exe 版本不符

Get-MocVersion 表示已安裝 6 月組建，而wssdcloudagent.exe版本表示已安裝 5 月組建。

MOC 代理程式服務映射路徑具有部署標識元參數

執行下列命令以顯示雲端代理程式的映像路徑：

reg query "HKLM\System\CurrentControlSet\Services\wssdcloudagent"

範例輸出

"C:\Program Files\AksHci\wssdcloudagent.exe" --service --basedir "base dir" --cloudagentfqdn "cloudagent fqdn" --dotfolderpath "dot folder path" --objectdatastore "data store" --clusterresourcename "cluster name" --certificatevalidityfactor 1 --deploymentid "deployment id"

使用下列命令來顯示節點代理程式的映射路徑： reg 查詢 “HKLM\System\CurrentControlSet\Services\wssdagent”

範例輸出

"C:\Program Files\AksHci\wssdagent.exe" --service --basedir "base dir" --cloudloginfile "cloud login file path" --dotfolderpath "dotfolder path" --nodeagentfqdn "node fqdn" --objectdatastore "object data store" --wssdproviderspec "provider spec" --deploymentid "deployment id"

若要減輕問題，請執行下列 PowerShell Cmdlet：

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\wssdcloudagent" -Name ImagePath -Value 'above cloud agent image path without the deployment id'
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\wssdagent" -Name ImagePath -Value 'above node agent image path without the deployment id'

升級時，您可能會失去新增至背景工作節點的所有自定義污點、角色和標籤。 由於 AKS 是受控服務，因此不支援在提供的 PowerShell Cmdlet 或 Windows Admin Center 外部執行時新增自定義污點、標籤和角色。

若要解決此問題，請執行 New-AksHciNodePool Cmdlet，為您的背景工作節點正確 建立具有污點 的節點集區。

如果您建立了管理叢集，但前 60 天尚未部署工作負載叢集，您將無法建立工作負載叢集，因為其現在已不在原則中。 在此情況下，當您執行Update-AksHci時，更新程式會遭到封鎖，並出現等候部署 『AksHci 計費操作員』 準備好的錯誤。 如果您執行 Sync-AksHciBilling，則會傳回成功的輸出。 不過，如果您執行 Get-AksHciBillingStatus，連線狀態為 OutofPolicy。

如果您尚未在 60 天內部署工作負載叢集，則計費會超出原則。

修正此問題的唯一方法是使用全新安裝重新部署。

如果一個接一個地重新啟動 Azure Stack HCI 節點，部分虛擬機會失去連結的 vNIC。 此 vNIC 遺失會導致 VM 失去網路連線，且叢集處於不良狀態。

若要重現

1. 重新啟動一個 Azure Stack HCI 節點。
2. 等候節點完成重新啟動。 節點必須在故障轉移叢集中標示 Up 。
3. 重新啟動其他節點。
4. Repeat.

預期行為 叢集狀態應該狀況良好。 所有 VM 都應該連結 NIC。

若要解決此問題，請使用MOC命令將 vNIC 新增至 VM。

1. 取得 VM 的 vNIC 名稱。

(Get-MocVirtualMachine -group <group> -name <vmname>).virtualmachineproperties.networkprofile.networkinterfaces

或

mocctl.exe compute vm get --name <vmname> --group <group>

2. 將 vNIC 連線至 VM。

Connect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

或

mocctl.exe compute vm nic add --name <vnicname> --vm-name <vmname> --group <group>

3. 如果 vNIC connect 命令失敗，請嘗試中斷連線並再次連線。 以下是 vNIC 中斷連線的命令。

Disconnect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

或

mocctl.exe compute vm nic remove --name <vnicname> --vm-name <vmname> --group <group>

Pod 停滯在 等候靜態 Pod 有就緒條件。

若要釋放 Pod 並解決此問題，您應該重新啟動 kubelet。 若要使用靜態 Pod 檢視 NotReady 節點，請執行下列命令：

kubectl get nodes -o wide

若要取得錯誤節點的詳細資訊，請執行下列命令：

kubectl describe node <IP of the node>

執行下列命令，使用 SSH 登入 NotReady 節點：

ssh -i <path of the private key file> administrator@<IP of the node>

然後，若要重新啟動 kubelet，請執行下列命令：

/etc/.../kubelet restart

在 Windows Admin Center 中執行升級時，發生下列錯誤：

Error occurred while fetching platform upgrade information. RemoteException: No match was found for the specified search criteria and module name 'AksHci'. Try Get-PSRepository to see all available registered module repositories.

當 Azure Stack HCI 上的 AKS 部署在已設定 Proxy 的環境中時，通常會發生此錯誤訊息。 目前，Windows Admin Center 不支援在 Proxy 環境中安裝模組。

若要解決此錯誤，請使用 Proxy PowerShell 命令在 Azure Stack HCI 上設定 AKS。

使用開放式原則代理程式 （OPA） 升級 Kubernetes 叢集時，例如 OPA GateKeeper，程式可能會停止回應且無法完成。 此問題可能會發生，因為原則代理程式已設定為防止從私人登錄提取容器映射。

若要解決此問題，如果您升級使用 OPA 部署的叢集，請確定您的原則允許從 Azure Container Registry 提取映像。 針對 Azure Stack HCI 升級上的 AKS，您應該在原則清單中新增下列端點： ecpacr.azurecr.io。

在具有 Azure Stack HCI 部署 AKS 的主機上執行 OS 更新，可能會導致部署進入錯誤狀態，並讓第二天作業失敗。 MOC NodeAgent 服務可能無法在更新的主機上啟動。 所有對節點的MOC呼叫都會失敗。

若要重現：當您將現有 AKS 部署從 HCI 更新為 HCIv2 的叢集時，AKS New-AksHciCluster 作業可能會失敗。 錯誤訊息指出MOC節點為 OutOfCapacity。 例如：

System.Collections.Hashtable.generic_non_zero1 [Error: failed to create nic test-load-balancer-whceb-nic for machinetest-load-balancer-whceb: unable to create VM network interface: failed to create network interface test-load-balancer-whceb-nic in resource group clustergroup-test: rpc error: code = Unknown desc = Location 'MocLocation' doesn't expose any nodes to create VNIC 'test-load-balancer-whceb-nic' on: OutOfCapacity]

若要解決此問題，請在受影響的節點上啟動 wssdagent Moc NodeAgent 服務。 這會解決此問題，並將部署帶回良好的狀態。 執行以下命令：

Get-ClusterNode -ErrorAction Stop | ForEach-Object { Invoke-Command -ComputerName $_ -ScriptBlock { Start-Service wssdagent -WarningAction:SilentlyContinue } }

執行 Update-AksHciCluster 之後，升級程式會停滯不前。

執行下列命令，以檢查是否有執行您正在升級之先前 Kubernetes 版本的機器 PHASE 。

kubectl get machines -o wide --kubeconfig (Get-KvaConfig).kubeconfig

如果有計算機具有 PHASE 刪除和 VERSION 比對先前的 Kubernetes 版本，請繼續進行下列步驟。

若要解決此問題，您需要下列資訊：

1. 您要升級工作負載叢集的 Kubernetes 版本。
2. 停滯之節點的IP位址。

若要尋找這項資訊，請執行下列 Cmdlet 和 命令。 根據預設，Cmdlet Get-AksHciCredential 會將 kubeconfig 寫入 。~/.kube/config 如果您在呼叫 Get-AksHciCredential時為工作負載叢集 kubeconfig 指定不同的位置，則必須提供該位置給 kubectl 做為另一個自變數。 例如： kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig> 。

Get-AksHciCredential -name <workload cluster name>
kubectl get nodes -o wide

需要修正節點應該會顯示 STATUS Ready,SchedulingDisabled。 如果您看到具有此狀態的節點，請使用 INTERNAL-IP 此節點的 ，作為下列命令中的IP位址值。 使用您要升級至 的 Kubernetes 版本作為版本值;這應該符合 VERSION 節點的值與 ROLES control-plane,master。 請務必包含 Kubernetes 版本的完整值，包括 v，例如 v1.22.6。

ssh -i (Get-MocConfig).sshPrivateKey -o StrictHostKeyChecking=no  clouduser@<IP address> sudo crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

執行此 ssh 命令之後，應該刪除具有舊 Kubernetes 版本的其餘節點，並繼續進行升級。

在具有 Azure Stack HCI 部署 AKS 的主機上執行 OS 更新可能會導致部署進入錯誤狀態，這會使管理叢集的 API 伺服器無法連線，且第二天作業失敗。 kube-vip Pod 無法將VIP設定套用至介面，因此無法連線到VIP。

若要重現：將現有 AKS HCI 部署從 HCI 更新為 HCIv2 的叢集。 然後嘗試執行嘗試連線到管理叢集的命令，例如 Get-AksHciCluster。 嘗試連線到管理叢集的任何作業都失敗，並出現下列錯誤：

PS C:\Users\wolfpack> Get-AksHciCluster
C:\Program Files\AksHci\kvactl.exe cluster list --kubeconfig="C:\ClusterStorage\Volume1\Msk8s\WorkingDir\1.0.8.10223\kubeconfig-mgmt" System.Collections.Hashtable.generic_non_zero 1 [Error: failed to connect to the cluster: action failed after 9
attempts: Get "https://10.193.237.5:6443/api?timeout=10s": net/http: request canceled while waiting for connection
(Client.Timeout exceeded while awaiting headers)]
At C:\Program Files\WindowsPowerShell\Modules\Kva\1.0.22\Common.psm1:2164 char:9
+         throw $errMessage
+         ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (C:\Program File...iting headers)]:String) [], RuntimeException
    + FullyQualifiedErrorId : C:\Program Files\AksHci\kvactl.exe cluster list --kubeconfig="C:\ClusterStorage\Volume1\Msk8s\WorkingDir\1.0.8.10223\kubeconfig-mgmt" System.Collections.Hashtable.generic_non_zero 1 [Error: failed to connect to the cluster: action failed after 9 attempts: Get "https://10.193.237.5:6443/api?timeout=10s": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)]

若要解決此問題：請重新啟動 kube-vip 容器，讓部署回到良好狀態。

1. kube-vip取得容器識別碼：

ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl ls | grep 'kube-vip'"

輸出看起來應該像這樣，容器識別碼是第一個值 4a49a5158a5f8。 例如：

4a49a5158a5f8       7751a28bb5ce1       28 minutes ago      Running             kube-vip                         1                   cf9681f921a55

1. 重新啟動重新啟動容器：

ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl stop <Container ID>"

執行 Update-AksHci PowerShell Cmdlet 時，會出現此狀態消息。

請檢閱下列根本原因以解決問題：

• 原因一：在 AksHci 計費操作員更新期間，操作員錯誤地將自己標示為原則外。 若要解決此問題，請開啟新的 PowerShell 視窗並執行 Sync-AksHciBilling。 您應該會在接下來 20-30 分鐘內看到計費作業繼續。

• 原因二：管理叢集 VM 可能記憶體不足，導致無法連線到 API 伺服器，並讓 Get-AksHciCluster、計費和更新的所有命令逾時。因應措施是，將管理叢集 VM 設定為 Hyper-V 中的 32 GB，然後重新啟動它。

• 原因三： AksHci 計費操作員 可能不足儲存空間，這是因為MICROSOFT SQL 組態設定中有錯誤。 缺少儲存空間可能會導致升級停止回應。 若要解決此問題，請使用下列步驟手動調整計費 Pod pvc 的大小。

  1. 執行下列命令以編輯 Pod 設定：

     kubectl edit pvc mssql-data-claim --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
     

  2. 當 [記事本] 或其他編輯器以 YAML 檔案開啟時，請編輯從 100Mi 到 5Gi 的記憶體行：

     spec:
       resources:
         requests:
           **storage: 5Gi**
     

  3. 使用下列命令檢查計費部署的狀態：

     kubectl get deployments/billing-manager-deployment --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
     

當您將叢集從 Azure Stack HCI 2022 年 2 月更新的 AKS 升級至 2022 年 4 月更新時，更新可能會停滯在無限時間內升級。 可能會有 Pod 卡在 Terminating 或 CrashLoopBackoff 狀態中。

您可能會看到部分 AksHci CSI 附加元件資源遺失。 這些資源 Pod 會使用 csi-akshcicsi-controller 或 從 csi-akshcicsi-node 精靈集部署。

2022 年 2 月更新中的 AksHci CSI 附加元件包含 CSI 驅動程式規格的變更，有時可能會讓附加元件的資源在升級期間處於沒有回應的狀態。 CSI 驅動程式的 .spec.fsGroupPolicy 設定為新的值，即使它是不可變的欄位也一樣。 由於欄位不可變，因此驅動程式規格不會更新。 因此，其他 AksHci CSI 附加元件資源可能無法完全協調。 所有 CSI 資源都會重新建立。

若要手動解決問題，可以手動刪除 CSI 驅動程式。 拿掉之後，雲端操作員會在10分鐘內協調AksHci CSI附加元件，並重新建立驅動程式以及其餘遺漏的附加元件資源。

kubectl --kubeconfig $(Get-AksHciConfig).Kva.kubeconfig delete csidriver disk.csi.akshci.com`

成功升級之後，Windows Admin Center 更新儀錶板仍會顯示舊版。

重新整理瀏覽器以修正此問題。

Azure Stack HCI 上 AKS 的 6 月 1.0.1.10628 組建會在叢集中建立過多的 Kubernetes 設定秘密。 從 6 月 1.0.1.10628 版升級到 7 月 1.0.2.10723 版的升級路徑已改善，以清除額外的 Kubernetes 秘密。 不過，在某些情況下，升級期間仍不會清除秘密，因此升級程式會失敗。

如果您遇到此問題，請執行下列步驟：

1. 將下列腳本儲存為名為 fix_leaked_secrets.ps1 的檔案：

   upgparam (
   [Parameter(Mandatory=$true)]
   [string] $ClusterName,
   [Parameter(Mandatory=$true)]
   [string] $ManagementKubeConfigPath
   )
   
   $ControlPlaneHostName = kubectl get nodes --kubeconfig $ManagementKubeConfigPath -o=jsonpath='{.items[0].metadata.name}'
   "Hostname is: $ControlPlaneHostName"
   
   $leakedSecretPath1 = "$ClusterName-template-secret-akshci-cc"
   $leakedSecretPath2 = "$ClusterName-moc-kms-plugin"
   $leakedSecretPath3 = "$ClusterName-kube-vip"
   $leakedSecretPath4 = "$ClusterName-template-secret-akshc"
   $leakedSecretPath5 = "$ClusterName-linux-template-secret-akshci-cc"
   $leakedSecretPath6 = "$ClusterName-windows-template-secret-akshci-cc"
   
   $leakedSecretNameList = New-Object -TypeName 'System.Collections.ArrayList';
   $leakedSecretNameList.Add($leakedSecretPath1) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath2) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath3) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath4) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath5) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath6) | Out-Null
   
   foreach ($leakedSecretName in $leakedSecretNameList)
   {
   "Deleting secrets with the prefix $leakedSecretName"
   $output = kubectl --kubeconfig $ManagementKubeConfigPath exec etcd-$ControlPlaneHostName -n kube-system -- sh -c "ETCDCTL_API=3 etcdctl --cacert /etc/kubernetes/pki/etcd/ca.crt --key /etc/kubernetes/pki/etcd/server.key --cert /etc/kubernetes/pki/etcd/server.crt del /registry/secrets/default/$leakedSecretName --prefix=true"
   "Deleted: $output"
   }
   

2. 接下來，使用 您儲存的 fix_secret_leak.ps1 檔案執行下列命令：

      .\fix_secret_leak.ps1 -ClusterName (Get-AksHciConfig).Kva.KvaName -ManagementKubeConfigPath (Get-AksHciConfig).Kva.Kubeconfig
   

3. 最後，使用下列 PowerShell 命令重複升級程式：

      Update-AksHci
   

下一步

• 疑難排解概觀
• 安裝問題和錯誤
• Windows Admin Center 已知問題

如果您在使用 AKS Arc 時繼續遇到問題，您可以透過 GitHub 提出 Bug。