Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

1.2. 已知问题

查看 Red Hat Advanced Cluster Management for Kubernetes 中的已知问题。以下列表包含本发行版本的已知问题，或从上一版本中继承的问题。对于 Red Hat OpenShift Container Platform 集群，请参阅 OpenShift Container Platform 已知问题。

1.2.1. 已知的与文档相关的问题
复制链接

1.2.2. 已知的与安装相关的问题
复制链接

将 Red Hat Advanced Cluster Management 升级到新版本后，属于 StatefulSet 的少数 pod 可能会处于 failed 状态。这个问题不经常出现，是由一个已知的 Kubernetes 问题造成的。

这个问题的一个临时解决方案是删除失败的 pod。Kubernetes 会自动使用正确的设置重新启动它。

当 OpenShift Container Platform 集群处于升级阶段时，集群 Pod 会被重启，并且集群可能在大约 1 到 5 分钟之内会处于升级失败状态。这个行为是正常的，在几分钟后自动解决。

从 2.4.x 升级到 2.5.0 后，两个集群 curator 控制器可能会同时运行。为 Cluster Lifecycle Ansible 集成的一些 prehook 和 posthook 创建了两个或多个 AnsibleJob。请参阅以下流程来解决这个问题：

  1. 检查是否有两个集群 curator 控制器正在运行。运行以下命令，其中包含来自多集群引擎 operator 的 multicluster-engine 命名空间，以及 open-cluster-management 命名空间： 

    kubectl -n multicluster-engine get deploy cluster-curator-controller
    Copy to Clipboard Toggle word wrap 
    kubectl -n open-cluster-management get deploy cluster-curator-controller
    Copy to Clipboard Toggle word wrap

  2. 如果两个集群 curator 控制器都在运行，删除 open-cluster-management 命名空间中的 cluster-curator-controller。运行以下命令： 

    kubectl -n open-cluster-management delete deploy cluster-curator-controller
    Copy to Clipboard Toggle word wrap

1.2.2.4. Create MultiClusterEngine 按钮无法正常工作
复制链接

在 Red Hat OpenShift Container Platform 控制台中安装 Red Hat Advanced Cluster Management for Kubernetes 后，会出现一个带有以下信息的弹出窗口：

MultiClusterEngine required

创建一个 MultiClusterEngine 实例来使用这个 Operator。

弹出窗口中的 Create MultiClusterEngine 按钮可能无法正常工作。要临时解决这个问题，在 Provided APIs 部分的 MultiClusterEngine 标题中选择 Create instance。

1.2.3. 已知的与 Web 控制台相关的问题
复制链接

虽然 Red Hat Advanced Cluster Management 版本 2.5.2 及更高版本支持在 Red Hat OpenShift Container Platform 版本 4.11 上支持 2.5.x 版本，但 Red Hat Advanced Cluster Management 2.5.x 不支持 dark 模式。在设置中禁用 dark 模式，或升级到 Red Hat Advanced Cluster Management 版本 2.6 来启用 dark 模式。

虽然 multicluster engine for Kubernetes operator 2.0.2 及更新版本，但在 Red Hat OpenShift Container Platform 版本 4.11 上支持更新的 2.0.x 版本，但 multicluster engine for Kubernetes operator 2.0.x 不支持 dark 模式。在设置中禁用 dark 模式，或升级到 multicluster engine for Kubernetes operator 版本 2.1 来启用 dark 模式。

1.2.3.3. LDAP 用户名是区分大小写的
复制链接

LDAP 用户名是区分大小写的。使用的名称必须与在 LDAP 目录中配置的方法完全相同。

该产品支持 Mozilla Firefox 74.0 或 Linux、macOS 和 Windows 提供的最新版本。为了获得最好的兼容性，请升级至最新版本。

1.2.3.5. 搜索自定义中的存储大小限制
复制链接

当您更新 searchcustomization CR 中的存储大小时，PVC 配置不会改变。如果您需要更新存储大小，使用以下命令更新 PVC（<storageclassname>-search-redisgraph-0）： 

oc edit pvc <storageclassname>-search-redisgraph-0
Copy to Clipboard Toggle word wrap

1.2.3.6. 搜索查询解析错误
复制链接

如果环境变大，需要更多测试进行扩展，搜索查询可能会超时，导致解析错误消息。这个错误会在等待了搜索查询 30 秒后显示。

使用以下命令扩展超时时间： 

kubectl annotate route multicloud-console haproxy.router.openshift.io/timeout=Xs
Copy to Clipboard Toggle word wrap

1.2.3.7. 无法编辑集群集的命名空间绑定
复制链接

当您为带有 admin 角色的集群集编辑命名空间绑定时，您可能会遇到类似以下消息的错误：

ResourceError: managedclustersetbindings.cluster.open-cluster-management.io "<cluster-set>" is forbidden: User "<user>" cannot create/delete resource "managedclustersetbindings" in API group "cluster.open-cluster-management.io" in the namespace "<namespace>".

要解决这个问题，请确保还有权在您要绑定的命名空间中创建或删除 ManagedClusterSetBinding 资源。角色绑定只允许将集群集绑定到命名空间。

1.2.3.8. 集群详情中的假扩展警报
复制链接

当您在控制台中查看集群详情时，可能会在 Nodes 或 Machine pool 选项卡中看到以下信息：

worker 节点当前正在从这个集群中移除。点 View machine 按钮查看扩展操作的状态（在此控制台中反映更改可能需要几分钟时间）。

如果没有机器池，则会出现使用 User Provisioned Infrastructure (UPI) 安装的供应商，忽略假的警报。当存在不是 control plane 一部分的 worker 节点时，会出现警报。如果 worker 节点直接添加到集群中，而不是扩展机器池，则可以使用 Installer Provisioned Infrastructure (IPI) 安装来置备的集群错误警报。

