Menu Close

故障排除

Red Hat Advanced Cluster Management for Kubernetes 2.1

故障排除

摘要

Troubleshooting in Red Hat Advanced Cluster Management for Kubernetes

第 1 章 故障排除

在使用故障排除指南前,您可以运行 oc adm must-gather 命令来收集详情、日志并采取措施调试问题。

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

1.1. must-gather

首先,了解用户运行 must-gather 命令来调试问题的故障排除场景。

  • 场景一: 使用文档故障排除部分查看是否记录了问题的解决方案。这个指南按照产品的主要功能进行组织。

    在这种情况下,您可以参阅本指南来查看您的问题的解决方案是否在文档中。例如,在创建建集群时出现问题,您可能会在这个指南的 管理集群部分中找到解决方案。

  • 情况 2:如果您的问题没有记录及解决的步骤,请运行 must-gather 命令并使用输出调试问题。
  • 情况 3:如果您无法使用 must-gather 命令的输出来解决这个问题,请与红帽支持共享您的输出。

请参阅以下步骤以使用 must-gather 命令启动:

要进行故障排除,请了解用户运行 must-gather 命令调试问题的故障排除场景,然后查看使用该命令的步骤。

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

  1. 了解 must-gather 命令并在 Red Hat OpenShift Container Platform 中安装所需的先决条件:收集数据
  2. 登录到您的集群。对于通常的用例,您应该在登录到 hub 集群时运行 must-gather

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

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

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

  3. 添加用于收集数据和目录的 Red Hat Advanced Cluster Management for Kubernetes 镜像。运行以下命令,在其中提供您要插入的镜像和输出目录:

    oc adm must-gather --image=registry.redhat.io/rhacm2/acm-must-gather-rhel8:v2.1.0 --dest-dir=<directory>
  4. 进入您指定的目录查看输出。输出以以下级别进行组织:

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

1.2. 在断开连接的环境中运行 must-gather

完成以下步骤以在断开连接的环境中运行 must-gather 命令:

  1. 在断开连接的环境中,将 RedHat operator 目录镜像镜像(mirror)到其 mirror registry 中。如需更多信息,请参阅在断开连接的网络中安装
  2. 运行以下命令以提取日志,从其 mirror registry 中引用镜像:
REGISTRY=registry.example.com:5000
IMAGE=$REGISTRY/rhacm2/acm-must-gather-rhel8@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8
oc adm must-gather --image=$IMAGE --dest-dir=./data

1.3. 记录的故障排除

查看与 Red Hat Advanced Cluster Management for Kubernetes 故障排除相关的主题:

安装

与原始安装相关的任务,请查看安装

集群管理

与原始集群管理相关的任务,请查看管理集群

应用程序管理

与原始应用程序管理相关的任务,查看 管理应用程序

监管和风险

要获得原始的安全指南,请参阅 安全性

控制台可观察性

控制台观察功能包括搜索和 Visual Web Terminal,以及标头和导航功能。与原始的观察相关的问题,参阅控制台中的可观察性

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

在重新安装 Red Hat Advanced Cluster Management for Kubernetes 时,pod 没有启动。

1.4.1. 症状:重新安装失败

在安装 Advanced Cluster Management 后,如果 pod 没有启动,这很可能是因为以前已安装了 Red Hat Advanced Cluster Management,在您进行最新安装时以前安装的一些组件没有被删除。

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

1.4.2. 解决问题: 重新安装失败

