13.3. OpenShift Virtualization 上托管集群故障排除

当您对 OpenShift Virtualization 上的托管集群进行故障排除时，从顶层 HostedCluster 和 NodePool 资源开始，然后关闭堆栈，直到找到根本原因。以下步骤可帮助您发现常见问题的根本原因。

13.3.1. HostedCluster 资源处于部分状态

如果因为 HostedCluster 资源处于待处理而没有完全在线托管的 control plane，请通过检查先决条件、资源条件和节点和 Operator 状态来识别问题。

流程

确保您满足 OpenShift Virtualization 上托管集群的所有先决条件。
查看 HostedCluster 和 NodePool 资源的条件，以了解防止进度的验证错误。
通过使用托管集群的 kubeconfig 文件，检查托管集群的状态：
- 查看 oc get clusteroperators 命令的输出，以查看哪些集群 Operator 处于待处理状态。
- 查看 oc get nodes 命令的输出，以确保 worker 节点已就绪。

13.3.2. 没有注册 worker 节点

如果托管 control plane 没有注册 worker 节点而无法完全在线，请通过检查托管 control plane 的不同部分的状态来识别问题。

流程

查看带有故障的 HostedCluster 和 NodePool 条件，以指示问题可能是什么。
输入以下命令查看 NodePool 资源的 KubeVirt worker 节点虚拟机 (VM) 状态：
```
$ oc get vm -n <namespace>
```
如果虚拟机处于 provisioning 状态，请输入以下命令查看 VM 命名空间中的 CDI 导入 pod，以说明导入程序 pod 没有被完成的原因：
```
$ oc get pods -n <namespace> | grep "import"
```
如果虚拟机处于 start 状态，请输入以下命令查看 virt-launcher pod 的状态：
```
$ oc get pods -n <namespace> -l kubevirt.io=virt-launcher
```
如果 virt-launcher pod 处于待处理状态，请调查不调度 pod 的原因。例如，可能没有足够的资源来运行 virt-launcher pod。
如果虚拟机正在运行，但没有注册为 worker 节点，请使用 Web 控制台获取受影响虚拟机的 VNC 访问权限。VNC 输出指示是否应用了 ignition 配置。如果虚拟机在启动时无法访问托管的 control plane ignition 服务器，则无法正确置备虚拟机。
如果应用了 ignition 配置，但虚拟机仍然没有注册为节点，请参阅 识别问题：访问虚拟机控制台日志 以了解如何在启动过程中访问虚拟机控制台日志。

其他资源

鉴别问题：访问虚拟机控制台日志

13.3.3. worker 节点处于 NotReady 状态

在集群创建过程中，节点在推出网络堆栈时临时进入 NotReady 状态。该流程的这一部分是正常的。但是，如果这一部分的进程用时超过 15 分钟，则可能会出现问题。

流程

通过调查节点对象和 pod 来识别问题：

输入以下命令查看节点对象中的条件，并确定节点未就绪的原因：
```
$ oc get nodes -o yaml
```

输入以下命令查找集群中的 pod 失败：

$ oc get pods -A --field-selector=status.phase!=Running,status,phase!=Succeeded

13.3.4. Ingress 和控制台集群 operator 没有在线

如果托管的 control plane 没有完全在线，因为 Ingress 和控制台集群 Operator 没有在线，请检查通配符 DNS 路由和负载均衡器。

流程

如果集群使用默认的 Ingress 行为，请输入以下命令来确保在托管虚拟机的 OpenShift Container Platform 集群上启用了通配符 DNS 路由：

$ oc patch ingresscontroller -n openshift-ingress-operator \
  default --type=json -p \
  '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'

如果您将自定义基域用于托管的 control plane，请完成以下步骤：
- 确保负载均衡器正确以虚拟机 pod 为目标。
- 确保通配符 DNS 条目以负载均衡器 IP 地址为目标。

13.3.5. 托管集群的负载均衡器服务不可用

如果托管的 control plane 没有完全在线，因为负载均衡器服务不可用，请检查事件、详情和 Kubernetes 集群配置管理器(KCCM) pod。

流程

查找与托管集群中的负载均衡器服务关联的事件和详情。
默认情况下，托管集群的负载均衡器由托管的 control plane 命名空间中的 kubevirt-cloud-controller-manager 处理。确保 KCCM pod 在线，并查看其日志以查找错误或警告。要识别托管的 control plane 命名空间中的 KCCM pod，请输入以下命令：
```
$ oc get pods -n <hosted_control_plane_namespace> -l app=cloud-controller-manager
```