1.2.4. 已知的可观察性问题
复制链接

当各种 hub 集群使用相同的 S3 存储部署 Red Hat Advanced Cluster Management observability 时，可以在 Kubernetes/Service-Level Overview/API Server 仪表板中检测并显示重复的 local-clusters。重复的集群在以下面板中影响结果： Top Clusters、超过 SLO 的集群数，以及满足 SLO 的集群数量。local-clusters 是与共享 S3 存储关联的唯一集群。要防止多个 local-clusters 显示在仪表板中，建议每个唯一的 hub 集群使用针对 hub 集群的 S3 存储桶来部署可观察性。

1.2.4.2. Observability endpoint operator 无法拉取镜像
复制链接

如果您创建一个 pull-secret 用于部署到 MultiClusterObservability CustomResource（CR），且 open-cluster-management-observability 命名空间中没有 pull-secret，则 observability endpoint operator 会失败。当您导入新集群或导入使用 Red Hat Advanced Cluster Management 创建的 Hive 集群时，需要在受管集群上手动创建 pull-image secret。

如需更多信息，请参阅启用可观察性。

1.2.4.3. 没有来自 ROKS 和 HyperShift 集群的数据
复制链接

Red Hat Advanced Cluster Management observability 不会在内置仪表板中显示 ROKS 集群和 HyperShift 集群中的数据。这是因为 ROKS 和 HyperShift 不会从它们管理的服务器公开任何 API 服务器指标。以下 Grafana 仪表板包含不支持 ROKS 和 HyperShift 集群的面板： Kubernetes/API 服务器,Kubernetes/Compute Resources/Workload,Kubernetes/Compute Resources/Namespace(Workload)

对于 ROKS 集群和 HyperShift 集群，Red Hat Advanced Cluster Management observability 不会在仪表板的 etcd 面板中显示数据。

1.2.4.5. search-collector pod 的高 CPU 使用率
复制链接

当在管理 1000 个集群的 hub 集群中禁用搜索时，search-collector pod 会因为内存不足(OOM)而崩溃。完成以下步骤：

  1. 如果在 hub 集群上禁用了搜索，这意味着没有部署 search-redisgraph-pod，通过将 search-collector 部署缩减为 0 个副本来减少内存用量。
  2. 如果在 hub 集群上启用了搜索，这意味着部署了 search-redisgraph-pod，请编辑 search-collector 部署来增加分配的内存。

在某些情况下，搜索 Pod 不会在证书更改后自动重新部署。这会导致服务 pod 间的证书不匹配，进而导致 Transfer Layer Security (TLS) 握手失败。要解决这个问题，重启搜索 Pod 以重置证书。

1.2.4.7. Grafana 控制台中没有指标数据
复制链接

  • 注解查询在 Grafana 控制台中会失败：

    当在 Grafana 控制台中搜索特定注解时，您可能会因为已过期的令牌收到以下错误消息：

    "Annotation Query Failed"

    重新刷新浏览器，验证您是否已登录到 hub 集群。

  • rbac-query-proxy pod 中的错误：

    由于未授权访问 managedcluster 资源，您可能会在查询集群或项目时收到以下错误：

    no project or cluster found

    检查角色权限并进行相应的更新。如需更多信息，请参阅基于角色的访问控制。

1.2.4.8. 受管集群上的 Prometheus 数据丢失
复制链接

默认情况下，OpenShift 上的 Prometheus 使用临时存储。Prometheus 会在重启时丢失所有指标数据。

如果在由 Red Hat Advanced Cluster Management 管理的 OpenShift Container Platform 受管集群上启用或禁用了可观察性，observability 端点 Operator 会添加额外的 alertmanager 配置来自动重启本地 Prometheus，以此更新 cluster-monitoring-config ConfigMap。

1.2.4.9. Error ingesting out-of-order samples
复制链接

Observability receive pod 报告以下出错信息： 

Error on ingesting out-of-order samples
Copy to Clipboard Toggle word wrap

错误消息表示，在指标收集间隔期间，由受管集群发送的时间序列数据比在之前的集合间隔发送的时间序列数据旧。当出现这个问题时，Thanos 接收器会丢弃数据，这可能会在 Grafana 仪表板中显示的数据中造成差距。如果经常看到这个错误，建议将指标收集间隔增加到一个更高的值。例如，您可以将间隔增加到 60 秒。

只有在时间序列间隔被设置为较低值（如 30 秒）时，才会注意到这个问题。请注意，当指标收集间隔被设置为默认值 300 秒时，不会看到这个问题。

1.2.4.10. Grafana 部署在受管集群中失败
复制链接

如果清单的大小超过 50 千字节，Grafana 实例不会部署到受管集群。在部署了可观察性后，只有 local-cluster 出现在 Grafana 中。

1.2.5. 已知的与集群管理相关的问题
复制链接

请查看以下与集群管理相关的已知问题和限制：

当使用裸机供应商并以断开连接安装的方式创建集群时，您必须将所有设置保存在 Configuration for disconnected installation 部分的凭证中。您不能在集群创建控制台编辑器中输入它们。

当使用 VMware vSphere 或 Red Hat OpenStack Platform 供应商和断开连接的安装创建集群时，如果需要一个证书才能访问镜像 registry，您必须在断开连接的安装配置部分的附加信任捆绑包字段中输入它。如果在集群创建控制台编辑器中输入该证书，它将被忽略。

当为裸机、VMware vSphere 或 Red Hat OpenStack Platform 供应商创建凭证时，请注意，断开连接的安装的代理和配置中的附加信任捆绑包字段包含了相同的值，因为安装程序无法区分证书。您仍然可以独立使用这些功能。如果代理和断开连接的安装需要不同的证书，您可以在字段中输入多个证书。

