排查 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 的证书 tattoo YAML 文件。

此问题可能是由于配置文件存在于控制平面 VM 中，而不是工作器节点 VM 中。

若要解决此问题，请手动将证书 tattoo 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。

创建 Kubernetes 节点之前，Aks-Hci PowerShell 命令不会验证主机服务器上的可用内存。 此问题可能会导致内存耗尽和虚拟机无法启动。

当前未正常处理此失败，部署将停止响应，且不会显示清楚的错误消息。 如果部署已停止响应，请打开事件查看器，并检查是否有 Hyper-V 相关错误消息指出没有足够的内存来启动 VM。

运行 Get-AksHciCluster 以验证 Windows Admin Center 中 AKS Arc 安装的状态时，输出显示错误：“找不到版本为 1.0.3.10818 的版本。”但是，在运行 Get-AksHciVersion 时，它显示安装了相同的版本。 此错误表示生成已过期。

若要解决此问题，请运行 Uninstall-AksHci，然后运行新的 AKS Arc 生成。

在 Azure Stack HCI 群集中使用群集管理工具将 VM 从一个节点（节点 A）移动到另一个节点（节点 B）时，VM 可能无法在新节点上启动。 将 VM 移回原始节点之后，它也无法在其中启动。

发生此问题的原因是，用于清理首次迁移的逻辑是以异步方式运行。 因此，Azure Kubernetes 服务的“更新 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-AksHci、 Update-AksHciCertificates、 Update-AksHciClusterCertificates和与管理群集的所有交互）可能会返回“错误：必须登录到服务器 (未经授权的) 。

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 文件复制到 HCI 主机：

• 通过 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 Stack HCI 部署上的两个 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 Stack HCI 上的 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 Stack HCI 上的 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 插件和容器。

   若要获取容器 ID，请运行以下命令：

   $ 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>"
   

在 Windows Admin Center 扩展版本 1.82.0 中安装 Azure Stack HCI 上的 AKS 时，使用 PowerShell 安装了管理群集，并已尝试使用 Windows 管理中心部署工作负载群集。 其中一台计算机安装了 PowerShell 模块版本 1.0.2，其他计算机安装了 PowerShell 模块 1.1.3。 尝试部署工作负荷群集失败，出现错误“找不到与参数名称'nodePoolName'匹配的参数”。此错误可能是由于版本不匹配而发生的。 从 PowerShell 版本 1.1.0 开始，已将 -nodePoolName <String> 参数添加到 -nodePoolName <String>，根据设计，使用 Windows Admin Center 扩展版本 1.82.0 时，此参数是必需的。

若要解决此问题，请执行以下操作之一：

• 使用 PowerShell 将工作负载群集手动更新为版本 1.1.0 或更高版本。
• 使用 Windows Admin Center 将群集更新到版本 1.1.0 或最新的 PowerShell 版本。

如果管理群集是使用 Windows Admin Center 部署的，则不会出现此问题，因为它已安装了最新的 PowerShell 模块。

在 Azure Stack HCI 上部署 AKS，然后运行 kubectl get pods时，同一节点中的 Pod 会停滞在 “终止” 状态。 计算机拒绝 SSH 连接，因为节点可能遇到高内存需求。 之所以出现此问题，是因为 Windows 节点过度预配，并且没有为核心组件预留内存。

若要避免这种情况，请将 CPU 和内存的资源限制和资源请求添加到 Pod 规范中，以确保不会过度预配节点。 Windows 节点不支持基于资源限制的逐出，因此你应估计容器要使用的量，然后确保节点有足够的 CPU 和内存量。 可在系统要求中查找详细信息。

在 AKS 主机管理群集上使用以下 Azure 策略时，群集自动缩放可能会失败：“Kubernetes 群集不应使用默认命名空间。发生这种情况的原因是，在 AKS 主机管理群集上实现策略会阻止在默认命名空间中创建自动缩放程序配置文件。 若要解决此问题，请选择以下选项之一：

• 卸载 AKS 主机管理群集上的 Azure Policy 扩展。 在此处详细了解如何卸载Azure Policy扩展。
• 更改 Azure 策略的范围以排除 AKS 主机管理群集。 在此处详细了解Azure Policy范围。
• 将 AKS 主机管理群集的策略强制模式设置为“禁用”。 在此处详细了解强制模式。

这是 Azure Stack HCI 上的 AKS 7 月更新（版本 1.0.2.10723）的已知问题。 发生此错误的原因是，CloudAgent 服务在系统中跨多个群集共享卷分发虚拟机时超时。

若要解决此问题，应该升级到 Azure Stack HCI 上的 AKS 的最新版本。

如果在 Azure Stack HCI 上预配了零个 Linux 或 Windows 节点的 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 STACK HCI 节点上重启 wssdagent。 这仅适用于在执行横向扩展操作时通过创建节点池或在节点上重启 wssdagent 后创建新的 Kubernetes 群集时生成的新 VM。 但是，必须将现有 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 主机关闭了四天以上，导致证书过期。 证书通常以四天为周期进行轮换。 运行 AksHciClusterCerts 以修复证书过期问题。

在具有静态 IP 地址和 Windows 节点的工作负荷群集中，节点 (包括 daemonset pod) 的所有 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>

后续步骤

• 疑难解答概述
• 网络问题和错误
• 存储已知问题