故障排除

Red Hat Advanced Cluster Management for Kubernetes 2.1

故障排除

摘要

对 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,以及标头和导航功能。要查看原始的可观察指南,使用控制台中的 Observability

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. conditionss 部分。
    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. 症状:受管集群创建失败并显示证书 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. 鉴别问题:受管集群创建失败并显示未知证书颁发机构

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

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. 鉴别问题:受管集群创建失败且没有标记权限

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

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. 鉴别问题:受管集群创建失败并显示无效的 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 finalizer。
  5. 输入 :wq 命令保存列表并退出 vi 编辑器。
  6. 输入以下命令来删除命名空间:

    oc delete ns <cluster-name>

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

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

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

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

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

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"

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

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

1.16.2. 解决这个问题:应用程序部署版本

  1. 更新资源中的 apiVersion。例如,如果 subscription 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 会重启,因为没有为独立订阅容器分配足够内存。

multicluster-operators-standalone-subscription pod 的内存限值在 multicluster subscription community operator CSV 中增加到 2GB,但此资源限制设置会被 OLM 忽略。

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

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

    % oc get sub -n open-cluster-management acm-operator-subscription
  2. 编辑 operator 订阅自定义资源,添加 spec.config.resources.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,KubeConfigMissing,HubConfigSecretError, 或 HubConfigSecretUnauthorized,从 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 中收到 klusterlet-addon-appmgr pod 的错误:OOMKilled

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 部署并添加 replicas:0 到 spec 以缩减。

    - 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)后,可观察性功能的状态会一直处于 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。您可能会收到以下出错信息:获取 prometheus 资源失败

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,并增加持久性卷声明(PVC)。
  3. open-cluster-management-observability 命名空间中重启 data-observability-observatorium-thanos-receive-default-<pod_name>

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 日志。当错误在日志中修复时,会出现以下信息:指标已成功推送
    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"}