在某些情况下，客户门户网站中的 Red Hat Advanced Cluster Management 文档的其他部分的内部链接不会直接链接到指定部分。在某些情况下，链接会指向最高级别的部分。

如果发生这种情况，您可以手动找到指定的部分，或者完成以下步骤以解决：

升级到 Red Hat Advanced Cluster Management 版本 2.7 后，apps.open-cluster-management.io 组中的资源的用户权限不可用。从 Red Hat Advanced Cluster Management 版本 2.7 开始，这些自定义资源定义不再由 OLM 部署，并会产生以下更改：

如果 RBAC 用户需要访问这些资源，您必须授予正确的权限。

从 2.4.x 升级到 2.5.x，然后再升级到 2.6.x，受管集群命名空间中的已弃用资源可能会被保留。如果版本 2.6.x 从 2.4.x 升级，则需要手动删除这些已弃用的资源：

注： 在从 2.5.x 升级到 2.6.x 版本前，您需要等待 30 分钟或更长时间。

您可以从控制台中删除，也可以运行类似以下示例的命令，用于您要删除的资源：

oc delete -n <managed cluster namespace> managedclusteraddons.addon.open-cluster-management.io <resource-name>

查看可能保留的已弃用资源列表：

managedclusteraddons.addon.open-cluster-management.io:
policy-controller
manifestworks.work.open-cluster-management.io:
-klusterlet-addon-appmgr
-klusterlet-addon-certpolicyctrl
-klusterlet-addon-crds
-klusterlet-addon-iampolicyctrl
-klusterlet-addon-operator
-klusterlet-addon-policyctrl
-klusterlet-addon-workmgr

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

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

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

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

MultiClusterEngine required

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

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

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

对于旧版本的 Firefox，有模糊处理的问题。为了获得最好的兼容性，请升级至最新版本。

如需更多信息，请参阅支持的浏览器。

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

oc edit pvc <storageclassname>-search-redisgraph-0

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

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

kubectl annotate route multicloud-console haproxy.router.openshift.io/timeout=Xs

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

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 资源。角色绑定只允许将集群集绑定到命名空间。

置备托管的 control plane 集群后，如果 ClusterVersionUpgradeable 参数太长，您可能无法在 Red Hat Advanced Cluster Management 控制台的集群概述中水平滚动。因此，您无法查看隐藏的数据。

要临时解决这个问题，请使用浏览器缩放控制来缩放，增加 Red Hat Advanced Cluster Management 控制台窗口大小，或者复制文本并将其粘贴到不同的位置。

如果您使用依赖于 Ansible Automation Platform Operator 的集成，且没有在 Red Hat OpenShift Container Platform 集群上查看已安装的 Operator 的权限，您可能会看到类似如下的错误消息：

Ansible Automation Platform Operator 需要使用自动化模板。在自动化模板中使用工作流作业模板需要 2.2.1 或更高版本。

如果您使用已安装 Operator 的系统管理员确认，您可以安全地忽略错误消息。

当各种 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 存储桶来部署可观察性。

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

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

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

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

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

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

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

Error on ingesting out-of-order samples

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

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

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

如果您在 2.6 之前的系统中部署了 grafana-dev 实例，并将环境升级到 2.6，grafana-dev 无法正常工作。您必须运行以下命令来删除现有 grafana-dev 实例：

./setup-grafana-dev.sh --clean

使用以下命令重新创建实例：

./setup-grafana-dev.sh --deploy

klusterlet-addon-search pod 失败，因为达到内存限制。您必须通过自定义受管集群中的 klusterlet-addon-search 部署来更新内存请求和限制。在 hub 集群中编辑名为 search-collector 的 ManagedclusterAddon 自定义资源。在 search-collector 中添加以下注解并更新内存 addon.open-cluster-management.io/search_memory_request=512Mi 和 addon.open-cluster-management.io/search_memory_limit=1024Mi。

例如，如果您有一个名为 foobar 的受管集群，请运行以下命令将内存请求更改为 512Mi，内存限值为 1024Mi ：

oc annotate managedclusteraddon search-collector -n foobar \
addon.open-cluster-management.io/search_memory_request=512Mi \
addon.open-cluster-management.io/search_memory_limit=1024Mi

如果在 mulitclusterengine 自定义资源中将 disableHubSelfManagement 参数设置为 true 时，Grafana 仪表板会显示一个空标签列表。您必须将参数设置为 false 或删除参数来查看标签列表。如需了解更多详细信息，请参阅 disableHubSelfManagement。

