1.8. 已知问题

在 OpenShift Container Platform 4.1 中，匿名用户可以访问发现端点。之后的版本会取消对这端点的访问，以减少可能的安全漏洞攻击面。一些发现端点被转发到聚合的 API 服务器。但是，升级的集群中会保留未经身份验证的访问，因此现有用例不会中断。

如果您是一个从 OpenShift Container Platform 4.1 升级到 4.12 的集群的集群管理员，您可以撤销或继续允许未经身份验证的访问。除非对未经身份验证的访问有特殊需要，否则您应该撤销它。如果您继续允许未经身份验证的访问，请注意相关的风险。

使用以下脚本撤销对发现端点的未经身份验证的访问：

## Snippet to remove unauthenticated group from all the cluster role bindings
$ for clusterrolebinding in cluster-status-binding discovery system:basic-user system:discovery system:openshift:discovery ;
do
### Find the index of unauthenticated group in list of subjects
index=$(oc get clusterrolebinding ${clusterrolebinding} -o json | jq 'select(.subjects!=null) | .subjects | map(.name=="system:unauthenticated") | index(true)');
### Remove the element at index from subjects array
oc patch clusterrolebinding ${clusterrolebinding} --type=json --patch "[{'op': 'remove','path': '/subjects/$index'}]";
done

此脚本从以下集群角色绑定中删除未经身份验证的对象：

(BZ#1821771)

在有些情况下，IBM Cloud VPC 集群可能无法安装，因为有些 worker 机器没有启动。相反，这些 worker 机器保留在 Provisioned 阶段。

这个问题有一个临时解决方案。在执行初始安装的主机上，删除失败的机器并再次运行安装程序。

目录源更新后，OLM 需要时间来更新订阅状态。这意味着，当 Topology Aware Lifecycle Manager (TALM) 决定是否需要补救时，订阅策略的状态可能会继续显示为合规。因此，在订阅策略中指定的 Operator 不会进行升级。作为临时解决方案，请在目录源策略的 spec 部分包含一个 status 字段，如下所示：

metadata:
  name: redhat-operators-disconnected
spec:
  displayName: disconnected-redhat-operators
  image: registry.example.com:5000/disconnected-redhat-operators/disconnected-redhat-operator-index:v4.11
status:
  connectionState:
    lastObservedState: READY

这可减少 OLM 拉取新索引镜像并使 pod 就绪的延迟，从而减少目录源策略补救和订阅状态更新之间的时间。如果问题仍然存在，且订阅策略状态更新仍较晚，您可以使用相同的订阅策略应用另一个 ClusterGroupUpdate CR，或者具有不同名称相同的 ClusterGroupUpdate CR。(OCPBUGS-2813)

如果所有选择的集群在 ClusterGroupUpdate CR 启动后，TALM 会跳过补救策略。使用修改后的目录源策略和同一 ClusterGroupUpdate CR 中的订阅策略更新 Operator 不会被完成。订阅策略会被跳过，因为它仍然合规，直到强制实施目录源更改。作为临时解决方案，请在 common-subscription 策略中添加以下对 CR 的更改，例如：

metadata.annotations.upgrade: "1"

这会在 ClusterGroupUpdate CR 开始前使策略不合规。(OCPBUGS-2812)

BMCEventSubscription CR 无法在 ACM 部署的多集群环境中为 spoke 集群创建 Redfish 订阅，其中 metal3 服务只在 hub 集群上运行。解决方法是通过直接调用 Redfish API 来创建订阅，例如运行以下命令：

curl -X POST -i --insecure -u "<BMC_username>:<BMC_password>" https://<BMC_IP>/redfish/v1/EventService/Subscriptions \
    -H 'Content-Type: application/json' \
    --data-raw '{
    "Protocol": "Redfish",
    "Context": "any string is valid",
    "Destination": "https://hw-event-proxy-openshift-bare-metal-events.apps.example.com/webhook",
    "EventTypes": ["Alert"]
    }'

您应该会收到 201 Created 响应和一个带有 Location: /redfish/v1/EventService/Subscriptions/<sub_id> 的标头，它表示成功创建了 Redfish 事件订阅。(OCPBUGSM-43707)

当使用 GitOps ZTP 方法管理集群并删除还没有完成安装的集群时，hub 集群上的集群命名空间清理可能会无限期地挂起。要完成命名空间删除，请从集群命名空间中的两个 CR 中删除 baremetalhost.metal3.io finalizer：

平台 Operator 和 RukPak 的已知问题：

使用外部云供应商的集群在轮转后无法检索更新的凭证。以下平台会受到影响：

作为临时解决方案，请运行以下命令重启 openshift-cloud-controller-manager pod：

$ oc delete pods --all -n openshift-cloud-controller-manager

(OCPBUGS-5036)

当在使用 OVN-Kubernetes 网络供应商的集群中替换 control plane 机器时，与 OVN-Kubernetes 相关的 pod 可能无法在替换的机器上启动。当发生这种情况时，新机器上缺少网络会阻止 etcd 替换旧机器。因此，集群会处于这个状态，并可能会降级。当 control plane 被手动替换或被 control plane 机器集替换 时，可能会发生此行为。

目前还没有临时解决方案来解决这个问题。要避免这个问题，禁用 control plane 机器集，如果集群使用 OVN-Kubernetes 网络供应商，则不要手动替换 control plane 机器。(OCPBUGS-5306)

使用调度到 control plane 节点的 Azure File NFS 卷创建 pod 会导致挂载被拒绝。(OCPBUGS-18581)

要临时解决这个问题：如果您的 control plane 节点可以调度，pod 可以在 worker 节点上运行，使用 nodeSelector 或 Affinity 将 pod 调度到 worker 节点上。

当使用静态 IP 寻址和 Tang 加密安装 OpenShift Container Platform 集群时，节点在没有网络设置的情况下启动。此条件可防止节点访问 Tang 服务器，从而导致安装失败。要解决此条件，您必须将每个节点的网络设置设置为 ip 安装程序参数。