对 TKGS 集群置备错误进行故障排除

检查集群 API 日志

如果无法创建 TKG 集群，请检查 CAPW/V 是否正常工作。

CAPW/V 控制器是特定于基础架构的集群 API 实施。通过主管启用 CAPW/V。CAPW/V 是 TKG 的一个组件，负责管理 TKG 集群的生命周期。

CAPW/V 负责创建和更新 VirtualNetwork。仅当 VirtualNetwork 准备就绪时，才能继续创建集群节点。集群创建工作流是否通过了此阶段？

CAPW/V 负责创建和更新 VirtualMachineService。是否已成功创建 VirtualMachineService？是否获取了外部 IP？集群创建工作流是否通过了此阶段？

要回答这些问题，请查看集群 API 日志，如下所示：

kubectl config use-context tkg-cluster-ns

kubectl get pods -n vmware-system-capw  | grep capv-controller

kubectl logs -n vmware-system-capw -c manager capv-controller-manager-...

集群规范验证错误

根据 YAML 规范，允许在密钥名称中使用空格字符。它是包含空格的标量字符串，且不需要引号。

但是，TKGS 验证不允许在密钥名称中使用空格字符。在 TKGS 中，有效密钥名称只能包含字母数字字符、短划线（如 key-name）、下划线（如 KEY_NAME）或点（如 key.name）。

如果在集群规范中的密钥名称中使用空格字符，则不会部署 TKGS 集群。vmware-system-tkg-controller-manager 日志将显示以下错误消息：

Invalid value: \"Key Name\": a valid config key must consist of alphanumeric characters, '-', '_' or '.' (e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')"

要修复该错误，请完全移除空格字符，或将其替换为支持的字符。

应用 TKG 集群 YAML 时出错

如果在应用 TKG 集群 YAML 时收到错误，请按以下方式进行故障排除。

集群网络未处于正确状态

了解 TKG 集群置备工作流：

CAPV 会为每个 TKG 集群网络创建一个 VirtualNetwork 对象。
如果为主管配置了 NSX 网络，则 NCP 会监视 VirtualNetwork 对象，并为每个 VirtualNetwork 创建 NSX Tier-1 路由器和 NSX 分段。
CAPV 会检查 VirtualNetwork 的状态，并在准备就绪后继续执行工作流中的下一步。

虚拟机服务控制器会监视 CAPV 创建的自定义对象，并使用这些规范创建和配置构成 TKG 集群的虚拟机。

NSX Container Plugin (NCP) 是一个控制器，用于监视通过 Kubernetes API 添加到 etcd 的网络资源，并编排 NSX 相应对象的创建。

每个控制器都在主管控制平面上作为 Kubernetes Pod 运行。要对网络问题进行故障排除，请查看 CAPV 控制器日志、虚拟机服务日志和 NCP 日志。

查看容器日志，其中 name-XXXX 是运行时的唯一 Pod 名称：

kubectl get pods -A
kubectl logs pod/name-XXXXX -c pod-name -n namesapce

控制平面节点计数无效

主管上的 TKG 集群支持 1 个或 3 个控制平面节点。如果输入不同的副本数，集群置备将失败。

控制平面/工作线程虚拟机的存储类无效

运行下列命令：

kubectl describe ns <tkg-clsuter-namesapce>

确保已将存储类分配给您尝试在其中创建 TKG 集群的命名空间。引用该存储类的 vSphere 命名空间中需要 ResourceQuota，并且主管中需要存在该存储类。

确保名称与主管中存在的存储类匹配。以 vSphere 管理员身份运行 kubectl get storageclasses 主管。将存储配置文件应用于主管时，WCP 可能会转换名称（例如，连字符变为下划线）。

虚拟机类无效

确保集群 YAML 中提供的值与 kubectl get virtualmachineclass 返回的虚拟机类之一匹配。TKG 集群只能使用绑定类。将虚拟机类添加到 vSphere 命名空间时，将绑定此类。

