排查 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 生成。

使用群集管理工具将 VM 从一个节点（节点 A）移到 Azure 本地群集中的另一个节点（节点 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-AksHciCertificatesUpdate-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 文件复制到 Azure 本地主机：

• 通过 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 本地部署上两个 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 本地部署上启动 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 本地版 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 本地安装的 AKS 上，管理群集是使用 PowerShell 设置的，并且尝试使用 Windows Admin Center 部署工作负荷群集。 其中一台计算机安装了 PowerShell 模块版本 1.0.2，其他计算机安装了 PowerShell 模块 1.1.3。 尝试部署工作负荷群集失败，并出现错误“找不到与参数名称'nodePoolName'匹配的参数”。此错误可能由于版本不匹配而发生。 从 PowerShell 版本 1.1.0 开始，已将 -nodePoolName <String> 参数添加到 New-AksHciCluster，根据设计，使用 Windows Admin Center 扩展版本 1.82.0 时，此参数是必需的。

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

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

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

在 Azure 本地部署 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 本地 7 月更新上的 AKS（版本 1.0.2.10723）的已知问题。 发生此错误的原因是，CloudAgent 服务在系统中跨多个群集共享卷分发虚拟机时超时。

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

如果使用零 Linux 或 Windows 节点在 Azure 本地预配 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 本地节点上重启 wssdagent 。 这仅适用于执行横向扩展操作时通过创建节点池生成的新 VM，或者在重启 wssdagent 节点上后创建新的 Kubernetes 群集时生成。 但是，必须将现有 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>

后续步骤

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