支持控制台（Console）开发人员开始试用联系人

1.9. 故障排除

在使用故障排除指南前，您可以运行 oc adm must-gather 命令来收集详情、日志和步骤来调试问题。如需了解更多详细信息，请参阅 运行 must-gather 命令进行故障排除。

另外，查看您基于角色的访问。详情请参阅 multicluster engine operator 基于角色的访问控制。

1.9.1. 记录的故障排除

查看 multicluster engine operator 故障排除主题列表：

安装：

要查看安装任务的主要文档，请参阅安装和升级多集群引擎 operator。

集群管理：

要查看有关管理集群的主要文档，请参阅 集群生命周期简介。

1.9.2. 运行 must-gather 命令进行故障排除

要进行故障排除，参阅可以使用 must-gather 命令进行调试的用户情景信息，然后使用这个命令进行故障排除。

需要的访问权限：集群管理员

1.9.2.1. must-gather 情境

  • 场景一：如果您的问题已被记录，使用 已记录的故障排除文档部分进行解决。这个指南按照产品的主要功能进行组织。

    在这种情况下，您可以参阅本指南来查看您的问题的解决方案是否在文档中。

  • 情况 2：如果这个指南中没有与您的问题相关的内容，运行 must-gather 命令并使用输出来调试问题。
  • 情况 3：无法使用 must-gather 命令的输出结果无法帮助解决您的问题，请向红帽支持提供您的输出。

1.9.2.2. must-gather 过程

请参阅以下流程来使用 must-gather 命令：

  1. 了解 must-gather 命令以及使用它的前提条件，请参阅 OpenShift Container Platform 文档中的 收集集群数据。

  2. 登录到您的集群。对于通常的用例，您应该在登录到您的 引擎 集群时运行 must-gather。

    注： 如果要检查您的受管集群，找到位于 cluster-scoped-resources 目录中的 gather-managed.log 文件： 

    <your-directory>/cluster-scoped-resources/gather-managed.log>

    检查 JOINED 和 AVAILABLE 栏没有被设置为 True 的受管集群。您可以在这些没有以 True 状态连接的集群中运行 must-gather 命令。

  3. 为用于收集数据和目录的 Kubernetes 镜像添加多集群引擎。运行以下命令: 
oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel9:v2.5 --dest-dir=<directory>

  1. 进入您指定的目录查看输出。输出以以下级别进行组织：

    • 两个对等级别：cluster-scoped-resources 和 namespace 资源。
    • 每个对等级别下的子类：用于 cluster-scope 和 namespace-scoped 资源的自定义资源定义的 API 组。
    • 每个子类的下一级： 按 kind 进行排序的 YAML 文件。

1.9.2.3. 在断开连接的环境中的 must-gather

在断开连接的环境中，按照以下步骤运行 must-gather 命令：

  1. 在断开连接的环境中，将 RedHat operator 目录镜像镜像（mirror）到其 mirror registry 中。如需更多信息，请参阅 在断开连接的网络中安装。
  2. 运行以下命令以提取日志，该日志从其镜像 registry 中引用镜像。将 sha256 替换为当前镜像： 
REGISTRY=registry.example.com:5000
IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel9@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8>

oc adm must-gather --image=$IMAGE --dest-dir=./data

您可以在此处为产品团队创建一个 JIRA 错误。https://issues.redhat.com/projects/ACM/summary/

1.9.2.4. 托管集群的 must-gather

如果您在托管 control plane 集群时遇到问题，您可以运行 must-gather 命令来收集信息以进行故障排除。

需要的访问权限： 集群管理

1.9.2.4.1. 关于托管集群的 must-gather 命令

must-gather 命令为管理集群和托管集群生成输出。了解有关收集的数据的更多信息。

  • 从多集群引擎 operator hub 集群收集以下数据：

    • 集群范围的资源：这些资源是管理集群的节点定义。
    • hypershift-dump 压缩文件：如果您需要与其他人员共享内容，该文件非常有用。
    • 命名空间资源 ：这些资源包括来自相关命名空间中的所有对象，如配置映射、服务、事件和日志。
    • 网络日志： 这些日志包括 OVN 北向和南向数据库和每个数据库的状态。
    • 托管的集群：此级别的输出涉及托管集群内的所有资源。

  • 从托管集群收集数据：

    • 集群范围的资源：这些资源包含所有集群范围的对象，如节点和 CRD。
    • 命名空间资源 ：这些资源包括来自相关命名空间中的所有对象，如配置映射、服务、事件和日志。

虽然输出不包含集群中的任何 secret 对象，但它可以包含对 secret 的名称的引用。

1.9.2.4.2. 先决条件

要通过运行 must-gather 命令来收集信息，您必须满足以下条件：

  • 您必须确保 kubeconfig 文件已被加载，并指向 multicluster engine operator hub 集群。
  • 您必须具有 HostedCluster 资源的 name 值，以及部署自定义资源的命名空间。
1.9.2.4.3. 为托管集群输入 must-gather 命令

参阅以下流程从 must-gather 命令收集信息：

  1. 输入以下命令收集有关托管集群的信息。将 <v2.x > 替换为您使用的版本： 

    oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel9:<v2.x> /usr/bin/gather hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE hosted-cluster-name=HOSTEDCLUSTERNAME

    hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE 参数是可选的。如果没有包括该参数，则命令会像托管集群一样在 default 命名空间（即 集群 ）中运行。

  2. 要将命令的结果保存到压缩文件中，请运行相同的命令并添加 --dest-dir=NAME 参数，该参数是可选的。使用您要保存结果的目录的名称替换 NAME。将 <v2.x > 替换为您使用的版本。请使用可选参数查看以下命令： 

    oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel9:<v2.x> /usr/bin/gather hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE hosted-cluster-name=HOSTEDCLUSTERNAME --dest-dir=NAME ; tar -cvzf NAME.tgz NAME
1.9.2.4.4. 在断开连接的环境中输入 must-gather 命令

在断开连接的环境中，按照以下步骤运行 must-gather 命令：

  1. 在断开连接的环境中，将 RedHat operator 目录镜像镜像（mirror）到其 mirror registry 中。如需更多信息，请参阅 在断开连接的网络中安装。

  2. 运行以下命令以提取日志，从其 mirror registry 中引用镜像： 

    REGISTRY=registry.example.com:5000
IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel8@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8

oc adm must-gather --image=$IMAGE /usr/bin/gather hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE hosted-cluster-name=HOSTEDCLUSTERNAME --dest-dir=./data
1.9.2.4.5. 其他资源

1.9.3. 故障排除：将 day-two 节点添加到现有集群失败，并显示待处理的用户操作

将节点或缩减到由 multicluster engine 为 Kubernetes operator 创建的现有集群中，且使用 Zero Touch Provisioning 或 Host inventory create 方法在安装过程中会失败。安装过程在发现阶段可以正常工作，但在安装阶段失败。

网络的配置失败。在集成控制台中的 hub 集群中看到 Pending 用户操作。在描述中，您可以看到它在重启步骤中失败。

有关失败的错误消息不准确，因为安装主机中运行的代理无法报告信息。