当您从 hub 集群中删除 VolSync ManagedClusterAddOn 时，它会删除受管集群上的 VolSync operator 订阅，但不会删除集群服务版本(CSV)。要从受管集群中删除 CSV，请在您要删除 VolSync 的每个受管集群中运行以下命令： 

oc delete csv -n openshift-operators volsync-product.v0.4.0
Copy to Clipboard Toggle word wrap

如果您安装了不同版本的 VolSync，请将 v0.4.0 替换为您的安装版本。

当您使用 sushy-tools 在裸机上置备受管集群时，置备可能会失败，并显示 虚拟介质 cd 查询返回 500 错误。对于长时间运行的集群，使用 sushy-tools 无法保证它是可靠的。

请确保您使用 sushy-tools 的最新版本，并重新启动 sushy 模拟器来解决这个问题。

当您在运行 OpenShift Container Platform 版本 4.10 的双堆栈 hub 上置备裸机集群时，provision 会失败并显示以下错误消息：'timeout reached while the node'。要避免这个问题，请在 install-config.yaml 文件中禁用 provisioning 网络，如下例所示： 

platform:
  baremetal:
    provisioningNetwork: "Disabled"
Copy to Clipboard Toggle word wrap

如需有关 provisioning 网络的更多信息，请参阅 OpenShift Container Platform 文档中的使用 provisioning 网络进行部署。

1.2.5.6. 删除受管集群集不会自动删除其标签
复制链接

删除 ManagedClusterSet 后，添加到每个受管集群的标签不会被自动删除。从已删除受管集群集中包含的每个受管集群手动删除该标签。该标签类似以下示例：cluster.open-cluster-management.io/clusterset:<ManagedClusterSet Name>。

1.2.5.7. ClusterClaim 错误
复制链接

如果您针对 ClusterPool 创建 Hive ClusterClaim 并手动将 ClusterClaimspec 生命周期字段设置为无效的 golang 时间值，Red Hat Advanced Cluster Management 会停止履行并协调所有 ClusterClaims，而不只是格式不正确的声明。

如果发生这个错误，您可以在 clusterclaim-controller pod 日志中看到以下内容，它是一个带有池名称和无效生命周期的特定示例： 

E0203 07:10:38.266841       1 reflector.go:138] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:224: Failed to watch *v1.ClusterClaim: failed to list *v1.ClusterClaim: v1.ClusterClaimList.Items: []v1.ClusterClaim: v1.ClusterClaim.v1.ClusterClaim.Spec: v1.ClusterClaimSpec.Lifetime: unmarshalerDecoder: time: unknown unit "w" in duration "1w", error found in #10 byte of ...|time":"1w"}},{"apiVe|..., bigger context ...|clusterPoolName":"policy-aas-hubs","lifetime":"1w"}},{"apiVersion":"hive.openshift.io/v1","kind":"Cl|...
Copy to Clipboard Toggle word wrap

您可以删除无效的声明。

如果删除了不正确的声明，则声明可以在不需要进一步交互的情况下再次成功进行协调。

1.2.5.8. 产品频道与置备的集群不同步
复制链接

clusterimageset 处于 fast 频道，但置备的集群处于 stable 频道。目前，产品不会将 频道 同步到置备的 OpenShift Container Platform 集群。

进入 OpenShift Container Platform 控制台中的正确频道。点 Administration > Cluster Settings > Details Channel。

恢复受管集群使用自定义 CA 证书的 hub 集群的备份后，受管集群和 hub 集群之间的连接可能会失败。这是因为在恢复的 hub 集群上没有备份 CA 证书。要恢复连接，将受管集群的命名空间中自定义 CA 证书信息复制到恢复的 hub 集群上的 <managed_cluster>-admin-kubeconfig secret。

提示： 如果您在创建备份副本前将此 CA 证书复制到 hub 集群，备份副本会包括 secret 信息。当使用备份副本来恢复时，hub 和受管集群之间的连接会自动完成。

1.2.5.10. local-cluster 可能无法自动重新创建
复制链接

如果在 disableHubSelfManagement 被设置为 false 时删除 local-cluster，则 MulticlusterHub operator 会重新创建 local-cluster。分离 local-cluster 后，可能不会自动重新创建 local-cluster。

  • 要解决这个问题，修改由 MulticlusterHub operator 监控的资源。请参见以下示例： 

    oc delete deployment multiclusterhub-repo -n <namespace>
    Copy to Clipboard Toggle word wrap
  • 要正确分离 local-cluster，在 MultiClusterHub 中将 disableHubSelfManagement 设置为 true。

1.2.5.11. 在创建内部集群时需要选择子网
复制链接

当使用 Red Hat Advanced Cluster Management 控制台创建内部集群时，您必须为集群选择一个可用子网。它没有标记为必填字段。

1.2.5.12. Google Cloud Platform 上的集群置备失败
复制链接

当您尝试在 Google Cloud Platform(GCP)上置备集群时，可能会失败并显示以下错误： 

Cluster initialization failed because one or more operators are not functioning properly.
The cluster should be accessible for troubleshooting as detailed in the documentation linked below,
https://docs.openshift.com/container-platform/latest/support/troubleshooting/troubleshooting-installations.html
The 'wait-for install-complete' subcommand can then be used to continue the installation
Copy to Clipboard Toggle word wrap

您可以通过在 GCP 项目中启用 网络安全 API 来解决这个问题，它允许集群安装继续进行。