如果您有这个问题,请完成以下步骤:

  1. 根据卸载中介绍的步骤,执行卸载过程来删除当前的组件。
  2. 按照安装 Helm 中的内容,安装 Helm CLI 二进制版本 3.2.0 或更新版本。
  3. 确保将 Red Hat OpenShift Container Platform CLI 配置为运行 oc 命令。如需有关如何配置 oc 命令的更多信息,请参阅 OpenShift Container Platform 文档中的使用 CLI
  4. 将以下脚本复制到一个文件中:

    #!/bin/bash
    ACM_NAMESPACE=<namespace>
    oc delete mch --all -n $ACM_NAMESPACE
    helm ls --namespace $ACM_NAMESPACE | cut -f 1 | tail -n +2 | xargs -n 1 helm delete --namespace $ACM_NAMESPACE
    oc delete apiservice v1beta1.webhook.certmanager.k8s.io v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io
    oc delete clusterimageset --all
    oc delete configmap -n $ACM_NAMESPACE cert-manager-controller cert-manager-cainjector-leader-election cert-manager-cainjector-leader-election-core
    oc delete consolelink acm-console-link
    oc delete crd klusterletaddonconfigs.agent.open-cluster-management.io placementbindings.policy.open-cluster-management.io policies.policy.open-cluster-management.io userpreferences.console.open-cluster-management.io searchservices.search.acm.com
    oc delete mutatingwebhookconfiguration cert-manager-webhook cert-manager-webhook-v1alpha1
    oc delete oauthclient multicloudingress
    oc delete rolebinding -n kube-system cert-manager-webhook-webhook-authentication-reader
    oc delete scc kui-proxy-scc
    oc delete validatingwebhookconfiguration cert-manager-webhook cert-manager-webhook-v1alpha1

    将脚本中的 <namespace> 替换为安装 Red Hat Advanced Cluster Management 的命名空间的名称。确保指定正确的命名空间,因为命名空间会被清理和删除。

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

1.5. 因为资源存在而导致卸载失败的故障排除

1.5.1. 症状:因为存在资源而导致卸载失败

卸载 Red Hat Advanced Cluster Management for Kubernetes 时,安装失败并显示以下错误信息之一:

Cannot delete MultiClusterHub resource because ManagedCluster resource(s) exist
Cannot delete MultiClusterHub resource because BareMetalAssets resource(s) exist
Cannot delete MultiClusterHub resource because MultiClusterObservability resource(s) exist

1.5.2. 解决问题:因为资源存在而导致卸载失败

当您卸载 Red Hat Advanced Cluster Management for Kubernetes hub 集群时,这些错误会在仍然管理集群、托管裸机资产或收集可观察数据时发生。在卸载 hub 集群前,必须删除所有这些资源。

  • 要解决 ManagedCluster 错误消息,先分离仍由 hub 集群管理的所有集群,并尝试再次卸载。

有关分离集群的更多信息,请参阅从管理部分删除集群,在 创建集群中选择与您的供应商相关的信息。

  • 要解决 BareMetalAssets 资源错误消息,请从 hub 集群中删除所有裸机资产,并尝试再次卸载。

有关删除裸机资产的更多信息,请参阅 删除裸机资产

  • 要解决 MultiClusterObservability 资源错误,从 hub 集群中删除所有 MultiClusterObservability 资源,并尝试再次卸载。

1.6. 离线集群的故障排除

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

1.6.1. 症状:集群状态为离线

完成创建集群的步骤后,您无法从 Red Hat Advanced Cluster Management 控制台访问它,它的状态为 offline

1.6.2. 解决问题: 集群状态为离线

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

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

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

    1. 在 hub 集群中运行 oc get managedcluster <cluster_name> -o yaml 命令。使用集群名称替换 <cluster_name>
    2. 找到 status.conditions 部分。
    3. 检查 type: ManagedClusterConditionAvailable 的信息并解决所有问题。

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

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

1.7.1. 症状:集群处于待处理导入状态

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

1.7.2. 鉴别问题: 集群处于待处理导入状态

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

    kubectl get pod -n open-cluster-management-agent | grep klusterlet-registration-agent
  2. 在受管集群中运行以下命令查找错误的日志条目:

    kubectl logs <registration_agent_pod>

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

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