当您将 FQDN 或协议用于 endpoint 参数时，您的可观察性 pod 不会被启用。此时会显示以下出错信息：

Endpoint url cannot have fully qualified paths

输入没有协议部分的 URL。您的 endpoint 值必须类似您的 secret 的以下 URL：

endpoint: example.com:443

当您尝试查询历史数据时，计算的步骤值和 downsampled 数据之间存在差异，结果为空。例如，如果计算的步骤值为 5m，并且 downsampled 数据处于一小时的间隔，则数据不会出现在 Grafana 中。

此差异发生，因为 URL 查询参数必须通过 Thanos Query 前端数据源进行传递。之后，当数据缺失时，URL 查询可以对其他降级级别执行额外的查询。

您必须手动更新 Thanos Query 前端数据源配置。完成以下步骤：

您的查询数据会出现在 Grafana 仪表板中。

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

如果应用程序处于 blocked 状态，订阅会显示集群离线，但集群处于 healthy 和 ready 状态。

您不能在 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。

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

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

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

不支持 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

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

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

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

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

如果应用程序在更新放置规则后没有部署，请验证 application-manager pod 是否正在运行。application-manager 是需要在受管集群上运行的订阅容器。

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

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

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

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

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

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

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

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

Red Hat Ansible Automation Platform Operator 无法访问启用了代理的 OpenShift Container Platform 集群之外的 Ansible Automation Platform。要解决这个问题，您可以在代理中安装 Ansible Automation Platform。请参阅 Ansible Automation Platform 提供的安装步骤。

应用程序名称不能超过 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'

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

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

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

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

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

当您在 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 状态。

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

当您通过在 KlusterletAddonConfig 或分离集群中禁用策略控制器，或从受管集群中删除 config-policy-controller 附加组件时，ConfigurationPolicy CRD 可能会处于终止状态。如果 ConfigurationPolicy CRD 处于终止状态，如果稍后重新安装附加组件，则可能不会添加新策略。您还可以收到以下错误：

template-error; Failed to create policy template: create not allowed while custom resource definition is terminating

使用以下命令检查 CRD 是否卡住：

oc get crd configurationpolicies.policy.open-cluster-management.io -o=jsonpath='{.metadata.deletionTimestamp}'

如果删除时间戳位于资源上，则 CRD 会卡住。要解决这个问题，从集群中保留的配置策略中删除所有终结器。在受管集群中使用以下命令，将 <cluster-namespace> 替换为受管集群命名空间：

oc get configurationpolicy -n <cluster-namespace> -o name | xargs oc patch -n <cluster-namespace> --type=merge -p '{"metadata":{"finalizers": []}}'

配置策略资源会自动从集群中移除，CRD 会退出其终止状态。如果已经重新安装了附加组件，则在没有删除时间戳的情况下自动重新创建 CRD。

如果策略被设置为 remediationAction: enforce 并重复更新，Red Hat Advanced Cluster Management 控制台会显示重复违反情况，并成功更新。这可能会在以下两个情况下发生：

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

要解决这个问题，请禁用您的策略并重新启用它。您还可以删除整个策略。

对 Pod 安全策略的支持已从 OpenShift Container Platform 4.12 及更新的版本中删除，并从 Kubernetes v1.25 及之后的版本中删除。如果应用 PodSecurityPolicy 资源，您可能会收到以下不合规的信息：

violation - couldn't find mapping resource with kind PodSecurityPolicy, please check if you have CRD deployed

启用 Red Hat Advanced Cluster Management 备份和恢复组件并成功创建 DataProtectionApplication 资源后，会创建一个 BackupStorageLocation 资源，状态为 Available。当您使用 OADP 版本 1.1.2 或更高版本时，您可能会在创建 BackupSchedule 资源后收到以下信息，其状态为 FailedValidation ：

oc get backupschedule -n open-cluster-management-backup
NAME PHASE MESSAGE
rosa-backup-schedule FailedValidation Backup storage location is not available. Check velero.io.BackupStorageLocation and validate storage credentials.

此错误是由 BackupStorageLocation 资源中的 ownerReference 缺少的值造成的。DataProtectionApplication 资源的值应用作 ownerReference 的值。

要临时解决这个问题，请手动将 ownerReference 添加到 BackupStorageLocation 中：