当使用 Infrastructure Operator 创建 OpenShift Container Platform 集群时，ISO 镜像的文件名可能会太长。镜像名称长会导致镜像置备和集群置备失败。要确定这是否是问题，请完成以下步骤：

  1. 运行以下命令，查看您要置备的集群的裸机主机信息： 

    oc get bmh -n <cluster_provisioning_namespace>
    Copy to Clipboard Toggle word wrap

  2. 运行 describe 命令以查看错误信息： 

    oc describe bmh -n <cluster_provisioning_namespace> <bmh_name>
    Copy to Clipboard Toggle word wrap

  3. 类似以下示例的错误表示文件名的长度问题： 

    Status:
  Error Count:    1
  Error Message:  Image provisioning failed: ... [Errno 36] File name too long ...
    Copy to Clipboard Toggle word wrap

如果出现问题，通常位于以下 OpenShift Container Platform 版本上，因为基础架构操作员不使用镜像服务：

  • 4.8.17 及更早版本
  • 4.9.6 及更早版本

为了避免这个错误，将 OpenShift Container Platform 升级到 4.8.18 或更高版本，或 4.9.7 或更高版本。

1.2.5.14. 无法休眠 Azure Government 集群
复制链接

当您尝试休眠 Azure Government 集群时，休眠会失败，并显示添加到置备 pod 日志中的以下错误： 

Confidential Client is not supported in Cross Cloud request
Copy to Clipboard Toggle word wrap

当您意外尝试以不同名称的集群形式重新导入名为 local-cluster 的集群时，local-cluster 和重新导入的集群的状态将 离线。

要从这个问题单中恢复，请完成以下步骤：

  1. 在 hub 集群中运行以下命令，以临时编辑 hub 集群的自助管理设置： 

    oc edit mch -n open-cluster-management multiclusterhub
    Copy to Clipboard Toggle word wrap
  2. 添加 spec.disableSelfManagement=true 设置。

  3. 在 hub 集群中运行以下命令以删除并重新部署 local-cluster： 

    oc delete managedcluster local-cluster
    Copy to Clipboard Toggle word wrap

  4. 输入以下命令删除 local-cluster 管理设置： 

    oc edit mch -n open-cluster-management multiclusterhub
    Copy to Clipboard Toggle word wrap
  5. 删除之前添加的 spec.disableSelfManagement=true。

当满足以下任一条件时，配置为自动置备受管集群的 AnsibleJob 模板可能会失败：

  • hub 集群启用了集群范围代理。
  • Ansible Tower 只能通过代理来访问。

如果您通过安装 klusterlet operator 导入受管集群，klusterlet Operator 的版本必须与 hub 集群的版本相同，或者 klusterlet Operator 将无法正常工作。

1.2.5.18. 无法手动删除受管集群命名空间
复制链接

您无法手动删除受管集群的命名空间。受管集群命名空间会在受管集群分离后自动删除。如果在分离受管集群前手动删除受管集群命名空间，受管集群会在删除受管集群后显示持续终止状态。要删除此正在终止的受管集群，请从分离的受管集群中手动删除终结器。

1.2.5.19. 升级到 2.3 后无法更改集群中的凭证
复制链接

将 Red Hat Advanced Cluster Management 升级到 2.3 后，您无法在升级前更改由 Red Hat Advanced Cluster Management 创建和管理的任何受管集群的凭证 secret。

1.2.5.20. hub 集群和受管集群的时钟未同步
复制链接

hub 集群和管理集群的时间可能会不同步，在控制台中显示 unknown，当在几分钟内会变为 available。确保正确配置了 Red Hat OpenShift Container Platform hub 集群时间。请参阅 自定义节点。

您无法导入 IBM OpenShift Container Platform Kubernetes Service 版本 3.11 集群。支持 IBM OpenShift Kubernetes Service 的更新的版本。

当您分离 OpenShift Container Platform 3.11 上的受管集群时，open-cluster-management-agent 命名空间不会被自动删除。运行以下命令来手动删除命名空间： 

oc delete ns open-cluster-management-agent
Copy to Clipboard Toggle word wrap

当更改您的云供应商访问密钥时，置备的集群访问密钥不会在命名空间中更新。当凭证在托管受管集群的云供应商过期并尝试删除受管集群时，需要此项。如果发生了这种情况，请为您的云供应商运行以下命令来更新访问密钥：

  • Amazon Web Services (AWS) 

    oc patch secret {CLUSTER-NAME}-aws-creds -n {CLUSTER-NAME} --type json -p='[{"op": "add", "path": "/stringData", "value":{"aws_access_key_id": "{YOUR-NEW-ACCESS-KEY-ID}","aws_secret_access_key":"{YOUR-NEW-aws_secret_access_key}"} }]'
    Copy to Clipboard Toggle word wrap

  • Google Cloud Platform (GCP)

    在试图销毁集群时如果出现多个重复的 Invalid JWT Signature 日志错误信息，则代表发生了这个问题。如果您的日志包含此消息，请获取新的 Google Cloud Provider 服务帐户 JSON 密钥并输入以下命令： 

    oc set data secret/<CLUSTER-NAME>-gcp-creds -n <CLUSTER-NAME> --from-file=osServiceAccount.json=$HOME/.gcp/osServiceAccount.json
    Copy to Clipboard Toggle word wrap

    将 CLUSTER-NAME 替换为集群的名称。

    将文件 $HOME/.gcp/osServiceAccount.json 替换为包含新 Google Cloud Provider 服务帐户 JSON 密钥的文件的路径。

  • Microsoft Azure 

    oc set data secret/{CLUSTER-NAME}-azure-creds -n {CLUSTER-NAME} --from-file=osServiceAccount.json=$HOME/.azure/osServiceAccount.json
    Copy to Clipboard Toggle word wrap

  • VMware vSphere 

    oc patch secret {CLUSTER-NAME}-vsphere-creds -n {CLUSTER-NAME} --type json -p='[{"op": "add", "path": "/stringData", "value":{"username": "{YOUR-NEW-VMware-username}","password":"{YOUR-NEW-VMware-password}"} }]'
    Copy to Clipboard Toggle word wrap