1.7.3. 解决问题: 集群处于待处理导入状态

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

    oc get infrastructure cluster -o yaml | grep apiServerURL
  2. 确保来自受管集群的主机名可以被解析,并确保建立到主机和端口的出站连接。

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

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

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

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

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

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

1.8.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.8.1.3. 解决问题: 管理的集群创建失败,并显示证书 IP SAN 错误

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

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

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

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

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

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

Error: error setting up new vSphere SOAP client: Post https://vspherehost.com/sdk: x509: certificate signed by unknown authority"

1.8.2.3. 解决问题: 管理的集群创建失败并显示未知证书颁发机构

确保您在创建供应商连接时从证书认证机构输入了正确的证书。

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

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

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

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

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

x509: certificate has expired or is not yet valid

1.8.3.3. 解决问题: 管理的集群创建失败并显示过期的证书

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

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

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

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

1.8.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.8.4.3. 解决问题: 管理的集群创建没有足够权限进行标记

确保 VMware vCenter 所需的帐户权限正确。如需更多信息,请参阅删除的镜像 registry

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

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

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

1.8.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.8.5.3. 解决问题: 受管集群创建失败并显示无效的 dnsVIP

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

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

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

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

1.8.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.8.6.3. 解决问题: 受管集群创建失败并显示不正确的网络类型

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

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

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

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

1.8.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.8.7.3. 解决问题:因为错误处理磁盘更改导致 VMware vSphere 受管集群失败

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

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

1.9.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.2. 鉴别问题: OpenShift Container Platform 版本 3.11 集群导入失败

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

kubectl version

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

1.9.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.10. 证书更改后导入的集群离线故障排除

支持安装自定义 apiserver 证书,但在更改证书信息前导入的一个或多个集群可以具有 offline 状态。

1.10.1. 症状:证书更改后集群处于离线状态

完成更新证书 secret 的步骤后,在线的一个或多个集群现在会在 Red Hat Advanced Cluster Management for Kubernetes 控制台中显示 offline 状态。

1.10.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.10.3. 解决问题: 证书更改后集群处于离线状态

要在更新证书信息后手动恢复集群,请为每个受管集群完成以下步骤:

  1. 再次手动导入集群。从 Red Hat Advanced Cluster Management 创建的 Red Hat OpenShift Container Platform 集群将每 2 小时重新同步,以便可以为这些集群跳过这一步。

    1. 在 hub 集群中,输入以下命令显示导入命令:

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

      CLUSTER_NAME 替换为您要导入的受管集群的名称。

    2. 在受管集群中应用 import.yaml 文件:

      oc apply -f import.yaml

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

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

1.11.1. 症状:删除集群后命名空间被保留

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

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

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

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

    oc api-resources --verbs=list --namespaced -o name | grep -E '^secrets|^serviceaccounts|^managedclusteraddons|^roles|^rolebindings|^manifestworks|^leases|^managedclusterinfo|^appliedmanifestworks' | 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 终结器。
  5. 输入 :wq 命令保存列表并退出 vi 编辑器。
  6. 输入以下命令来删除命名空间:

    oc delete ns <cluster-name>

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

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

受管集群的状态在 offlineavailable 间交替,无需手动更改环境或集群。

1.12.1. 症状:集群状态从离线变为可用

当将受管集群连接到 hub 集群的网络不稳定时,hub 集群报告的受管集群的状态会在 offlineavailable 之间循环。

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

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

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

    oc edit managedcluster <cluster-name>

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

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

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

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

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

在使用 Red Hat Advanced Cluster Management 控制台创建一个新集群后,在控制台中集群会一直显示PendingFailed 状态。

1.13.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.MessageStatus.Conditions.Reason 条目中存在有关此问题的额外信息。

1.13.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.14. 应用程序 Git 服务器连接故障排除

来自 open-cluster-management 命名空间的日志显示克隆 Git 存储库失败。

1.14.1. 症状:Git 服务器连接