如果在其中恢复数据的新 hub 集群有用户创建的资源，则这个新的 hub 集群可能会有与活跃的 hub 集群不同的配置。例如，在将备份的数据恢复到新的 hub 集群中之前，在这个新的 hub 集群上可能已包括了一个现存的策略。

如果不是恢复的备份的一部分，Velero 会跳过现存的资源，因此新 hub 集群上的策略不会改变，这会导致新 hub 集群和活跃 hub 集群之间的不同配置。

为解决这个问题，集群备份和恢复 Operator 可以运行一个恢复后的操作以清理由用户创建的资源，或在 restore.cluster.open-cluster-management.io 资源时执行不同的恢复操作。

如需更多信息，请参阅管理备份和恢复 operator 中的在恢复前清理 hub 集群部分。

只有在被动 hub 集群上恢复激活数据时，才会显示受管集群。

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

When upgrading from version 2.4 to 2.5, cluster backup must be disabled

在升级集群前，请通过将 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

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

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

您必须在恢复集群中手动应用与 local-cluster 资源相关的配置更改。请参阅管理备份和恢复 operator 主题中的准备新的 hub 集群。

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

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

在主 hub 集群上手动导入的受管集群会在被动 hub 集群上恢复激活数据时显示一个 Pending Import 状态。如需更多信息，请参阅使用受管服务帐户自动连接集群。

当在新 hub 集群上恢复 hub 集群数据时，appliedmanifestwork 不会从没有固定集群集的应用程序订阅的放置规则的受管集群中删除。

有关不是固定集群集的应用程序订阅，请参阅以下放置规则示例：

spec:
  clusterReplicas: 1
  clusterSelector:
    matchLabels:
      environment: dev

因此，当受管集群从恢复的 hub 集群分离时，应用程序会被孤立。

要避免这个问题，请在放置规则中指定固定的集群集。请参见以下示例：

spec:
  clusterSelector:
    matchLabels:
      environment: dev

您还可以通过运行以下命令来手动删除剩余的 appliedmanifestwork ：

oc delete appliedmanifestwork <the-left-appliedmanifestwork-name>

当在新 hub 集群上恢复 hub 集群数据时，appliedmanifestwork 不会从没有固定集群集的应用程序订阅的放置规则的受管集群中删除。因此，当受管集群从恢复的 hub 集群分离时，应用程序会被孤立。

有关不是固定集群集的应用程序订阅，请参阅以下放置规则示例：

+

spec:
  clusterReplicas: 1
  clusterSelector:
    matchLabels:
      environment: dev

要避免这个问题，请在放置规则中指定固定的集群集。请参见以下示例：

+

spec:
  clusterSelector:
    matchLabels:
      environment: dev

您还可以通过运行以下命令来手动删除剩余的 appliedmanifestwork ：

oc delete appliedmanifestwork <the-left-appliedmanifestwork-name>

当您将 Red Hat Advanced Cluster Management 2.6 用作主 hub 集群时，但您的恢复 hub 集群位于 2.7 或更高版本的版本时，appliedmanifestworks 规格中缺少 agentID，因为此字段在 2.7 发行版本中引入。这会为受管集群上的主 hub 生成额外的 appliedmanifestworks。

要避免这个问题，请将主 hub 集群升级到 Red Hat Advanced Cluster Management 2.7，然后在新的 hub 集群中恢复备份。

通过为每个 appliedmanifestwork 手动设置 spec.agentID 来修复受管集群。

如果您使用 Managed Service Account，则受管集群 appliedmanifestwork addon-managed-serviceaccount-deploy 会从导入的受管集群中删除，而无需在新 hub 集群的 multicluster engine for Kubernetes operator 资源中启用它。

受管集群仍然导入到新的 hub 集群，但 managed-serviceaccount add-on 状态显示 Unknown。

在 multicluster engine operator 资源中启用 Managed Service Account 后，您可以恢复 managed-serviceaccount 附加组件。请参阅启用自动导入以了解如何启用受管服务帐户。

对于版本 2.8 及更早版本，在安装 Red Hat Advanced Cluster Management 时，您还可以使用 Operator Lifecycle Manager 部署 submariner-addon 组件。如果您没有创建 MultiClusterHub 自定义资源，submariner-addon pod 会发送错误，并阻止 Operator 安装。

发生以下通知，因为缺少 ClusterManagementAddon 自定义资源定义：

graceful termination failed, controllers failed with error: the server could not find the requested resource (post clustermanagementaddons.addon.open-cluster-management.io)