1.2.5.25. 销毁集群的进程没有完成
复制链接

当销毁受管集群时，在一小时后仍然继续显示 Destroying 状态，且集群不会被销毁。要解决这个问题请完成以下步骤：

  1. 手动确保云中没有孤立的资源,，且清理与受管集群关联的所有供应商资源。

  2. 输入以下命令为正在删除的受管集群打开 ClusterDeployment： 

    oc edit clusterdeployment/<mycluster> -n <namespace>
    Copy to Clipboard Toggle word wrap

    将 mycluster 替换为您要销毁的受管集群的名称。

    使用受管集群的命名空间替换 namespace。

  3. 删除 hive.openshift.io/deprovision finalizer，以强制停止尝试清理云中的集群资源的进程。
  4. 保存您的更改，验证 ClusterDeployment 是否已不存在。

  5. 运行以下命令手动删除受管集群的命名空间： 

    oc delete ns <namespace>
    Copy to Clipboard Toggle word wrap

    使用受管集群的命名空间替换 namespace。

您不能使用 Red Hat Advanced Cluster Management 控制台升级 OpenShift Container Platform Dedicated 环境中的 OpenShift Container Platform 受管集群。

当 Red Hat Advanced Cluster Management for Kubernetes hub 集群在 IBM Power 或 IBM Z 系统上运行时，您无法使用 Ansible Tower 集成，因为 Ansible Automation Platform Resource Operator 不提供 ppc64le 或 s390x 镜像。

Red Hat OpenShift Container Platform 集群和非 OpenShift Container Platform 集群都支持 pod 日志功能，但非 OpenShift Container Platform 集群需要启用 LoadBalancer 来使用该功能。完成以下步骤以启用 LoadBalancer：

  1. 云供应商有不同的 LoadBalancer 配置。有关更多信息，请访问您的云供应商文档。
  2. 检查 loggingEndpoint 是否显示 managedClusterInfo 状态来验证 Red Hat Advanced Cluster Management 上是否启用了 LoadBalancer。

  3. 运行以下命令，以检查 loggingEndpoint.IP 或 loggingEndpoint.Host 是否具有有效的 IP 地址或主机名： 

    oc get managedclusterinfo <clusterName> -n <clusterNamespace> -o json | jq -r '.status.loggingEndpoint'
    Copy to Clipboard Toggle word wrap

如需有关 LoadBalancer 类型的更多信息，请参阅 Kubernetes 文档中的 Service 页面。

1.2.5.30. 升级后，cluster-proxy-addon 不会启动
复制链接

从 2.4.x 升级到 2.5.0 后，cluster-proxy-addon 不会启动，cluster-proxy-addon-manager 会引发一个 nil 指针异常。

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

  1. 禁用 cluster-proxy-addon。请参阅高级配置以了解更多信息。
  2. 从 open-cluster-management 命名空间中删除 cluster-proxy-signer secret。
  3. 启用 cluster-proxy-addon。

1.2.6. 已知的与应用程序管理相关的问题
复制链接

请参阅以下对应用程序生命周期组件的已知问题。

您不能在 subscription-admin 角色中使用 ObjectBucket 频道类型指定 allow 和 deny 列表。在其他频道类型中，订阅中的 allow 和 deny 列表表示可以部署哪些 Kubernetes 资源，以及不应部署哪些 Kubernetes 资源。

控制台中的 Argo ApplicationSet 无法部署到 3.x OpenShift Container Platform 受管集群，因为 Infrastructure.config.openshift.io API 在 3.x 上不可用。

在受管集群中运行的 application-manager 附加组件现在由 subscription operator 处理，后者之前由 klusterlet operator 处理。订阅 operator 没有管理 multicluster-hub，因此对 multicluster-hub 镜像清单 ConfigMap 中的 multicluster_operators_subscription 镜像的更改不会自动生效。

如果订阅 operator 使用的镜像通过更改 multicluster-hub 镜像清单 ConfigMap 中的 multicluster_operators_subscription 镜像覆盖，则受管集群中的 application-manager add-on 不会使用新镜像，直到订阅 operator pod 重启为止。您需要重启 pod。

1.2.6.4. 应用程序拓扑显示错误的应用程序
复制链接

如果在不同的 Gitops 实例中创建具有相同名称的 ApplicationSets，则 Application topology 会显示错误的应用程序。如果安装了多个 Gitops 实例，则每个 Gitops 实例中具有相同名称的 ApplicationSets，并且 ApplicationSets 的拓扑将无法正确显示。这是因为拓扑没有区分所创建的 ApplicationSets 的命名空间。

确保在每个 Gitops 实例中使用不同的名称创建 ApplicationSet，以正确显示拓扑。

1.2.6.5. 除非根据订阅管理员部署策略资源
复制链接

对于 Red Hat Advanced Cluster Management 版本 2.4，默认情况下，policy.open-cluster-management.io/v1 资源不再被应用程序订阅部署。

订阅管理员需要部署应用程序订阅以更改此默认行为。

如需更多信息，请参阅以订阅管理员身份创建允许和拒绝列表。在之前的 Red Hat Advanced Cluster Management 版本中，由现有应用程序订阅部署的 policy.open-cluster-management.io/v1 资源仍然保留，除非应用程序订阅由订阅管理员部署。

1.2.6.6. 应用程序 Ansible hook 独立模式
复制链接

不支持 Ansible hook 独立模式。要使用订阅在 hub 集群上部署 Ansible hook，您可以使用以下订阅 YAML： 

apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
  name: sub-rhacm-gitops-demo
  namespace: hello-openshift
annotations:
  apps.open-cluster-management.io/github-path: myapp
  apps.open-cluster-management.io/github-branch: master
