1.3. 已知问题

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

卸载 Red Hat Advanced Cluster Management 时，您需要在重新安装和升级前手动删除以前的 StorageVersionMigration。

例如，如果您从 OpenShift Container Platform 卸载 Red Hat Advanced Cluster Management 2.10，以使用早期版本的 Red Hat Advanced Cluster Management，然后尝试再次升级到 2.10，除非删除 StorageVersionMigration 资源，否则升级会失败。

安装 infrastructure-operator 时，与 ARM 聚合流无法正常工作。将 ALLOW_CONVERGED_FLOW 设置为 false 以解决这个问题。

当问题解决时，代理会出现在清单中。

从 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>

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

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。

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

E0430 19:11:20.810624 1 clientset.go:188] "cannot connect once" err="rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\""

E0430 19:11:20.810624 1 clientset.go:188] "cannot connect once" err="rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\""

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.

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.

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>

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

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

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

出现以下值 ：512Mi。

当使用 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 控制台窗口大小，或者复制文本并将其粘贴到不同的位置。

当您添加多个标签表达式或尝试为 ApplicationSet 输入集群选择器时，您可能会重复收到以下信息，"Expand to enter expression"。尽管出现这个问题，您可以输入集群选择。

如果您有 OpenShift Container Platform 4.17，则搜索 serviceaccount 缺少一些权限，需要以用户身份运行。因此，Argo CD pull 模型资源同步控制器无法从搜索 API 访问应用程序资源列表。

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

注： Red Hat Advanced Cluster Management 支持（OpenShift Container Platform 3.11 已被弃用。

创建以 OpenShift Container Platform 3.11 集群为目标的订阅应用程序后，应用程序拓扑会显示错误用于 ReplicaSet 和 Pod 资源，因为 Kubernetes 中的一个缺陷。这个缺陷是 pod-template-hash 与 ReplicaSet 或 Pod 资源名称中的哈希不匹配的位置。更新的 Kubernetes 版本已被修正，但 OpenShift Container Platform 3.11 不会被修复。详情请参阅 Kubernetes 错误参考。

由于这个程序错误，拓扑可能无法反映资源的状态。例如，pod 和 replicaset 不会反映，但这些资源存在。

应用程序附加组件组件使用 Kubernetes Lease API ,leases.coordination.k8s.io，OpenShift Container Platform 3.11 用户缺少这个组件。Kubernetes 1.14 中引入了 Kubernetes Lease API，但 OpenShift Container Platform 3.11 捆绑包 Kubernetes 版本 1.11。

要解决这个问题，手动将以下 Kubernetes Lease API CustomResourceDefinition 应用到 OpenShift Container Platform 3.11 受管集群：

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: leases.coordination.k8s.io
spec:
  group: coordination.k8s.io
  names:
    kind: Lease
    listKind: LeaseList
    plural: leases
    singular: lease
    shortNames:
    - ls
  scope: Namespaced
  versions:
  - name: v1
    served: true    storage: true    schema:
      openAPIV3Schema:
        description: Lease defines a lease concept.
        type: object
        properties:
          apiVersion:
            type: string
          kind:
            type: string
          metadata:
            type: object
          spec:
            type: object
            properties:
              acquireTime:
                format: date-time
                type: string
              holderIdentity:
                type: string
              leaseDurationSeconds:
                format: int64
                type: integer
              leaseTransitions:
                format: int64
                type: integer
              renewTime:
                format: date-time
                type: string
            required:
            - holderIdentity
            - leaseDurationSeconds
            - renewTime
        required:
        - kind
        - metadata
        - spec
  additionalPrinterColumns:
  - JSONPath: .metadata.creationTimestamp
    name: Age
    type: date
  subresources:
    status: {}

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: leases.coordination.k8s.io
spec:
  group: coordination.k8s.io
  names:
    kind: Lease
    listKind: LeaseList
    plural: leases
    singular: lease
    shortNames:
    - ls
  scope: Namespaced
  versions:
  - name: v1
    served: true    storage: true    schema:
      openAPIV3Schema:
        description: Lease defines a lease concept.
        type: object
        properties:
          apiVersion:
            type: string
          kind:
            type: string
          metadata:
            type: object
          spec:
            type: object
            properties:
              acquireTime:
                format: date-time
                type: string
              holderIdentity:
                type: string
              leaseDurationSeconds:
                format: int64
                type: integer
              leaseTransitions:
                format: int64
                type: integer
              renewTime:
                format: date-time
                type: string
            required:
            - holderIdentity
            - leaseDurationSeconds
            - renewTime
        required:
        - kind
        - metadata
        - spec
  additionalPrinterColumns:
  - JSONPath: .metadata.creationTimestamp
    name: Age
    type: date
  subresources:
    status: {}