open-cluster-management 命名空间中的订阅控制器 pod multicluster-operators-hub-subscription-<random-characters> 的日志表示克隆 Git 存储库失败。您收到 x509: certificate signed by unknown authority 错误或 BadGateway 错误。

1.14.2. 解决问题:Git 服务器连接

重要: 如果您使用以前的版本,升级到产品 2.1。

  1. apps.open-cluster-management.io_channels_crd.yaml 保存为名为 apps.open-cluster-management.io_channels_crd.yaml 的文件。
  2. 在 Advanced Cluster Management 集群中,运行以下命令以应用该文件:

    oc apply -f apps.open-cluster-management.io_channels_crd.yaml
  3. open-cluster-management 命名空间中,编辑 advanced-cluster-management.v2.1.0 CSV,运行以下命令并编辑:

    oc edit csv advanced-cluster-management.v2.1.0 -n open-cluster-management

    查找以下容器:

    • multicluster-operators-standalone-subscription
    • multicluster-operators-hub-subscription

      使用以下内容替换容器镜像:

      quay.io/open-cluster-management/multicluster-operators-subscription:2.2-PR337-91af6cb37d427d22160b2c055589a4418dada4eb

    更新会在 open-cluster-management 命名空间中重新创建以下 pod:

    • multicluster-operators-standalone-subscription-<random-characters>
    • multicluster-operators-hub-subscription-<random-characters>
  4. 检查新 pod 是否使用新 docker 镜像运行。运行以下命令,然后查找新 docker 镜像:
oc get pod multicluster-operators-standalone-subscription-<random-characters> -n open-cluster-management -o yaml
oc get pod multicluster-operators-hub-subscription-<random-characters> -n open-cluster-management -o yaml
  1. 更新受管集群上的镜像。

    在 hub 集群中,使用实际的受管集群名称替换 CLUSTER_NAME 来运行以下命令:

    oc annotate klusterletaddonconfig -n CLUSTER_NAME CLUSTER_NAME klusterletaddonconfig-pause=true --overwrite=true
  2. 运行以下命令,将 CLUSTER_NAME 替换为实际受管集群名称:

    oc edit manifestwork -n CLUSTER_NAME  CLUSTER_NAME-klusterlet-addon-appmgr
  3. 找到 spec.global.imageOverrides.multicluster_operators_subscription 并将值设置为:

    quay.io/open-cluster-management/multicluster-operators-subscription:2.2-PR337-91af6cb37d427d22160b2c055589a4418dada4eb

    这会在受管集群的 open-cluster-management-agent-addon 命名空间中重新创建 klusterlet-addon-appmgr-<random-characters> pod。

  4. 检查新 pod 是否使用新 docker 镜像运行。
  5. 当您通过控制台或 CLI 创建应用程序时,手动在频道 spec 中添加 'insecureSkipVerify: true'。请参见以下示例:

    apiVersion: apps.open-cluster-management.io/v1
    ind: Channel
    metadata:
    labels:
      name: sample-channel
      namespace: sample
    spec:
      type: GitHub
      pathname: <Git URL>
      insecureSkipVerify: true

1.15. 未使用放置规则选择本地集群的故障排除

受管集群使用放置规则选择,但不会选择 local-cluster (也被管理的 hubb 集群)。放置规则用户没有在 local-cluster 命名空间中创建可部署资源的权限。

1.15.1. 症状:未选择对本地集群进行故障排除

所有受管集群都使用放置规则选择,但 local-cluster 不是。放置规则用户没有在 local-cluster 命名空间中创建可部署资源的权限。

1.15.2. 解决问题: 未选择对本地集群进行故障排除

