解决升级 AKS Arc 时出现的问题

不会删除旧版 PowerShell。

若要解决此问题，可以 运行此脚本来卸载较旧的 PowerShell 版本。

升级或纵向扩展目标群集后，证书续订 Pod 现在处于崩溃循环状态。 它需要来自路径 /etc/Kubernetes/pki 的 cert tattoo 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，请将其设置回 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 代理服务映像路径具有部署 ID 参数

运行以下命令以显示云代理的映像路径：

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 Billing Operator 部署准备就绪”。 如果运行 Sync-AksHciBilling，它将返回成功的输出。 但是，如果运行 Get-AksHciBillingStatus，则连接状态为 OutofPolicy。

如果你未在 60 天内部署工作负载群集，则计费就不符合策略。

解决此问题的唯一方法是使用干净安装重新部署。

如果 Azure Stack HCI 节点一个接一个地重新启动，则某些虚拟机会丢失附加到这些节点的 vNIC。 vNIC 的这种丢失会导致 VM 失去网络连接，并且群集进入错误状态。

重现步骤

1. 重新启动一个 Azure Stack HCI 节点。
2. 等待节点完成重新启动。 需要在故障转移群集中标记 Up 该节点。
3. 重新启动其他节点。
4. 自我

预期行为 群集状态应为正常。 所有 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 连接命令失败，请尝试断开连接并重新连接。 下面是用于 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 时，通常会出现此错误消息。 目前，Windows Admin Center 不支持在代理环境中安装模块。

要解决此错误，请使用代理 PowerShell 命令设置 Azure Stack HCI 上的 AKS。

使用开放策略代理 (OPA) （如 OPA GateKeeper）升级 Kubernetes 群集时，该过程可能会挂起，无法完成。 出现此问题的原因是该策略代理已配置为阻止从私有注册表中拉取容器映像。

若要解决此问题，如果你升级使用 OPA 部署的群集，请确保你的策略允许从 Azure 容器注册表中拉取映像。 对于 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

需要修复的节点应显示 STATUSReady,SchedulingDisabled。 如果看到具有此状态的节点，请在 INTERNAL-IP 以下命令中将此节点的 用作 IP 地址值。 使用要升级到的 Kubernetes 版本作为版本值;这应该与 节点中的值匹配VERSIONROLEScontrol-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 版本的剩余节点，并继续升级。

在具有 AKS on Azure Stack HCI 部署的主机上运行 OS 更新可能会导致部署进入错误状态，从而导致无法访问管理群集的 API 服务器，并导致第二天操作失败。 Pod kube-vip 无法将 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 容器 ID：

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

输出应如下所示，容器 ID 为第一个值 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 的所有命令、计费和更新超时。解决方法是在 Hyper-V 中将管理群集 VM 设置为 32 GB，然后重新启动它。

• 原因 3：AksHci Billing Operator 可能会超出存储空间，这是由 Microsoft SQL 配置设置中的 bug 引起的。 存储空间不足可能导致升级停止响应。 要解决此问题，请使用以下步骤手动调整计费 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 上的 AKS 2022 年 2 月更新升级到 2022 年 4 月更新时，更新可能会无限期地停滞升级。 可能存在处于 或 CrashLoopBackoff 状态的 Terminating Pod。

你可能会发现缺少一些 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。