命令 kubectl get virtualmachineclasses 会返回主管上的所有虚拟机类，但只能使用绑定的虚拟机类。

找不到 TKR 分发版

如果看到类似以下内容的错误：

“Error from server (unable to find Kubernetes distributions): 
admission webhook “version.mutating.tanzukubernetescluster.run.tanzu.vmware.com” 
denied the request: unable to find Kubernetes distributions”

这可能是因为内容库有问题。要列出可用内容，请使用命令 kubectl get virtualmachineimages -A。得到的结果是内容库中可用和同步或上载的内容。

对于主管上的 TKG，存在与新 TKR API 兼容的新 TKR 名称。您需要确保在内容库中正确命名每个 TKR。

内容库中的名称：photon-3-amd64-vmi-k8s-v1.23.8---vmware.2-tkg.1-zshippable

TKG 集群规范中的相应名称：version: v1.23.8+vmware.2-tkg.1-zshippable

已应用 TKG YAML，但未创建任何虚拟机

如果 TKG 2.0 集群 YAML 有效且已应用，但未创建节点虚拟机，请按以下方式进行故障排除。

检查 CAPI/CAPV 资源

检查 TKG 是否创建了 CAPI/CAPV 级别资源。

检查 CAPV 是否已创建 VirtualMachine 资源。
查看虚拟机运算符日志以了解未创建虚拟机的原因，例如，由于 ESX 主机上的资源不足，导致 OVF 部署失败。
查看 CAPV 和 VM Operator 日志。
查看 NCP 日志。NCP 负责为控制平面实现 VirtualNetwork、VirtualNetworkInterface 和 LoadBalancer。如果出现与这些资源相关的任何错误，则表示存在问题。

虚拟机服务错误

虚拟机服务错误

在命名空间中运行 kubectl get virtualmachineservices
是否已创建虚拟机服务？
在命名空间中运行 kubectl describe virtualmachineservices
虚拟机服务上是否报告错误？

虚拟网络错误

在命名空间中运行 kubectl get virtualnetwork。

是否为此集群创建了虚拟网络？

在命名空间中运行 kubectl describe virtual network。

是否为虚拟机创建了虚拟网络接口？

TKG 集群控制平面未运行

如果 TKG 控制平面未运行，请检查发生错误时资源是否已准备就绪。它是未启动的加入节点控制平面还是 init 节点？此外，检查是否未在节点对象中设置提供程序 ID。

检查发生错误时资源是否已准备就绪

除了查找日志外，检查相关对象的状态 ControlPlaneLoadBalancer 也有助于了解发生错误时资源是否已准备就绪。请参见“网络故障排除”。

它是未启动的加入节点控制平面还是 init 节点？

节点有时无法正常加入。查看特定虚拟机的节点日志。如果 init 节点未成功启动，集群可能缺少工作节点和控制平面节点。

未在节点对象中设置提供程序 ID

如果已创建虚拟机，请检查它是否具有 IP，然后查看 cloud-init 日志（已正确执行 kubeadm 命令）

检查 CAPI 控制器日志以查看是否存在任何问题。您可以在 TKG 集群上使用 kubectl get nodes 进行检查，然后检查节点对象上是否存在提供程序 ID。

未创建 TKG 工作节点

如果创建了 TKG 集群和控制平面虚拟机，但未创建任何工作线程或未创建其他虚拟机对象，请尝试执行以下操作：

kubectl describe cluster CLUSTER-NAME

检查命名空间中的虚拟机资源，是否创建了任何其他虚拟机资源？

如果没有，请查看 CAPV 日志，了解为什么没有创建其他虚拟机对象（引导数据不可用）。

如果 CAPI 无法通过负载均衡器（具有节点虚拟机 IP 的 NSX 或具有外部负载均衡器的 VDS）与 TKG 集群控制平面进行通信，请使用命名空间中的密钥获取 TKG 集群 kubeconfig：

