发行注记

如果您从 OpenShift Container Platform 卸载 Red Hat Advanced Cluster Management，如果您稍后想要安装早期版本，则会导致问题。例如，当卸载 Red Hat Advanced Cluster Management 时，安装早期版本的 Red Hat Advanced Cluster Management 和升级该版本，升级可能会失败。如果没有删除自定义资源，升级会失败。

在 重新安装步骤前，按照清理工件 以防止出现这个问题。

ACM-14343

如果您在使用 Image -Based Break/Fix 重新安装集群时更改 spec.nodes.<node-id>.bmcAddress 字段，则 SiteConfig operator 无法联系原始机器 nd 无法从原始集群中删除数据镜像资源。要临时解决这个问题，请在使用基于镜像的 Break/Fix 重新安装集群前从数据镜像资源中删除终结器。

ACM-21889

此处列出了备份和恢复已知问题和限制，以及临时解决方案（如果可用）。

您可以使用 BareMetalHosts 自动将主机添加到主机清单中。默认情况下，您的 BareMetalHost 不包含在您的备份中。

要将 BareMetalHosts 包含在您的备份中，请将 cluster.open-cluster-management.io/backup: cluster-activation 标签添加到 BareMetalHosts 中。如需更多信息，请参阅 受管集群激活时间 恢复的资源。

ACM-26582

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

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

spec:
  clusterSelector:
    matchLabels:
      environment: dev

spec:
  clusterSelector:
    matchLabels:
      environment: dev

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

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

klusterlet-addon-search pod 失败，因为达到内存限制。您必须通过自定义受管集群中的 klusterlet-addon-search 部署来更新内存请求和限制。在 hub 集群中编辑名为 search-collector 的 ManagedclusterAddon 自定义资源。在 search-collector 中添加以下注解并更新 memory, 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

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

ACM-27173

搜索 hub 集群中资源的 RBAC 映射。根据 RBAC 设置，用户可能无法看到来自受管集群的节点数据。搜索的结果可能与集群的 Nodes 页面中显示的结果不同。

ACM-4598

在控制台中，您可以为 OpenShift Dedicated 集群请求升级，但升级会失败，并显示 Cannot upgrade non openshift cluster 错误消息。目前没有临时解决方案。

ACM-10143

search-postgres pod 处于 CrashLoopBackoff 状态。如果 Red Hat Advanced Cluster Management 部署到启用了 hugepages 参数的节点，并且 search-postgres pod 调度到这些节点中，则 pod 不会启动。

完成以下步骤以增加 search-postgres pod 的内存：

此时会出现以下值： 512Mi。

ACM-7467

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

ACM-25389

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

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

ACM-27107

如果您没有在 OpenShift Cloud Manager 控制台中访问 cluster-ID，您仍然可以从终端获取 Red Hat OpenShift Service on AWS cluster-ID 的描述。您需要 Red Hat OpenShift Service on AWS 命令行界面。请参阅 Red Hat OpenShift Service on AWS CLI 文档。

要获取 cluster-ID，请从 Red Hat OpenShift Service on AWS 命令行界面运行以下命令：

rosa describe cluster --cluster=<cluster-name> | grep -o ’^ID:.*

rosa describe cluster --cluster=<cluster-name> | grep -o ’^ID:.*

ACM-10651

如果 hub 集群无法访问或与受管集群通信，则会出现以下限制：

ACM-6292

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

ACM-17790

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

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

ACM-16977

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

ACM-5636

不支持带有 Red Hat OpenShift Virtualization 4.20 的 Red Hat Advanced Cluster Management 2.15 Virtualization。您需要在 Red Hat Advanced Cluster Management 2.15 中使用 Red Hat OpenShift Virtualization 4.20.1 或更高版本。

当您将 OpenShift GitOps operator 升级到 1.17 版本时，您可以在 ApplicationSet 资源状态中获得权限错误。

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

ACM-23907

当您部署 Subscription 应用程序（已弃用）时，它会在 Application Topology 页面中为 Subscription 节点显示警告信息。如果您检查订阅节点详情，它会错误地显示 local-cluster 离线。

从 Console 导航中点 Infrastructure > Clusters 来检查 local-cluster 的实际状态。

ACM-18544

当应用程序资源在 hub 集群中更新时，Application page 表也会被更新。如果您打开了 Application 表的菜单，则在每次更新到 Application 页表时都会关闭它。由于菜单可以经常关闭，因此您可能很难单击菜单。