1.9.3.1. 症状：为第二天 worker 安装失败

发现阶段后，主机将重启以继续安装，但它无法配置网络。检查以下症状和信息：

  • 在集成控制台中的 hub 集群中，检查添加节点上的 Pending 用户操作，并带有 Rebooting 指示符： 

    This host is pending user action. Host timed out when pulling ignition. Check the host console... Rebooting

  • 在 Red Hat OpenShift Container Platform 配置受管集群中，检查现有集群的 MachineConfig。检查 MachineConfig 是否在以下目录中创建任何文件：

    • /sysroot/etc/NetworkManager/system-connections/
    • /sysroot/etc/sysconfig/network-scripts/
  • 在安装主机的终端中，检查失败的主机是否有以下消息：您可以使用 journalctl 查看日志消息： 
info: networking config is defined in the real root

info: will not attempt to propagate initramfs networking

如果您在日志中收到最后一条消息，则不会传播网络配置，因为它已在之前在 Symptom 中列出的文件夹中找到现有网络配置。

1.9.3.2. 解决问题：重新创建节点合并网络配置

执行以下任务以在安装过程中使用正确的网络配置：

  1. 从 hub 集群中删除节点。
  2. 重复前面的流程，以同样的方式安装节点。

  3. 使用以下注解创建节点的 BareMetalHost 对象： 

    "bmac.agent-install.openshift.io/installer-args": "[\"--append-karg\", \"coreos.force_persist_ip\"]"

节点开始安装。在发现阶段后，节点会在现有集群的更改和初始配置之间合并网络配置。

1.9.4. 在代理平台上删除托管的 control plane 集群失败的问题

当您在 Agent 平台上销毁托管的 control plane 集群时，所有后端资源通常会被删除。如果没有正确删除机器资源，集群删除会失败。在这种情况下，您必须手动删除剩余的机器资源。

1.9.4.1. 症状：销毁托管 control plane 集群时发生错误

试图销毁 Agent 平台上托管的 control plane 集群后，hcp destroy 命令会失败并显示以下错误：

+ 

2024-02-22T09:56:19-05:00    ERROR    HostedCluster deletion failed    {"namespace": "clusters", "name": "hosted-0", "error": "context deadline exceeded"}
2024-02-22T09:56:19-05:00    ERROR    Failed to destroy cluster    {"error": "context deadline exceeded"}

1.9.4.2. 解决问题： 手动删除剩余的机器资源

完成以下步骤，在 Agent 平台上成功销毁托管的 control plane 集群：

  1. 运行以下命令，将 < hosted_cluster_namespace > 替换为托管集群命名空间的名称来查看剩余的机器资源列表： 

    oc get machine -n <hosted_cluster_namespace>

    请参见以下示例输出： 

    NAMESPACE           NAME             CLUSTER          NODENAME   PROVIDERID   PHASE      AGE   VERSION
clusters-hosted-0   hosted-0-9gg8b   hosted-0-nhdbp                           Deleting   10h   4.15.0-rc.8

  2. 运行以下命令以删除附加到机器资源的 machine.cluster.x-k8s.io finalizer： 

    oc edit machines -n <hosted_cluster_namespace>

  3. 运行以下命令验证您是否在终端中收到 No resources found 信息： 

    oc get agentmachine -n <hosted_cluster_namespace>

  4. 运行以下命令，在 Agent 平台上销毁托管的 control plane 集群： 

    hcp destroy cluster agent --name <cluster_name>

    将 <cluster_name> 替换为集群的名称。

1.9.5. 安装状态故障排除处于安装或待处理状态

安装 multicluster engine operator 时，MultiClusterEngine 会一直处于 Installing 阶段，或者多个 pod 维护 Pending 状态。

1.9.5.1. 症状：一直处于 Pending 状态

安装 MultiClusterEngine 后超过十分钟，来自 MultiClusterEngine 资源的 status.components 字段的一个或多个组件报告 ProgressDeadlineExceeded。这可能是集群中的资源限制的问题。

检查安装了 MultiClusterEngine 的命名空间中的 pod。您可能会看到 Pending 状态，如下所示： 

reason: Unschedulable
message: '0/6 nodes are available: 3 Insufficient cpu, 3 node(s) had taint {node-role.kubernetes.io/master:
        }, that the pod didn't tolerate.'

在这种情况下，集群中 worker 节点资源不足以运行该产品。

1.9.5.2. 解决问题： 调整 worker 节点大小

如果您有这个问题，则需要使用更大或多个 worker 节点来更新集群。如需了解调整集群大小的信息，请参阅调整集群大小。

1.9.6. 重新安装失败的故障排除

重新安装多集群引擎 operator 时，pod 不会启动。

1.9.6.1. 症状：重新安装失败

如果在安装 multicluster engine operator 后 pod 没有启动，通常是因为之前安装 multicluster engine operator 的项目在卸载时无法正确删除。

在本例中，pod 在完成安装过程后没有启动。

1.9.6.2. 解决问题： 重新安装失败

如果您有这个问题，请完成以下步骤：

  1. 按照 卸载 中的步骤，运行卸载过程来删除当前的组件。
  2. 按照安装 Helm 中的内容，安装 Helm CLI 二进制版本 3.2.0 或更新版本。
  3. 确保您的 Red Hat OpenShift Container Platform CLI 被配置为运行 oc 命令。如需有关如何配置 oc 命令的更多信息 ，请参阅 OpenShift Container Platform 文档中的 OpenShift CLI 入门。

  4. 将以下脚本复制到一个文件中： 

    #!/bin/bash
MCE_NAMESPACE=<namespace>
oc delete multiclusterengine --all
oc delete apiservice v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io
oc delete crd discoveredclusters.discovery.open-cluster-management.io discoveryconfigs.discovery.open-cluster-management.io
oc delete mutatingwebhookconfiguration ocm-mutating-webhook managedclustermutators.admission.cluster.open-cluster-management.io
oc delete validatingwebhookconfiguration ocm-validating-webhook
oc delete ns $MCE_NAMESPACE

    将 脚本中的 <namespace > 替换为安装 multicluster engine operator 的命名空间的名称。确保指定正确的命名空间，因为命名空间会被清理和删除。

  5. 运行该脚本以删除以前安装中的内容。
  6. 运行安装。请参阅在线安装。

1.9.7. 离线集群的故障排除

一些常见的原因会导致集群显示离线状态。

1.9.7.1. 症状：集群状态为离线

完成创建集群的步骤后，您无法从 Red Hat Advanced Cluster Management 控制台访问集群，集群的状态为离线（offline）。

1.9.7.2. 解决问题： 集群状态为离线

  1. 确定受管集群是否可用。您可以在 Red Hat Advanced Cluster Management 控制台的 Clusters 区域中进行检查。

    如果不可用，请尝试重启受管集群。

  2. 如果受管集群状态仍处于离线状态，完成以下步骤：

    1. 在 hub 集群上运行 oc get managedcluster <cluster_name> -o yaml 命令。将 <cluster_name> 替换为集群的名称。
    2. 找到 status. conditionss 部分。
    3. 检查 type: ManagedClusterConditionAvailable 信息并解决相关的问题。