要解决这个问题,您需要在 local-cluster 命名空间中授予可部署资源的管理权限。完成以下步骤:

  1. 确认受管集群列表包含 local-cluster,放置规则 decisions 列表没有显示本地集群。运行以下命令并查看结果:

    % oc get managedclusters
    NAME            HUB ACCEPTED   MANAGED CLUSTER URLS   JOINED   AVAILABLE   AGE
    local-cluster   true                                  True     True        56d
    cluster1        true                                  True     True        16h
    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: all-ready-clusters
      namespace: default
    spec:
      clusterSelector: {}
    status:
      decisions:
      - clusterName: cluster1
        clusterNamespace: cluster1
  2. .yaml 文件中创建一个 Role,授予 local-cluster 命名空间中的可部署管理权限。请参见以下示例:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: deployables-admin-user-zisis
      namespace: local-cluster
    rules:
    - apiGroups:
      - apps.open-cluster-management.io
      resources:
      - deployables
      verbs:
      - '*'
  3. 创建 RoleBinding 资源,授予放置规则用户对 local-cluster 命名空间的访问权限。请参见以下示例:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: deployables-admin-user-zisis
      namespace: local-cluster
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: deployables-admin-user-zisis
      namespace: local-cluster
    subjects:
    - kind: User
      name: zisis
      apiGroup: rbac.authorization.k8s.io

1.16. 对应用程序 Kubernetes 部署版本进行故障排除

可能不支持带有已弃用 Kubernetes apiVersion 的受管集群。有关已弃用 API 版本的详情,请参阅 Kubernetes 问题

1.16.1. 症状: 应用程序部署版本

如果 Subscription YAML 文件中的一个或多个应用程序资源使用弃用的 API,您可能会收到与以下类似的错误信息:

failed to install release: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for
kind "Deployment" in version "extensions/v1beta1"

或者,在名为 old.yaml 的 YAML 文件中使用新的 Kubernetes API 版本时,您可能会收到以下错误:

error: unable to recognize "old.yaml": no matches for kind "Deployment" in version "deployment/v1beta1"

1.16.2. 解决: 应用程序部署版本

  1. 更新资源中的 apiVersion。例如,如果订阅 YAML 文件中显示 Deployment kind 的错误,您需要将 apiVersionextensions/v1beta1 更新至 apps/v1

    请参见以下示例:

    apiVersion: apps/v1
    kind: Deployment
  2. 在受管集群中运行以下命令来验证可用版本:

    kubectl explain <resource>
  3. 检查 VERSION

1.17. 独立订阅内存故障排除

因为内存问题,multicluster-operators-standalone-subscription pod 会定期重启。

1.17.1. 症状:独立订阅内存

当 Operator Lifecycle Manager(OLM)部署所有 operator 而不仅仅是 multicluster-subscription-operator 时,multicluster-operators-standalone-subscription pod 会重启,因为没有足够的内存分配给独立订阅容器。

在多集群订阅社区 operator CSV 中,multicluster-operators-standalone-subscription pod 的内存限制增加到 2GB,但 OLM 会忽略此资源限制设置。

1.17.2. 解决问题:独立订阅内存

  1. 安装后,找到订阅 multicluster subscription community operator 的 operator 订阅 CR。运行以下命令:

    % oc get sub -n open-cluster-management acm-operator-subscription
  2. 通过附加 spec.config.resources 文件来编辑 operator 订阅自定义资源,以定义资源限制。.yaml

    注: 不要创建新的、订阅了同一个多集群订阅社区 operator 的订阅自定义资源。因为两个 operator 订阅都链接到一个 operator,operator Pod 会被 "killed" 并由两个 operator 订阅自定义资源重启。

    请参阅以下更新的 .yaml 文件示例:

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: multicluster-operators-subscription-alpha-community-operators-openshift-marketplace
      namespace: open-cluster-management
    spec:
      channel: release-2.1
      config:
        resources:
          limits:
            cpu: 750m
            memory: 2Gi
          requests:
            cpu: 150m
            memory: 128Mi
      installPlanApproval: Automatic
      name: multicluster-operators-subscription
      source: community-operators
      sourceNamespace: openshift-marketplace
  3. 保存资源后,确保独立订阅 Pod 被重启为有 2GB 内存限制。运行以下命令:

    % oc get pods -n open-cluster-management multicluster-operators-standalone-subscription-7c8cbf885f-c94kz -o yaml
    apiVersion: v1
    kind: Pod
    ...
    spec:
      containers:
      - image: quay.io/open-cluster-management/multicluster-operators-subscription:community-2.1
    ...
        resources:
          limits:
            cpu: 750m
            memory: 2Gi
          requests:
            cpu: 150m
            memory: 128Mi
    ...
    status:
      qosClass: Burstable

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

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