注： Red Hat Advanced Cluster Management 支持（OpenShift Container Platform 3.11 已被弃用。

当您在 Red Hat OpenShift Container Platform 4.15 中创建服务帐户时，一些云供应商（如 IBM VMware 和 Bare Metal）置备的服务帐户时，帐户不会自动创建 secret。因此，Red Hat Advanced Cluster Management gitopsCluster 控制器无法为 Argo CD push 模型生成受管集群 secret。

此问题不会在 AWS 置备的 Red Hat OpenShift Container Platform 4.15 中发生。但是，这个问题可能会在由其他云供应商置备的 Red Hat OpenShift Container Platform 4.15 中发生。这个问题在 Red Hat Advanced Cluster Management 2.10.3 中以及 Red Hat Advanced Cluster Management 2.9.4 中提供。

要解决这个问题，您必须手动创建一个 secret，并将其附加到服务帐户 open-cluster-management-agent-addon/application-manager。要做到这一点，请完成以下步骤：

要验证您是否已成功创建了 secret 并将其附加到服务帐户，请完成以下步骤：

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

使用 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

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

无法为 OpenShift Container Platform 3.11 受管集群上的 Argo CD Push 模型创建自定义集群 secret。这是因为 OpenShift Container Platform 3.11 受管集群不支持受管服务帐户附加组件。

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

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

因此，如果 Argo CD 应用程序由 Argo CD pull 模型传播到本地集群，则不会清理本地集群 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

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 资源。

在受管集群中运行的 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

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

如果应用程序在更新放置规则后没有部署，请验证 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'

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.10 的应用程序的 Console 和 Topology 已更改。控制台 Topology 页面中没有过滤功能。

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

恢复的 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 中。

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

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

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

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

不支持使用自签名 CA 证书的 HTTPS 代理。

当各种 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

Error on ingesting out-of-order samples

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

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

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

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

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

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

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

./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

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。

Endpoint url cannot have fully qualified paths

Endpoint url cannot have fully qualified paths

endpoint: example.com:443

endpoint: example.com:443

指标收集器不会检测到您使用 addonDeploymentConfig 配置的受管集群中的代理配置。作为临时解决方案，您可以通过删除受管集群清单工作来启用 代理。删除 ManifestWork 会强制应用 addonDeploymentConfig 中的更改。

当需要自定义 CA 捆绑包时，受管集群中的代理配置无法正常工作。

OpenShift Container Platform 3.11 不提供容器安全 Operator。因此，您无法在 ImageManifestVuln 策略中使用 policy-imagemanifestvuln-sub 的策略模板，并将其应用到 OpenShift Container Platform 3.11 集群。

如果您尝试应用 ImageManifestVuln 策略，您会收到以下违反消息：

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

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

监管资源不会被正确清理。当组件被设置为 false 或在 MultiClusterHub operator 中被禁用时，会在可以清理它管理的附加组件前删除监管组件。

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

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

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

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

当您通过在 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": []}}'

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

当您修改现有配置策略时，pruneObjectBehavior 无法正常工作。查看 pruneObjectBehavior 可能无法正常工作的原因：

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

对 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

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

当您创建具有相同策略模板名称的策略时，您会收到不一致的结果，但您可能不知道原因。例如，使用名为 create-pod 的多个配置策略定义策略会导致结果不一致。最佳实践：对策略模板避免使用重复名称。

当您在 MultiClusterHub 对象中禁用监管部署时，不会在没有错误的情况下清理部署。完成以下步骤以禁用监管，以便同时清理部署：

