1.9. 故障排除
在使用故障排除指南前,您可以运行 oc adm must-gather 命令来收集详情、日志和步骤来调试问题。如需了解更多详细信息,请参阅 运行 must-gather 命令进行故障排除。
另外,查看您基于角色的访问。详情请参阅 multicluster engine operator 基于角色的访问控制。
1.9.1. 记录的故障排除 复制链接链接已复制到粘贴板!
查看 multicluster engine operator 故障排除主题列表:
安装:
要查看安装任务的主要文档,请参阅安装和升级多集群引擎 operator。
集群管理:
要查看有关管理集群的主要文档,请参阅 集群生命周期简介。
- 将 day-two 节点添加到现有集群的故障排除会失败,并显示待处理用户操作
- 离线集群的故障排除
- 受管集群导入失败的故障排除
- 重新导入集群失败并显示未知颁发机构错误
- 对带有待处理导入状态的集群进行故障排除
- 证书更改后导入的集群离线故障排除
- 集群状态从离线变为可用的故障排除
- VMware vSphere 上创建集群的故障排除
- 集群在控制台中带有待处理或失败状态的故障排除
- OpenShift Container Platform 版本 3.11 集群导入失败的故障排除
- 带有降级条件的 Klusterlet 故障排除
- 删除集群后命名空间会保留
- 导入集群时出现自动 Auto-import-secret-exists 错误
- 在创建放置后缺少 PlacementDecision 进行故障排除
- 对 Dell 硬件上的裸机主机发现失败的故障排除
- Minimal ISO 引导故障故障排除
1.9.2. 运行 must-gather 命令进行故障排除 复制链接链接已复制到粘贴板!
要进行故障排除,参阅可以使用 must-gather 命令进行调试的用户情景信息,然后使用这个命令进行故障排除。
需要的访问权限:集群管理员
1.9.2.1. must-gather 情境 复制链接链接已复制到粘贴板!
场景一:如果您的问题已被记录,使用 已记录的故障排除文档部分进行解决。这个指南按照产品的主要功能进行组织。
在这种情况下,您可以参阅本指南来查看您的问题的解决方案是否在文档中。
-
情况 2:如果这个指南中没有与您的问题相关的内容,运行
must-gather命令并使用输出来调试问题。 -
情况 3:无法使用
must-gather命令的输出结果无法帮助解决您的问题,请向红帽支持提供您的输出。
1.9.2.2. must-gather 过程 复制链接链接已复制到粘贴板!
请参阅以下流程来使用 must-gather 命令:
-
了解
must-gather命令以及使用它的前提条件,请参阅 OpenShift Container Platform 文档中的 收集集群数据。 登录到您的集群。对于通常的用例,您应该在登录到您的 引擎 集群时运行
must-gather。注: 如果要检查您的受管集群,找到位于
cluster-scoped-resources目录中的gather-managed.log文件:<your-directory>/cluster-scoped-resources/gather-managed.log>检查 JOINED 和 AVAILABLE 栏没有被设置为
True的受管集群。您可以在这些没有以True状态连接的集群中运行must-gather命令。为用于收集数据和目录的 Kubernetes 镜像添加多集群引擎。运行以下命令,在其中使用当前支持的版本替换
v2.x插入镜像和输出目录:oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel8:v2.x --dest-dir=<directory>进入您指定的目录查看输出。输出以以下级别进行组织:
-
两个对等级别:
cluster-scoped-resources和namespace资源。 - 每个对等级别下的子类:用于 cluster-scope 和 namespace-scoped 资源的自定义资源定义的 API 组。
-
每个子类的下一级: 按
kind进行排序的 YAML 文件。
-
两个对等级别:
1.9.2.3. 在断开连接的环境中的 must-gather 复制链接链接已复制到粘贴板!
在断开连接的环境中,按照以下步骤运行 must-gather 命令:
- 在断开连接的环境中,将 RedHat operator 目录镜像镜像(mirror)到其 mirror registry 中。如需更多信息,请参阅 在断开连接的网络中安装。
-
运行以下命令以提取日志,该日志从其镜像 registry 中引用镜像。将
sha256替换为当前镜像:
REGISTRY=registry.example.com:5000
IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel8@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8>
oc adm must-gather --image=$IMAGE --dest-dir=./data
您可以在此处为产品团队创建一个 JIRA 错误。https://issues.redhat.com/projects/ACM/summary/
1.9.2.4. 托管集群的 must-gather 复制链接链接已复制到粘贴板!
如果托管 control plane 集群出现问题,您可以运行 must-gather 命令来收集信息,以帮助您进行故障排除。
1.9.2.4.1. 关于托管集群的 must-gather 命令 复制链接链接已复制到粘贴板!
该命令为管理集群和托管集群生成输出。
多集群引擎 operator hub 集群中的数据:
- 集群范围的资源:这些资源是管理集群的节点定义。
-
hypershift-dump压缩文件:如果您需要与其他人员共享内容,该文件非常有用。 - 命名空间资源 :这些资源包括来自相关命名空间中的所有对象,如配置映射、服务、事件和日志。
- 网络日志: 这些日志包括 OVN 北向和南向数据库和每个数据库的状态。
- 托管的集群:此级别的输出涉及托管集群内的所有资源。
来自托管集群的数据:
- 集群范围的资源:这些资源包含所有集群范围的对象,如节点和 CRD。
- 命名空间资源 :这些资源包括来自相关命名空间中的所有对象,如配置映射、服务、事件和日志。
虽然输出不包含集群中的任何 secret 对象,但它可以包含对 secret 的名称的引用。
1.9.2.4.2. 先决条件 复制链接链接已复制到粘贴板!
要通过运行 must-gather 命令来收集信息,您必须满足以下条件:
-
您必须确保
kubeconfig文件已被加载,并指向 multicluster engine operator hub 集群。 - 您必须具有对 multicluster engine operator hub 集群的 cluster-admin 访问权限。
-
您必须具有
HostedCluster资源的 name 值,以及部署自定义资源的命名空间。
1.9.2.4.3. 为托管集群输入 must-gather 命令 复制链接链接已复制到粘贴板!
输入以下命令收集有关托管集群的信息。在命令中,
hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE参数是可选的;如果没有包括它,则命令会像在 default 命名空间(即集群)中运行。oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel8:v2.x /usr/bin/gather hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE hosted-cluster-name=HOSTEDCLUSTERNAME要将命令的结果保存到压缩文件中,请包含
--dest-dir=参数,将 NAME 替换为您要保存结果的目录的名称:NAMEoc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel8:v2.x /usr/bin/gather hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE hosted-cluster-name=HOSTEDCLUSTERNAME --dest-dir=NAME ; tar -cvzf NAME.tgz NAME
1.9.2.4.4. 在断开连接的环境中输入 must-gather 命令 复制链接链接已复制到粘贴板!
在断开连接的环境中,按照以下步骤运行 must-gather 命令:
- 在断开连接的环境中,将 RedHat operator 目录镜像镜像(mirror)到其 mirror registry 中。如需更多信息,请参阅 在断开连接的网络中安装。
运行以下命令以提取日志,从其 mirror registry 中引用镜像:
REGISTRY=registry.example.com:5000 IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel8@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8 oc adm must-gather --image=$IMAGE /usr/bin/gather hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE hosted-cluster-name=HOSTEDCLUSTERNAME --dest-dir=./data
1.9.2.4.5. 其他资源 复制链接链接已复制到粘贴板!
- 有关托管 control plane 故障排除的更多信息,请参阅 OpenShift Container Platform 文档中的 托管 control plane 故障排除。
1.9.3. 故障排除:将 day-two 节点添加到现有集群失败,并显示待处理的用户操作 复制链接链接已复制到粘贴板!
将节点或缩减到由 multicluster engine 为 Kubernetes operator 创建的现有集群中,且使用 Zero Touch Provisioning 或 Host inventory create 方法在安装过程中会失败。安装过程在发现阶段可以正常工作,但在安装阶段失败。
网络的配置失败。在集成控制台中的 hub 集群中看到 Pending 用户操作。在描述中,您可以看到它在重启步骤中失败。
有关失败的错误消息不准确,因为安装主机中运行的代理无法报告信息。
1.9.3.1. 症状:为第二天 worker 安装失败 复制链接链接已复制到粘贴板!
发现阶段后,主机将重启以继续安装,但它无法配置网络。检查以下症状和信息:
在集成控制台中的 hub 集群中,检查添加节点上的
Pending用户操作,并带有Rebooting指示符:This host is pending user action. Host timed out when pulling ignition. Check the host console... Rebooting在 Red Hat OpenShift Container Platform 配置受管集群中,检查现有集群的
MachineConfig。检查MachineConfig是否在以下目录中创建任何文件:-
/sysroot/etc/NetworkManager/system-connections/ -
/sysroot/etc/sysconfig/network-scripts/
-
-
在安装主机的终端中,检查失败的主机是否有以下消息:您可以使用
journalctl查看日志消息:
info: networking config is defined in the real root
info: will not attempt to propagate initramfs networking
如果您在日志中收到最后一条消息,则不会传播网络配置,因为它已在之前在 Symptom 中列出的文件夹中找到现有网络配置。
1.9.3.2. 解决问题:重新创建节点合并网络配置 复制链接链接已复制到粘贴板!
执行以下任务以在安装过程中使用正确的网络配置:
- 从 hub 集群中删除节点。
- 重复前面的流程,以同样的方式安装节点。
使用以下注解创建节点的
BareMetalHost对象:"bmac.agent-install.openshift.io/installer-args": "[\"--append-karg\", \"coreos.force_persist_ip\"]"
节点开始安装。在发现阶段后,节点会在现有集群的更改和初始配置之间合并网络配置。
1.9.4. 安装状态故障排除处于安装或待处理状态 复制链接链接已复制到粘贴板!
安装 multicluster engine operator 时,MultiClusterEngine 会一直处于 Installing 阶段,或者多个 pod 维护 Pending 状态。
1.9.4.1. 症状:一直处于 Pending 状态 复制链接链接已复制到粘贴板!
安装 MultiClusterEngine 后超过十分钟,来自 MultiClusterEngine 资源的 status.components 字段的一个或多个组件报告 ProgressDeadlineExceeded。这可能是集群中的资源限制的问题。
检查安装了 MultiClusterEngine 的命名空间中的 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.9.4.2. 解决问题: 调整 worker 节点大小 复制链接链接已复制到粘贴板!
如果您有这个问题,则需要使用更大或多个 worker 节点来更新集群。如需了解调整集群大小的信息,请参阅调整集群大小。
1.9.5. 重新安装失败的故障排除 复制链接链接已复制到粘贴板!
重新安装多集群引擎 operator 时,pod 不会启动。
1.9.5.1. 症状:重新安装失败 复制链接链接已复制到粘贴板!
如果在安装 multicluster engine operator 后 pod 没有启动,通常是因为之前安装 multicluster engine operator 的项目在卸载时无法正确删除。
在本例中,pod 在完成安装过程后没有启动。
1.9.5.2. 解决问题: 重新安装失败 复制链接链接已复制到粘贴板!
如果您有这个问题,请完成以下步骤:
- 按照 卸载 中的步骤,运行卸载过程来删除当前的组件。
- 按照安装 Helm 中的内容,安装 Helm CLI 二进制版本 3.2.0 或更新版本。
-
确保您的 Red Hat OpenShift Container Platform CLI 被配置为运行
oc命令。如需有关如何配置oc命令的更多信息 ,请参阅 OpenShift Container Platform 文档中的 OpenShift CLI 入门。 将以下脚本复制到一个文件中:
#!/bin/bash MCE_NAMESPACE=<namespace> oc delete multiclusterengine --all oc delete apiservice v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io oc delete crd discoveredclusters.discovery.open-cluster-management.io discoveryconfigs.discovery.open-cluster-management.io oc delete mutatingwebhookconfiguration ocm-mutating-webhook managedclustermutators.admission.cluster.open-cluster-management.io oc delete validatingwebhookconfiguration ocm-validating-webhook oc delete ns $MCE_NAMESPACE将
脚本中的 <namespace> 替换为安装 multicluster engine operator 的命名空间的名称。确保指定正确的命名空间,因为命名空间会被清理和删除。- 运行该脚本以删除以前安装中的内容。
- 运行安装。请参阅在线安装。
1.9.6. 离线集群的故障排除 复制链接链接已复制到粘贴板!
一些常见的原因会导致集群显示离线状态。
1.9.6.1. 症状:集群状态为离线 复制链接链接已复制到粘贴板!
完成创建集群的步骤后,您无法从 Red Hat Advanced Cluster Management 控制台访问集群,集群的状态为离线(offline)。
1.9.6.2. 解决问题: 集群状态为离线 复制链接链接已复制到粘贴板!
确定受管集群是否可用。您可以在 Red Hat Advanced Cluster Management 控制台的 Clusters 区域中进行检查。
如果不可用,请尝试重启受管集群。
如果受管集群状态仍处于离线状态,完成以下步骤:
-
在 hub 集群上运行
oc get managedcluster <cluster_name> -o yaml命令。将<cluster_name>替换为集群的名称。 -
找到
status. conditionss部分。 -
检查
type: ManagedClusterConditionAvailable信息并解决相关的问题。
-
在 hub 集群上运行
1.9.7. 受管集群导入失败的故障排除 复制链接链接已复制到粘贴板!
如果集群导入失败,您可以执行一些步骤来确定集群导入失败的原因。
1.9.7.1. 症状:导入的集群不可用 复制链接链接已复制到粘贴板!
完成导入集群的步骤后,您无法从控制台访问它。
1.9.7.2. 解决问题: 导入的集群不可用 复制链接链接已复制到粘贴板!
在尝试导入集群后,有几个可能的原因会导致导入集群的不可用。如果集群导入失败,请完成以下步骤,直到找到失败导入的原因:
在 hub 集群中,运行以下命令来确保导入控制器正在运行。
kubectl -n multicluster-engine get pods -l app=managedcluster-import-controller-v2您应该会看到两个正在运行的 pod。如果任何一个 pod 没有运行,请运行以下命令来查看日志以确定原因:
kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1在 hub 集群中,运行以下命令以确定受管集群导入 secret 是否由导入控制器成功生成:
kubectl -n <managed_cluster_name> get secrets <managed_cluster_name>-import如果导入 secret 不存在,请运行以下命令来查看导入控制器的日志条目,并确定它没有被创建的原因:
kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1 | grep importconfig-controller在 hub 集群中,如果您的受管集群是
local-cluster,或者由 Hive 置备,或者具有自动导入 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.8. 重新导入集群失败并显示未知颁发机构错误 复制链接链接已复制到粘贴板!
如果您在将受管集群重新导入到多集群引擎 operator hub 集群时遇到问题,请按照以下步骤排除此问题。
1.9.8.1. 症状:重新导入集群失败并显示未知颁发机构错误 复制链接链接已复制到粘贴板!
使用 multicluster engine operator 置备 OpenShift Container Platform 集群后,当更改或将 API 服务器证书添加到 OpenShift Container Platform 集群时,重新导入集群可能会失败,并显示 x509: certificate signed by unknown authority 错误。
1.9.8.2. 鉴别问题: 重新导入集群失败并显示未知颁发机构错误 复制链接链接已复制到粘贴板!
在重新导入受管集群后,运行以下命令在 multicluster engine operator hub 集群上获取导入控制器日志:
kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 -f
如果出现以下错误日志,受管集群 API 服务器证书可能会改变:
ERROR Reconciler error {"controller": "clusterdeployment-controller", "object": {"name":"awscluster1","namespace":"awscluster1"}, "namespace": "awscluster1", "name": "awscluster1", "reconcileID": "a2cccf24-2547-4e26-95fb-f258a6710d80", "error": "Get \"https://api.awscluster1.dev04.red-chesterfield.com:6443/api?timeout=32s\": x509: certificate signed by unknown authority"}
要确定受管集群 API 服务器证书是否已更改,请完成以下步骤:
运行以下命令,将
your-managed-cluster-name替换为受管集群的名称来指定受管集群名称:cluster_name=<your-managed-cluster-name>运行以下命令获取受管集群
kubeconfigsecret 名称:kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')运行以下命令,将
kubeconfig导出到新文件:oc -n ${cluster_name} get secret ${kubeconfig_secret_name} -ojsonpath={.data.kubeconfig} | base64 -d > kubeconfig.oldexport KUBECONFIG=kubeconfig.old运行以下命令,使用
kubeconfig从受管集群获取命名空间:oc get ns
如果您收到类似以下消息的错误,您的集群 API 服务器符已更改,且 kubeconfig 文件无效。
无法连接到服务器:x509: certificate signed by unknown authority
1.9.8.3. 解决问题: 重新导入集群失败并显示未知颁发机构错误 复制链接链接已复制到粘贴板!
受管集群管理员必须为受管集群创建一个新的有效的 kubeconfig 文件。
创建新的 kubeconfig 后,执行以下步骤为受管集群更新新的 kubeconfig :
运行以下命令来设置
kubeconfig文件路径和集群名称。将<path_to_kubeconfig> 替换为新kubeconfig文件的路径。将<managed_cluster_name> 替换为受管集群的名称:cluster_name=<managed_cluster_name> kubeconfig_file=<path_to_kubeconfig>运行以下命令来对新的
kubeconfig进行编码:kubeconfig=$(cat ${kubeconfig_file} | base64 -w0)注: 在 macOS 中运行以下命令:
kubeconfig=$(cat ${kubeconfig_file} | base64)运行以下命令来定义
kubeconfigjson 补丁:kubeconfig_patch="[\{\"op\":\"replace\", \"path\":\"/data/kubeconfig\", \"value\":\"${kubeconfig}\"}, \{\"op\":\"replace\", \"path\":\"/data/raw-kubeconfig\", \"value\":\"${kubeconfig}\"}]"运行以下命令,从受管集群检索您的管理员
kubeconfigsecret 名称:kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')运行以下命令,使用您的新
kubeconfig对管理员kubeconfigsecret 进行补丁:oc -n ${cluster_name} patch secrets ${kubeconfig_secret_name} --type='json' -p="${kubeconfig_patch}"
1.9.9. 对带有待处理导入状态的集群进行故障排除 复制链接链接已复制到粘贴板!
如果在集群的控制台上持续接收到 Pending import(待处理到)信息时,请按照以下步骤排除此问题。
1.9.9.1. 症状:集群处于待处理导入状态 复制链接链接已复制到粘贴板!
在使用 Red Hat Advanced Cluster Management 控制台导入一个集群后,出现在控制台中的集群带有 Pending import 状态。
1.9.9.2. 鉴别问题: 集群处于待处理导入状态 复制链接链接已复制到粘贴板!
在受管集群中运行以下命令查看有问题的 Kubernetes pod 的名称:
kubectl get pod -n open-cluster-management-agent | grep klusterlet-registration-agent在受管集群中运行以下命令查找错误的日志条目:
kubectl logs <registration_agent_pod> -n open-cluster-management-agent把 registration_agent_pod 替换为在第 1 步中获得的 pod 名称。
-
在返回的结果中搜索显示有网络连接问题的内容。示例包括:
no such host。
1.9.9.3. 解决问题: 集群处于待处理导入状态 复制链接链接已复制到粘贴板!
通过在 hub 集群中输入以下命令来检索有问题的端口号:
oc get infrastructure cluster -o yaml | grep apiServerURL确保来自受管集群的主机名可以被解析,并确保建立到主机和端口的出站连接。
如果无法通过受管集群建立通信,集群导入就不完整。受管集群的集群状态将会是 Pending import。
1.9.10. 证书更改后导入的集群离线故障排除 复制链接链接已复制到粘贴板!
虽然支持安装自定义的 apiserver 证书,但在更改证书前导入的一个或多个集群会处于offline 状态。
1.9.10.1. 症状:证书更改后集群处于离线状态 复制链接链接已复制到粘贴板!
完成更新证书 secret 的步骤后,在线的一个或多个集群现在在控制台中显示 离线状态。
1.9.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.9.10.3. 解决问题: 证书更改后集群处于离线状态 复制链接链接已复制到粘贴板!
如果您的受管集群是由 multicluster engine operator 创建的 local-cluster 或受管集群,则必须等待 10 分钟或更长时间恢复受管集群。
要立即恢复受管集群,您可以删除 hub 集群上的受管集群导入 secret,并使用 multicluster engine operator 恢复它。运行以下命令:
oc delete secret -n <cluster_name> <cluster_name>-import
将 < cluster_name > 替换为您要恢复的受管集群的名称。
如果要恢复使用 multicluster engine operator 导入的受管集群,请完成以下步骤再次导入受管集群:
在 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.9.11. 集群状态从离线变为可用的故障排除 复制链接链接已复制到粘贴板!
在没有对环境或集群进行任何手工更改的情况下,受管集群的状态在 offline(离线) 和 available(可用) 间转换。
1.9.11.1. 症状:集群状态从离线变为可用 复制链接链接已复制到粘贴板!
当将受管集群连接到 hub 集群的网络不稳定时,hub 集群所报告的受管集群的状态在离线和可用之间不断转换。
1.9.11.2. 解决问题: 集群状态从离线变为可用 复制链接链接已复制到粘贴板!
要尝试解决这个问题,请完成以下步骤:
输入以下命令在 hub 集群上编辑
ManagedCluster规格:oc edit managedcluster <cluster-name>将 cluster-name 替换为您的受管集群的名称。
-
在
ManagedCluster规格中增加leaseDurationSeconds的值。默认值为 5 分钟,但可能没有足够的时间来保持与网络问题的连接。为租期指定较长的时间。例如,您可以将这个值提高为 20 分钟。
1.9.12. VMware vSphere 上创建集群的故障排除 复制链接链接已复制到粘贴板!
如果您在 VMware vSphere 上创建 Red Hat OpenShift Container Platform 集群时遇到问题,请查看以下故障排除信息以查看它们是否解决了您的问题。
注:当集群创建过程在 VMware vSphere 上失败时,您将无法使用该链接来查看日志。如果发生这种情况,您可以通过查看 thehive-controllers pod 的日志来找出问题。hive-controllers 日志位于 hive 命名空间中。
1.9.12.1. 受管集群创建失败并显示证书 IP SAN 错误 复制链接链接已复制到粘贴板!
1.9.12.1.1. 症状: Managed 集群创建失败并显示证书 IP SAN 错误 复制链接链接已复制到粘贴板!
在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,并显示一个错误消息,显示证书 IP SAN 错误。
1.9.12.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.9.12.1.3. 解决问题: 管理的集群创建失败,并显示证书 IP SAN 错误 复制链接链接已复制到粘贴板!
使用 VMware vCenter 服务器完全限定主机名,而不是凭证中的 IP 地址。您还可以更新 VMware vCenter CA 证书以包含 IP SAN。
1.9.12.2. 受管集群创建失败并显示未知证书颁发机构 复制链接链接已复制到粘贴板!
1.9.12.2.1. 症状:管理集群创建失败并显示未知证书颁发机构 复制链接链接已复制到粘贴板!
在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,因为证书由未知颁发机构签名。
1.9.12.2.2. 鉴别问题: Managed 集群创建失败并显示未知证书颁发机构 复制链接链接已复制到粘贴板!
受管集群的部署失败,并在部署日志中返回以下错误:
Error: error setting up new vSphere SOAP client: Post https://vspherehost.com/sdk: x509: certificate signed by unknown authority"
1.9.12.2.3. 解决问题: 管理的集群创建失败并显示未知证书颁发机构 复制链接链接已复制到粘贴板!
确保您在创建凭证时从证书认证机构输入了正确的证书。
1.9.12.3. 受管集群创建带有过期证书失败 复制链接链接已复制到粘贴板!
1.9.12.3.1. 情况: 集群创建失败并显示过期的证书 复制链接链接已复制到粘贴板!
在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,因为证书已过期或者无效。
1.9.12.3.2. 鉴别问题: 管理的集群创建失败并显示过期的证书 复制链接链接已复制到粘贴板!
受管集群的部署失败,并在部署日志中返回以下错误:
x509: certificate has expired or is not yet valid
1.9.12.3.3. 解决问题: 管理的集群创建失败并显示过期的证书 复制链接链接已复制到粘贴板!
确保同步了 ESXi 主机上的时间。
1.9.12.4. 受管集群创建失败且没有标记权限 复制链接链接已复制到粘贴板!
1.9.12.4.1. 症状:管理集群创建失败且没有足够特权进行标记 复制链接链接已复制到粘贴板!
在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,因为没有足够的权限进行标记。
1.9.12.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.9.12.4.3. 解决问题: 管理的集群创建没有足够权限进行标记 复制链接链接已复制到粘贴板!
确保 VMware vCenter 所需的帐户权限正确。如需更多信息,请参阅在安装过程中删除的镜像 registry。
1.9.12.5. 受管集群创建失败并显示无效的 dnsVIP 复制链接链接已复制到粘贴板!
1.9.12.5.1. 症状: 受管集群创建失败并显示无效的 dnsVIP 复制链接链接已复制到粘贴板!
在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,因为存在无效的 dnsVIP。
1.9.12.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.9.12.5.3. 解决问题: 受管集群创建失败并显示无效的 dnsVIP 复制链接链接已复制到粘贴板!
从支持 VMware Installer Provisioned Infrastructure 的 OpenShift Container Platform 版本中选择一个发行镜像。
1.9.12.6. 受管集群创建带有不正确的网络类型失败 复制链接链接已复制到粘贴板!
1.9.12.6.1. 症状: 集群创建失败并显示不正确的网络类型 复制链接链接已复制到粘贴板!
在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,因为指定的网络类型不正确。
1.9.12.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.9.12.6.3. 解决问题: 受管集群创建失败并显示不正确的网络类型 复制链接链接已复制到粘贴板!
为指定的 VMware 集群选择一个有效的 VMware vSphere 网络类型。
1.9.12.7. 受管集群创建失败并显示磁盘更改错误 复制链接链接已复制到粘贴板!
1.9.12.7.1. 症状:因为错误处理磁盘更改导致添加 VMware vSphere 受管集群失败 复制链接链接已复制到粘贴板!
在 VMware vSphere 上创建新的 Red Hat OpenShift Container Platform 集群后,集群会失败,因为在处理磁盘更改时会出现错误。
1.9.12.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.9.12.7.3. 解决问题:因为错误处理磁盘更改导致 VMware vSphere 受管集群失败 复制链接链接已复制到粘贴板!
使用 VMware vSphere 客户端为用户授予Profile-driven Storage Privileges 的所有权限。
1.9.13. 集群在控制台中带有待处理或失败状态的故障排除 复制链接链接已复制到粘贴板!
如果您在控制台中看到您创建的集群的状态为 Pending 或 Failed,请按照以下步骤排除问题。
1.9.13.1. 症状:集群在控制台中带有待处理或失败状态 复制链接链接已复制到粘贴板!
在使用控制台创建新集群后,集群不会超过 Pending 状态或显示 Failed 状态。
1.9.13.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.9.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.9.14. OpenShift Container Platform 版本 3.11 集群导入失败的故障排除 复制链接链接已复制到粘贴板!
1.9.14.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|...
这通常是因为安装的 kubectl 命令行工具的版本为 1.11 或更早版本。运行以下命令,以查看您正在运行的 kubectl 命令行工具的版本:
kubectl version
如果返回的数据列出了 1.11 或更早版本,按照解决问题:OpenShift Container Platform 版本 3.11 集群导入失败中的内容进行解决。
您可以通过完成以下步骤之一解决这个问题:
安装
kubectl命令行工具的最新版本。-
下载
kubectl工具的最新版本:参阅 Kubernetes 文档中的安装和设置 kubectl。 -
升级
kubectl工具后再次导入集群。
-
下载
运行包含导入命令的文件。
- 启动 使用 CLI 导入受管集群 的步骤。
-
在创建用于导入集群的命令时,将该命令复制到名为
import.yaml的 YAML 文件中。 运行以下命令从文件中再次导入集群:
oc apply -f import.yaml
1.9.15. 带有降级条件的 Klusterlet 故障排除 复制链接链接已复制到粘贴板!
Klusterlet 降级条件可帮助诊断受管集群中的 Klusterlet 代理的状态。如果 Klusterlet 处于 degraded 条件,受管集群中的 Klusterlet 代理可能会出错,需要进行故障排除。对于设置为 True 的 Klusterlet 降级条件,请参见以下信息。
1.9.15.1. 症状:Klusterlet 处于降级状况 复制链接链接已复制到粘贴板!
在受管集群中部署 Klusterlet 后,KlusterletRegistrationDegraded 或 KlusterletWorkDegraded 条件会显示 True 的状态。
1.9.15.2. 鉴别问题: Klusterlet 处于降级状况 复制链接链接已复制到粘贴板!
在受管集群中运行以下命令查看 Klusterlet 状态:
kubectl get klusterlets klusterlet -oyaml-
检查
KlusterletRegistrationDegraded或KlusterletWorkDegraded以查看该条件是否被设置为True。请根据解决这个问题的内容处理降级问题。
1.9.15.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。注册代理将再次引导以获取新的 hub 集群 kubeconfig secret。 -
如果
KlusterletRegistrationDegraded显示为 True,且状况原因为 GetRegistrationDeploymentFailed 或 UnavailableRegistrationPod,您可以检查条件消息以获取问题详情并尝试解决。 -
如果
KlusterletWorkDegraded显示 True,且状况原因为 GetWorkDeploymentFailed 或 UnavailableWorkPod,您可以检查条件消息以获取问题详情并尝试解决。
1.9.16. 删除集群后命名空间会保留 复制链接链接已复制到粘贴板!
当您删除受管集群时,该命名空间通常会作为移除集群过程的一部分被删除。在个别情况下,命名空间会和其中的一些工件一起被保留。在这种情况下,您必须手动删除命名空间。
1.9.16.1. 症状:删除集群后命名空间被保留 复制链接链接已复制到粘贴板!
删除受管集群后,命名空间没有被删除。
1.9.16.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.9.17. 导入集群时出现自动 Auto-import-secret-exists 错误 复制链接链接已复制到粘贴板!
集群导入失败,并显示出错信息:auto import secret exists。
1.9.17.1. 症状:导入集群时出现 Auto import secret exists 错误 复制链接链接已复制到粘贴板!
当导入 hive 集群以进行管理时,会显示 auto-import-secret already exists 错误。
1.9.17.2. 解决问题:导入集群时出现 Auto import secret exists 错误 复制链接链接已复制到粘贴板!
当您试图导入之前管理的集群时,会出现此问题。如果出现这种情况,当您尝试重新导入集群时,secret 会发生冲突。
要临时解决这个问题,请完成以下步骤:
在 hub 集群中运行以下命令来手工删除存在的
auto-import-secret:oc delete secret auto-import-secret -n <cluster-namespace>将
cluster-namespace替换为集群的命名空间。- 使用集群导入简介 中的流程再次导入集群。
1.9.18. 在创建放置后缺少 PlacementDecision 进行故障排除 复制链接链接已复制到粘贴板!
如果在创建放置后没有生成 PlacementDescision,请按照以下步骤排除此问题。
1.9.18.1. 症状:创建放置后缺少 PlacementDecision 复制链接链接已复制到粘贴板!
创建 放置 后,不会自动生成一个 PlacementDescision。
1.9.18.2. 解决问题: 在创建放置后缺少 PlacementDecision 复制链接链接已复制到粘贴板!
要解决这个问题,请完成以下步骤:
运行以下命令检查
放置条件:kubectl describe placement <placement-name>将
placement-name替换为放置的名称。输出可能类似以下示例:
Name: demo-placement Namespace: default Labels: <none> Annotations: <none> API Version: cluster.open-cluster-management.io/v1beta1 Kind: Placement Status: Conditions: Last Transition Time: 2022-09-30T07:39:45Z Message: Placement configurations check pass Reason: Succeedconfigured Status: False Type: PlacementMisconfigured Last Transition Time: 2022-09-30T07:39:45Z Message: No valid ManagedClusterSetBindings found in placement namespace Reason: NoManagedClusterSetBindings Status: False Type: PlacementSatisfied Number Of Selected Clusters: 0在输出中检查
PlacementMisconfigured和PlacementSatisfied的Status:-
如果
PlacementMisconfiguredStatus为 true,则您的Placement具有配置错误。检查包含的消息,了解配置错误的详情以及如何解决它们。 -
如果
PlacementSatisfiedStatus为 false,则没有受管集群满足您的放置。检查包含的消息以获取更多详细信息以及如何解决错误。在上例中,放置命名空间中没有找到ManagedClusterSetBindings。
-
如果
您可以检查
Events中每个集群的分数,以了解某些具有较低分数的集群没有被选择。输出可能类似以下示例:Name: demo-placement Namespace: default Labels: <none> Annotations: <none> API Version: cluster.open-cluster-management.io/v1beta1 Kind: Placement Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal DecisionCreate 2m10s placementController Decision demo-placement-decision-1 is created with placement demo-placement in namespace default Normal DecisionUpdate 2m10s placementController Decision demo-placement-decision-1 is updated with placement demo-placement in namespace default Normal ScoreUpdate 2m10s placementController cluster1:0 cluster2:100 cluster3:200 Normal DecisionUpdate 3s placementController Decision demo-placement-decision-1 is updated with placement demo-placement in namespace default Normal ScoreUpdate 3s placementController cluster1:200 cluster2:145 cluster3:189 cluster4:200注: 放置控制器分配一个分数,并为每个过滤的
ManagedCluster生成事件。当集群分数更改时,放置控制器会生成新事件。
1.9.19. 对 Dell 硬件上的裸机主机发现失败的故障排除 复制链接链接已复制到粘贴板!
如果在 Dell 硬件上发现裸机主机失败,则集成的 Dell Remote Access Controller (iDRAC)可能会被配置为不允许来自未知证书颁发机构的证书。
1.9.19.1. 症状:在 Dell 硬件中发现裸机主机失败 复制链接链接已复制到粘贴板!
完成使用基板管理控制器发现裸机主机的步骤后,会显示类似如下的错误消息:
ProvisioningError 51s metal3-baremetal-controller Image provisioning failed: Deploy step deploy.deploy failed with BadRequestError: HTTP POST https://<bmc_address>/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia returned code 400. Base.1.8.GeneralError: A general error has occurred. See ExtendedInfo for more information Extended information: [
{"Message": "Unable to mount remote share https://<ironic_address>/redfish/boot-<uuid>.iso.", 'MessageArgs': ["https://<ironic_address>/redfish/boot-<uuid>.iso"], "MessageArgs@odata.count": 1, "MessageId": "IDRAC.2.5.RAC0720", "RelatedProperties": ["#/Image"], "RelatedProperties@odata.count": 1, "Resolution": "Retry the operation.", "Severity": "Informational"}
]
1.9.19.2. 解决问题: 在 Dell 硬件中发现裸机主机的故障 复制链接链接已复制到粘贴板!
iDRAC 配置为不接受来自未知证书颁发机构的证书。
要绕过这个问题,请完成以下步骤禁用主机 iDRAC 基板管理控制器上的证书验证:
- 在 iDRAC 控制台中,进入到 Configuration > Virtual media > Remote file share。
-
将 Expired 或无效证书操作的值更改为
Yes。
1.9.20. Minimal ISO 引导故障故障排除 复制链接链接已复制到粘贴板!
当您尝试引导最小 ISO 时可能会遇到问题。
1.9.20.1. 症状:最小 ISO 引导失败 复制链接链接已复制到粘贴板!
引导屏幕显示主机无法下载根文件系统镜像。
1.9.20.2. 解决问题: Minimal ISO 引导失败 复制链接链接已复制到粘贴板!
请参阅 OpenShift Container Platform 文档中的辅助安装程序 故障排除最小 ISO 引导失败,以了解如何排除此问题。
1.9.21. Red Hat OpenShift Virtualization 上托管集群的故障排除 复制链接链接已复制到粘贴板!
当您对 Red Hat OpenShift Virtualization 上的托管集群进行故障排除时,请从顶层 HostedCluster 和 NodePool 资源开始,然后处理堆栈,直到您找到根本原因。以下步骤可帮助您发现常见问题的根本原因。
1.9.21.1. 症状: HostedCluster 资源处于部分状态 复制链接链接已复制到粘贴板!
托管的 control plane 不会完全在线,因为 HostedCluster 资源待处理。
1.9.21.1.1. 鉴别问题: 检查先决条件、资源状况和节点和 operator 状态 复制链接链接已复制到粘贴板!
- 确保您满足 Red Hat OpenShift Virtualization 上托管集群的所有先决条件
-
查看
HostedCluster和NodePool资源中的条件,以了解防止进度的验证错误。 通过使用托管的集群的
kubeconfig文件,检查托管集群的状态:-
查看
oc get clusteroperators命令的输出以查看哪些集群操作器待处理。 -
查看
oc get nodes命令的输出,以确保 worker 节点就绪。
-
查看
1.9.21.2. 症状:没有 worker 节点被注册 复制链接链接已复制到粘贴板!
托管的 control plane 不会完全在线,因为托管的 control plane 没有注册 worker 节点。
1.9.21.2.1. 鉴别问题: 检查托管 control plane 的各种部分的状态 复制链接链接已复制到粘贴板!
-
查看
HostedCluster和NodePool条件,以了解问题可能是什么。 输入以下命令查看
NodePool资源的 KubeVirt worker 节点虚拟机(VM)状态:oc get vm -n <namespace>如果虚拟机处于 provisioning 状态,请输入以下命令来查看 VM 命名空间中的 CDI 导入 pod,以了解 importer pod 尚未完成的原因:
oc get pods -n <namespace> | grep "import"如果虚拟机处于启动状态,请输入以下命令查看 virt-launcher pod 的状态:
oc get pods -n <namespace> -l kubevirt.io=virt-launcher如果 virt-launcher pod 处于待处理状态,请调查 pod 没有调度的原因。例如,运行 virt-launcher pod 可能没有足够的资源。
- 如果虚拟机正在运行,但它们没有注册为 worker 节点,请使用 Web 控制台获得对受影响虚拟机的 VNC 访问。VNC 输出指示是否应用了 ignition 配置。如果虚拟机在启动时无法访问托管的 control plane ignition 服务器,则虚拟机无法正确置备。
- 如果应用了 ignition 配置,但虚拟机仍然没有注册为节点,请参阅 识别问题:访问 VM 控制台日志 以了解如何在启动时访问虚拟机控制台日志。
1.9.21.3. 症状: Worker 节点处于 NotReady 状态 复制链接链接已复制到粘贴板!
在集群创建过程中,在部署网络堆栈时,节点会临时进入 NotReady 状态。该过程的这一部分是正常的。但是,如果这部分进程需要超过 15 分钟,则可能会出现问题。
1.9.21.3.1. 鉴别问题:检查节点对象和 pod 复制链接链接已复制到粘贴板!
输入以下命令查看节点对象中的条件,并确定节点未就绪的原因:
oc get nodes -o yaml输入以下命令查找集群中的 pod 失败:
oc get pods -A --field-selector=status.phase!=Running,status,phase!=Succeeded
1.9.21.4. 症状:入口和控制台集群操作器不会上线 复制链接链接已复制到粘贴板!
托管的 control plane 不会完全在线,因为 Ingress 和控制台集群 Operator 没有在线。
1.9.21.4.1. 鉴别问题: 检查通配符 DNS 路由和负载均衡器 复制链接链接已复制到粘贴板!
如果集群使用默认 Ingress 行为,请输入以下命令来确保在托管虚拟机(VM)的 OpenShift Container Platform 集群中启用了通配符 DNS 路由:
oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'如果您将自定义基域用于托管的 control plane,请完成以下步骤:
- 确保负载均衡器正确以 VM pod 为目标。
- 确保通配符 DNS 条目以负载均衡器 IP 为目标。
1.9.21.5. 症状:托管集群的负载均衡器服务不可用 复制链接链接已复制到粘贴板!
托管的 control plane 不会完全在线,因为负载均衡器服务不可用。
1.9.21.5.1. 鉴别问题: 检查事件、详情和 kccm pod 复制链接链接已复制到粘贴板!
- 查找与托管集群中的负载均衡器服务关联的事件和详情。
默认情况下,托管集群的负载均衡器由托管的 control plane 命名空间中的 kubevirt-cloud-controller-manager 处理。确保 kccm pod 在线,并查看其日志中是否有错误或警告。要识别托管的 control plane 命名空间中的 kccm pod,请输入以下命令:
oc get pods -n <hosted-control-plane-namespace> -l app=cloud-controller-manager
1.9.21.6. 症状: 托管集群 PVC 不可用 复制链接链接已复制到粘贴板!
托管的 control plane 不会完全在线,因为托管集群的持久性卷声明(PVC)不可用。
1.9.21.6.1. 鉴别问题: 检查 PVC 事件和详情,以及组件日志 复制链接链接已复制到粘贴板!
- 查找与 PVC 关联的事件和详情,以了解发生哪些错误。
如果 PVC 无法附加到 pod,请查看托管集群中 kubevirt-csi-node daemonset 组件的日志,以进一步调查问题。要为每个节点识别 kubevirt-csi-node pod,请输入以下命令:
oc get pods -n openshift-cluster-csi-drivers -o wide -l app=kubevirt-csi-driver如果 PVC 无法绑定到持久性卷(PV),查看托管 control plane 命名空间中的 kubevirt-csi-controller 组件的日志。要识别托管 control plane 命名空间中的 kubevirt-csi-controller pod,请输入以下命令:
oc get pods -n <hcp namespace> -l app=kubevirt-csi-driver
1.9.21.7. 症状:虚拟机节点没有正确加入集群 复制链接链接已复制到粘贴板!
托管的 control plane 不会完全在线,因为虚拟机节点没有正确加入集群。
1.9.21.7.1. 鉴别问题: 访问虚拟机控制台日志 复制链接链接已复制到粘贴板!
要访问 VM 控制台日志,请完成 如何获取 OpenShift Virtualization Hosted Control Plane 集群部分虚拟机的串口控制台日志的步骤。
1.9.22. 裸机上托管集群故障排除 复制链接链接已复制到粘贴板!
当您在裸机上对托管集群进行故障排除时,请执行以下步骤来发现常见问题的根本原因。
1.9.22.1. 症状:无法将节点添加到裸机上的托管 control plane 中 复制链接链接已复制到粘贴板!
当您使用 Assisted Installer 置备的节点扩展托管的 control plane 集群时,主机无法拉取包含端口 22642 的 URL。对于托管 control plane,该 URL 无效,并表示集群存在问题。
1.9.22.2. 鉴别问题: 节点无法添加到裸机上的托管 control plane 复制链接链接已复制到粘贴板!
要确定这个问题,请查看 assisted-service 日志:
oc logs -n multicluster-engine <assisted_service_pod_name>1 - 1
- 指定 Assisted Service pod 名称。
在日志中查找类似这些示例的错误:
error="failed to get pull secret for update: invalid pull secret data in secret pull-secret"pull secret must contain auth for \"registry.redhat.io\"
1.9.22.3. 解决问题: 无法将节点添加到裸机上的托管 control plane 复制链接链接已复制到粘贴板!
- 要解决这个问题,请按照 将 pull secret 添加到命名空间 中的说明进行操作。