故障排除
查找 Red Hat Advanced Cluster Management 的故障排除信息。
摘要
第 1 章 故障排除 复制链接链接已复制到粘贴板!
查看 Red Hat Advanced Cluster Management 组件的故障排除主题。在使用故障排除指南前,您可以运行 must-gather 命令来收集详情、日志并采取调试问题的步骤。
有关 must-gather 信息,请查看以下部分:
另外,查看您基于角色的访问。详情请参阅 基于角色的访问控制。
1.1. 记录的故障排除 复制链接链接已复制到粘贴板!
查看与 Red Hat Advanced Cluster Management for Kubernetes 故障排除相关的主题:
安装
要查看安装任务的主要文档,请参阅安装和升级。
备份和恢复
要查看备份和恢复的主要文档,请参阅备份和恢复。
集群管理
要查看有关管理集群的主要文档,请参阅 multicluster engine operator 集群生命周期概述。
- 离线集群的故障排除
- 受管集群导入失败的故障排除
- 对带有待处理导入状态的集群进行故障排除
- 证书更改后导入的集群离线故障排除
- 集群状态从离线变为可用的故障排除
- VMware vSphere 上创建集群的故障排除
- 集群在控制台中带有待处理或失败状态的故障排除
- 带有降级条件的 Klusterlet 故障排除
- Object storage 频道 secret 故障排除
- 删除集群后命名空间会保留
- 导入集群时出现自动 Auto-import-secret-exists 错误
- 对 VolSync 的 cinder Container Storage Interface (CSI)驱动程序进行故障排除
- 集群 Curator 自动模板无法部署故障排除
多集群全局 hub
要查看有关多集群全局 hub 的主要文档,请参阅 多集群全局 hub。
应用程序管理
要查看有关应用程序管理的主要文档,请参阅管理应用程序。
监管
控制台可观察性
控制台观察功能包括 搜索,以及标头和导航功能。要查看 Observability 指南,请参阅 控制台中的 Observability。
Submariner 网络和服务发现
本节列出了在 Red Hat Advanced Cluster Management 或 multicluster engine operator 中使用 Submariner 故障排除步骤。有关常规 Submariner 故障排除信息,请参阅 Submariner 文档中的故障排除部分。
要查看 Submariner 网络服务和服务发现的主要文档,请参阅 Submariner multicluster networking 和 service discovery。
要进行故障排除,参阅可以使用 must-gather 命令进行调试的用户情景信息,然后使用这个命令进行故障排除。
需要的访问权限:集群管理员
1.2.1. must-gather 情境 复制链接链接已复制到粘贴板!
场景一: 如果您的问题已被记录,使用 已记录的故障排除文档部分进行解决。这个指南按照产品的主要功能进行组织。
在这种情况下,您可以参阅本指南来查看您的问题的解决方案是否在文档中。例如,在创建建集群时出现问题,您可能会在这个指南的 管理集群部分中找到解决方案。
-
情况 2:如果这个指南中没有与您的问题相关的内容,运行
must-gather命令并使用输出来调试问题。 -
情况 3:无法使用
must-gather命令的输出结果无法帮助解决您的问题,请向红帽支持提供您的输出。
1.2.2. must-gather 过程 复制链接链接已复制到粘贴板!
请参阅以下流程来使用 must-gather 命令:
-
了解
must-gather命令以及按照 Red Hat OpenShift Container Platform 文档中的 收集集群数据 所需的先决条件。 登录到您的集群。添加用于收集数据和目录的 Red Hat Advanced Cluster Management for Kubernetes 镜像。运行以下命令,在其中提供您要插入的镜像和输出目录:
oc adm must-gather --image=registry.redhat.io/rhacm2/acm-must-gather-rhel9:v2.13 --dest-dir=<directory>对于通常的用例,在登录到您的 hub 集群时运行
must-gather命令。注: 如果要检查受管集群,找到位于
cluster-scoped-resources目录中的gather-managed.log文件:<your-directory>/cluster-scoped-resources/gather-managed.log>检查 JOINED 和 AVAILABLE 栏没有被设置为
True的受管集群。您可以在这些没有以True状态连接的集群中运行must-gather命令。进入您指定的目录查看输出。输出以以下级别进行组织:
-
两个对等级别:
cluster-scoped-resources和namespace资源。 - 每个对等级别下的子类:用于 cluster-scope 和 namespace-scoped 资源的自定义资源定义的 API 组。
-
每个子类的下一级: 按
kind进行排序的 YAML 文件。
-
两个对等级别:
1.2.3. 在断开连接的环境中的 must-gather 复制链接链接已复制到粘贴板!
在断开连接的环境中,按照以下步骤运行 must-gather 命令:
- 在断开连接的环境中,将 RedHat operator 目录镜像镜像(mirror)到其 mirror registry 中。如需更多信息,请参阅 在断开连接的网络环境中安装。
运行以下命令收集所有信息,将 <
2.x> 替换为 <acm-must-gather> 支持的版本,如2.13和 <multicluster-engine/must-gather>,如2.8。REGISTRY=<internal.repo.address:port> IMAGE1=$REGISTRY/rhacm2/acm-must-gather-rhel9:v<2.x> oc adm must-gather --image=$IMAGE1 --dest-dir=<directory>
如果您在当前支持的某个版本或产品文档时遇到问题,请访问 红帽支持,您可以在其中进行故障排除、查看知识库文章、与支持团队连接,或者创建一个问题单。您必须使用您的红帽凭证登录。
1.3. 运行 must-gather 命令排除多集群全局 hub 的问题 复制链接链接已复制到粘贴板!
您可以运行 must-gather 命令来排除多集群全局 hub 的问题。运行 must-gather 命令来收集详情、日志并采取调试问题的步骤。当您请求支持时,这个调试信息会很有用。
oc adm must-gather 命令从集群中收集解决问题通常需要的信息,包括以下项目的信息:
- 资源定义
- 服务日志
1.3.1. 先决条件 复制链接链接已复制到粘贴板!
运行 must-gather 命令必须满足以下先决条件:
-
使用具有
cluster-admin角色的用户访问全局 hub 和受管 hub 集群。 - 在本地机器上安装 OpenShift Container Platform 命令行界面。如需更多信息,请参阅 OpenShift Container Platform 文档中的 OpenShift CLI 入门。
-
了解
must-gather命令以及通过阅读 OpenShift Container Platform 文档中的 收集集群数据 来安装所需的先决条件。
1.3.2. 运行 must-gather 命令 复制链接链接已复制到粘贴板!
完成以下步骤,使用 must-gather 命令收集信息:
- 登录到您的全局 hub 集群。
运行以下命令:
oc adm must-gather --image=registry.redhat.io/rhacm2/acm-must-gather-rhel9:v2.13 --dest-dir=<directory>-
如果要检查受管 hub 集群,请在这些集群中运行
must-gather命令。
为以下资源收集信息:
-
两个对等级别:
cluster-scoped-resources和namespaces资源。 - 每个对等级别下的子类:用于 cluster-scope 和 namespace-scoped 资源的自定义资源定义的 API 组。
-
每个子类的下一级: 按
kind进行排序的 YAML 文件。 -
对于多集群全局 hub 集群,您可以在命名空间资源中检查
PostgresCluster和Kafka。 -
对于全局 hub 集群,您可以检查 multicluster global hub 相关 pod,并在
命名空间资源的pod中记录日志。 -
对于受管 hub 集群,您可以检查 multicluster global hub 代理 pod,并在
命名空间资源的pod中记录日志。
1.4. Red Hat Edge Manager 代理的 must-gather 步骤 复制链接链接已复制到粘贴板!
要调试设备上的 Red Hat Edge Manager 代理,您可以使用 flightctl-must-gather 命令。
需要的访问权限:集群管理员
请参见以下步骤:
- 在您要调试的设备中运行以下命令:
sudo flightctl-must-gather
1.5. 安装状态故障排除处于安装或待处理状态 复制链接链接已复制到粘贴板!
在安装 Red Hat Advanced Cluster Management 时,MultiClusterHub 会一直处于 Installing 阶段,或多个 pods 一直处于 Pending 状态。
1.5.1. 症状:一直处于 Pending 状态 复制链接链接已复制到粘贴板!
安装 MultiClusterHub 后已超过了十分钟,一个或多个来自 MultiClusterHub 资源的 status.components 字段的组件报告 ProgressDeadlineExceeded。这可能是集群中的资源限制的问题。
检查安装了 Multiclusterhub 的命名空间中的 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.5.2. 解决问题: 调整 worker 节点大小 复制链接链接已复制到粘贴板!
如果您有这个问题,则需要使用更大或多个 worker 节点来更新集群。如需了解调整集群大小的信息,请参阅调整集群大小。
从 2.7.x 升级到 2.8.x 后,cluster- engine 命名空间的 会崩溃。
ocm- controller
尝试列出 ManagedClusterSet 和 ManagedClusterSetBinding 自定义资源定义后,会出现以下出错信息:
Error from server: request to convert CR from an invalid group/version: cluster.open-cluster-management.io/v1beta1
前面的消息表示,从 v1beta1 到 v1beta2 的 ManagedClusterSets 和 ManagedClusterSetBindings 自定义资源定义的迁移失败。
要解决这个问题,您必须手动启动 API 迁移。完成以下步骤:
将
cluster-manager恢复到以前的版本。使用以下命令暂停
multiclusterengine:oc annotate mce multiclusterengine pause=true运行以下命令,将
cluster-manager部署的镜像替换为之前的版本:oc patch deployment cluster-manager -n multicluster-engine -p \ '{"spec":{"template":{"spec":{"containers":[{"name":"registration-operator","image":"registry.redhat.io/multicluster-engine/registration-operator-rhel8@sha256:35999c3a1022d908b6fe30aa9b85878e666392dbbd685e9f3edcb83e3336d19f"}]}}}}' export ORIGIN_REGISTRATION_IMAGE=$(oc get clustermanager cluster-manager -o jsonpath='{.spec.registrationImagePullSpec}')将
ClusterManager资源中的注册镜像引用替换为以前的版本。运行以下命令:oc patch clustermanager cluster-manager --type='json' -p='[{"op": "replace", "path": "/spec/registrationImagePullSpec", "value": "registry.redhat.io/multicluster-engine/registration-rhel8@sha256:a3c22aa4326859d75986bf24322068f0aff2103cccc06e1001faaf79b9390515"}]'
运行以下命令,将
ManagedClusterSets和ManagedClusterSetBindings自定义资源定义恢复到以前的版本:oc annotate crds managedclustersets.cluster.open-cluster-management.io operator.open-cluster-management.io/version- oc annotate crds managedclustersetbindings.cluster.open-cluster-management.io operator.open-cluster-management.io/version-重新启动
cluster-manager,并等待自定义资源定义重新创建。运行以下命令:oc -n multicluster-engine delete pods -l app=cluster-manager oc wait crds managedclustersets.cluster.open-cluster-management.io --for=jsonpath="{.metadata.annotations['operator\.open-cluster-management\.io/version']}"="2.3.3" --timeout=120s oc wait crds managedclustersetbindings.cluster.open-cluster-management.io --for=jsonpath="{.metadata.annotations['operator\.open-cluster-management\.io/version']}"="2.3.3" --timeout=120s使用以下命令启动存储版本迁移:
oc patch StorageVersionMigration managedclustersets.cluster.open-cluster-management.io --type='json' -p='[{"op":"replace", "path":"/spec/resource/version", "value":"v1beta1"}]' oc patch StorageVersionMigration managedclustersets.cluster.open-cluster-management.io --type='json' --subresource status -p='[{"op":"remove", "path":"/status/conditions"}]' oc patch StorageVersionMigration managedclustersetbindings.cluster.open-cluster-management.io --type='json' -p='[{"op":"replace", "path":"/spec/resource/version", "value":"v1beta1"}]' oc patch StorageVersionMigration managedclustersetbindings.cluster.open-cluster-management.io --type='json' --subresource status -p='[{"op":"remove", "path":"/status/conditions"}]'运行以下命令等待迁移完成:
oc wait storageversionmigration managedclustersets.cluster.open-cluster-management.io --for=condition=Succeeded --timeout=120s oc wait storageversionmigration managedclustersetbindings.cluster.open-cluster-management.io --for=condition=Succeeded --timeout=120s将
cluster-manager恢复到 Red Hat Advanced Cluster Management 2.13。它可能需要几分钟时间。运行以下命令:oc annotate mce multiclusterengine pause- oc patch clustermanager cluster-manager --type='json' -p='[{"op": "replace", "path": "/spec/registrationImagePullSpec", "value": "'$ORIGIN_REGISTRATION_IMAGE'"}]'
1.6.2.1. 验证 复制链接链接已复制到粘贴板!
要验证 Red Hat Advanced Cluster Management 是否已恢复,请运行以下命令:
oc get managedclusterset
oc get managedclustersetbinding -A
运行命令后,ManagedClusterSets 和 ManagedClusterSetBindings 资源会被列出,且没有错误消息。
1.7. 离线集群的故障排除 复制链接链接已复制到粘贴板!
一些常见的原因会导致集群显示离线状态。
1.7.1. 症状:集群状态为离线 复制链接链接已复制到粘贴板!
完成创建集群的步骤后,您无法从 Red Hat Advanced Cluster Management 控制台访问集群,集群的状态为离线(offline)。
1.7.2. 解决问题: 集群状态为离线 复制链接链接已复制到粘贴板!
确定受管集群是否可用。您可以在 Red Hat Advanced Cluster Management 控制台的 Clusters 区域中进行检查。
如果不可用,请尝试重启受管集群。
如果受管集群状态仍处于离线状态,完成以下步骤:
-
在 hub 集群上运行
oc get managedcluster <cluster_name> -o yaml命令。将<cluster_name>替换为集群的名称。 -
找到
status. conditionss部分。 -
检查
type: ManagedClusterConditionAvailable信息并解决相关的问题。
-
在 hub 集群上运行
1.8. 受管集群导入失败的故障排除 复制链接链接已复制到粘贴板!
如果集群导入失败,您可以执行一些步骤来确定集群导入失败的原因。
1.8.1. 症状:导入的集群不可用 复制链接链接已复制到粘贴板!
完成导入集群的步骤后,您无法从 Red Hat Advanced Cluster Management for Kubernetes 控制台访问它。
1.8.2. 解决问题: 导入的集群不可用 复制链接链接已复制到粘贴板!
在尝试导入集群后,有几个可能的原因会导致导入集群的不可用。如果集群导入失败,请完成以下步骤,直到找到失败导入的原因:
在 Red Hat Advanced Cluster Management hub 集群中,运行以下命令,以确保 Red Hat Advanced Cluster Management 导入控制器正在运行。
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在 Red Hat Advanced Cluster Management hub 集群中,运行以下命令以确定受管集群导入 secret 是否由 Red Hat Advanced Cluster Management 导入控制器成功生成:
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在 Red Hat Advanced Cluster Management 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,则命令的结果表示失败的原因。- 检查受管集群的 Klusterlet 状态是否有降级条件。请参阅 带有降级条件的 Klusterlet 故障排除,以查找 Klusterlet 被降级的原因。
1.9. 对带有待处理导入状态的集群进行故障排除 复制链接链接已复制到粘贴板!
如果在集群的控制台上持续接收到 Pending import(待处理到)信息时,请按照以下步骤排除此问题。
1.9.1. 症状:集群处于待处理导入状态 复制链接链接已复制到粘贴板!
在使用 Red Hat Advanced Cluster Management 控制台导入一个集群后,出现在控制台中的集群带有 Pending import 状态。
1.9.2. 鉴别问题: 集群处于待处理导入状态 复制链接链接已复制到粘贴板!
在受管集群中运行以下命令查看有问题的 Kubernetes pod 的名称:
kubectl get pod -n open-cluster-management-agent | grep klusterlet-agent在受管集群中运行以下命令查找错误的日志条目:
kubectl logs <klusterlet_agent_pod> -n open-cluster-management-agent将 klusterlet_agent_pod 替换为在第 1 步中获得的 pod 名称。
-
在返回的结果中搜索显示有网络连接问题的内容。示例包括:
no such host。
1.9.3. 解决问题: 集群处于待处理导入状态 复制链接链接已复制到粘贴板!
通过在 hub 集群中输入以下命令来检索有问题的端口号:
oc get infrastructure cluster -o yaml | grep apiServerURL确保来自受管集群的主机名可以被解析,并确保建立到主机和端口的出站连接。
如果无法通过受管集群建立通信,集群导入就不完整。受管集群的集群状态将会是 Pending import。
1.10. 对带有已存在错误的集群的故障排除 复制链接链接已复制到粘贴板!
如果您无法将 OpenShift Container Platform 集群导入到 Red Hat Advanced Cluster Management MultiClusterHub 并收到 AlreadyExists 错误,请按照以下步骤排除此问题。
将 OpenShift Container Platform 集群导入到 Red Hat Advanced Cluster Management MultiClusterHub 时会显示错误日志:
error log:
Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition
Error from server (AlreadyExists): error when creating "STDIN": customresourcedefinitions.apiextensions.k8s.io "klusterlets.operator.open-cluster-management.io" already exists
The cluster cannot be imported because its Klusterlet CRD already exists.
Either the cluster was already imported, or it was not detached completely during a previous detach process.
Detach the existing cluster before trying the import again."
运行以下命令,检查您要导入的集群中的任何与 Red Hat Advanced Cluster Management MultiClusterHub 相关的资源:
oc get all -n open-cluster-management-agent
oc get all -n open-cluster-management-agent-addon
使用以下命令删除 klusterlet 自定义资源:
oc get klusterlet | grep klusterlet | awk '{print $1}' | xargs oc patch klusterlet --type=merge -p '{"metadata":{"finalizers": []}}'
运行以下命令以删除预先存在的资源:
oc delete namespaces open-cluster-management-agent open-cluster-management-agent-addon --wait=false
oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc delete crds --wait=false
oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc patch crds --type=merge -p '{"metadata":{"finalizers": []}}'
1.11. VMware vSphere 上创建集群的故障排除 复制链接链接已复制到粘贴板!
如果您在 VMware vSphere 上创建 Red Hat OpenShift Container Platform 集群时遇到问题,请查看以下故障排除信息以查看它们是否解决了您的问题。
注:当集群创建过程在 VMware vSphere 上失败时,您将无法使用该链接来查看日志。如果发生这种情况,您可以通过查看 thehive-controllers pod 的日志来找出问题。hive-controllers 日志位于 hive 命名空间中。
1.11.1. 受管集群创建失败并显示证书 IP SAN 错误 复制链接链接已复制到粘贴板!
1.11.1.1. 症状: Managed 集群创建失败并显示证书 IP SAN 错误 复制链接链接已复制到粘贴板!
在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,并显示一个错误消息,显示证书 IP SAN 错误。
1.11.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.11.1.3. 解决问题: 管理的集群创建失败,并显示证书 IP SAN 错误 复制链接链接已复制到粘贴板!
使用 VMware vCenter 服务器完全限定主机名,而不是凭证中的 IP 地址。您还可以更新 VMware vCenter CA 证书以包含 IP SAN。
1.11.2. 受管集群创建失败并显示未知证书颁发机构 复制链接链接已复制到粘贴板!
1.11.2.1. 症状:管理集群创建失败并显示未知证书颁发机构 复制链接链接已复制到粘贴板!
在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,因为证书由未知颁发机构签名。
1.11.2.2. 鉴别问题: Managed 集群创建失败并显示未知证书颁发机构 复制链接链接已复制到粘贴板!
受管集群的部署失败,并在部署日志中返回以下错误:
Error: error setting up new vSphere SOAP client: Post https://vspherehost.com/sdk: x509: certificate signed by unknown authority"
1.11.2.3. 解决问题: 管理的集群创建失败并显示未知证书颁发机构 复制链接链接已复制到粘贴板!
确保您在创建凭证时从证书认证机构输入了正确的证书。
1.11.3. 受管集群创建带有过期证书失败 复制链接链接已复制到粘贴板!
1.11.3.1. 情况: 集群创建失败并显示过期的证书 复制链接链接已复制到粘贴板!
在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,因为证书已过期或者无效。
1.11.3.2. 鉴别问题: 管理的集群创建失败并显示过期的证书 复制链接链接已复制到粘贴板!
受管集群的部署失败,并在部署日志中返回以下错误:
x509: certificate has expired or is not yet valid
1.11.3.3. 解决问题: 管理的集群创建失败并显示过期的证书 复制链接链接已复制到粘贴板!
确保同步了 ESXi 主机上的时间。
1.11.4. 受管集群创建失败且没有标记权限 复制链接链接已复制到粘贴板!
1.11.4.1. 症状:管理集群创建失败且没有足够特权进行标记 复制链接链接已复制到粘贴板!
在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,因为没有足够的权限进行标记。
1.11.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.11.4.3. 解决问题: 管理的集群创建没有足够权限进行标记 复制链接链接已复制到粘贴板!
确保 VMware vCenter 所需的帐户权限正确。如需更多信息,请参阅在安装过程中删除的镜像 registry。
1.11.5. 受管集群创建失败并显示无效的 dnsVIP 复制链接链接已复制到粘贴板!
1.11.5.1. 症状: 受管集群创建失败并显示无效的 dnsVIP 复制链接链接已复制到粘贴板!
在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,因为存在无效的 dnsVIP。
1.11.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.11.5.3. 解决问题: 受管集群创建失败并显示无效的 dnsVIP 复制链接链接已复制到粘贴板!
从支持 VMware Installer Provisioned Infrastructure 的 OpenShift Container Platform 版本中选择一个发行镜像。
1.11.6. 受管集群创建带有不正确的网络类型失败 复制链接链接已复制到粘贴板!
1.11.6.1. 症状: 集群创建失败并显示不正确的网络类型 复制链接链接已复制到粘贴板!
在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,因为指定的网络类型不正确。
1.11.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.11.6.3. 解决问题: 受管集群创建失败并显示不正确的网络类型 复制链接链接已复制到粘贴板!
为指定的 VMware 集群选择一个有效的 VMware vSphere 网络类型。
1.11.7. 受管集群创建失败并显示磁盘更改错误 复制链接链接已复制到粘贴板!
1.11.7.1. 症状:因为错误处理磁盘更改导致添加 VMware vSphere 受管集群失败 复制链接链接已复制到粘贴板!
在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,因为在处理磁盘更改时会出现错误。
1.11.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.11.7.3. 解决问题:因为错误处理磁盘更改导致 VMware vSphere 受管集群失败 复制链接链接已复制到粘贴板!
使用 VMware vSphere 客户端为用户授予Profile-driven Storage Privileges 的所有权限。
如果您在 Red Hat OpenStack Platform 上创建 Red Hat OpenShift Container Platform 集群时遇到问题,请参阅以下故障排除信息来查看它们是否解决了您的问题。
1.12.1. 症状:受管集群创建失败,并带有 unknown authority 错误 复制链接链接已复制到粘贴板!
在使用自签名证书在 Red Hat OpenStack Platform 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,并显示 unknown authority 错误。
1.12.2. 鉴别问题: 管理的集群创建失败带有 unknown authority 错误 复制链接链接已复制到粘贴板!
受管集群的部署失败,并返回以下出错信息:
x509: certificate signed by unknown authority
1.12.3. 解决问题: 受管集群创建失败并显示 unknown authority 错误 复制链接链接已复制到粘贴板!
验证是否已正确配置以下文件:
clouds.yaml文件必须在cacert参数中指定ca.crt文件的路径。cacert参数在生成 ignition shim 时传递给了 OpenShift 安装程序。请参见以下示例:clouds: openstack: cacert: "/etc/pki/ca-trust/source/anchors/ca.crt"certificatesSecretRef参数必须引用一个其文件名与ca.crt文件匹配的 secret。请参见以下示例:spec: baseDomain: dev09.red-chesterfield.com clusterName: txue-osspoke platform: openstack: cloud: openstack credentialsSecretRef: name: txue-osspoke-openstack-creds certificatesSecretRef: name: txue-osspoke-openstack-certificatebundle要使用匹配文件名创建 secret,请运行以下命令:
oc create secret generic txue-osspoke-openstack-certificatebundle --from-file=ca.crt=ca.crt.pem -n $CLUSTERNAME-
ca.cert文件的大小必须小于 63 KB。
1.13. 证书更改后导入的集群离线故障排除 复制链接链接已复制到粘贴板!
支持安装自定义 apiserver 证书,但在更改证书信息前导入的一个或多个集群 处于离线状态。
1.13.1. 症状:证书更改后集群处于离线状态 复制链接链接已复制到粘贴板!
完成更新证书 secret 的步骤后,在线的一个或多个集群现在在控制台中显示 离线状态。
1.13.2. 鉴别问题: 证书更改后集群处于离线状态 复制链接链接已复制到粘贴板!
更新自定义 API 服务器证书信息后,在新证书前导入并运行的集群会处于 offline 状态。
表示证书有问题的错误会出现在离线受管集群的 open-cluster-management-agent 命名空间中的 pod 日志中。以下示例与日志中显示的错误类似:
请参阅以下 klusterlet-agent 日志:
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
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
1.13.3. 解决问题: 证书更改后集群处于离线状态 复制链接链接已复制到粘贴板!
如果要恢复受管集群,请完成以下步骤以再次导入受管集群:
在 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 集群中分离受管集群。步骤使用受管集群中的当前设置更新所需的清单,包括新证书信息。
1.14. 删除集群后命名空间会保留 复制链接链接已复制到粘贴板!
当您删除受管集群时,该命名空间通常会作为移除集群过程的一部分被删除。在个别情况下,命名空间会和其中的一些工件一起被保留。在这种情况下,您必须手动删除命名空间。
1.14.1. 症状:删除集群后命名空间被保留 复制链接链接已复制到粘贴板!
删除受管集群后,命名空间没有被删除。
1.14.2. 解决问题: 删除集群后命名空间被保留 复制链接链接已复制到粘贴板!
完成以下步骤以手动删除命名空间:
运行以下命令以生成保留在 <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。-
在元数据中找到
finalizer属性。 -
使用 vi 编辑器的
dd命令删除非 Kubernetes finalizer。 -
输入
:wq命令保存列表并退出vi编辑器。 输入以下命令来删除命名空间:
oc delete ns <cluster-name>使用您要删除的命名空间的名称替换
cluster-name。
1.15. 导入集群时出现自动 Auto-import-secret-exists 错误 复制链接链接已复制到粘贴板!
集群导入失败,并显示出错信息:auto import secret exists。
1.15.1. 症状:导入集群时出现 Auto import secret exists 错误 复制链接链接已复制到粘贴板!
当导入 hive 集群以进行管理时,会显示 auto-import-secret already exists 错误。
1.15.2. 解决问题:导入集群时出现 Auto import secret exists 错误 复制链接链接已复制到粘贴板!
当您试图导入之前由 Red Hat Advanced Cluster Management 管理的集群时,会出现这种情况。如果出现这种情况,当您尝试重新导入集群时,secret 会发生冲突。
要临时解决这个问题,请完成以下步骤:
在 hub 集群中运行以下命令来手工删除存在的
auto-import-secret:oc delete secret auto-import-secret -n <cluster-namespace>将
cluster-namespace替换为集群的命名空间。- 使用集群导入介绍 中的步骤再次导入集群。
如果您在 cinder Container Storage Interface (CSI)驱动程序中使用 VolSync 或使用默认设置,您可能会遇到正在使用的 PVC 的错误。
1.16.1. 症状 :volumesnapshot 错误状态 复制链接链接已复制到粘贴板!
您可以将 VolSync ReplicationSource 或 ReplicationDestination 配置为使用快照。另外,您可以在 ReplicationSource 和 ReplicationDestination 中配置 storageclass 和 volumesnapshotclass。cinder volumesnapshotclass 上有一个参数,名为 force-create,默认值为 false。volumesnapshotclass 上的 force-create 参数意味着 cinder 不允许将 volumesnapshot 视为使用中的 PVC。因此,volumesnapshot 处于错误状态。
1.16.2. 解决问题: 将参数设置为 true 复制链接链接已复制到粘贴板!
-
为 cinder CSI 驱动程序创建一个新的
volumesnapshotclass。 将参数
force-create更改为true。请参见以下 YAML 示例:apiVersion: snapshot.storage.k8s.io/v1 deletionPolicy: Delete driver: cinder.csi.openstack.org kind: VolumeSnapshotClass metadata: annotations: snapshot.storage.kubernetes.io/is-default-class: 'true' name: standard-csi parameters: force-create: 'true'
1.17. 通过访问 PostgreSQL 数据库进行故障排除 复制链接链接已复制到粘贴板!
1.17.1. 症状:带有多集群全局 hub 的错误 复制链接链接已复制到粘贴板!
您可能会遇到多集群全局 hub 的各种错误。您可以访问置备的 PostgreSQL 数据库来查看对多集群全局 hub 问题进行故障排除的信息。
1.17.2. 解决问题: 访问 PostgresSQL 数据库 复制链接链接已复制到粘贴板!
There are two ways to access the provisioned PostgreSQL database.
使用
ClusterIP服务oc exec -it multicluster-global-hub-postgresql-0 -c multicluster-global-hub-postgresql -n multicluster-global-hub -- psql -U postgres -d hoh # Or access the database installed by crunchy operator oc exec -it $(kubectl get pods -n multicluster-global-hub -l postgres-operator.crunchydata.com/role=master -o jsonpath='{.items..metadata.name}') -c database -n multicluster-global-hub -- psql -U postgres -d hoh -c "SELECT 1"LoadBalancer将服务类型公开给默认置备的
LoadBalancer:cat <<EOF | oc apply -f - apiVersion: v1 kind: Service metadata: name: multicluster-global-hub-postgresql-lb namespace: multicluster-global-hub spec: ports: - name: postgres port: 5432 protocol: TCP targetPort: 5432 selector: name: multicluster-global-hub-postgresql type: LoadBalancer EOF运行以下命令来获取凭证:
# Host oc get svc multicluster-global-hub-postgresql-lb -n multicluster-global-hub -ojsonpath='{.status.loadBalancer.ingress[0].hostname}' # Database URI oc get secret storage-config -n multicluster-global-hub -ojsonpath='{.data.database-url}' | base64 -d # Database CA oc get secret storage-config -ojsonpath='{.data.ca\.crt}' | base64 -d将服务类型公开给 crunchy operator 置备的
LoadBalancer:oc patch postgrescluster postgres -n multicluster-global-hub -p '{"spec":{"service":{"type":"LoadBalancer"}}}' --type merge运行以下命令来获取凭证:
# Host oc get svc -n multicluster-global-hub postgres-ha -ojsonpath='{.status.loadBalancer.ingress[0].hostname}' # Username oc get secrets -n multicluster-global-hub postgres-pguser-postgres -o go-template='{{index (.data) "user" | base64decode}}' # Password oc get secrets -n multicluster-global-hub postgres-pguser-postgres -o go-template='{{index (.data) "password" | base64decode}}' # Database oc get secrets -n multicluster-global-hub postgres-pguser-postgres -o go-template='{{index (.data) "dbname" | base64decode}}'
1.18. 使用数据库转储和恢复进行故障排除 复制链接链接已复制到粘贴板!
在生产环境中,定期备份您的 PostgreSQL 数据库作为数据库管理任务。备份也可用于调试多集群全局 hub。
1.18.1. 症状:带有多集群全局 hub 的错误 复制链接链接已复制到粘贴板!
您可能会遇到多集群全局 hub 的各种错误。您可以使用数据库转储和恢复来排除多集群全局 hub 的问题。
1.18.2. 解决问题: 为 dubugging 转储数据库输出 复制链接链接已复制到粘贴板!
有时您需要转储多集群全局 hub 数据库中的输出,以调试问题。PostgreSQL 数据库提供 pg_dump 命令行工具来转储数据库的内容。要转储 localhost 数据库服务器的数据,请运行以下命令:
pg_dump hoh > hoh.sql
要转储位于带有压缩格式的远程服务器中的多集群全局 hub 数据库,请使用命令行选项控制连接详情,如下例所示:
pg_dump -h my.host.com -p 5432 -U postgres -F t hoh -f hoh-$(date +%d-%m-%y_%H-%M).tar
1.18.3. 解决问题: 从转储恢复数据库 复制链接链接已复制到粘贴板!
要恢复 PostgreSQL 数据库,您可以使用 psql 或 pg_restore 命令行工具。psql 工具用于恢复 pg_dump 创建的纯文本文件:
psql -h another.host.com -p 5432 -U postgres -d hoh < hoh.sql
pg_restore 工具用于在其中一个非纯文本格式(custom、tar 或目录)中从 pg_dump 创建的存档中恢复 PostgreSQL 数据库:
pg_restore -h another.host.com -p 5432 -U postgres -d hoh hoh-$(date +%d-%m-%y_%H-%M).tar
1.19. 集群状态从离线变为可用的故障排除 复制链接链接已复制到粘贴板!
在没有对环境或集群进行任何手工更改的情况下,受管集群的状态在 offline(离线) 和 available(可用) 间转换。
1.19.1. 症状:集群状态从离线变为可用 复制链接链接已复制到粘贴板!
当将受管集群连接到 hub 集群的网络不稳定时,hub 集群所报告的受管集群的状态在离线和可用之间不断转换。
hub 集群和受管集群之间的连接通过租期维护,该租期在 leaseDurationSeconds 间隔值验证。如果租期没有在 leaseDurationSeconds 值的五个连续尝试中验证,则集群被标记为 offline。
例如,集群在五分钟后标记为 离线,其中 leaseDurationSeconds 间隔为 60 秒。由于连接问题或延迟等原因,此配置可能不足,从而导致不稳定。
1.19.2. 解决问题: 集群状态从离线变为可用 复制链接链接已复制到粘贴板!
五个验证尝试是默认设置且无法更改,但您可以更改 leaseDurationSeconds 间隔。
确定您希望集群标记为 离线 的时间(以分钟为单位),然后将该值乘以 60 以转换为秒。然后,按默认的五次尝试次数划分。结果是您的 leaseDurationSeconds 值。
输入以下命令在 hub 集群上编辑
ManagedCluster规格,但将cluster-name替换为受管集群的名称:oc edit managedcluster <cluster-name>在
ManagedCluster规格中增加leaseDurationSeconds的值,如下例所示:apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: <cluster-name> spec: hubAcceptsClient: true leaseDurationSeconds: 60- 保存并应用该文件。
1.20. 集群在控制台中带有待处理或失败状态的故障排除 复制链接链接已复制到粘贴板!
如果您在控制台中看到您创建的集群的状态为 Pending 或 Failed,请按照以下步骤排除问题。
1.20.1. 症状:集群在控制台中带有待处理或失败状态 复制链接链接已复制到粘贴板!
在使用 Red Hat Advanced Cluster Management 控制台创建一个新集群后,在控制台中集群会一直显示Pending 或 Failed 状态。
1.20.2. 鉴别问题: 集群在控制台中显示待处理或失败状态 复制链接链接已复制到粘贴板!
如果集群显示 Failed 状态,进入集群的详情页面并使用提供的日志的链接。如果没有找到日志或集群显示 Pending 状态,请按照以下步骤检查日志:
流程 1
在 hub 集群中运行以下命令,查看在命名空间中为新集群创建的 Kubernetes pod 的名称:
oc get pod -n <new_cluster_name>使用您创建的集群名称替换
new_cluster_name。如果没有 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 名称。- 搜索日志中可能会解释造成问题的原因的错误信息。
流程 2
如果没有在其名称中带有
provision的 pod,则代表问题在进程早期发生。完成以下步骤以查看日志:在 hub 集群中运行以下命令:
oc describe clusterdeployments -n <new_cluster_name>使用您创建的集群名称替换
new_cluster_name。有关集群安装日志的更多信息,请参阅 Red Hat OpenShift 文档中的 收集安装日志。- 检查是否在资源的 Status.Conditions.Message 和 Status.Conditions.Reason 条目中存在有关此问题的额外信息。
1.20.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.21. Grafana 故障排除 复制链接链接已复制到粘贴板!
当您在 Grafana explorer 中查询一些耗时的指标时,您可能会遇到一个网关超时错误。
1.21.1. 症状:Grafana explorer 网关超时 复制链接链接已复制到粘贴板!
如果您在 Grafana explorer 中查询一些耗时的指标时遇到 Gateway Time-out 错误,则超时可能是由 open-cluster-management-observability 命名空间中的 Grafana 造成的。
1.21.2. 解决问题: 配置 Grafana 复制链接链接已复制到粘贴板!
如果您有这个问题,请完成以下步骤:
验证 Grafana 的默认配置是否有预期的超时设置:
要验证 Grafana 的默认超时设置,请运行以下命令:
oc get secret grafana-config -n open-cluster-management-observability -o jsonpath="{.data.grafana\.ini}" | base64 -d | grep dataproxy -A 4应显示以下超时设置:
[dataproxy] timeout = 300 dial_timeout = 30 keep_alive_seconds = 300要验证 Grafana 的默认数据源查询超时时间,请运行以下命令:
oc get secret/grafana-datasources -n open-cluster-management-observability -o jsonpath="{.data.datasources\.yaml}" | base64 -d | grep queryTimeout应显示以下超时设置:
queryTimeout: 300s
如果您验证了 Grafana 的默认配置有预期的超时设置,您可以运行以下命令来在
open-cluster-management-observability命名空间中配置 Grafana:oc annotate route grafana -n open-cluster-management-observability --overwrite haproxy.router.openshift.io/timeout=300s
刷新 Grafana 页面,并尝试再次查询指标。网关超时错误不再显示。
1.22. 未使用放置规则选择本地集群的故障排除 复制链接链接已复制到粘贴板!
受管集群使用放置规则选择,但不会选择 local-cluster (这也是管理的 hub 集群)。放置规则用户没有在 local-cluster 命名空间中获取 managedcluster 资源的权限。
1.22.1. 症状:不选择为受管集群对本地集群进行故障排除 复制链接链接已复制到粘贴板!
所有受管集群都使用放置规则选择,但 local-cluster 不是。放置规则用户没有在 local-cluster 命名空间中获取 managedcluster 资源的权限。
1.22.2. 解决问题: 未选择作为受管集群的故障排除本地集群 复制链接链接已复制到粘贴板!
已弃用: PlacementRule
要解决这个问题,您需要在 local-cluster 命名空间中授予 managedcluster 管理权限。完成以下步骤:
确认受管集群列表包含
local-cluster,并且放置规则的decisions列表不显示local-cluster。运行以下命令并查看结果:% oc get managedclusters请参阅
local-cluster被加入的示例输出,但它不在PlacementRule的 YAML 中:NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE local-cluster true True True 56d cluster1 true True True 16hapiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: all-ready-clusters namespace: default spec: clusterSelector: {} status: decisions: - clusterName: cluster1 clusterNamespace: cluster1在 YAML 文件中创建一个
Role,以便在local-cluster命名空间中授予managedcluster管理权限。请参见以下示例:apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: managedcluster-admin-user-zisis namespace: local-cluster rules: - apiGroups: - cluster.open-cluster-management.io resources: - managedclusters verbs: - get创建
RoleBinding资源,向放置规则用户授予local-cluster命名空间的访问权限。请参见以下示例:apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: managedcluster-admin-user-zisis namespace: local-cluster roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: managedcluster-admin-user-zisis namespace: local-cluster subjects: - kind: User name: zisis apiGroup: rbac.authorization.k8s.io
1.23. 对应用程序 Kubernetes 部署版本进行故障排除 复制链接链接已复制到粘贴板!
可能不支持带有已弃用 Kubernetes apiVersion 的受管集群。有关已弃用 API 版本的详情,请参阅 Kubernetes 问题。
1.23.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.23.2. 解决: 应用程序部署版本 复制链接链接已复制到粘贴板!
更新资源中的
apiVersion。例如,如果 subscription YAML 文件中显示 Deployment kind 的错误,您需要将apiVersion从extensions/v1beta1更新至apps/v1。请参见以下示例:
apiVersion: apps/v1 kind: Deployment在受管集群中运行以下命令来验证可用版本:
kubectl explain <resource>-
检查
VERSION。
1.24. 带有降级条件的 Klusterlet 故障排除 复制链接链接已复制到粘贴板!
Klusterlet 降级条件可帮助诊断受管集群中的 klusterlet 代理的状态。如果 Klusterlet 处于 degraded 条件,受管集群中的 klusterlet 代理可能会出错,需要进行故障排除。对于设置为 True 的 Klusterlet 降级条件,请参见以下信息。
1.24.1. 症状:Klusterlet 处于降级状况 复制链接链接已复制到粘贴板!
在受管集群中部署 Klusterlet 后,KlusterletRegistrationDegraded 或 KlusterletWorkDegraded 条件会显示 True 的状态。
1.24.2. 鉴别问题: Klusterlet 处于降级状况 复制链接链接已复制到粘贴板!
在受管集群中运行以下命令查看 Klusterlet 状态:
kubectl get klusterlets klusterlet -oyaml-
检查
KlusterletRegistrationDegraded或KlusterletWorkDegraded以查看该条件是否被设置为True。请根据解决这个问题的内容处理降级问题。
1.24.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。klusterlet 代理会创建一个新的 hub 集群 kubeconfig secret。 -
如果
KlusterletRegistrationDegraded显示 True,且状况原因为 GetRegistrationDeploymentFailed 或 UnavailableRegistrationPod,您可以检查条件信息以获取问题详情并尝试解决。 -
如果
KlusterletWorkDegraded显示为 True,且状况原因为 GetWorkDeploymentFailed,或 UnavailableWorkPod,您可以检查条件消息以获取问题详情并尝试解决。
1.25. Object storage 频道 secret 故障排除 复制链接链接已复制到粘贴板!
如果更改 SecretAccessKey,Object 存储频道的订阅将无法自动获取更新的 secret,您会收到一个错误。
1.25.1. 症状:对象存储频道 secret 复制链接链接已复制到粘贴板!
Object 存储频道的订阅无法自动获取更新的 secret。这可会阻止订阅 operator 协调并将资源从对象存储部署到受管集群的过程。
1.25.2. 解决问题: 对象存储频道 secret 复制链接链接已复制到粘贴板!
您需要手动输入凭证来创建 secret,然后引用频道中的 secret。
注解订阅 CR,以便生成一个协调的单个订阅 operator。请参阅以下
data规格:apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: deva namespace: ch-obj labels: name: obj-sub spec: type: ObjectBucket pathname: http://ec2-100-26-232-156.compute-1.amazonaws.com:9000/deva sourceNamespaces: - default secretRef: name: dev --- apiVersion: v1 kind: Secret metadata: name: dev namespace: ch-obj labels: name: obj-sub data: AccessKeyID: YWRtaW4= SecretAccessKey: cGFzc3dvcmRhZG1pbg==运行
oc annotate进行测试:oc annotate appsub -n <subscription-namespace> <subscription-name> test=true
运行命令后,您可以进入 Application 控制台以验证资源是否已部署到受管集群。或者您可以登录到受管集群,以查看应用程序资源是否在给定命名空间中创建。
1.26. 对可观察性功能进行故障排除 复制链接链接已复制到粘贴板!
安装可观察组件后,该组件可能会卡住,并显示 Installing 状态。
1.26.1. 症状: MultiClusterObservability 资源处于没有就绪的状态 复制链接链接已复制到粘贴板!
如果在安装并创建 Observability 自定义资源定义 (CRD) 后,可观察性 (observability) 状态会一直处于 Installing 状态,则可能是因为没有为 spec:storageConfig:storageClass 参数定义值。或者,可观察性组件自动找到默认的 storageClass,但如果没有存储值,则组件会停留在 Installing 状态下。
1.26.2. 解决这个问题: MultiClusterObservability 资源处于没有就绪的状态 复制链接链接已复制到粘贴板!
如果您有这个问题,请完成以下步骤:
验证是否安装了可观察性组件:
要验证
multicluster-observability-operator,请运行以下命令:kubectl get pods -n open-cluster-management|grep observability要验证是否存在正确的 CRD,请运行以下命令:
kubectl get crd|grep observ在启用组件前,必须显示以下 CRD:
multiclusterobservabilities.observability.open-cluster-management.io observabilityaddons.observability.open-cluster-management.io observatoria.core.observatorium.io
- 如果为裸机集群创建自己的 storageClass,请参阅使用 NFS 的持久性存储。
-
为确保可观察性组件可以找到默认的 storageClass,请更新
multicluster-observability-operator自定义资源定义中的storageClass参数。您的参数可能类似以下值:
storageclass.kubernetes.io/is-default-class: "true"
安装完成后,可观察组件状态会被更新为 Ready 状态。如果安装无法完成,则会显示 Fail 状态。
1.27. OpenShift 监控服务故障排除 复制链接链接已复制到粘贴板!
受管集群中的 Observability 服务需要从 OpenShift Container Platform 监控堆栈中提取指标数据。如果 OpenShift Container Platform 监控堆栈没有处于就绪状态,则不会安装 metrics-collector。
1.27.1. 症状:OpenShift 监控服务未就绪 复制链接链接已复制到粘贴板!
endpoint-observability-operator-x pod 会检查 prometheus-k8s 服务是否在 openshift-monitoring 命名空间中可用。如果这个服务没有出现在 openshift-monitoring 命名空间中,则不会部署 metrics-collector。您可能会收到以下出错信息:Failed to get prometheus resource。
1.27.2. 解决问题: OpenShift 监控服务未就绪 复制链接链接已复制到粘贴板!
如果您有这个问题,请完成以下步骤:
- 登录您的 OpenShift Container Platform 集群。
-
访问
openshift-monitoring命名空间,验证prometheus-k8s服务是否可用。 -
在受管集群的
open-cluster-management-addon-observability命名空间中重启endpoint-observability-operator-xpod。
1.28. metrics-collector 故障排除 复制链接链接已复制到粘贴板!
当 observability-client-ca-certificate secret 没有在受管集群中被重新刷新时,您可能会收到一个内部服务器错误。
1.29. Thanos compactor halts 故障排除 复制链接链接已复制到粘贴板!
您可能会收到紧凑器停止的错误消息。当存在损坏块或 Thanos 紧凑器持久性卷声明(PVC)空间不足时,会出现这种情况。
1.29.1. 症状:Thanos compactor halts 复制链接链接已复制到粘贴板!
Thanos compactor 会停止,因为持久性卷声明(PVC)中没有剩余空间。您会收到以下信息:
ts=2024-01-24T15:34:51.948653839Z caller=compact.go:491 level=error msg="critical error detected; halting" err="compaction: group 0@5827190780573537664: compact blocks [ /var/thanos/compact/compact/0@15699422364132557315/01HKZGQGJCKQWF3XMA8EXAMPLE]: 2 errors: populate block: add series: write series data: write /var/thanos/compact/compact/0@15699422364132557315/01HKZGQGJCKQWF3XMA8EXAMPLE.tmp-for-creation/index: no space left on device; write /var/thanos/compact/compact/0@15699422364132557315/01HKZGQGJCKQWF3XMA8EXAMPLE.tmp-for-creation/index: no space left on device"
1.29.2. 解决问题:Thanos compactor halts 复制链接链接已复制到粘贴板!
要解决这个问题,增大 Thanos compactor PVC 的存储空间。完成以下步骤:
-
增加
data-observability-thanos-compact-0PVC 的存储空间。如需更多信息,请参阅增加和减少持久性卷和持久性卷声明。 通过删除 pod 来重启
observability-thanos-compactpod。新 pod 会自动创建并启动。oc delete pod observability-thanos-compact-0 -n open-cluster-management-observability-
重启
observability-thanos-compactpod 后,检查acm_thanos_compact_bulk_compactions指标。当 Thanos compactor 通过 backlog 工作时,指标值会减少。 确认指标在循环中发生了变化,并检查磁盘使用情况。然后您可以重新尝试再次减少 PVC。
注意: 这可能需要几周时间。
1.29.3. 症状:Thanos compactor halts 复制链接链接已复制到粘贴板!
Thanos compactor 会停止,因为您已损坏的块。您可能会收到以下输出,其中 01HKZYEZ2DVDQXF1STVEXAMPLE 块已损坏:
ts=2024-01-24T15:34:51.948653839Z caller=compact.go:491 level=error msg="critical error detected; halting" err="compaction: group 0@15699422364132557315: compact blocks [/var/thanos/compact/compact/0@15699422364132557315/01HKZGQGJCKQWF3XMA8EXAMPLE /var/thanos/compact/compact/0@15699422364132557315/01HKZQK7TD06J2XWGR5EXAMPLE /var/thanos/compact/compact/0@15699422364132557315/01HKZYEZ2DVDQXF1STVEXAMPLE /var/thanos/compact/compact/0@15699422364132557315/01HM05APAHXBQSNC0N5EXAMPLE]: populate block: chunk iter: cannot populate chunk 8 from block 01HKZYEZ2DVDQXF1STVEXAMPLE: segment index 0 out of range"
1.29.4. 解决问题:Thanos compactor halts 复制链接链接已复制到粘贴板!
在对象存储配置中添加 thanos bucket verify 命令。完成以下步骤:
通过在对象存储配置中添加
thanos bucket verify命令来解决块错误。使用以下命令在observability-thanos-compactpod 中设置配置:oc rsh observability-thanos-compact-0 [..] thanos tools bucket verify -r --objstore.config="$OBJSTORE_CONFIG" --objstore-backup.config="$OBJSTORE_CONFIG" --id=01HKZYEZ2DVDQXF1STVEXAMPLE如果上一个命令不起作用,则必须标记块以进行删除,因为它可能会损坏。运行以下命令:
thanos tools bucket mark --id "01HKZYEZ2DVDQXF1STVEXAMPLE" --objstore.config="$OBJSTORE_CONFIG" --marker=deletion-mark.json --details=DELETE如果您阻止删除,请运行以下命令清理标记的块:
thanos tools bucket cleanup --objstore.config="$OBJSTORE_CONFIG"
1.31. 安装后无法连接 Submariner 故障排除 复制链接链接已复制到粘贴板!
如果在配置 Submariner 后 Submariner 没有正确运行,请完成以下步骤以诊断问题。
1.31.1. 症状:在安装后无法连接 Submariner 复制链接链接已复制到粘贴板!
在安装后,Submariner 网络不会被通信。
1.31.2. 鉴别问题: Submariner 在安装后无法连接 复制链接链接已复制到粘贴板!
如果在部署 Submariner 后没有建立网络连接,请开始故障排除步骤。请注意,部署 Submariner 的过程可能需要几分钟时间。
1.31.3. 解决问题: Submariner 在安装后无法连接 复制链接链接已复制到粘贴板!
当 Submariner 在部署后无法正常工作时,请完成以下步骤:
检查以下要求,以确定 Submariner 的组件是否正确部署:
-
submariner-addonpod 在 hub 集群的open-cluster-management命名空间中运行。 以下 pod 在每个受管集群的
submariner-operator命名空间中运行:- submariner-addon
- submariner-gateway
- submariner-routeagent
- submariner-operator
- Submariner-globalnet(仅在 ClusterSet 中启用了 Globalnet 时)
- submariner-lighthouse-agent
- submariner-lighthouse-coredns
-
Submariner-networkplugin-syncer (仅在指定的 CNI 值是
OVNKubernetes时) - submariner-metrics-proxy
-
-
运行
subctl diagnose all命令来检查所需 pod 的状态,但submariner-addonpod 除外。 -
确保运行
must-gather命令来收集有助于解决问题的日志。
1.32. Submariner 端到端测试失败的故障排除 复制链接链接已复制到粘贴板!
运行 Submariner 端到端测试后,您可能会遇到失败。使用以下部分帮助您对这些端到端测试失败进行故障排除。
1.32.1. 症状: Submariner 端到端数据平面测试失败 复制链接链接已复制到粘贴板!
当端到端数据平面测试失败时,Submariner 测试显示 连接器 pod 可以连接到 监听程序 pod,但后续 连接器 pod 会一直处于 侦听 阶段。
1.32.2. 解决问题: Submariner 端到端数据平面测试失败 复制链接链接已复制到粘贴板!
最大传输单元(MTU)可能会导致端到端数据平面测试失败。例如,MTU 可能会导致互联网协议安全(IPsec) 的集群间通信 失败。通过运行使用小数据包大小的端到端数据平面测试来验证 MTU 是否为故障。
要运行这类测试,请在 Submariner 工作区中运行以下命令:
subctl verify --verbose --only connectivity --context <from_context> --tocontext <to_context> --image-override submariner-nettest=quay.io/submariner/nettest:devel --packet-size 200
如果测试使用这个小数据包大小成功,您可以通过设置传输控制协议(TCP)最大片段大小(MSS)来解决连接问题。通过完成以下步骤设置 TCP MSS:
通过注解网关节点来设置 TCP MSS
clamping值。例如,运行以下命令,值为1200:oc annotate node <node_name> submariner.io/tcp-clamp-mss=1200运行以下命令重启所有
RouteAgentpod:oc delete pod -n submariner-operator -l app=submariner-routeagent
1.32.3. 症状:对于裸机集群,Submariner 端到端测试失败 复制链接链接已复制到粘贴板!
如果容器网络接口(CNI)是 OpenShiftSDN,或者将虚拟可扩展 local-area 网络(VXLAN)用于 集群 隧道,则端到端数据平面测试可能会失败。
1.32.4. 解决问题: 对于裸机集群,Submariner 端到端测试会失败 复制链接链接已复制到粘贴板!
硬件的用户数据报 Protocal (UDP)校验和计算中存在一个错误,可能是裸机集群的端到端数据平面测试失败的一个根本原因。要排除这个程序错误,请通过应用以下 YAML 文件来禁用硬件卸载:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: disable-offload
namespace: submariner-operator
spec:
selector:
matchLabels:
app: disable-offload
template:
metadata:
labels:
app: disable-offload
spec:
tolerations:
- operator: Exists
containers:
- name: disable-offload
image: nicolaka/netshoot
imagePullPolicy: IfNotPresent
securityContext:
allowPrivilegeEscalation: true
capabilities:
add:
- net_admin
drop:
- all
privileged: true
readOnlyRootFilesystem: false
runAsNonRoot: false
command: ["/bin/sh", "-c"]
args:
- ethtool --offload vxlan-tunnel rx off tx off;
ethtool --offload vx-submariner rx off tx off;
sleep infinity
restartPolicy: Always
securityContext: {}
serviceAccount: submariner-routeagent
serviceAccountName: submariner-routeagent
hostNetwork: true
1.33. 恢复状态故障排除完成并显示错误 复制链接链接已复制到粘贴板!
恢复备份后,资源会被正确恢复,但 Red Hat Advanced Cluster Management 恢复资源会显示 FinishedWithErrors 状态。
1.33.1. 症状:恢复状态故障排除完成并显示错误 复制链接链接已复制到粘贴板!
Red Hat Advanced Cluster Management 显示 FinishedWithErrors 状态,由 Red Hat Advanced Cluster Management 恢复所创建的一个或多个 Velero 恢复资源显示 PartiallyFailed 状态。
1.33.2. 解决问题: 恢复状态完成并出错 复制链接链接已复制到粘贴板!
如果您从空备份中恢复,可以安全地忽略 FinishedWithErrors 状态。
Red Hat Advanced Cluster Management for Kubernetes 恢复显示所有 Velero 恢复资源的累积状态。如果一个状态是 PartiallyFailed,另一个状态为 Completed,则您会看到累积的状态 PartiallyFailed,代表至少有一个问题。
要解决这个问题,请检查所有带有 PartiallyFailed 状态的单独 Velero 恢复资源的状态,并查看日志以了解更多详情。您可以直接从对象存储获取日志,或使用 DownloadRequest 自定义资源从 OADP Operator 下载它。
要从控制台创建 DownloadRequest,请完成以下步骤:
- 进入 Operators > Installed Operators > Create DownloadRequest。
-
选择
BackupLog作为 Kind,并按照控制台说明完成DownloadRequest创建。
1.34. 对多行 YAML 解析进行故障排除 复制链接链接已复制到粘贴板!
当您想使用 fromSecret 功能将 Secret 资源的内容添加到 Route 资源中时,内容会被错误地显示。
1.34.1. 症状:对多行 YAML 解析进行故障排除 复制链接链接已复制到粘贴板!
当受管集群和 hub 集群与证书数据进行隐藏的集群时,则内容不会被解析为模板 JSON 字符串。您可能会收到以下出错信息:
message: >-
[spec.tls.caCertificate: Invalid value: "redacted ca certificate
data": failed to parse CA certificate: data does not contain any
valid RSA or ECDSA certificates, spec.tls.certificate: Invalid
value: "redacted certificate data": data does not contain any valid
RSA or ECDSA certificates, spec.tls.key: Invalid value: "": no key specified]
1.34.2. 解决问题: 对多行 YAML 解析进行故障排除 复制链接链接已复制到粘贴板!
配置证书策略,以获取 hub 集群和受管集群 fromSecret 值。使用 autoindent 功能更新您的证书策略,其内容如下:
tls:
certificate: |
{{ print "{{hub fromSecret "open-cluster-management" "minio-cert" "tls.crt" hub}}" | base64dec | autoindent }}
1.35. ClusterCurator 自动模板故障排除无法部署 复制链接链接已复制到粘贴板!
如果您使用 ClusterCurator 自动模板,且部署失败,请按照以下步骤排除此问题。
1.35.1. 症状: ClusterCurator 自动模板无法部署 复制链接链接已复制到粘贴板!
您不能使用 ClusterCurator 自动模板部署受管集群。这个过程可能会停留在 posthook 中,可能无法创建任何日志。
1.35.2. 解决问题: ClusterCurator 自动模板无法部署 复制链接链接已复制到粘贴板!
完成以下步骤以识别并解决问题:
-
检查集群命名空间中的
ClusterCurator资源状态,是否有任何消息。 -
在名为
curator-job requirements的Job资源中,它与上一步中位于同一个集群命名空间中,检查 pod 日志是否有任何错误。
注: 作业会在一小时后删除,因为生存时间为生存时间(TTL)设置。