spec:
  hooksecretref:
      name: toweraccess
  channel: rhacm-gitops-demo/ch-rhacm-gitops-demo
  placement:
     local: true
Copy to Clipboard Toggle word wrap

但是，此配置可能永远不会创建 Ansible 实例，因为 spec.placement.local:true 有以 standalone 模式运行的订阅。您需要在 hub 模式中创建订阅。

  1. 创建部署到 local-cluster 的放置规则。请参见以下示例： 

    apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: <towhichcluster>
  namespace: hello-openshift
spec:
  clusterSelector:
    matchLabels:
      local-cluster: "true" #this points to your hub cluster
    Copy to Clipboard Toggle word wrap

  2. 在您的订阅中引用该放置规则。请参见以下信息： 

    apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
  name: sub-rhacm-gitops-demo
  namespace: hello-openshift
annotations:
  apps.open-cluster-management.io/github-path: myapp
  apps.open-cluster-management.io/github-branch: master
spec:
  hooksecretref:
      name: toweraccess
  channel: rhacm-gitops-demo/ch-rhacm-gitops-demo
  placement:
     placementRef:
        name: <towhichcluster>
        kind: PlacementRule
    Copy to Clipboard Toggle word wrap

应用两者后，您应该看到 hub 集群中创建的 Ansible 实例。

1.2.6.7. 为应用程序编辑角色错误
复制链接

具有 Editor 角色的用户应只拥有应用程序的 read 或 update 授权。但这样的用户会错误地具有应用程序的 create 和 delete 的权限。OpenShift Container Platform Operator Lifecycle Manager 默认设置会更改产品的设置。要解决这个问题，请遵循以下步骤：

  1. 运行 oc edit clusterrole applications.app.k8s.io-v1beta2-edit -o yaml 以打开应用程序编辑集群角色。
  2. 从 verbs 列表中删除 create 和 delete。
  3. 保存更改。

1.2.6.8. 编辑放置规则错误的角色
复制链接

在 Editor 角色中执行的用户应该对放置规则只有 read 或 update权限，但因为存在错误，编辑器也可能会有 create 和 delete 权限。OpenShift Container Platform Operator Lifecycle Manager 默认设置会更改产品的设置。要解决这个问题，请遵循以下步骤：

  1. 运行 oc edit clusterrole placementrules.apps.open-cluster-management.io-v1-edit 以打开应用程序编辑集群角色。
  2. 从 verbs 列表中删除 create 和 delete。
  3. 保存更改。

如果应用程序在更新放置规则后没有部署，验证 klusterlet-addon-appmgr pod 是否正在运行。klusterlet-addon-appmgr 是需要在端点集群中运行的订阅容器。

您可以运行 oc get pods -n open-cluster-management-agent-addon 来验证。

您还可以在控制台中搜索 kind:pod cluster:yourcluster 来查看 klusterlet-addon-appmgr 是否在运行。

如果无法验证，请尝试再次导入集群并重新验证。

1.2.6.10. Subscription operator 不会创建一个 SCC
复制链接

如需了解更多与 Red Hat OpenShift Container Platform SCC 相关的信息，请参阅 管理 Security Context Constraints (SCC)。它是受管集群所需的一个额外的配置。

不同的部署有不同的安全性上下文和不同的服务帐户。订阅 operator 无法自动创建一个 SCC。pod 的管理员控制权限。需要一个安全性上下文约束（SCC）CR，以便为相关服务帐户启用适当的权限，以便在非默认命名空间中创建 pod:

要手动在命名空间中创建 SCC CR，完成以下操作：

  1. 找到在部署中定义的服务帐户。例如，查看以下 nginx 部署： 

     nginx-ingress-52edb
 nginx-ingress-52edb-backend
    Copy to Clipboard Toggle word wrap

  2. 在命名空间中创建 SCC CR 为服务帐户或帐户分配所需的权限。请参见以下示例， 其中添加了 SecurityContextConstraints： 

    apiVersion: security.openshift.io/v1
 defaultAddCapabilities:
 kind: SecurityContextConstraints
 metadata:
   name: ingress-nginx
   namespace: ns-sub-1
 priority: null
 readOnlyRootFilesystem: false
 requiredDropCapabilities:
 fsGroup:
   type: RunAsAny
 runAsUser:
   type: RunAsAny
 seLinuxContext:
   type: RunAsAny
 users:
 - system:serviceaccount:my-operator:nginx-ingress-52edb
 - system:serviceaccount:my-operator:nginx-ingress-52edb-backend
    Copy to Clipboard Toggle word wrap

1.2.6.11. 应用程序频道需要唯一的命名空间
复制链接

在同一命名空间中创建多个频道可能会导致 hub 集群出现错误。

例如，安装程序将命名空间 charts-v1 作为 Helm 类型频道使用，因此不要在 charts-v1 中创建任何其他频道。确保您在唯一命名空间中创建频道。所有频道需要单独的命名空间，但 GitHub 频道除外，它们可与另一个 GitHub 频道共享命名空间。

1.2.6.12. Ansible Automation Platform 作业失败
复制链接

当您选择不兼容的选项时，Ansible 作业无法运行。只有选择了 -cluster 范围内的频道选项时，Ansible Automation Platform 才起作用。这会影响需要执行 Ansible 作业的所有组件。

Ansible Automation Platform(AAP)Operator 无法访问支持代理的 OpenShift Container Platform 集群外的 Ansible Tower。要解决这个问题，您可以在代理中安装 Ansible tower。请参阅 Ansible Tower 提供的安装步骤。

当创建 Helm Argo 应用程序时，模板信息会在 YAML 文件正确时会出现空的。升级到 Errata 2.4.1 以修复错误。

1.2.6.15. 应用程序名称要求
复制链接