要解决这个问题，点 Application name 进入 Application details 页面，您可以在其中点击相同的操作菜单，而无需在每次更新的情况下。

ACM-18543

当您在 放置资源 中使用 Exist 或 DoesNotExist 运算符时，应用程序拓扑节点详情会将表达式显示为 \" invalidExpr。此显示错误，表达式仍然有效，且在 放置资源 中工作。要解决这个问题，请编辑 放置资源 YAML 中的表达式。

ACM-15077

创建引用 PlacementRule 资源的订阅应用程序后，控制台中的 YAML 编辑器不会显示订阅 YAML。使用您的终端编辑订阅 YAML 文件。

ACM-8889

使用 Helm Chart，您可以在 Kubernetes secret 中定义隐私数据，并在 Helm Chart 的 value.yaml 文件中定义此 secret。

用户名和密码由引用的 Kubernetes secret 资源 dbsecret 提供。例如，请参阅以下示例 value.yaml 文件：

credentials:
  secretName: dbsecret
  usernameSecretKey: username
  passwordSecretKey: password

credentials:
  secretName: dbsecret
  usernameSecretKey: username
  passwordSecretKey: password

只有在 Helm 二进制 CLI 中才支持带有 secret 依赖项的 Helm Chart。Operator SDK Helm 库不支持它。Red Hat Advanced Cluster Management 订阅控制器应用 operator SDK Helm 库来安装和升级 Helm Chart。因此，Red Hat Advanced Cluster Management 订阅无法使用 secret 依赖项部署 Helm Chart。

ACM-8727

当您使用 Argo CD pull 模型来部署 ApplicationSet 应用程序，且应用程序资源名称会被自定义时，每个集群的资源名称可能会有所不同。当发生这种情况时，拓扑无法正确显示您的应用程序。

ACM-6954

hub 集群应用程序集部署到目标受管集群，但本地集群（一个受管 hub 集群）作为目标受管集群排除。

因此，如果 Argo CD pull 模型将 Argo CD 应用程序传播到本地集群，则不会清理本地集群 Argo CD 应用程序，即使本地集群已从 Argo CD ApplicationSet 资源的放置决定中删除。

要临时解决这个问题并清理本地集群 Argo CD 应用程序，请从本地集群 Argo CD 应用程序中删除 skip-reconcile 注解。请参阅以下注解：

annotations:
    argocd.argoproj.io/skip-reconcile: "true"

annotations:
    argocd.argoproj.io/skip-reconcile: "true"

另外，如果您在 Argo CD 控制台的 Applications 部分手动刷新 pull model Argo CD 应用程序，则不会处理刷新，并且 Argo CD 控制台中的 REFRESH 按钮被禁用。

要临时解决这个问题，请从 Argo CD 应用程序中删除 refresh 注解。请参阅以下注解：

annotations:
    argocd.argoproj.io/refresh: normal

annotations:
    argocd.argoproj.io/refresh: normal

ACM-7843

Argo CD 控制器和传播控制器可能会在同一应用程序资源上协调，并导致受管集群中应用程序部署的重复实例，但来自不同部署模型。

对于使用 pull 模型部署应用程序，当 Argo CD argocd.argoproj.io/skip-reconcile 注解添加到 ApplicationSet 的 template 部分时，Argo CD 控制器会忽略这些应用程序资源。

argocd.argoproj.io/skip-reconcile 注解仅适用于 GitOps operator 版本 1.9.0 或更高版本。为防止冲突，请等待 hub 集群和所有受管集群都升级到 GitOps operator 版本 1.9.0，然后再实施 pull 模型。

MulticlusterApplicationSetReport 中列出的所有资源实际上都部署到受管集群中。如果资源无法部署，则资源不包含在资源列表中，但原因会在错误消息中列出。

对于超过 1000 个受管集群和 Argo CD 应用程序集的大型环境，部署到数百个受管集群，hub 集群上的 Argo CD 应用程序创建可能需要几分钟时间。您可以在应用程序集的 clusterDecisionResource 生成器中将 requeueAfterSeconds 设置为 zero，如下例所示：

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cm-allclusters-app-set
  namespace: openshift-gitops
spec:
  generators:
  - clusterDecisionResource:
      configMapRef: ocm-placement-generator
      labelSelector:
        matchLabels:
          cluster.open-cluster-management.io/placement: app-placement
      requeueAfterSeconds: 0

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cm-allclusters-app-set
  namespace: openshift-gitops
