1.11. 故障排除

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

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

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

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

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

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

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

运行以下命令，将 < 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.14.0-rc.8

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

oc edit machines -n <hosted_cluster_namespace>

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

oc get agentmachine -n <hosted_cluster_namespace>

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

hcp destroy cluster agent --name <cluster_name>

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

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

#!/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 的命名空间的名称。确保指定正确的命名空间，因为命名空间会被清理和删除。

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

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

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

在 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

在 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

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

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

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

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

cluster_name=<your-managed-cluster-name>

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

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

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

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

export KUBECONFIG=kubeconfig.old

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

oc get ns

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

cluster_name=<managed_cluster_name>
kubeconfig_file=<path_to_kubeconfig>

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

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

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

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

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

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

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

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

运行以下命令，使用新的 kubeconfig 修补管理员 kubeconfig secret：

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

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

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

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

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

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

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

oc get infrastructure cluster -o yaml | grep apiServerURL

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

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

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

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

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

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

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

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

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

oc apply -f import.yaml

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

oc edit managedcluster <cluster-name>

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

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

kubectl get klusterlets klusterlet -oyaml

运行以下命令以生成保留在 <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。

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

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

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

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

oc delete ns <cluster-name>

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

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

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

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

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

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

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

您可以在 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 生成事件。当集群分数更改时，放置控制器会生成新事件。

运行以下命令来获取内部 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

运行以下命令应用 rhcos-boot-kubevirt.yaml 文件来创建 ImageDigestMirrorSet 对象：

oc apply -f rhcos-boot-kubevirt.yaml

将 spec.hubKubeAPIServerConfig.serverVerificationStrategy 设置为 UseSystemTruststore。请参见以下示例：

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerConfig:
    serverVerificationStrategy: UseSystemTruststore

通过在 hub 集群中运行以下命令来应用资源。将 <filename > 替换为您的文件的名称：

oc apply -f <filename>

有些受管集群的状态可能会恢复。继续处于 Unknown 状态的受管集群的过程。

通过在 hub 集群中运行以下命令来导出并解码 hub 集群中的 import.yaml 'file。将 '<cluster_name> 替换为集群的名称。

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

在受管集群中运行以下命令来应用该文件。

oc apply -f <cluster_name>-import.yaml