应用程序名称不能超过 37 个字符。如果字符超过这个数量，应用部署将显示以下错误： 

status:
  phase: PropagationFailed
  reason: 'Deployable.apps.open-cluster-management.io "_long_lengthy_name_" is invalid: metadata.labels: Invalid value: "_long_lengthy_name_": must be no more than 63 characters/n'
Copy to Clipboard Toggle word wrap

1.2.6.16. 应用程序控制台表限制
复制链接

参阅控制台中不同 Application 表的限制：

  • 在 Overview 页面的 Applications 表和 Advanced 配置页面上的 Subscriptions 表中，Clusters 列会显示部署应用程序资源的集群计数。因为应用程序是由本地集群上的资源定义的，所以本地集群会包含在搜索结果中，无论实际的应用程序资源是否在本地集群中部署。
  • 在 Subscriptions 的 Advanced configuration 列表中，Applications 栏显示使用该订阅的应用程序总数，如果订阅部署了子应用程序，它们也会包含在搜索结果中。
  • Channels 的 Advanced configuration 列表中，Subscriptions 栏显示使用该频道的本地集群中的订阅总数，但这不包括由其他订阅部署的订阅，这些订阅包含在搜索结果中。

1.2.6.17. 没有应用程序控制台拓扑过滤
复制链接

2.5 的应用程序的 Console 和 Topology 已更改。控制台 Topology 页面中没有过滤功能。

当您创建将资源部署到与 ApplicationSet YAML 中定义的命名空间的 ApplicationSet 应用程序时，资源状态不会出现在拓扑中。

允许和决绝列表功能无法在对象存储应用程序订阅中工作。

1.2.6.20. ApplicationSet 向导不会自动获取路径
复制链接

当使用与之前创建的 ApplicationSet 相同的 URL 和分支创建新 ApplicationSet 后，ApplicationSet 向导不会自动获取路径。

要临时解决这个问题，请在 Path 字段中输入路径。

1.2.7. 已知的监管问题
复制链接

当您使用外部身份提供程序登录到 Red Hat Advanced Cluster Management 时，您可能无法从 Red Hat Advanced Cluster Management 注销。当您使用与 IBM Cloud 和 Keycloak 作为身份提供程序一起安装的 Red Hat Advanced Cluster Management 时会出现这种情况。

在尝试从 Red Hat Advanced Cluster Management 注销前，您必须从外部身份提供程序注销。

1.2.7.2. Gatekeeper operator 安装失败
复制链接

当您在 Red Hat OpenShift Container Platform 版本 4.9 上安装 gatekeeper operator 时，安装会失败。在将 OpenShift Container Platform 升级到 4.9.0 之前，您必须将 gatekeeper operator 升级到 0.2.0 版本。如需更多信息，请参阅升级 gatekeeper 和 gatekeeper operator。

当您有一个配置策略，它的 complianceType 参数被设置为 mustnothave，remediationAction 参数被配置为 enforce，策略会在向 Kubernetes API 发出删除请求后被列为合规。因此，在策略列为合规时，Kubernetes 对象可能会一直处于 Terminating 状态。

1.2.7.4. 使用策略部署的 Operator 不支持 ARM
复制链接

虽然支持安装到 ARM 环境中，但使用策略部署的 operator 可能不支持 ARM 环境。安装 Operator 的以下策略不支持 ARM 环境：

1.2.7.5. 策略模板问题
复制链接

当您为配置策略编辑策略模板时，您可能会遇到以下问题：

  • 当您将配置策略重命名为新名称时，带有旧名称的配置策略的副本会保留。
  • 如果您从 hub 集群上的策略中删除配置策略，则配置策略会保留在受管集群中，但不会提供其状态。要解决这个问题，请禁用您的策略并重新启用它。您还可以删除整个策略。

1.2.8. 备份和恢复已知问题
复制链接

hub 集群的备份和恢复功能需要 OpenShift API 数据保护(OADP)操作器。OADP operator 不适用于 IBM Power 或 IBM Z 架构。

1.2.8.2. 避免备份冲突
复制链接

随着 hub 集群从被动更改为主集群和后端，不同的集群就可以在同一存储位置备份数据。这可能导致备份冲突，这意味着最新的备份是由被动 hub 集群生成的。

passive hub 集群会生成备份，因为在 hub 集群中启用了 BackupSchedule.cluster.open-cluster-management.io 资源，但它应该不再写入备份数据，因为 hub 集群不再是一个主 hub 集群。运行以下命令检查是否有备份冲突： 

oc get backupschedule -A
Copy to Clipboard Toggle word wrap

您可能会收到以下状态： 

NAMESPACE       NAME               PHASE             MESSAGE
openshift-adp   schedule-hub-1   BackupCollision   Backup acm-resources-schedule-20220301234625, from cluster with id [be97a9eb-60b8-4511-805c-298e7c0898b3] is using the same storage location. This is a backup collision with current cluster [1f30bfe5-0588-441c-889e-eaf0ae55f941] backup. Review and resolve the collision then create a new BackupSchedule resource to  resume backups from this cluster.
Copy to Clipboard Toggle word wrap

通过将 BackupSchedule.cluster.open-cluster-management.io 资源状态设置为 BackupCollision 来避免备份冲突。由 BackupSchedule 资源所创建的 Schedule.velero.io 资源会自动删除。

hub-backup-pod 策略会报告备份冲突。管理员必须验证哪个 hub 集群将数据写入存储位置。然后，从 passive hub 集群中删除 BackupSchedule.cluster.open-cluster-management.io 资源，并在主 hub 集群上重新创建新的 BackupSchedule.cluster.open-cluster-management.io 资源，以恢复备份。

如需更多信息，请参阅集群备份和恢复 Operator。