spec:
  generators:
  - clusterDecisionResource:
      configMapRef: ocm-placement-generator
      labelSelector:
        matchLabels:
          cluster.open-cluster-management.io/placement: app-placement
      requeueAfterSeconds: 0

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

ACM-22763

在受管集群中运行的 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 资源仍然保留，除非应用程序订阅由订阅管理员部署。

ACM-893

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

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 实例。

ACM-8036

如果应用程序在更新放置规则后没有部署，请验证 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，请参阅 管理安全性上下文约束，这是受管集群所需的额外配置。

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

ACM-24248

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

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

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

ACM-14469

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

ACM-16821

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

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'

ACM-14310

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

ACM-12410

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

ACM-20831

如果您创建一个 ClusterPermission 资源，其中包含同一命名空间中的多个角色绑定，且没有设置可选 name 字段，则会失败。发生此错误的原因是，与命名空间中的角色绑定使用相同的名称。

要解决这个问题，请为每个角色绑定设置可选 name 字段。

ACM-21342

multicluster-observability-addon-manager pod 处于 OOMKilled 状态，因为 pod 会监视 hub 集群中的所有配置映射和 secret，从而导致它使用太多资源。当您启用多集群观察附加组件时，指标集合会失败。

要避免这个问题，请不要启用多集群观察附加组件。multicluster observability 附加组件默认是禁用的。如果启用了多集群可观察性附加组件，请在 MulticlusterObservability 自定义资源中将 enabled 设置为 false 来禁用附加组件。请参阅以下 MultiClusterObservability 自定义资源示例：

+

apiVersion: observability.open-cluster-management.io/v1beta2
kind: MultiClusterObservability
metadata:
  name: observability
spec:
  capabilities:
    platform:
      metrics:
        default:
          enabled: false
    userWorkloads:
      metrics:
        default:
          enabled: false

apiVersion: observability.open-cluster-management.io/v1beta2
kind: MultiClusterObservability
metadata:
  name: observability
spec:
  capabilities:
    platform:
      metrics:
        default:
          enabled: false
    userWorkloads:
      metrics:
        default:
          enabled: false

当您通过在 MultiClusterObservability 自定义资源中设置 mco-disable-alerting: true 来禁用 Red Hat Advanced Cluster Management 2.15 警报转发，且您手动配置警报转发，则会失败。升级后会失败，因为 observability-alertmanager-accessor 和 hub-alertmanager-router-ca secret 的名称被修改为包含 hub 集群名称的 postfix。

要解决这个问题，请更新您手动配置为使用 secret 的新名称的警报转发配置。

对于平台警报，更新 openshift-monitoring 命名空间中的 cluster-monitoring-config 配置映射中的 secret 名称。对于用户工作负载警报，更新 openshift-user-workload-monitoring 命名空间中的 user-workload-monitoring-config 配置映射中的 secret 名称。在 openshift-monitoring 和 openshift-user-workload-monitoring 命名空间中查找新 secret 名称。

ACM-26604

保留所有分辨率级别的默认保留（如 retentionResolutionRaw、retentionResolution5m 或 retentionResolution1h ）是 365 天(365d)。此 365d 默认保留意味着 1 小时分辨率的默认保留已从 0d 缩短为 365d。此保留更改可能会导致您丢失数据。如果您没有在 MultiClusterObservability spec.advanced.retentionConfig 参数中为解析保留设置显式值，则可能会丢失数据。

如需更多信息，请参阅为保留添加高级配置。

ACM-11048

恢复 hub 集群中的 Observatorium API 网关 pod 可能会在备份和恢复过程后包含过时的租户数据，因为 Kubernetes 的限制。有关限制的更多信息，请参阅自动挂载的 ConfigMap。

因此，Observatorium API 和 Thanos 网关拒绝来自收集器的指标，Red Hat Advanced Cluster Management Grafana 仪表板不会显示数据。

请参阅 Observatorium API 网关 pod 日志中的以下错误：

level=error name=observatorium caller=logchannel.go:129 msg="failed to forward metrics" returncode="500 Internal Server Error" response="no matching hashring to handle tenant\n"

level=error name=observatorium caller=logchannel.go:129 msg="failed to forward metrics" returncode="500 Internal Server Error" response="no matching hashring to handle tenant\n"

