以下功能是本发行版本的技术预览 ：

当您将 Red Hat Advanced Cluster Management 从 2.2.x 升级到 2.3.1 时，升级会失败。Multiclusterhub 状态显示：failed to download chart from helm repo（在组件错误信息中）。您可能还会看与 no endpoints available for service "ocm-webhook" 问题相关的错误。

在 hub 集群中，在安装 Red Hat Advanced Cluster Management 的命名空间中运行以下命令以重启部署并升级到 2.3.1 版本：

oc delete deploy ocm-proxyserver ocm-controller ocm-webhook multiclusterhub-repo

注：错误解决，但协调过程可能不会立即启动。这可以通过在安装产品的同一命名空间中重启 multicluster-operators-standalone-subscription 来加快执行。

当您将 Red Hat Advanced Cluster Management 从 2.3.0 版本升级到 2.3.1 时，受管集群中的 open-cluster-management-agent-addon-addon 命名空间中的 klusterlet-addon-operator pod 会返回 ImagePullBackOff 错误。

在 hub 集群中完成以下步骤以修复这个问题并升级到 2.3.1 版本：

您正在运行 Red Hat Advanced Cluster Management 版本 2.3.1。

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

您可能会看到 Cluster 页面中显示的节点与搜索结果之间的不同。

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

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

在控制台和 Visual Web 终端中，用户无法搜索包括一个空空格的值。

在以 kubeadmin 登陆后，点下拉菜单中的 Log out 选项，控制台会返回到登录屏幕，但一个浏览器标签页会打开 /logout URL。该页面为空白，您可以关闭此页而不影响您的控制台。

出于安全考虑，搜索不再会显示在受管集群上发现的 secret 的内容。当您通过控制台搜索 secret 时，可能会收到以下出错信息：

Unable to load resource data - Check to make sure the cluster hosting this resource is online

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

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

如果您创建一个 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 面板中显示数据。

当在管理 1000 个集群的 hub 集群上禁用搜索时，search-collector pod CPU 的使用率会高于正常状态。在四天时间内，CPU 的用量大约 2.148Mi。您可以通过将 search-collector 减少到 0 个副本来减少内存用量。

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

当您升级到启用了 observability 的 2.3.2 时，一些集群会降级，因为可观察性附加组件未就绪。运行以下命令重启 multicluster-observability-operator pod：

oc delete po multicluster-observability-operator -n open-cluster-management

observability pod 被重新创建。

在断开连接环境的个别情况下，observability StatefulSet 的一些 pod 会一直处于 ErrPullImage 状态，因为 pod 无法拉取镜像。这些 pod 中定义的镜像与相关的 StatefulSet 中定义的镜像不同。要解决这个问题，您需要删除使用错误镜像的 pod。pod 会自动重启，并且应使用正确的镜像。

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

Error on ingesting out-of-order samples

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

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

在某些情况下，当您删除受管集群时，受管集群的命名空间可能会处于终止状态，因为它的 manifestworks 资源不会被删除。运行以下命令以删除剩余的 manifestworks 资源并删除命名空间：

kubectl -n <managed-cluster-namespace> get manifestworks | grep -v NAME | awk '{print $1}' | xargs kubectl -n <managed-cluster-namespace> patch manifestworks -p '{"metadata":{"finalizers": []}}' --type=merge

在部署集群时提供无效的信息时，不可避免的集群状态会显示 创建 状态，即使它无法启动。无效的信息（如部署中与 install-config 文件中指定的区域不匹配的区域）会导致在 Hive 置备 pod 中添加以下错误：

provision failed, requirements not met

Red Hat Advanced Cluster Management 版本 2.3 继续报告为集群创建的状态，但无效的信息会阻止创建集群。

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

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

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

当您尝试在 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

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

当您意外尝试以不同名称的集群形式重新导入名为 local-cluster 的集群时，local-cluster 和重新导入集群的状态会显示"offline"。

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

当您尝试创建集群时指定无效的 Ansible 作业模板名称并且失败时，集群会在控制台的不同屏幕上显示不同的状态。当通过 Infrastructure > Clusters > Managed cluster 查看状态时，它会显示一个 Failed 状态。当选择：Infrastructure > Clusters > Cluster sets > <your_cluster_set_name> > Managed clusters，状态会一直处于 Creating。正确的状态应该为 Failed。您可以尝试再次创建集群，并输入正确的 Ansible 模板名称。

有时，在分离本地集群后，local-cluster 可能无法自动重新导入。当发生这种情况时，local-cluster 在 Red Hat Advanced Cluster Management 控制台中会显示 Pending Import 状态。

要重新导入 local-cluster，请完成以下步骤：

当您删除使用 Red Hat Advanced Cluster Management 控制台创建的受管集群时，受管集群的 clusterdeployment 可能会处于终止状态。要绕过这个问题并删除这个 clusterdeployment，通过编辑集群的 agentclusterinstall 资源来手动删除 agentclusterinstall.agent-install.openshift.io/ai-deprovision finalizer。

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

您无法在不创建包含这两个架构文件的发行镜像 (ClusterImageSet) 的情况下在与 hub 集群架构不同的架构中创建受管集群。例如，您无法从 ppc64le hub 集群创建 x86_64 集群。集群创建失败，因为 OpenShift Container Platform 发行 registry 不提供多架构镜像清单。

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

创建流程使用合并的发行镜像来创建集群。

您无法通过将集群的标签更新至新集群集，将集群或集群集从一个集群设置为另一个集群。要将集群或集群设置为另一个集群，请使用 Red Hat Advanced Cluster Management 控制台将其从集群集中删除。从集群集合中删除后，使用控制台将其添加到新集群中。

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

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