1.18.1. 症状:Klusterlet 处于降级状况

在受管集群中部署 Klusterlet 后,KlusterletRegistrationDegradedKlusterletWorkDegraded 条件会显示 True 状态。

1.18.2. 鉴别问题: Klusterlet 处于降级状况

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

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

1.18.3. 解决问题: Klusterlet 处于降级状况

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

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

1.19. 受管集群中的 Klusterlet 应用程序管理器故障排除

当您从 Red Hat Advanced Cluster Management for Kubernetes 升级时,Red Hat OpenShift Container Platform 受管集群版本 4.5 和 4.6 上的 klusterlet-addon-appmgr pod 是 OOMKilled

1.19.1. 症状:受管集群中的 Klusterlet 应用程序管理器

您在 Red Hat OpenShift Container Platform 受管集群版本 4.5 和 4.6: OOMKilled 上收到 klusterlet-addon-appmgr pod 的错误。

1.19.2. 解决问题: 受管集群中的 Klusterlet 应用程序管理器

对于 Red Hat Advanced Cluster Management for Kubernetes 2.1.x,您需要手动将 pod 的内存限值增加到 8Gb。请参见以下步骤:

  1. 在 hub 集群中,注解 klusterletaddonconfig 来暂停复制。使用以下命令:

    oc annotate klusterletaddonconfig -n ${CLUSTER_NAME} ${CLUSTER_NAME} klusterletaddonconfig-pause=true --  overwrite=true
  2. 在 hub 集群中,缩减 klusterlet-addon-operator。使用以下命令:

    oc edit manifestwork ${CLUSTER_NAME}-klusterlet-addon-operator -n ${CLUSTER_NAME}
  3. 找到 klusterlet-addon-operator 部署并在 spec 中添加 replicas: 0 来缩减。

    - apiVersion: apps/v1
      kind: Deployment
      metadata:
        labels:
          app: cluster1
        name: klusterlet-addon-operator
        namespace: open-cluster-management-agent-addon
        spec:
          replicas: 0

    在受管集群中,open-cluster-management-agent-addon/klusterlet-addon-operator pod 将被终止。

  4. 登录到受管集群,手动增加 appmgr pod 中的内存限值。

    运行以下命令:

    % oc edit deployments -n open-cluster-management-agent-addon klusterlet-addon-appmgr

    例如,如果限制为 5G,将限制增加到 8G。

    resources:
      limits:
        memory: 2Gi  -> 8Gi
      requests:
        memory: 128Mi -> 256Mi

1.20. 对可观察性功能进行故障排除

安装可观察组件后,该组件可能会卡住,并显示 Installing 状态。

1.20.1. 症状: MultiClusterObservability 资源处于没有就绪的状态

如果在安装并创建 Observability CustomResosurceDefinition(CRD)后,可观察性(observability)状态会处于 Installing 状态,则可能无法为 spec:storageConfigObject:statefulSetStorageClass 参数定义值。另外,可观察性组件会自动找到默认的 storageClass,但如果没有存储值,则组件会卡住 Installing 状态。

1.20.2. 解决这个问题: MultiClusterObservability 资源处于没有就绪的状态