1.9.8. 受管集群导入失败的故障排除

如果集群导入失败，您可以执行一些步骤来确定集群导入失败的原因。

1.9.8.1. 症状：导入的集群不可用

完成导入集群的步骤后，您无法从控制台访问它。

1.9.8.2. 解决问题： 导入的集群不可用

在尝试导入集群后，有几个可能的原因会导致导入集群的不可用。如果集群导入失败，请完成以下步骤，直到找到失败导入的原因：

  1. 在 hub 集群中，运行以下命令来确保导入控制器正在运行。 

    kubectl -n multicluster-engine get pods -l app=managedcluster-import-controller-v2

    您应该会看到两个正在运行的 pod。如果任何一个 pod 没有运行，请运行以下命令来查看日志以确定原因： 

    kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1

  2. 在 hub 集群中，运行以下命令以确定受管集群导入 secret 是否由导入控制器成功生成： 

    kubectl -n <managed_cluster_name> get secrets <managed_cluster_name>-import

    如果导入 secret 不存在，请运行以下命令来查看导入控制器的日志条目，并确定它没有被创建的原因： 

    kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1 | grep importconfig-controller

  3. 在 hub 集群中，如果您的受管集群是 local-cluster，或者由 Hive 置备，或者具有自动导入 secret，请运行以下命令来检查受管集群的导入状态。 

    kubectl get managedcluster <managed_cluster_name> -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}' | grep ManagedClusterImportSucceeded

    如果 ManagedClusterImportSucceeded 条件为 true，则命令的结果表示失败的原因。

  4. 检查受管集群的 Klusterlet 状态是否有降级条件。请参阅 带有降级条件的 Klusterlet 故障排除，以查找 Klusterlet 被降级的原因。

1.9.9. 重新导入集群失败并显示未知颁发机构错误

如果您在将受管集群重新导入到多集群引擎 operator hub 集群时遇到问题，请按照以下步骤排除此问题。

1.9.9.1. 症状：重新导入集群失败并显示未知颁发机构错误

使用 multicluster engine operator 置备 OpenShift Container Platform 集群后，当更改或将 API 服务器证书添加到 OpenShift Container Platform 集群时，重新导入集群可能会失败，并显示 x509: certificate signed by unknown authority 错误。

1.9.9.2. 鉴别问题： 重新导入集群失败并显示未知颁发机构错误

在重新导入受管集群后，运行以下命令在 multicluster engine operator hub 集群上获取导入控制器日志： 

kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 -f

如果出现以下错误日志，受管集群 API 服务器证书可能会改变：

ERROR Reconciler error {"controller": "clusterdeployment-controller", "object": {"name":"awscluster1","namespace":"awscluster1"}, "namespace": "awscluster1", "name": "awscluster1", "reconcileID": "a2cccf24-2547-4e26-95fb-f258a6710d80", "error": "Get \"https://api.awscluster1.dev04.red-chesterfield.com:6443/api?timeout=32s\": x509: certificate signed by unknown authority"}

要确定受管集群 API 服务器证书是否已更改，请完成以下步骤：

  1. 运行以下命令，将 your-managed-cluster-name 替换为受管集群的名称来指定受管集群名称： 

    cluster_name=<your-managed-cluster-name>

  2. 运行以下命令获取受管集群 kubeconfig secret 名称： 

    kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')

  3. 运行以下命令，将 kubeconfig 导出到新文件： 

    oc -n ${cluster_name} get secret ${kubeconfig_secret_name} -ojsonpath={.data.kubeconfig} | base64 -d > kubeconfig.old
    export KUBECONFIG=kubeconfig.old

  4. 运行以下命令，使用 kubeconfig 从受管集群获取命名空间： 

    oc get ns

如果您收到类似以下消息的错误，您的集群 API 服务器符已更改，且 kubeconfig 文件无效。

无法连接到服务器：x509: certificate signed by unknown authority

1.9.9.3. 解决问题： 重新导入集群失败并显示未知颁发机构错误

受管集群管理员必须为受管集群创建一个新的有效的 kubeconfig 文件。

创建新的 kubeconfig 后，执行以下步骤为受管集群更新新的 kubeconfig ：

  1. 运行以下命令来设置 kubeconfig 文件路径和集群名称。将 <path_to_kubeconfig > 替换为新 kubeconfig 文件的路径。将 <managed_cluster_name > 替换为受管集群的名称： 

    cluster_name=<managed_cluster_name>
kubeconfig_file=<path_to_kubeconfig>

  2. 运行以下命令来对新的 kubeconfig 进行编码： 

    kubeconfig=$(cat ${kubeconfig_file} | base64 -w0)

    注： 在 macOS 中运行以下命令： 

    kubeconfig=$(cat ${kubeconfig_file} | base64)

  3. 运行以下命令来定义 kubeconfig json 补丁： 

    kubeconfig_patch="[\{\"op\":\"replace\", \"path\":\"/data/kubeconfig\", \"value\":\"${kubeconfig}\"}, \{\"op\":\"replace\", \"path\":\"/data/raw-kubeconfig\", \"value\":\"${kubeconfig}\"}]"

  4. 运行以下命令，从受管集群检索您的管理员 kubeconfig secret 名称： 

    kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')

  5. 运行以下命令，使用您的新 kubeconfig 对管理员 kubeconfig secret 进行补丁： 

    oc -n ${cluster_name} patch secrets ${kubeconfig_secret_name} --type='json' -p="${kubeconfig_patch}"

1.9.10. 对带有待处理导入状态的集群进行故障排除

如果在集群的控制台上持续接收到 Pending import（待处理到）信息时，请按照以下步骤排除此问题。

1.9.10.1. 症状：集群处于待处理导入状态

在使用 Red Hat Advanced Cluster Management 控制台导入一个集群后，出现在控制台中的集群带有 Pending import 状态。

1.9.10.2. 鉴别问题： 集群处于待处理导入状态

  1. 在受管集群中运行以下命令查看有问题的 Kubernetes pod 的名称： 

    kubectl get pod -n open-cluster-management-agent | grep klusterlet-registration-agent

  2. 在受管集群中运行以下命令查找错误的日志条目： 

    kubectl logs <registration_agent_pod> -n open-cluster-management-agent

    把 registration_agent_pod 替换为在第 1 步中获得的 pod 名称。

  3. 在返回的结果中搜索显示有网络连接问题的内容。示例包括：no such host。

1.9.10.3. 解决问题： 集群处于待处理导入状态

  1. 通过在 hub 集群中输入以下命令来检索有问题的端口号： 

    oc get infrastructure cluster -o yaml | grep apiServerURL

  2. 确保来自受管集群的主机名可以被解析，并确保建立到主机和端口的出站连接。

    如果无法通过受管集群建立通信，集群导入就不完整。受管集群的集群状态将会是 Pending import。

1.9.11. 证书更改后导入的集群离线故障排除

虽然支持安装自定义的 apiserver 证书，但在更改证书前导入的一个或多个集群会处于offline 状态。