使用命名空间中的密钥获取 TKG 集群 kubeconfig：

kubectl get secret -n <namespace> <tkg-cluster-name>-kubeconfig -o jsonpath='{.data.value}' | base64 -d 
> tkg-cluster-kubeconfig; kubectl --kubeconfig tkg-cluster-kubeconfig get pods -A

如果此操作失败，并显示“连接被拒绝”，则表示您的控制平面未正确初始化。如果出现 I/O 超时，请验证与 kubeconfig 中的 IP 地址的连接。

具有嵌入式负载均衡器的 NSX：

确认控制平面 LB 已启动且可访问。
如果 LB 没有 IP，请检查 NCP 日志并检查 NSX-T UI 以查看相关组件是否处于正确状态。（NSX-T LB、VirtualServer、ServerPool 应处于正常状态）。
如果 LB 具有 IP，但不可访问（curl -k https://<LB- VIP>:6443/healthz 应返回未授权错误）。
如果 LoadBalancer 类型的服务外部 IP 处于“挂起”状态，请检查 TKG 集群是否可以通过主管 LB VIP 与主管 Kubernetes API 进行通信。确保没有 IP 地址重叠。

检查 TKG 控制平面节点是否处于正常状态：

检查 TKG 集群控制平面是否报告任何错误（例如，无法使用提供程序 ID 创建节点）。
TKG 集群云提供商未使用正确的提供程序 ID 标记节点，因此 CAPI 无法对客户机集群节点中的提供程序 ID 和主管集群的计算机资源进行比较，也就无法进行验证。

通过 SSH 连接控制平面虚拟机，或使用 TKG 集群 kubeconfig 检查 TKG 云提供商 Pod 是否正在运行/是否记录了任何错误。请参见以 Kubernetes 管理员和系统用户身份连接到 TKG 服务集群。

kubectl get po -n vmware-system-cloud-provider

kubectl logs -n vmware-system-cloud-provider <pod name>

如果 VMOP 未成功协调 VirtualMachineService，请查看虚拟机运算符日志。

如果 NCP 在创建 NSX-T 资源时出现问题，请检查 NCP 日志。

如果控制平面未正确初始化，请确定虚拟机 IP。状态应包含虚拟机 IP。

kubectl get virtualmachine -n <namespace> <TKC-name>-control-plane-0 -o yaml

ssh vmware-system-user@<vm-ip> -i tkc-cluster-ssh

检查 kubeadm 是否记录了任何错误。

cat /var/log/cloud-init-output.log | less

已置备的 TKG 集群停滞在“正在创建”阶段

运行以下命令，检查集群状态。

kubectl get tkc -n <namespace>

kubectl get cluster -n <namespace>

kubectl get machines -n <namespace>

KubeadmConfig 存在，但 CAPI 找不到它。检查 vmware-system-capv 中的令牌是否具有查询 kubeadmconfig 的适当权限。

$kubectl --token=__TOKEN__ auth can-i get kubeadmconfig 
yes

可能是控制器运行时缓存未更新。CAPI 监视缓存可能已失效，无法获取新对象。如有必要，请重新启动 capi-controller-manager 以解决该问题。

kubectl rollout restart deployment capi-controller-manager -n vmware-system-capv

vSphere 命名空间停滞在“正在终止”阶段

从版本兼容性角度验证 TKR、主管和 vCenter 是否同步。

仅当删除了命名空间下的所有资源时，才能删除命名空间。

kubectl describe namespace NAME

出现以下错误：“服务器出错 (找不到 Kubernetes 分发版): 准入 webhook ‘version.mutating.tanzukubernetescluster.run.tanzu.vmware.com’ 已拒绝请求: 找不到 Kubernetes 分发版”

检查 vCenter 上的虚拟机映像。

kubectl get virtualmachineimages -A