对数据库和策略合规历史记录 API 中断提供了内置弹性，但任何无法由受管集群记录的合规性事件都会在内存中排队，直到它们成功记录为止。这意味着，如果受管集群上有中断并且 managed -policy-framework pod 重启，则所有排队的合规性事件都会丢失。

如果您在数据库中断期间创建或更新新策略，则无法记录为这个新策略发送的任何合规事件，因为无法更新策略到数据库 ID 的映射。当数据库恢复在线时，映射会自动更新，并从这些策略中记录将来的合规事件。

如果数据丢失到 PostgreSQL 服务器，如在没有最新数据的情况下恢复到备份，则必须重启 Red Hat Advanced Cluster Management hub 集群上的监管策略传播器，以便它可以将策略映射到数据库 ID。在重启监管策略传播器前，不再记录与数据库中存在的策略关联的新合规事件。

要重启监管策略传播器，请在 Red Hat Advanced Cluster Management hub 集群中运行以下命令：

oc -n open-cluster-management rollout restart deployment/grc-policy-propagator

oc -n open-cluster-management rollout restart deployment/grc-policy-propagator

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

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

您自带的 Kafka 中有三个名为 spec、status 和 event 的主题。将多集群全局 hub 升级到 1.3 或更高版本后，只会保留 spec 和 status 主题。通过多集群全局 hub 操作对象配置这些主题。您传输的默认 topis 是 gh-spec 和 gh-status。

multicluster global hub 操作对象是系统的 API 或资源，multicluster global hub operator 是控制器。升级多集群全局 hub 后，请协调您自己的 Kafka 集群和多集群全局 hub 操作对象之间的主题。您可以在 Kafka 集群中创建 gh-spec 和 gh-status 主题，或者更改多集群全局 hub 操作对象以使用现有的 spec 和 status 主题。

使用以下 YAML 示例更新多集群全局 hub 操作对象，以使用您自己的 Kafka 主题：

apiVersion: operator.open-cluster-management.io/v1alpha4
kind: MulticlusterGlobalHub
spec:
  availabilityConfig: Basic
  dataLayer:
    kafka:
      topics:
        specTopic: spec
        statusTopic: status
    postgres:
      retention: 18m
  enableMetrics: false

apiVersion: operator.open-cluster-management.io/v1alpha4
kind: MulticlusterGlobalHub
spec:
  availabilityConfig: Basic
  dataLayer:
    kafka:
      topics:
        specTopic: spec
        statusTopic: status
    postgres:
      retention: 18m
  enableMetrics: false

如果多集群全局 hub 在启用了 FIPS 的最新 OpenShift Container Platform 环境中运行，则无法访问 Grafana 控制台，因为 oauth-proxy 镜像错误。Red Hat Advanced Cluster Management 2.10.x 支持最新的 OpenShift Container Platform 版本，可让您从 Red Hat Advanced Cluster Management 2.10.x 中获取 oauth-proxy 镜像。

要访问 Grafana 控制台，请使用 Red Hat Advanced Cluster Management 捆绑包镜像手动更新 oauth-proxy 镜像。要更新 oauth-proxy 镜像，请完成以下步骤：

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

如果您的原始多集群全局 hub 集群崩溃，则多集群全局 hub 会丢失其生成的事件和 cron 作业。即使恢复新的多集群全局 hub 集群，也不会恢复事件和 cron 作业。要解决这个问题，您可以手动运行 cron 作业，请参阅 手动运行总结过程。

没有成功创建的受管集群，这意味着受管集群中不存在 clusterclaim id.k8s.io，不会在策略合规仪表板中计算，但在策略合规仪表板中显示。

如果在 OpenShift Container Platform 4.13 上安装 multicluster global hub Operator，则链接到受管集群列表的所有超链接，仪表板中的详情页面可能会重定向到 Red Hat Advanced Cluster Management 主页。

您需要手动进入目标页面。

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

另外，Cluster Group Compliancy Overview 也是一个问题。

如果受管 hub 集群导入 OpenShift Container Platform 3.11 集群（已弃用）作为受管集群，则无法重定向到 Global Hub > Overview 仪表板中的 Observability 页面。

您需要手动导航到目标页面。