如果您有这个问题,请完成以下步骤:

  1. 验证是否安装了 observaility 组件:

    1. 要验证 multicluster-observability-operator,请运行以下命令:

      kubectl get pods -n open-cluster-management|grep observability
    2. 要验证是否存在正确的 CRD,请运行以下命令:

      kubectl get crd|grep observ

      在启用组件前,必须显示以下 CRD:

      multiclusterobservabilities.observability.open-cluster-management.io
      observabilityaddons.observability.open-cluster-management.io
      observatoria.core.observatorium.io
  2. 如果您为裸机集群创建自己的 storageClass,请参阅 如何在集群中或从集群中创建 NFS 置备程序。
  3. 为确保可观察性组件可以找到默认的 storageClass,更新 multicluster-observability-operator CRD 中的 storageClass 参数。您的参数可能类似以下值:
storageclass.kubernetes.io/is-default-class: "true"

安装完成后,可观察组件状态会被更新为 Ready 状态。如果安装无法完成,则会显示 Fail 状态。

1.21. OpenShift 监控服务故障排除

受管集群中的 Observability 服务需要从 OpenShift Container Platform 监控堆栈中提取指标数据。如果 OpenShift Container Platform 监控堆栈未就绪,则不会安装 metrics-collector

1.21.1. 症状:OpenShift 监控服务未就绪

endpoint-observability-operator-x pod 检查 prometheus-k8s 服务在 openshift-monitoring 命名空间中是否可用。如果 openshift-monitoring 命名空间中不存在该服务,则 metrics-collector 不会被部署。您可能会收到以下出错信息: Failed to get prometheus resource

1.21.2. 解决问题: OpenShift 监控服务未就绪

如果您有这个问题,请完成以下步骤:

  1. 登录您的 OpenShift Container Platform 集群。
  2. 访问 openshift-monitoring 命名空间,以验证 prometheus-k8s 服务是否可用。
  3. 重启受管集群 open-cluster-management-addon-observability 命名空间中的 endpoint-observability-operator-x pod。

1.22. 在 managedcluster 资源中不正确的标签值

当您导入受管集群时,默认会安装可观察组件。您的放置规则可能类似以下信息:

status:
  decisions:
  - clusterName: sample-managed-cluster
    clusterNamespace: sample-managed-cluster

如果放置规则中没有包括受管集群,则不会安装可观察性组件。

1.22.1. 症状: managedcluster 资源中有不正确的标签值

如果发现导入的集群没有被包括,则可能会禁用受管集群资源的可观察性服务。

请记住 :当启用该服务时,vendor:OpenShift 标签被添加来代表目标受管集群。只有在 OpenShift Container Platform 受管集群中才支持可观察性服务。

1.22.2. 解决问题: managedcluster 资源中有不正确的标签值

如果您有这个问题,请为目标受管集群启用可观察性服务,并在 managedcluster 资源中更新标签。

完成以下步骤:

  1. 登录您的 Red Hat Advanced Cluster Management 集群。
  2. 通过更新放置规则,将 observability 参数值改为 enabled。运行以下命令:

    oc edit placementrule -n open-cluster-management-observability
  3. 运行以下命令来验证 OpenShift 是否已被列为目标受管集群的厂商:

    oc get managedcluster <CLUSTER NAME> -o yaml

    metadata.labels.vendor 参数值更新为 OpenShift

1.23. 对 metrics-collector 进行故障排除

指标收集器可能无法将指标推送到 {product-short} hub 集群

1.23.1. 症状 1:认证无效

导入受管集群后,可能会因为 metrics-collector-deployment-<pod_name> 认证无效而收到以下出错信息:

x509: certificate signed by unknown authority

如果在 metrics-collector-deployment-<pod_name> pod 重启后删除或重新创建了 observability-managed-cluster-certs secret,则可能会收到错误。证书没有在 secret 中更新。

1.23.2. 解决问题: 认证无效