Thanos 接收带有以下错误的 pod 日志：

caller=handler.go:551 level=error component=receive component=receive-handler tenant=xxxx err="no matching hashring to handle tenant" msg="internal server error"

caller=handler.go:551 level=error component=receive component=receive-handler tenant=xxxx err="no matching hashring to handle tenant" msg="internal server error"

请参阅以下流程来解决这个问题：

注意： 默认情况下 N = 2，但在某些自定义配置环境中可能会大于 2。

这会使用正确的租户信息重启所有 Observatorium API 网关 pod，在 5 到 10 分钟后，来自收集器的数据也会在 Grafana 中显示。

ACM-9681

您必须在定义的 Red Hat Advanced Cluster Management hub 集群命名空间中使用标签。标签 openshift.io/cluster-monitoring: "true" 会导致 Cluster Monitoring Operator 提取指标的命名空间。

当部署或升级 Red Hat Advanced Cluster Management 时，Red Hat Advanced Cluster Management Observability ServiceMonitor 和 PrometheusRule 资源不再存在于 openshift-monitoring 命名空间中。

ACM-8499

observability 附加组件的 Prometheus AdditionalAlertManagerConfig 资源不支持代理设置。您必须禁用 observability 警报转发功能。

完成以下步骤以禁用警报转发：

不支持带有自签名 CA 证书的 HTTPS 代理。

ACM-7118

自定义 Observatorium API 和 Alertmanager URL 仅支持带有 TLS 透传的中间组件。如果两个自定义 URL 都指向同一中间组件，则必须使用单独的子域，因为 OpenShift Container Platform 路由器不支持具有相同主机的两个单独的路由对象。

ACM-11407

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

ACM-20715

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

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

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

使用以下命令检查自定义资源定义是否卡住：

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

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

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

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

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

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

ACM-25139

如果策略被设置为 remediationAction: enforce 并重复更新，Red Hat Advanced Cluster Management 控制台会显示重复违反情况，并成功更新。重复更新生成多个策略事件，这可能会导致 governance-policy-framework-addon pod 耗尽内存和崩溃。请参阅以下可能的原因和错误解决方案：

ACM-3109

Kyverno 策略由 Policy Generator 生成的策略报告 Red Hat Advanced Cluster Management 集群中的以下信息：

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

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

原因是 PolicyReport API 版本在生成器中不正确，与部署的 Kyverno 不匹配。

ACM-12743

请参阅以下在使用网络功能时可能出现的已知问题和限制。

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

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

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

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

当您升级 multicluster global hub 且在 multicluster global hub 集群中有一些 ManagedClusterMigration 资源时，您可能会遇到以下错误：

error validating existing CRs against new CRD''s schema for "managedclustermigrations.global-hub.open-cluster-management.io":
      error validating global-hub.open-cluster-management.io/v1alpha1, Kind=ManagedClusterMigration
      "multicluster-global-hub/xxx": updated validation is
      too restrictive: [].spec.from: Required value'

error validating existing CRs against new CRD''s schema for "managedclustermigrations.global-hub.open-cluster-management.io":
      error validating global-hub.open-cluster-management.io/v1alpha1, Kind=ManagedClusterMigration
      "multicluster-global-hub/xxx": updated validation is
      too restrictive: [].spec.from: Required value'

要解决这个问题，请在升级多集群全局 hub 前删除所有 ManagedClusterMigration 资源。运行以下命令:

oc delete mcm --all

oc delete mcm --all

ACM-25679

如果您以托管模式导入受管 hub 集群并分离此受管 hub 集群，则会删除并重新创建 open-cluster-management-agent-addon 命名空间。分离的受管 hub 集群也会删除并重新创建此命名空间中的所有附加组件资源。

当前没有解决此问题的方法。

ACM-15014

在联邦信息处理标准(FIPS)环境中，Kafka operator 会因为内存不足(OOM)状态而保持重启。要解决这个问题，请将资源限值设置为至少 512M。有关如何设置此限制的详细步骤，请参阅 amq stream doc。

ACM-12592

在 Global Hub Policy Group Compliancy Overview hub 仪表板中，您可以通过单击 标准组的 View Offending Policies 来检查一个数据点，但在点击此链接后，标准组过滤器无法传递给新页面。

这也是 Cluster Group Compliancy 概述 的问题。

ACM-7461

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 可以做什么或可以访问什么。