适用于:Azure 本地 AKS 上的 AKS,Windows Server 上的 AKS 使用本文可帮助你排查和解决 AKS Arc 中 Kubernetes 管理和工作负荷群集的问题。
运行 Remove-ClusterNode 命令时,会从故障转移群集中逐出该节点,但如果之后不运行 Remove-AksHciNode,则该节点将仍然存在于 CloudAgent 中。
由于节点已从群集中删除,但未从 CloudAgent 中删除,如果使用 VHD 创建新节点,则会出现“找不到文件”错误。 出现此问题的原因是 VHD 位于共享存储中,并且已删除的节点无权访问它。
若要解决此问题,请从群集中删除物理节点,然后执行以下步骤:
- 运行
Remove-AksHciNode
,从 CloudAgent 中取消注册节点。 - 执行日常维护(例如,重新映像计算机)。
- 将节点添加回群集。
- 运行
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 文件从控制平面节点复制到所有工作器节点。
- 将工作负载群集上的控制平面 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 .\
- 将 YAML 文件从主机复制到辅工作器节点 VM。 在复制该文件之前,必须将 YAML 文件中的计算机名更改为要复制到的节点名(这是工作负载群集控制平面的节点名)。
scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml
- 如果 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
- 对所有工作器节点重复步骤 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-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 文件复制到 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 对此并没有明显改善,可以安全忽略。
如果按照以下步骤操作,你将看到此问题:
- 创建 Kubernetes 群集。
- 将群集缩放到两个以上的节点。
- 通过运行以下命令删除节点:
kubectl delete node <node-name>
- 运行以下命令返回节点的列表:
kubectl get nodes
输出中未列出已删除的节点。 5.使用管理权限打开 PowerShell 窗口,并运行以下命令:
get-vm
已删除的节点仍在列出。
此失败会导致系统无法识别到节点已丢失,并因此不会启动新节点。
如果不使用管理或工作负荷群集超过 60 天,证书将过期,并且必须续订它们,然后才能升级 AKS Arc。AKS 群集在 60 天内未升级时,KMS 插件令牌和证书在 60 天内都过期。 群集仍然正常运行。 但是,由于超过 60 天,因此需要调用Microsoft支持才能升级。 如果群集在此时间段后重新启动,它将保持非功能状态。
若要解决此问题,请执行以下步骤:
- 通过 手动轮换令牌来修复管理群集证书,然后重启 KMS 插件和容器。
- 通过运行
Repair-MocLogin
修复mocctl
证书。 - 通过 手动轮换令牌来修复工作负荷群集证书,然后重启 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 服务器。 为此,请执行以下步骤:
通过运行以下命令来轮换令牌:
$ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
使用下列命令将令牌复制到 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
重启 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
最后,通过运行以下命令重启容器:
$ 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 将无法拉取映像。
若要解决此问题,请执行以下步骤:
- 使用 SSH 连接到受影响的节点,并运行以下命令:
sudo su
- 若要拉取该映像,请运行以下命令:
crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>