13.3.6. 托管的集群 PVC 不可用

如果托管的 control plane 没有被完全在线，因为托管集群的持久性卷声明 (PVC) 不可用，请检查 PVC 事件和详情，以及组件日志。

流程

查找与 PVC 关联的事件和详情，以了解发生的错误。
如果 PVC 无法附加到 pod，请查看托管集群中 kubevirt-csi-node daemonset 组件的日志，以进一步调查问题。要识别每个节点的 kubevirt-csi-node pod，请输入以下命令：
```
$ oc get pods -n openshift-cluster-csi-drivers -o wide -l app=kubevirt-csi-driver
```
如果 PVC 无法绑定到持久性卷 (PV)，查看托管 control plane 命名空间中的 kubevirt-csi-controller 组件的日志。要识别托管的 control plane 命名空间中的 kubevirt-csi-controller pod，请输入以下命令：
```
$ oc get pods -n <hcp namespace> -l app=kubevirt-csi-driver
```

13.3.7. VM 节点没有正确加入集群

如果托管的 control plane 无法完全在线，因为 VM 节点没有正确加入集群，访问 VM 控制台日志。

流程

要访问虚拟机控制台日志，请完成 OpenShift Virtualization Hosted Control Plane 集群的虚拟机部分如何获取串口控制台日志的步骤。

13.3.8. RHCOS 镜像镜像失败

对于在断开连接的环境中的 OpenShift Virtualization 上托管的 control plane，oc-mirror 无法自动将 Red Hat Enterprise Linux CoreOS (RHCOS) 镜像镜像到内部 registry。当您创建第一个托管集群时，Kubevirt 虚拟机无法引导，因为引导镜像在内部 registry 中不可用。

要解决这个问题，请手动将 RHCOS 镜像镜像到内部 registry。

流程

运行以下命令来获取内部 registry 名称：

$ oc get imagecontentsourcepolicy -o json | jq -r '.items[].spec.repositoryDigestMirrors[0].mirrors[0]'

运行以下命令来获取有效负载镜像：

$ oc get clusterversion version -ojsonpath='{.status.desired.image}'

提取 0000_50_installer_coreos-bootimages.yaml 文件，该文件包含来自托管集群上的有效负载镜像的引导镜像。将 <payload_image> 替换为有效负载镜像的名称。运行以下命令:
```
$ oc image extract --file /release-manifests/0000_50_installer_coreos-bootimages.yaml <payload_image> --confirm
```

运行以下命令来获取 RHCOS 镜像：

$ cat 0000_50_installer_coreos-bootimages.yaml | yq -r .data.stream | jq -r '.architectures.x86_64.images.kubevirt."digest-ref"'

将 RHCOS 镜像镜像(mirror)到内部 registry。将 <rhcos_image> 替换为您的 RHCOS 镜像，例如 quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:d9643ead36b1c026be664c9c65c11433c6cdf71bfd93ba229141d134a4a6dd94。将 <internal_registry> 替换为内部 registry 的名称；例如，virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev。运行以下命令:
```
$ oc image mirror <rhcos_image> <internal_registry>
```
创建名为 rhcos-boot-kubevirt.yaml 的 YAML 文件，该文件定义 ImageDigestMirrorSet 对象。请参见以下示例配置：
```
apiVersion: config.openshift.io/v1
kind: ImageDigestMirrorSet
metadata:
  name: rhcos-boot-kubevirt
spec:
  repositoryDigestMirrors:
    - mirrors:
        - <rhcos_image_no_digest> 1
      source: virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev 2
```
1
在没有摘要的情况下指定 RHCOS 镜像，如 quay.io/openshift-release-dev/ocp-v4.0-art-dev。
2
指定内部 registry 的名称，例如 virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev。
运行以下命令应用 rhcos-boot-kubevirt.yaml 文件来创建 ImageDigestMirrorSet 对象：
```
$ oc apply -f rhcos-boot-kubevirt.yaml
```

13.3.9. 将非裸机集群返回到后向绑定池

如果您在没有 BareMetalHosts 的情况下使用后绑定受管集群，您必须完成额外的手动步骤来删除后绑定集群，并将节点返回到 Discovery ISO。

对于没有 BareMetalHosts 的绑定受管集群，删除集群信息不会自动将所有节点返回到 Discovery ISO。

流程

要使用后绑定非裸机节点，请完成以下步骤：

删除集群信息。如需更多信息，请参阅从管理中删除集群。
清理根磁盘。
使用 Discovery ISO 手动重新引导。