1.9.11.1. 症状：证书更改后集群处于离线状态

完成更新证书 secret 的步骤后，在线的一个或多个集群现在在控制台中显示 离线状态。

1.9.11.2. 鉴别问题： 证书更改后集群处于离线状态

更新自定义 API 服务器证书信息后，在新证书前导入并运行的集群会处于 offline 状态。

表示证书有问题的错误会出现在离线受管集群的 open-cluster-management-agent 命名空间中的 pod 日志中。以下示例与日志中显示的错误类似：

请参阅以下 work-agent 日志： 

E0917 03:04:05.874759       1 manifestwork_controller.go:179] Reconcile work test-1-klusterlet-addon-workmgr fails with err: Failed to update work status with err Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:05.874887       1 base_controller.go:231] "ManifestWorkAgent" controller failed to sync "test-1-klusterlet-addon-workmgr", err: Failed to update work status with err Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:37.245859       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManifestWork: failed to list *v1.ManifestWork: Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks?resourceVersion=607424": x509: certificate signed by unknown authority

请参阅以下 registration-agent 日志： 

I0917 02:27:41.525026       1 event.go:282] Event(v1.ObjectReference{Kind:"Namespace", Namespace:"open-cluster-management-agent", Name:"open-cluster-management-agent", UID:"", APIVersion:"v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'ManagedClusterAvailableConditionUpdated' update managed cluster "test-1" available condition to "True", due to "Managed cluster is available"
E0917 02:58:26.315984       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1beta1.CertificateSigningRequest: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority
E0917 02:58:26.598343       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true": x509: certificate signed by unknown authority
E0917 02:58:27.613963       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: failed to list *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority

1.9.11.3. 解决问题： 证书更改后集群处于离线状态

如果您的受管集群是由 multicluster engine operator 创建的 local-cluster 或受管集群，则必须等待 10 分钟或更长时间恢复受管集群。

要立即恢复受管集群，您可以删除 hub 集群上的受管集群导入 secret，并使用 multicluster engine operator 恢复它。运行以下命令: 

oc delete secret -n <cluster_name> <cluster_name>-import

将 < cluster_name > 替换为您要恢复的受管集群的名称。

如果要恢复使用 multicluster engine operator 导入的受管集群，请完成以下步骤再次导入受管集群：

  1. 在 hub 集群中，运行以下命令来重新创建受管集群导入 secret： 

    oc delete secret -n <cluster_name> <cluster_name>-import

    将 <cluster_name> 替换为您要导入的受管集群的名称。

  2. 在 hub 集群中，运行以下命令来将受管集群导入 secret 公开给 YAML 文件： 

    oc get secret -n <cluster_name> <cluster_name>-import -ojsonpath='{.data.import\.yaml}' | base64 --decode  > import.yaml

    将 <cluster_name> 替换为您要导入的受管集群的名称。

  3. 在受管集群中，运行以下命令应用 import.yaml 文件： 

    oc apply -f import.yaml

注：前面的步骤不会从 hub 集群中分离受管集群。步骤使用受管集群中的当前设置更新所需的清单，包括新证书信息。

1.9.12. 集群状态从离线变为可用的故障排除

在没有对环境或集群进行任何手工更改的情况下，受管集群的状态在 offline（离线） 和 available（可用） 间转换。

1.9.12.1. 症状：集群状态从离线变为可用

当将受管集群连接到 hub 集群的网络不稳定时，hub 集群所报告的受管集群的状态在离线和可用之间不断转换。

1.9.12.2. 解决问题： 集群状态从离线变为可用

要尝试解决这个问题，请完成以下步骤：

  1. 输入以下命令在 hub 集群上编辑 ManagedCluster 规格： 

    oc edit managedcluster <cluster-name>

    将 cluster-name 替换为您的受管集群的名称。

  2. 在 ManagedCluster 规格中增加 leaseDurationSeconds 的值。默认值为 5 分钟，但可能没有足够的时间来保持与网络问题的连接。为租期指定较长的时间。例如，您可以将这个值提高为 20 分钟。

1.9.13. VMware vSphere 上创建集群的故障排除

如果您在 VMware vSphere 上创建 Red Hat OpenShift Container Platform 集群时遇到问题，请查看以下故障排除信息以查看它们是否解决了您的问题。

注：当集群创建过程在 VMware vSphere 上失败时，您将无法使用该链接来查看日志。如果发生这种情况，您可以通过查看 thehive-controllers pod 的日志来找出问题。hive-controllers 日志位于 hive 命名空间中。

1.9.13.1. 受管集群创建失败并显示证书 IP SAN 错误

1.9.13.1.1. 症状： Managed 集群创建失败并显示证书 IP SAN 错误

在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后，集群会失败，并显示一个错误消息，显示证书 IP SAN 错误。

1.9.13.1.2. 鉴别问题： 管理的集群创建失败并显示证书 IP SAN 错误

受管集群的部署失败，并在部署日志中返回以下错误： 

time="2020-08-07T15:27:55Z" level=error msg="Error: error setting up new vSphere SOAP client: Post https://147.1.1.1/sdk: x509: cannot validate certificate for xx.xx.xx.xx because it doesn't contain any IP SANs"
time="2020-08-07T15:27:55Z" level=error
1.9.13.1.3. 解决问题： 管理的集群创建失败，并显示证书 IP SAN 错误

使用 VMware vCenter 服务器完全限定主机名，而不是凭证中的 IP 地址。您还可以更新 VMware vCenter CA 证书以包含 IP SAN。

1.9.13.2. 受管集群创建失败并显示未知证书颁发机构

1.9.13.2.1. 症状：管理集群创建失败并显示未知证书颁发机构

在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后，集群会失败，因为证书由未知颁发机构签名。

1.9.13.2.2. 鉴别问题： Managed 集群创建失败并显示未知证书颁发机构

受管集群的部署失败，并在部署日志中返回以下错误： 

Error: error setting up new vSphere SOAP client: Post https://vspherehost.com/sdk: x509: certificate signed by unknown authority"
1.9.13.2.3. 解决问题： 管理的集群创建失败并显示未知证书颁发机构

确保您在创建凭证时从证书认证机构输入了正确的证书。

1.9.13.3. 受管集群创建带有过期证书失败

1.9.13.3.1. 情况： 集群创建失败并显示过期的证书

在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后，集群会失败，因为证书已过期或者无效。

1.9.13.3.2. 鉴别问题： 管理的集群创建失败并显示过期的证书

受管集群的部署失败，并在部署日志中返回以下错误： 

x509: certificate has expired or is not yet valid
1.9.13.3.3. 解决问题： 管理的集群创建失败并显示过期的证书

确保同步了 ESXi 主机上的时间。

1.9.13.4. 受管集群创建失败且没有标记权限

1.9.13.4.1. 症状：管理集群创建失败且没有足够特权进行标记

在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后，集群会失败，因为没有足够的权限进行标记。

1.9.13.4.2. 鉴别问题： Managed 集群创建会失败，没有足够权限进行标记

受管集群的部署失败，并在部署日志中返回以下错误： 

time="2020-08-07T19:41:58Z" level=debug msg="vsphere_tag_category.category: Creating..."
time="2020-08-07T19:41:58Z" level=error
time="2020-08-07T19:41:58Z" level=error msg="Error: could not create category: POST https://vspherehost.com/rest/com/vmware/cis/tagging/category: 403 Forbidden"
time="2020-08-07T19:41:58Z" level=error
time="2020-08-07T19:41:58Z" level=error msg="  on ../tmp/openshift-install-436877649/main.tf line 54, in resource \"vsphere_tag_category\" \"category\":"
time="2020-08-07T19:41:58Z" level=error msg="  54: resource \"vsphere_tag_category\" \"category\" {"
1.9.13.4.3. 解决问题： 管理的集群创建没有足够权限进行标记

确保 VMware vCenter 所需的帐户权限正确。如需更多信息，请参阅在安装过程中删除的镜像 registry。

1.9.13.5. 受管集群创建失败并显示无效的 dnsVIP

1.9.13.5.1. 症状： 受管集群创建失败并显示无效的 dnsVIP

在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后，集群会失败，因为存在无效的 dnsVIP。

1.9.13.5.2. 鉴别问题： Managed 集群创建失败并显示无效的 dnsVIP

如果您在尝试使用 VMware vSphere 部署新受管集群时看到以下消息，这是因为您有一个较老的 OpenShift Container Platform 发行版本镜像，它不支持 VMware Installer Provisioned Infrastructure（IPI）： 

failed to fetch Master Machines: failed to load asset \\\"Install Config\\\": invalid \\\"install-config.yaml\\\" file: platform.vsphere.dnsVIP: Invalid value: \\\"\\\": \\\"\\\" is not a valid IP
1.9.13.5.3. 解决问题： 受管集群创建失败并显示无效的 dnsVIP

从支持 VMware Installer Provisioned Infrastructure 的 OpenShift Container Platform 版本中选择一个发行镜像。

1.9.13.6. 受管集群创建带有不正确的网络类型失败

1.9.13.6.1. 症状： 集群创建失败并显示不正确的网络类型

在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后，集群会失败，因为指定的网络类型不正确。

1.9.13.6.2. 鉴别问题： 管理的集群创建失败并显示不正确的网络类型

如果您在尝试使用 VMware vSphere 部署新受管集群时看到以下消息，这是因为您有一个旧的 OpenShift Container Platform 镜像，它不支持 VMware Installer Provisioned Infrastructure（IPI）： 

time="2020-08-11T14:31:38-04:00" level=debug msg="vsphereprivate_import_ova.import: Creating..."
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=error msg="Error: rpc error: code = Unavailable desc = transport is closing"
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=fatal msg="failed to fetch Cluster: failed to generate asset \"Cluster\": failed to create cluster: failed to apply Terraform: failed to complete the change"
1.9.13.6.3. 解决问题： 受管集群创建失败并显示不正确的网络类型

为指定的 VMware 集群选择一个有效的 VMware vSphere 网络类型。

1.9.13.7. 受管集群创建失败并显示磁盘更改错误

1.9.13.7.1. 症状：因为错误处理磁盘更改导致添加 VMware vSphere 受管集群失败

在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后，集群会失败，因为在处理磁盘更改时会出现错误。

1.9.13.7.2. 鉴别问题： 添加 VMware vSphere 受管集群会因为处理磁盘更改出错而失败

日志中会显示类似以下内容的消息： 

ERROR
ERROR Error: error reconfiguring virtual machine: error processing disk changes post-clone: disk.0: ServerFaultCode: NoPermission: RESOURCE (vm-71:2000), ACTION (queryAssociatedProfile): RESOURCE (vm-71), ACTION (PolicyIDByVirtualDisk)
1.9.13.7.3. 解决问题：因为错误处理磁盘更改导致 VMware vSphere 受管集群失败

使用 VMware vSphere 客户端为用户授予Profile-driven Storage Privileges 的所有权限。

1.9.14. 集群在控制台中带有待处理或失败状态的故障排除

如果您在控制台中看到您创建的集群的状态为 Pending 或 Failed，请按照以下步骤排除问题。

1.9.14.1. 症状：集群在控制台中带有待处理或失败状态

在使用控制台创建新集群后，集群不会超过 Pending 状态或显示 Failed 状态。

1.9.14.2. 鉴别问题： 集群在控制台中显示待处理或失败状态

如果集群显示 Failed 状态，进入集群的详情页面并使用提供的日志的链接。如果没有找到日志或集群显示 Pending 状态，请按照以下步骤检查日志：

  • 流程 1

    1. 在 hub 集群中运行以下命令，查看在命名空间中为新集群创建的 Kubernetes pod 的名称： 

      oc get pod -n <new_cluster_name>

      使用您创建的集群名称替换 new_cluster_name。

    2. 如果没有 pod 在列出的名称中包括 provision 字符串，则按照流程 2 继续进行。如果存在其标题中带有 provision 字符串的 pod，则在 hub 集群中运行以下命令以查看该 pod 的日志： 

      oc logs <new_cluster_name_provision_pod_name> -n <new_cluster_name> -c hive

      将 new_cluster_name_provision_pod_name 替换为您创建的集群的名称，后接包含 provision 的 pod 名称。

    3. 搜索日志中可能会解释造成问题的原因的错误信息。

  • 流程 2

    如果没有在其名称中带有 provision 的 pod，则代表问题在进程早期发生。完成以下步骤以查看日志：

    1. 在 hub 集群中运行以下命令： 

      oc describe clusterdeployments -n <new_cluster_name>

      使用您创建的集群名称替换 new_cluster_name。如需有关集群安装日志的更多信息，请参阅 Red Hat OpenShift 文档中的 收集安装日志的内容。

    2. 检查是否在资源的 Status.Conditions.Message 和 Status.Conditions.Reason 条目中存在有关此问题的额外信息。

1.9.14.3. 解决问题： 集群在控制台中显示待处理或失败状态

在日志中找到错误后，确定如何在销毁集群并重新创建它之前解决相关的错误。

以下示例包括了一个选择不支持的区的日志错误，以及解决它所需的操作： 

No subnets provided for zones

When you created your cluster, you selected one or more zones within a region that are not supported.在重新创建集群时完成以下操作之一以解决此问题：

  • 在区域里（region）选择不同的区（zone）。
  • 如果列出了其它区，则省略不支持的区。
  • 为集群选择不同的区域。

在处理了日志中记录的问题后，销毁集群并重新创建它。

有关创建集群的更多信息，请参阅 集群创建简介。

1.9.15. OpenShift Container Platform 版本 3.11 集群导入失败的故障排除

1.9.15.1. 症状：OpenShift Container Platform 版本 3.11 集群导入失败

试图导入 Red Hat OpenShift Container Platform 版本 3.11 集群后，导入会失败，并显示类似以下内容的日志消息： 

customresourcedefinition.apiextensions.k8s.io/klusterlets.operator.open-cluster-management.io configured
clusterrole.rbac.authorization.k8s.io/klusterlet configured
clusterrole.rbac.authorization.k8s.io/open-cluster-management:klusterlet-admin-aggregate-clusterrole configured
clusterrolebinding.rbac.authorization.k8s.io/klusterlet configured
namespace/open-cluster-management-agent configured
secret/open-cluster-management-image-pull-credentials unchanged
serviceaccount/klusterlet configured
deployment.apps/klusterlet unchanged
klusterlet.operator.open-cluster-management.io/klusterlet configured
Error from server (BadRequest): error when creating "STDIN": Secret in version "v1" cannot be handled as a Secret:
v1.Secret.ObjectMeta:
v1.ObjectMeta.TypeMeta: Kind: Data: decode base64: illegal base64 data at input byte 1313, error found in #10 byte of ...|dhruy45="},"kind":"|..., bigger context ...|tye56u56u568yuo7i67i67i67o556574i"},"kind":"Secret","metadata":{"annotations":{"kube|...

1.9.15.2. 鉴别问题： OpenShift Container Platform 版本 3.11 集群导入失败

这通常是因为安装的 kubectl 命令行工具的版本为 1.11 或更早版本。运行以下命令，以查看您正在运行的 kubectl 命令行工具的版本： 

kubectl version

如果返回的数据列出了 1.11 或更早版本，按照解决问题：OpenShift Container Platform 版本 3.11 集群导入失败中的内容进行解决。

1.9.15.3. 解决问题： OpenShift Container Platform 版本 3.11 集群导入失败

您可以通过完成以下步骤之一解决这个问题：

  • 安装 kubectl 命令行工具的最新版本。

    1. 下载 kubectl 工具的最新版本：参阅 Kubernetes 文档中的安装和设置 kubectl。
    2. 升级 kubectl 工具后再次导入集群。

  • 运行包含导入命令的文件。

    1. 启动 使用 CLI 导入受管集群 的步骤。
    2. 在创建用于导入集群的命令时，将该命令复制到名为 import.yaml 的 YAML 文件中。

    3. 运行以下命令从文件中再次导入集群： 

      oc apply -f import.yaml

1.9.16. 带有降级条件的 Klusterlet 故障排除

Klusterlet 降级条件可帮助诊断受管集群中的 Klusterlet 代理的状态。如果 Klusterlet 处于 degraded 条件，受管集群中的 Klusterlet 代理可能会出错，需要进行故障排除。对于设置为 True 的 Klusterlet 降级条件，请参见以下信息。

1.9.16.1. 症状：Klusterlet 处于降级状况

在受管集群中部署 Klusterlet 后，KlusterletRegistrationDegraded 或 KlusterletWorkDegraded 条件会显示 True 的状态。

1.9.16.2. 鉴别问题： Klusterlet 处于降级状况

  1. 在受管集群中运行以下命令查看 Klusterlet 状态： 

    kubectl get klusterlets klusterlet -oyaml
  2. 检查 KlusterletRegistrationDegraded 或 KlusterletWorkDegraded 以查看该条件是否被设置为 True。请根据解决这个问题的内容处理降级问题。

1.9.16.3. 解决问题： Klusterlet 处于降级状况

请查看以下降级状态列表，以及如何尝试解决这些问题：

  • 如果 KlusterletRegistrationDegraded 条件的状态为 True 且状况原因为： BootStrapSecretMissing，您需要在 open-cluster-management-agent 命名空间中创建一个 bootstrap secret。
  • 如果 KlusterletRegistrationDegraded 条件显示为 True，且状况原因为 BootstrapSecretError 或 BootstrapSecretUnauthorized， 则当前的 bootstrap secret 无效。删除当前的 bootstrap secret，并在 open-cluster-management-agent 命名空间中重新创建有效的 bootstrap secret。
  • 如果 KlusterletRegistrationDegraded 和 KlusterletWorkDegraded 显示为 True，且状况原因为 HubKubeConfigSecretMissing，请删除 Klusterlet 并重新创建它。
  • 如果 KlusterletRegistrationDegraded 和 KlusterletWorkDegraded 显示为 True，则状况原因为： ClusterNameMissing、KubeConfigMissing、HubConfigSecretError 或 HubConfigSecretUnauthorized，从 open-cluster-management-agent 命名空间中删除 hub 集群 kubeconfig secret。注册代理将再次引导以获取新的 hub 集群 kubeconfig secret。
  • 如果 KlusterletRegistrationDegraded 显示为 True，且状况原因为 GetRegistrationDeploymentFailed 或 UnavailableRegistrationPod，您可以检查条件消息以获取问题详情并尝试解决。
  • 如果 KlusterletWorkDegraded 显示 True，且状况原因为 GetWorkDeploymentFailed 或 UnavailableWorkPod，您可以检查条件消息以获取问题详情并尝试解决。

1.9.17. 删除集群后命名空间会保留

当您删除受管集群时，该命名空间通常会作为移除集群过程的一部分被删除。在个别情况下，命名空间会和其中的一些工件一起被保留。在这种情况下，您必须手动删除命名空间。

1.9.17.1. 症状：删除集群后命名空间被保留

删除受管集群后，命名空间没有被删除。

1.9.17.2. 解决问题： 删除集群后命名空间被保留

完成以下步骤以手动删除命名空间：

  1. 运行以下命令以生成保留在 <cluster_name> 命名空间中的资源列表： 

    oc api-resources --verbs=list --namespaced -o name | grep -E '^secrets|^serviceaccounts|^managedclusteraddons|^roles|^rolebindings|^manifestworks|^leases|^managedclusterinfo|^appliedmanifestworks'|^clusteroauths' | xargs -n 1 oc get --show-kind --ignore-not-found -n <cluster_name>

    使用您要删除的集群的命名空间名称替换 cluster_name。

  2. 输入以下命令来编辑列表，删除列表中状态不是 Delete 的资源： 

    oc edit <resource_kind> <resource_name> -n <namespace>

    将 resource_kind 替换为资源类型。将 resource_name 替换为资源的名称。使用资源的命名空间的名称替换 namespace。

  3. 在元数据中找到 finalizer 属性。
  4. 使用 vi 编辑器的 dd 命令删除非 Kubernetes finalizer。
  5. 输入 :wq 命令保存列表并退出 vi 编辑器。

  6. 输入以下命令来删除命名空间： 

    oc delete ns <cluster-name>

    使用您要删除的命名空间的名称替换 cluster-name。

1.9.18. 导入集群时出现自动 Auto-import-secret-exists 错误

集群导入失败，并显示出错信息：auto import secret exists。

1.9.18.1. 症状：导入集群时出现 Auto import secret exists 错误

当导入 hive 集群以进行管理时，会显示 auto-import-secret already exists 错误。

1.9.18.2. 解决问题：导入集群时出现 Auto import secret exists 错误

当您试图导入之前管理的集群时，会出现此问题。如果出现这种情况，当您尝试重新导入集群时，secret 会发生冲突。

要临时解决这个问题，请完成以下步骤：

  1. 在 hub 集群中运行以下命令来手工删除存在的 auto-import-secret： 

    oc delete secret auto-import-secret -n <cluster-namespace>

    将 cluster-namespace 替换为集群的命名空间。

  2. 使用集群导入简介 中的流程再次导入集群。

1.9.19. 在创建放置后缺少 PlacementDecision 进行故障排除

如果在创建放置后没有生成 PlacementDescision，请按照以下步骤排除此问题。

1.9.19.1. 症状：创建放置后缺少 PlacementDecision

创建 放置 后，不会自动生成一个 PlacementDescision。

1.9.19.2. 解决问题： 在创建放置后缺少 PlacementDecision

要解决这个问题，请完成以下步骤：

  1. 运行以下命令检查 放置 条件： 

    kubectl describe placement <placement-name>

    将 placement-name 替换为 放置 的名称。

    输出可能类似以下示例： 

    Name:         demo-placement
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  cluster.open-cluster-management.io/v1beta1
Kind:         Placement
Status:
  Conditions:
    Last Transition Time:       2022-09-30T07:39:45Z
    Message:                    Placement configurations check pass
    Reason:                     Succeedconfigured
    Status:                     False
    Type:                       PlacementMisconfigured
    Last Transition Time:       2022-09-30T07:39:45Z
    Message:                    No valid ManagedClusterSetBindings found in placement namespace
    Reason:                     NoManagedClusterSetBindings
    Status:                     False
    Type:                       PlacementSatisfied
  Number Of Selected Clusters:  0

  2. 在输出中检查 PlacementMisconfigured 和 PlacementSatisfied 的 Status：

    • 如果 PlacementMisconfigured Status 为 true，则您的 Placement 具有配置错误。检查包含的消息，了解配置错误的详情以及如何解决它们。
    • 如果 PlacementSatisfied Status 为 false，则没有受管集群满足您的 放置。检查包含的消息以获取更多详细信息以及如何解决错误。在上例中，放置命名空间中没有找到 ManagedClusterSetBindings。

  3. 您可以检查 Events 中每个集群的分数，以了解某些具有较低分数的集群没有被选择。输出可能类似以下示例： 

    Name:         demo-placement
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  cluster.open-cluster-management.io/v1beta1
Kind:         Placement
Events:
  Type    Reason          Age   From                 Message
  ----    ------          ----  ----                 -------
  Normal  DecisionCreate  2m10s   placementController  Decision demo-placement-decision-1 is created with placement demo-placement in namespace default
  Normal  DecisionUpdate  2m10s   placementController  Decision demo-placement-decision-1 is updated with placement demo-placement in namespace default
  Normal  ScoreUpdate     2m10s   placementController  cluster1:0 cluster2:100 cluster3:200
  Normal  DecisionUpdate  3s      placementController  Decision demo-placement-decision-1 is updated with placement demo-placement in namespace default
  Normal  ScoreUpdate     3s      placementController  cluster1:200 cluster2:145 cluster3:189 cluster4:200

    注： 放置控制器分配一个分数，并为每个过滤的 ManagedCluster 生成事件。当集群分数更改时，放置控制器会生成新事件。

1.9.20. 对 Dell 硬件上的裸机主机发现失败的故障排除

如果在 Dell 硬件上发现裸机主机失败，则集成的 Dell Remote Access Controller (iDRAC)可能会被配置为不允许来自未知证书颁发机构的证书。

1.9.20.1. 症状：在 Dell 硬件中发现裸机主机失败

完成使用基板管理控制器发现裸机主机的步骤后，会显示类似如下的错误消息： 

ProvisioningError 51s metal3-baremetal-controller Image provisioning failed: Deploy step deploy.deploy failed with BadRequestError: HTTP POST https://<bmc_address>/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia returned code 400. Base.1.8.GeneralError: A general error has occurred. See ExtendedInfo for more information Extended information: [
{"Message": "Unable to mount remote share https://<ironic_address>/redfish/boot-<uuid>.iso.", 'MessageArgs': ["https://<ironic_address>/redfish/boot-<uuid>.iso"], "MessageArgs@odata.count": 1, "MessageId": "IDRAC.2.5.RAC0720", "RelatedProperties": ["#/Image"], "RelatedProperties@odata.count": 1, "Resolution": "Retry the operation.", "Severity": "Informational"}
]

1.9.20.2. 解决问题： 在 Dell 硬件中发现裸机主机的故障

iDRAC 配置为不接受来自未知证书颁发机构的证书。

要绕过这个问题，请完成以下步骤禁用主机 iDRAC 基板管理控制器上的证书验证：

  1. 在 iDRAC 控制台中，进入到 Configuration > Virtual media > Remote file share。
  2. 将 Expired 或无效证书操作的值更改为 Yes。

1.9.21. Minimal ISO 引导故障故障排除

当您尝试引导最小 ISO 时可能会遇到问题。

1.9.21.1. 症状：最小 ISO 引导失败

引导屏幕显示主机无法下载根文件系统镜像。

1.9.21.2. 解决问题： Minimal ISO 引导失败

请参阅 OpenShift Container Platform 文档中的辅助安装程序 故障排除最小 ISO 引导失败，以了解如何排除此问题。

1.9.22. Red Hat OpenShift Virtualization 上托管集群的故障排除

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

1.9.22.1. 症状： HostedCluster 资源处于部分状态

托管的 control plane 不会完全在线，因为 HostedCluster 资源待处理。

1.9.22.1.1. 鉴别问题： 检查先决条件、资源状况和节点和 operator 状态
  • 确保您满足 Red Hat OpenShift Virtualization 上托管集群的所有先决条件
  • 查看 HostedCluster 和 NodePool 资源中的条件，以了解防止进度的验证错误。

  • 通过使用托管的集群的 kubeconfig 文件，检查托管集群的状态：

    • 查看 oc get clusteroperators 命令的输出以查看哪些集群操作器待处理。
    • 查看 oc get nodes 命令的输出，以确保 worker 节点就绪。

1.9.22.2. 症状：没有 worker 节点被注册

托管的 control plane 不会完全在线，因为托管的 control plane 没有注册 worker 节点。

1.9.22.2.1. 鉴别问题： 检查托管 control plane 的各种部分的状态
  • 查看 HostedCluster 和 NodePool 条件，以了解问题可能是什么。

  • 输入以下命令查看 NodePool 资源的 KubeVirt worker 节点虚拟机(VM)状态： 

    oc get vm -n <namespace>

  • 如果虚拟机处于 provisioning 状态，请输入以下命令来查看 VM 命名空间中的 CDI 导入 pod，以了解 importer pod 尚未完成的原因： 

    oc get pods -n <namespace> | grep "import"

  • 如果虚拟机处于启动状态，请输入以下命令查看 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 配置，但虚拟机仍然没有注册为节点，请参阅 识别问题：访问 VM 控制台日志 以了解如何在启动时访问虚拟机控制台日志。

1.9.22.3. 症状： Worker 节点处于 NotReady 状态

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

1.9.22.3.1. 鉴别问题：检查节点对象和 pod

  • 输入以下命令查看节点对象中的条件，并确定节点未就绪的原因： 

    oc get nodes -o yaml

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

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

1.9.22.4. 症状：入口和控制台集群操作器不会上线

托管的 control plane 不会完全在线，因为 Ingress 和控制台集群 Operator 没有在线。

1.9.22.4.1. 鉴别问题： 检查通配符 DNS 路由和负载均衡器

  • 如果集群使用默认 Ingress 行为，请输入以下命令来确保在托管虚拟机(VM)的 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，请完成以下步骤：

    • 确保负载均衡器正确以 VM pod 为目标。
    • 确保通配符 DNS 条目以负载均衡器 IP 为目标。

1.9.22.5. 症状：托管集群的负载均衡器服务不可用

托管的 control plane 不会完全在线，因为负载均衡器服务不可用。

1.9.22.5.1. 鉴别问题： 检查事件、详情和 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

1.9.22.6. 症状： 托管集群 PVC 不可用

托管的 control plane 不会完全在线，因为托管集群的持久性卷声明(PVC)不可用。

1.9.22.6.1. 鉴别问题： 检查 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

1.9.22.7. 症状：虚拟机节点没有正确加入集群

托管的 control plane 不会完全在线，因为虚拟机节点没有正确加入集群。

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

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

1.9.22.8. 故障排除：将非裸机集群返回到后向绑定池

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

1.9.22.8.1. 症状：将非裸机集群返回到后向绑定池

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

1.9.22.8.2. 解决问题： 将非裸机集群返回到后向绑定池

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

  1. 删除集群信息。请参阅 从管理中删除集群 以了解更多信息。
  2. 清理根磁盘。
  3. 使用 Discovery ISO 手动重新引导。

1.9.22.9. 在带有托管 control plane 集群的 ROSA 上安装时，安装状态故障排除

当您在带有托管 control plane 集群的 Red Hat OpenShift Service on AWS (ROSA)上安装 Kubernetes Operator 时，多集群引擎 Operator 会停留在 Installing 步骤中，local-cluster 会一直处于 Unknown 状态。

1.9.22.9.1. 症状：在带有托管 control plane 集群的 ROSA 上安装时，安装状态会卡住

安装 multicluster engine operator 后，local-cluster 会一直处于 Unknown 状态 10 分钟。当您检查 hub 集群上的 open-cluster-management-agent 命名空间中的 klusterlet-agent pod 日志时，您会看到以下出错信息： 

E0809 18:45:29.450874       1 reflector.go:147] k8s.io/client-go@v0.29.4/tools/cache/reflector.go:229: Failed to watch *v1.CertificateSigningRequest: failed to list *v1.CertificateSigningRequest: Get "https://api.xxx.openshiftapps.com:443/apis/certificates.k8s.io/v1/certificatesigningrequests?limit=500&resourceVersion=0": tls: failed to verify certificate: x509: certificate signed by unknown authority
1.9.22.9.2. 解决问题： 在带有托管 control plane 集群的 ROSA 上安装时，安装会失败