如果您有这个问题,请完成以下步骤:

  1. 登录到您的 {product-short} hub 集群。
  2. 重启 multicluster-observability-operator-<pod_name> pod。
  3. 访问 open-cluster-management-addon-observability 命名空间,并在您的受管集群中重启 metrics-collector-deployment-<pod_name> pod。

1.23.3. 症状 2:挂载的持久性卷中的存储被耗尽

如果 data-observability-observatorium-thanos-receive-default-<pod_name> pod 中挂载的持久性卷的存储达到容量,指标收集器将无法将指标发送到 hub 集群。

您可能会在 metrics-collector-deployment-<your_pod_name> pod 的日志中收到以下错误消息: no space left on device

1.23.4. 解决问题: 挂载的持久性卷中的存储被耗尽

如果您有这个问题,请完成以下步骤:

  1. 登录到您的 OpenShift Container Platform 受管集群。
  2. 访问 data-observability-observatorium-thanos-receive-default-<pod_name> pod 并增加持久性卷声明。
  3. 重启 open-cluster-management-observability 命名空间中的 data-observability-observatorium-thanos-receive-default-<pod_name> pod。

1.24. Grafana 仪表板中的当前数据会消失

Red Hat Advanced Cluster Management 控制台中的 Grafana 仪表板中的当前数据会消失。

1.24.1. 症状 1:当前数据在 Grafana 仪表板中消失

Red Hat Advanced Cluster Management 集群概述仪表板中的数据为空,但历史数据仍可用。

1.24.2. 症状 2:在编辑 statefulSetSize 后 PVC 不会改变

另外,在受管集群中,您可能会在日志中收到在 open-cluster-management-addon-observability 命名空间中运行的任何 metrics-collector-deployment-x pod 的信息。您可能会收到以下出错信息,以及磁盘完全被占用的信息:

HTTP 500

1.24.3. 解决问题:扩展 PVC 大小

如果您有这个问题,请完成以下步骤:

  1. 运行查询确认磁盘空间已满。

    1. 登录到 Red Hat OpenShift Container Platform 控制台。
    2. 在导航菜单中点 MonitoringMetrics
    3. Expression 窗口中输入以下查询,并将查询按 Volume 列进行排序:

      kubelet_volume_stats_available_bytes{namespace="open-cluster-management-observability"}/kubelet_volume_stats_capacity_bytes{namespace="open-cluster-management-observability"}

      注意: 如果这个值是 0,则代表磁盘已满。如果磁盘已满,继续执行以下任务。

  2. 扩展 data-observability-observatorium-thanos-receive-default-x PVC,将 storage 参数更新为大于 MultiClusterObservability(mco)CR 的 statefulSetSize 值。对每个 data-observability-observatorium-thanos-receive-default-x PVC 运行以下命令:

    kubectl get pvc data-observability-observatorium-thanos-receive-default-0 -o yaml

    您的 data-observability-observatorium-thanos-receive-default-x PVC 可能类似以下内容:

    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage:

    这可能需要一些时间才能工作。当 storagestatus 匹配时,您的更改将生效。运行上一个命令进行检查。

  3. 通过完成以下步骤验证修复:

    1. 登录您的 Red Hat Advanced Cluster Management 控制台。
    2. 在导航菜单中选择 Observe environments > Overview
    3. 点击位于控制台标头旁的 Grafana 链接,从您的受管集群中查看指标。
    4. 检查 metrics-collector-deployment-x pod 日志。当在日志中修复错误时,会出现以下信息: Metrics pushed successfully
    5. 通过从 Red Hat OpenShift Container Platform 控制台运行查询来确认磁盘空间没有满。在 Expression 窗口中输入以下查询,并将查询按 Volume 列进行排序:

      kubelet_volume_stats_available_bytes{namespace="open-cluster-management-observability"}/kubelet_volume_stats_capacity_bytes{namespace="open-cluster-management-observability"}