本文說明將 Azure Kubernetes Service (AKS) Arc 部署升級至最新版本時可能會遇到的已知問題和錯誤。 您也可以檢閱 Windows Admin Center 的已知問題,以及在 Azure 本機上安裝 AKS 時。
成功升級之後,不會移除舊版的 PowerShell
不會移除舊版的 PowerShell。
若要解決此問題,您可以 執行此腳本來卸載舊版 PowerShell。
憑證更新 Pod 處於當機循環狀態
升級或相應增加目標叢集之後,憑證更新 Pod 現在處於當機循環狀態。 它預期路徑/etc/Kubernetes/pki
會有憑證紋身yaml
檔案。 組態檔存在於控制平面節點 VM 中,但不存在於背景工作節點 VM 上。
注意
此問題會在 2022 年 4 月版本之後修正。
若要解決此問題,請手動將憑證紋身檔案從控制平面節點複製到每個背景工作節點。
將檔案從控制平面 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 .\
將檔案從主計算機複製到背景工作節點 VM。
scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml
如果此檔案尚未設定為 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
針對每個背景工作節點重複步驟 2 和 3。
當叢集未升級超過 60 天時,節點通訊埠因令牌過期而無法加入 cloudagent 時外泄埠
當叢集未升級超過 60 天時,節點代理程式因令牌過期而無法在節點代理程式重新啟動期間啟動。 此失敗會導致代理程式處於開始階段。 持續嘗試加入 cloudagent 可能會耗盡主機上的埠供應。 下列命令的狀態為 [正在啟動]。
Get-Service wssdagent | Select-Object -Property Name, Status
預期的行為:節點代理程式應該處於開始階段,而此階段會持續嘗試加入雲端代理程式,耗盡埠。
若要解決此問題,請停止 wssdagent 執行。 由於服務處於啟動階段,因此可能會阻止您停止服務。 如果是,請在嘗試停止服務之前先終止進程。
確認 wssdagent 處於啟動階段。
Get-Service wssdagent | Select-Object -Property Name, Status
終止進程。
kill -Name wssdagent -Force
停止服務。
Stop-Service wssdagent -Force
注意
即使在停止服務之後,wssdagent 進程似乎會在幾秒鐘內啟動數次,再停止。 繼續進行下一個步驟之前,請確定下列命令會傳回所有節點上的錯誤。
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
在發生此問題的 Azure 本機叢集的每個節點上重複步驟 1、2 和 3。
確認 wssdagent 未執行之後,如果 cloudagent 未執行,請啟動 cloudagent。
Start-ClusterGroup -Name (Get-MocConfig).clusterRoleName
確認 cloudagent 已啟動並執行。
Get-ClusterGroup -Name (Get-MocConfig).clusterRoleName
執行下列命令來修正 wssdagent:
Repair-Moc
此命令完成後,wssdagent 應該處於執行中狀態。
Get-Service wssdagent | Select-Object -Property Name, Status
升級失敗之後,MOC 代理程式不會啟動
當 Azure 本機上的 AKS 無法從 5 月版本升級至 6 月版本時,預期 Azure 本機上的 AKS 應該還原為 5 月版本並繼續運作。 但它會讓MOC代理程式處於停止狀態,而手動嘗試啟動代理程式並不會啟用它們。
注意
此問題只有在從 5 月版本升級至 6 月版本時才相關。
重現的步驟
- 安裝 AKS-HCI PowerShell 模組 1.1.36 版。
- 升級 Azure 本機上的 AKS。 如果升級失敗,Azure 本機上的 AKS 會回復為 5 月,但 MOC 代理程式已關閉。
預期的行為
如果 Azure 本機升級上的 AKS 失敗,預期 Azure 本機上的 AKS 會還原為上一個版本,並繼續運作,而沒有任何問題。
徵兆
Aks-Hci 版本與MOC版本不符
Get-AksHciVersion
: 1.0.10.10513Get-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天內尚未建立,AKS Arc就會超出原則
如果您建立了管理叢集,但前 60 天尚未部署工作負載叢集,您將無法建立工作負載叢集,因為其現在已不在原則中。 在此情況下,當您執行Update-AksHci時,更新程式會遭到封鎖,並出現等候部署 『AksHci 計費操作員』 準備好的錯誤。 如果您執行 Sync-AksHciBilling,則會傳回成功的輸出。 不過,如果您執行 Get-AksHciBillingStatus,連線狀態為 OutofPolicy。
如果您尚未在 60 天內部署工作負載叢集,則計費會超出原則。
修正此問題的唯一方法是使用全新安裝重新部署。
計算機重新啟動後遺失 vNIC
注意
此問題已在 2022 年 5 月版本和更新版本中修正。
如果一個接一個地重新啟動 Azure 本機節點,部分虛擬機會遺失連結至它們的 vNIC。 此 vNIC 遺失會導致 VM 失去網路連線,且叢集處於不良狀態。
若要重現
- 重新啟動一個 Azure 本機節點。
- 等候節點完成重新啟動。 節點必須在故障轉移叢集中標示
Up
。 - 重新啟動其他節點。
- Repeat.
預期行為 叢集狀態應該狀況良好。 所有 VM 都應該連結 NIC。
若要解決此問題,請使用MOC命令將 vNIC 新增至 VM。
- 取得 VM 的 vNIC 名稱。
(Get-MocVirtualMachine -group <group> -name <vmname>).virtualmachineproperties.networkprofile.networkinterfaces
或
mocctl.exe compute vm get --name <vmname> --group <group>
- 將 vNIC 連線至 VM。
Connect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>
或
mocctl.exe compute vm nic add --name <vnicname> --vm-name <vmname> --group <group>
- 如果 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 停滯在 等候靜態 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 本機上的 AKS 部署在已設定 Proxy 的環境中時,通常會發生此錯誤訊息。 目前,Windows Admin Center 不支援在 Proxy 環境中安裝模組。
若要解決此錯誤,請使用 Proxy PowerShell 命令在 Azure 本機上設定 AKS。
使用開放式原則代理程序升級 Kubernetes 叢集時,升級程式會停止回應
使用開放式原則代理程式 (OPA) 升級 Kubernetes 叢集時,例如 OPA GateKeeper,程式可能會停止回應且無法完成。 此問題可能會發生,因為原則代理程式已設定為防止從私人登錄提取容器映射。
若要解決此問題,如果您升級使用 OPA 部署的叢集,請確定您的原則允許從 Azure Container Registry 提取映像。 針對 Azure 本機升級上的 AKS,您應該在原則清單中新增下列端點: ecpacr.azurecr.io。
將主機 OS HCI 更新為 HCIv2 會中斷 Azure 本機安裝的 AKS:OutOfCapacity
在具有 Azure 本機部署 AKS 的主機上執行 OS 更新,可能會導致部署進入錯誤狀態,並讓第二天作業失敗。 MOC NodeAgent 服務可能無法在更新的主機上啟動。 所有對節點的MOC呼叫都會失敗。
注意
此問題只會偶爾發生。
若要重現:當您將現有 AKS 部署從 HCI 更新為 HCIv2 OS 的叢集時,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 } }
目標叢集升級停滯於舊版 Kubernetes 中的一或多個節點
執行 Update-AksHciCluster 之後,升級程式會停滯不前。
執行下列命令,以檢查是否有執行您正在升級之先前 Kubernetes 版本的機器 PHASE
。
kubectl get machines -o wide --kubeconfig (Get-KvaConfig).kubeconfig
如果有計算機具有 PHASE
刪除和 VERSION
比對先前的 Kubernetes 版本,請繼續進行下列步驟。
若要解決此問題,您需要下列資訊:
- 您要升級工作負載叢集的 Kubernetes 版本。
- 停滯之節點的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 版本的其餘節點,並繼續進行升級。
將主機 OS HCI 更新為 HCIv2 會中斷 Azure 本機安裝的 AKS:無法連線到管理叢集
在具有 Azure 本機部署 AKS 的主機上執行 OS 更新可能會導致部署進入錯誤狀態,這會使管理叢集的 API 伺服器無法連線,且第二天作業失敗。 kube-vip
Pod 無法將VIP設定套用至介面,因此無法連線到VIP。
若要重現:將現有 AKS HCI OS 部署從 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
容器,讓部署回到良好狀態。
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
- 重新啟動重新啟動容器:
ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl stop <Container ID>"
執行 Update-AksHci 時,更新程式停滯於「等待部署 』AksHci 計費操作員」準備好」
執行 Update-AksHci PowerShell Cmdlet 時,會出現此狀態消息。
請檢閱下列根本原因以解決問題:
原因一:在 AksHci 計費操作員更新期間,操作員錯誤地將自己標示為原則外。 若要解決此問題,請開啟新的 PowerShell 視窗並執行 Sync-AksHciBilling。 您應該會在接下來 20-30 分鐘內看到計費作業繼續。
原因二:管理叢集 VM 可能記憶體不足,導致無法連線到 API 伺服器,並讓 Get-AksHciCluster、計費和更新的所有命令逾時。因應措施是,將管理叢集 VM 設定為 Hyper-V 中的 32 GB,然後重新啟動它。
原因三: AksHci 計費操作員 可能不足儲存空間,這是因為MICROSOFT SQL 組態設定中有錯誤。 缺少儲存空間可能會導致升級停止回應。 若要解決此問題,請使用下列步驟手動調整計費 Pod
pvc
的大小。執行下列命令以編輯 Pod 設定:
kubectl edit pvc mssql-data-claim --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
當 [記事本] 或其他編輯器以 YAML 檔案開啟時,請編輯從 100Mi 到 5Gi 的記憶體行:
spec: resources: requests: **storage: 5Gi**
使用下列命令檢查計費部署的狀態:
kubectl get deployments/billing-manager-deployment --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
將 Azure 本機上的 AKS 從 2022 年 2 月更新升級至 2022 年 4 月更新時,CSI 部署會消失並導致升級停止
當您將叢集從 Azure Localy 2022 Update 上的 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 更新儀錶板不會重新整理
成功升級之後,Windows Admin Center 更新儀錶板仍會顯示舊版。
重新整理瀏覽器以修正此問題。
使用 PowerShell 升級時,叢集上會建立過多的 Kubernetes 設定秘密
Azure Local 上 AKS 的 6 月 1.0.1.10628 組建會在叢集中建立過多的 Kubernetes 設定秘密。 從 6 月 1.0.1.10628 版升級到 7 月 1.0.2.10723 版的升級路徑已改善,以清除額外的 Kubernetes 秘密。 不過,在某些情況下,升級期間仍不會清除秘密,因此升級程式會失敗。
如果您遇到此問題,請執行下列步驟:
將下列腳本儲存為名為 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" }
接下來,使用 您儲存的 fix_secret_leak.ps1 檔案執行下列命令:
.\fix_secret_leak.ps1 -ClusterName (Get-AksHciConfig).Kva.KvaName -ManagementKubeConfigPath (Get-AksHciConfig).Kva.Kubeconfig
最後,使用下列 PowerShell 命令重複升級程式:
Update-AksHci