1.2.8.3. Velero 恢复限制
复制链接

查看以下恢复限制：

  • 新 hub 集群与初始 hub 集群不同，当在初始 hub 集群上恢复备份数据前，新的 hub 集群上有现有策略时。该策略不应在新 hub 集群上运行，因为这是一个无法使用备份资源的策略。
  • 因为 Velero 跳过现有资源，所以新 hub 集群中的策略不会改变。因此，策略与初始 hub 集群上备份的策略不同。
  • 当用户在新 hub 集群上恢复备份时，新的 hub 集群具有与活跃 hub 集群不同的配置。由于之前恢复的 hub 集群上有现有的策略，因此不会再次恢复。即使备份包含预期的更新，策略内容也不会由新的 hub 集群上的 Velero 更新。

要解决前面提到的限制，当创建 restore.cluster.open-cluster-management.io 资源时，集群备份和恢复 Operator 会运行一组步骤来通过清理 hub 集群前通过清理 hub 集群来准备恢复。如需更多信息，请参阅恢复前清理 hub 集群。

1.2.8.4. 不显示导入的受管集群
复制链接

在主 hub 集群上手动导入的受管集群只显示在被动 hub 集群上恢复激活数据时。

1.2.8.5. 集群备份和恢复升级限制
复制链接

如果您将集群从 2.4 升级到 2.5，并将 enableClusterBackup 参数设置为 true，则会出现以下信息： 

When upgrading from version 2.4 to 2.5, cluster backup must be disabled
Copy to Clipboard Toggle word wrap

在升级集群前，请通过将 enableClusterBackup 参数设置为 false 来禁用集群备份和恢复。MultiClusterHub 资源中的 components 部分可能类似以下 YAML 文件：

升级完成后可以重新启用备份和恢复组件。查看以下示例： 

overrides:
      components:
        - enabled: true
          name: multiclusterhub-repo
        - enabled: true
          name: search
        - enabled: true
          name: management-ingress
        - enabled: true
          name: console
        - enabled: true
          name: insights
        - enabled: true
          name: grc
        - enabled: true
          name: cluster-lifecycle
        - enabled: true
          name: volsync
        - enabled: true
          name: multicluster-engine
        - enabled: false
          name: cluster-proxy-addon
        - enabled: true <<<<<<<<
          name: cluster-backup
    separateCertificateManagement: false
Copy to Clipboard Toggle word wrap

如果您已手动安装 OADP，则必须在升级前手动卸载 OADP。升级成功并重新配置后，会自动安装 OADP。

1.2.8.6. 未恢复受管集群资源
复制链接

当您恢复 local-cluster 受管集群资源的设置并覆盖新 hub 集群中的 local-cluster 数据时，设置会被错误配置。上一个 hub 集群 local-cluster 的内容没有备份，因为资源包含 local-cluster 特定信息，如集群 URL 详情。

您必须在恢复集群中手动应用与 local-cluster 资源相关的配置更改。如需了解更多详细信息，请参阅准备新 hub 集群。

prepareForBackup 函数中定义的任何标签都不会添加到调度创建后创建的资源中。这会影响在备份启动前标记的 Red Hat OpenShift secret Hive 和 Infrastructure Operator。

查看受影响的资源列表：

  • clusterDeployments 使用的由集群声明创建的 secret
  • 集群池 secret
  • 带有标签 agent-install.openshift.io/watch 和 environment.metal3.io 的Secret

更新 BackupSchedule、veleroSchedule 或 veleroTTL 值以启动一组新的调度。然后，为恢复使用结果备份，它被定义为为备份标记最新的资源。

当您为 Hive 受管集群恢复更改或轮转颁发机构 (CA) 的备份时，受管集群将无法连接到新的 hub 集群。连接会失败，因为此受管集群的 admin kubeconfig secret 通过备份提供，所以不再有效。

您必须在新 hub 集群中手动更新受管集群的恢复的 admin kubeconfig secret。

1.2.9. Submariner 已知问题
复制链接

仅支持 OpenShiftSDN 作为 CNI 网络供应商。目前不支持 OVN。

当在包含 Red Hat Enterprise Linux worker 节点的集群中部署 Submariner 时，在 4.18.0-359.el8.x86_64 和 4.18.0-372.11.1.el8_6.x86_64 之间带有内核版本的 Red Hat Enterprise Linux worker 节点时，应用程序工作负载无法与远程集群通信。

在 Red Hat Advanced Cluster Management 的所有基础架构供应商不支持 Submariner。如需支持的供应商列表，请参阅 Red Hat Advanced Cluster Management 支持列表。

在 product-title-short} 控制台中，Submariner 不支持对 Red Hat OpenStack 集群的自动准备。您可以使用 Red Hat Advanced Cluster Management API 来手动准备云。

Submariner 支持使用 Globalnet 的无头服务。但是，当您从位于相同集群中使用 clusterset.local 域名的客户端访问导出的无头服务时，与无头服务关联的 globalIP 将返回到客户端，它不在集群中路由。

您可以使用 cluster.local 域名访问本地无头服务。

1.2.9.6. Submariner 不支持 air-gapped 集群
复制链接

对于在 air-gapped 环境中置备的集群，Submariner 不会验证。

1.2.9.7. 无法部署大量网关
复制链接

您无法部署多个网关。

1.2.9.8. 在启用 NAT 时 Submariner 不支持 VXLAN
复制链接

带有 VXLAN 电缆驱动程序的 Submariner 目前仅在非NAT 部署中被支持。

1.2.9.9. Globalnet 限制
复制链接

Red Hat OpenShift Data Foundation 灾难恢复解决方案不支持 Globalnet。对于地区性的灾难恢复情况，确保对集群和每个集群中的服务网络使用没有重叠的专用 IP 地址。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat