解决升级 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. 在出现此问题的 Azure 本地群集的每个节点上重复步骤 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
   

当 Azure 本地版 AKS 无法从 5 月版本升级到 6 月版本时，预期 Azure 本地版的 AKS 应还原到 5 月版本并继续运行。 但它使 MOC 代理处于停止状态，并且手动尝试启动代理不会激活它们。

重现步骤

1. 安装 AKS-HCI PowerShell 模块版本 1.1.36。
2. 升级 Azure 本地上的 AKS。 如果升级失败，Azure 本地 AKS 会回退到 5 月，但 MOC 代理已关闭。

预期行为

如果 Azure 本地升级上的 AKS 失败，预期 Azure 本地上的 AKS 会还原到以前的版本，并继续正常运行，且没有任何问题。

现象

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 本地节点，则某些虚拟机会丢失附加到其中的 vNIC。 这种 vNIC 丢失会导致 VM 失去网络连接，群集处于错误状态。

重现步骤

1. 重新启动一个 Azure 本地节点。
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 本地上的 AKS 部署在配置了代理的环境中时，通常会发生此错误消息。 目前，Windows Admin Center 不支持在代理环境中安装模块。

若要解决此错误，请使用代理 PowerShell 命令在 Azure 本地设置 AKS。

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

若要解决此问题，如果你升级使用 OPA 部署的群集，请确保你的策略允许从 Azure 容器注册表中拉取映像。 对于 Azure 本地升级上的 AKS，应在策略列表中添加以下终结点： ecpacr.azurecr.io。

在 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 } }

运行 Update-AksHciCluster 后，升级进程将停止。

运行以下命令，检查是否存在 PHASE 运行要从中升级的以前 Kubernetes 版本的具有“删除”的计算机。

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 版本作为版本值;这应与节点中的值匹配 VERSION ROLES control-plane,master。 请确保包含 Kubernetes 版本的完整值，例如vv1.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 本地部署上使用 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 容器，使部署恢复为良好状态。

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、计费和更新的所有命令超时。解决方法是，将管理群集 VM 设置为 Hyper-V 中的 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 本地 2022 年 2 月更新的 AKS 升级到 2022 年 4 月更新时，更新可能会无限期地停滞升级。 可能存在停滞在或CrashLoopBackoff状态中的 Terminating Pod。

你可能会发现缺少一些 AksHci CSI 加载项资源。 使用 csi-akshcicsi-controller 守护程序集或从守护程序集中部署的 csi-akshcicsi-node 这些资源 Pod。

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 本地版 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。