故障排除

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

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

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

卸载 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

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

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

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

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

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

试图导入 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|...

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

kubectl version

如果返回的数据列出了 1.11 或更早版本，请完成 解决问题：OpenShift Container Platform 版本 3.11 集群导入失败。

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

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

更新自定义 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

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

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

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

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

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

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

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

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

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

No subnets provided for zones

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

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

如需了解更多与创建集群相关的信息，请参阅创建集群。

来自 open-cluster-management 命令空间中的订阅控制器 pod multicluster-operators-hub-subscription-<random-characters> 的日志显示克隆 Git 仓库失败。您会看到一个 x509: certificate signed by unknown authority 错误，或 BadGateway 错误。

重要：如果您处于以前的版本中，请升级到 2.1 版本。

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

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

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

如果 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"

当 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 忽略。

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

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

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

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

如果在安装并创建 Observability CustomResosurceDefinition（CRD）后，可观察性功能的状态会一直处于 Installing 状态，则可能是因为没有为 spec:storageConfigObject:statefulSetStorageClass 参数定义值。或者，可观察性组件自动找到默认的 storageClass，但如果没有存储值，则组件会停留在 Installing 状态下。

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

storageclass.kubernetes.io/is-default-class: "true"

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

endpoint-observability-operator-x pod 会检查 prometheus-k8s 服务是否在 openshift-monitoring 命名空间中可用。如果这个服务没有出现在 openshift-monitoring 命名空间中，则不会部署 metrics-collector。您可能会收到以下出错信息：获取 prometheus 资源失败。

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

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

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

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

完成以下步骤：

导入受管集群后，可能会因为 metrics-collector-deployment-<pod_name> 的认证无效收到以下错误信息：

x509: certificate signed by unknown authority

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

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

如果 data-observability-observatorium-thanos-receive-default-<pod_name> pod 上挂载的持久性卷的存储已耗尽，则指标收集器无法将指标发送到 hub 集群。

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

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

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

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

HTTP 500

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