当 hub 集群在 OpenShift Container Platform 版本 4.8 上托管时，您无法使用 Red Hat Advanced Cluster Management hub 集群创建裸机受管集群。

当您分离一个受管集群时，Create resource 页面可能会临时中断并显示以下错误：

Error occurred while retrieving clusters info. Not found.

等待命名空间自动被删除，这在分离集群后需要 5-10 分钟完成。或者，如果命名空间处于终止状态，则需要手动删除命名空间。返回该页面查看错误是否已解决。

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

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

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

您必须以 root 身份登录才能运行 management-ingress 服务。

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

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

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

特定受管集群中特定资源的搜索详情页面可能会失败。在进行搜索前，您必须确保受管集群中的 work-manager 附加组件处于 Available 状态。

Argo CD 与 Red Hat Advanced Cluster Management 集成无法在在 IBM Power 上运行的 Red Hat Advanced Cluster Management hub 集群上工作，因为没有可用的 ppc64le 镜像。

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

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

当您 按 Applications 表 上的行操作按钮点击 Search application 时，您会被定向到 Search 页面，其结果可能与 应用程序详情页面中的 相同预设置过滤器不同。

当从 Argo CD 应用程序的应用程序详情页面中点链接 Search all related applications，搜索页面会返回无效的 preset 过滤器。

您可以在搜索控制台中删除目录过滤器来解决这个问题。

当使用 Create application 编辑器创建 Red Hat Advanced Cluster Management 应用程序时，当 hub 集群位于代理后面时，可能会收到 Git 存储库的以下错误：

与 Git 存储库的连接失败。无法获取分支。

您可以使用 Git 存储库 URL 而不是使用分支信息。在指定了分支时应用会正确部署。

Argo 应用的集群节点搜索链接可能会返回 name:undefined。

当您从 Argo 应用的集群节点详情中点 Launch resource in search 链接时，搜索过滤器可能会包含 name:undefined。

您可以通过将未定义的值替换为集群节点详情中的集群名称来解决这个问题。

如果集群使用多个订阅，集群可能无法在应用程序拓扑中正确分组。

当您使用多个订阅部署应用程序时，在 All Subscription 视图中的集群节点可能没有被正确分组。

例如，当使用多个订阅部署一个包含 Helm 和 Git 仓库组合在一起的应用程序时，All subscriptions 视图无法正确显示 Helm 订阅中资源的状态。

查看各个订阅视图中的拓扑，以显示正确的集群节点分组信息。

当您使用订阅下拉菜单在应用程序订阅间切换时，应用程序拓扑可能会失败。

要解决这个问题，尝试切换到其他订阅，或者刷新浏览器来查看拓扑显示的刷新。

不支持 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 实例。

如果在创建或编辑应用程序时选择了 Deploy on local cluster，则应用程序拓扑无法正确显示。在本地集群上部署 是选项,可在 hub 集群上部署资源,以便可以将其作为 本地集群 管理,但这不是本发行版本的最佳实践。

要解决这个问题，请执行以下步骤：

当订阅了命名空间频道且修复其他相关资源（如频道、secret、ConfigMap 或放置规则等）后，订阅会处于 FAILED 状态，命名空间订阅不会持续被协调。

要强制订阅再次进行协调以退出 FAILED 状态，完成以下步骤：

oc label subscriptions.apps.open-cluster-management.io the_subscription_name reconcile=true

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

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

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

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

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

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

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

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

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

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

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

当安装了 Ansible Automation Platform（早期访问）2.0.0 时，AnsibleJobs 无法运行。如果要通过 Red Hat Advanced Cluster Management 提交 prehook 和 posthook AnsibleJobs，请使用 Ansible Automation Platform Resource Operator 0.1.1。

应用程序名称不能超过 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 表的限制：

在 OpenShift Container Platform 4.8 中，默认启用 Finished 资源的 TTL Controller，这意味着作业会每小时被删除。此作业清理会导致 Ansible Automation Platform Resource Operator 重新运行关联的自动化。再次使用由策略框架创建的 AnsibleJob 资源中的现有详情运行自动化。提供的详细信息可能包括之前确定的违规行为，这些违规行为可能会错误地显示为重复违规行为。您可以禁用清理作业的控制器，以防止这些重复的违反情况。要禁用清理作业的控制器，请完成以下步骤：

当您将策略 PlacementRule 从 matchExpressions 更新至 matchLabels 时，旧的 matchExpression 不会被删除。

请参阅以下示例中第一个示例中的 matchExpressions 更改为 matchLabels，但 matchExpressions 不会被删除。

apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-etcdencryption
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      - {key: environment, operator: In, values: ["test"]}

spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions: []
    matchLabel: {}

当决定具有给定 ClusterRole 权限的用户数量时，IAM 策略控制器只会检查 Kubernetes User 资源，且不考虑 Kubernetes Group 资源中的用户。

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

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

具有集群范围角色绑定到 open-cluster-management:cluster-manager-admin 的用户无法创建自动化策略。若要修复此问题，您必须手动将角色添加到自动化策略中。

创建或更新集群角色(ClusterRole)，为 Ansible 资源向 cluster-manager-admin 角色添加规则。您的 YAML 可能会重新排序以下文件：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: add-ansible-rules
  labels:
    rbac.authorization.k8s.io/aggregate-to-ocm-cluster-manager-admin: "true"
rules:
- apiGroups: ["tower.ansible.com"]
  resources: ["ansiblejobs"]
  verbs: ["create","get", "list", "watch", "update", "delete", "deletecollection", "patch"]

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

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