ClusterManagementAddon 资源由 cluster-manager 部署创建，但当集群中安装 MultiClusterEngine 组件时，此部署将可用。

如果在创建 MultiClusterHub 自定义资源时没有在集群中可用的 MultiClusterEngine 资源，MultiClusterHub operator 会部署 MultiClusterEngine 实例，以及所需的 Operator，用于解决前面的错误。

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

在使用 Globalnet 时，在没有选择器的情况下的无头服务不支持服务发现。

只有非 NAT 部署支持使用 VXLAN 电缆驱动程序的 Submariner 部署。

如果使用 OVN Kubernetes CNI 网络，则需要 Red Hat OpenShift 4.11 或更高版本。

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

代理上的自签名证书可能会阻止加入集群连接到代理。连接失败并显示证书验证错误。您可以通过在相关 SubmarinerConfig 对象中将 InsecureBrokerConnection 设置为 true 来禁用代理证书验证。请参见以下示例：

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
   name: submariner
   namespace: <managed-cluster-namespace>
spec:
   insecureBrokerConnection: true

Submariner 只支持使用 OpenShift SDN 或 OVN-Kubernetes Container Network Interface (CNI) 网络供应商的 Red Hat OpenShift Container Platform 集群。

subctl diagnose firewall inter-cluster 命令无法在 Microsoft Azure 集群中工作。

当 Red Hat Advanced Cluster Management for Kubernetes 升级时，Submariner 会被自动升级。如果您使用自定义 CatalogSource 或 Subscription，则自动升级可能会失败。

为确保在受管集群上安装 Submariner 时自动升级可以正常工作，您必须在每个受管集群的 SubmarinerConfig 自定义资源中将 spec.subscriptionConfig.channel 字段设置为 stable-0.14。

GDPR 为处理个人数据建立了更强大的数据保护框架。GDPR 可以带来：

作为一个平台，Red Hat Advanced Cluster Management for Kubernetes 需要不同类别的技术数据，这些数据可能会被视为个人数据，如管理员用户 ID 和密码、服务用户 ID 和密码、IP 地址以及 Kubernetes 节点名称。Red Hat Advanced Cluster Management for Kubernetes 平台还处理管理平台的用户的信息。在平台中运行的应用程序可能会使用与平台无关的其他类别的个人数据。

本文档后续部分将介绍如何收集/创建这些技术数据、存储、访问、安全、日志和删除。

用户可以以各种方式提交在线评论/反馈/请求，主要有：

通常，只使用客户名称和电子邮件地址，以便可以进行回复，对个人数据的使用符合 红帽在线隐私声明。

Red Hat Advanced Cluster Management for Kubernetes 平台的身份验证管理程序接受来自控制台的用户凭证，并将凭证转发到后端的 OIDC 供应商，后者根据企业目录验证用户凭证。然后，OIDC 供应商会向身份验证程序返回一个带有 JSON Web Token（JWT）内容的身份验证 cookie（auth-cookie）。JWT 令牌包括了身份验证请求时的组成员信息，以及用户 ID 和电子邮件地址等信息。然后，这个身份验证 cookie 会发送到控制台。在会话存在期间，cookie 会被刷新。在退出控制台或关闭浏览器后，这个 cookie 会在 12 小时内有效。

对于所有来自控制台的验证请求，前端 NGINX 服务器对请求中的可用身份验证 cookie 进行解码，并通过调用验证管理程序来验证请求。

Red Hat Advanced Cluster Management for Kubernetes 平台的 CLI 需要用户在登陆时提供凭证。

kubectl 和 oc CLI 也需要凭证来访问集群。这些凭证可以从管理控制台获得，并在 12 小时后过期。支持通过服务帐户访问。

Red Hat Advanced Cluster Management for Kubernetes 平台支持的基于角色的控制访问（RBAC）。在角色映射阶段，身份验证阶段提供的用户名映射到用户或组角色。在授权哪些管理操作可由经过身份验证的用户执行时使用角色。

Red Hat Advanced Cluster Management for Kubernetes 平台对集群配置操作的角色控制访问，适用于 catalog 和 Helm 资源，以及 Kubernetes 资源。提供了几个 IAM（Identity and Access Management）角色，包括 Cluster Administrator、Administrator、Operator、Editor、Viewer。在将用户或用户组添加到一个团队时，会为用户或用户组分配一个角色。对资源的团队访问可以由命名空间控制。

Pod 安全策略用于设置集群级别的控制，控制 pod 可以做什么或可以访问什么。