要解决这个问题，请完成以下步骤，将 ISRG Root X1 证书添加到 klusterlet CA 捆绑包：

  1. 运行以下命令下载并编码 root CA 证书： 

    curl -s https://letsencrypt.org/certs/isrgrootx1.pem | base64 | tr -d "\n"

  2. 创建 KlusterletConfig 资源，并将编码的 CA 证书添加到 spec 参数部分。请参见以下示例： 

    apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: isrg-root-x1-ca
spec:
  hubKubeAPIServerCABundle: "<your_ca_certificate>"

  3. 通过在 hub 集群中运行以下命令来应用资源： 

    oc apply -f <filename>

  4. 通过在 hub 集群中运行以下命令来注解受管集群： 

    oc annotate --overwrite managedcluster local-cluster agent.open-cluster-management.io/klusterlet-config='isrg-root-x1-ca'

  5. 如果 local-cluster 状态在 1 分钟内没有恢复，请通过在 hub 集群中运行以下命令来导出并解码 import.yaml 文件： 

    oc get secret local-cluster-import -n local-cluster -o jsonpath={.data.import/.yaml} | base64 --decode > import.yaml

  6. 在 hub 集群中运行以下命令来应用该文件： 

    oc apply -f import.yaml
  7. 对于仅限新集群，在 ManagedCluster 资源中添加以下注解： 
annotations:
  agent.open-cluster-management.io/klusterlet-config: isrg-root-x1-ca

1.9.22.10. 在带有托管的 control plane 集群的 ROSA 上，所有受管集群的故障排除将变为 Unknown

在带有托管的 control plane 集群的 Red Hat OpenShift Service on AWS (ROSA)上，所有受管集群的状态都可以切换到 Unknown。

1.9.22.10.1. 症状：在带有托管的 control plane 集群的 ROSA 上，所有受管集群都变为 Unknown

ROSA 托管的集群的所有受管集群的状态都突然变为 Unknown。当您在受管集群中检查 open-cluster-management-agent 命名空间中的 klusterlet-agent pod 日志时，您会看到以下出错信息： 

E0809 18:45:29.450874       1 reflector.go:147] k8s.io/client-go@v0.29.4/tools/cache/reflector.go:229: Failed to watch *v1.CertificateSigningRequest: failed to list *v1.CertificateSigningRequest: Get "https://api.xxx.openshiftapps.com:443/apis/certificates.k8s.io/v1/certificatesigningrequests?limit=500&resourceVersion=0": tls: failed to verify certificate: x509: certificate signed by unknown authority
1.9.22.10.2. 解决问题： 所有受管集群在带有托管的 control plane 集群的 ROSA 上都变为 Unknown

要解决这个问题，请完成以下步骤，将 ISRG Root X1 证书添加到 klusterlet CA 捆绑包：

  1. 运行以下命令下载并编码 root CA 证书： 

    curl -s https://letsencrypt.org/certs/isrgrootx1.pem | base64 | tr -d "\n"

  2. 创建 KlusterletConfig 资源，并将编码的 CA 证书添加到 spec 参数部分。请参见以下示例： 

    apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: isrg-root-x1-ca
spec:
  hubKubeAPIServerCABundle: "<your_ca_certificate>"

  3. 通过在 hub 集群中运行以下命令来应用资源： 

    oc apply -f <filename>

  4. 通过在 hub 集群中运行以下命令来注解受管集群。根据需要替换值： 

    oc annotate --overwrite managedcluster <cluster_name> agent.open-cluster-management.io/klusterlet-config='isrg-root-x1-ca'

    有些受管集群的状态可能会恢复。

  5. 对于仍为 Unknown 的受管集群，请在 hub 集群中运行以下命令来从 hub 集群中导出并解码 import.yaml 文件。根据需要替换值： 

    oc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.import/.yaml} | base64 --decode > <cluster_name>-import.yaml

  6. 在受管集群中运行以下命令来应用该文件。根据需要替换值： 

    oc apply -f <cluster_name>-import.yaml
  7. 对于新的 Red Hat Advanced Cluster Management for Kubernetes hub 集群，请在 ManagedCluster 资源中添加以下注解： 
annotations:
  agent.open-cluster-management.io/klusterlet-config: isrg-root-x1-ca
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.