1.7. 已知问题

Machine Config Operator (MCO) 支持第 2 天代理支持时存在一个问题，它出现在重新配置现有非代理集群以使用代理时。MCO 应该对 RHCOS 信任捆绑包在配置映射中应用新配置的代理 CA 证书。当前这无法正常工作。作为临时解决方案，您必须手动将代理 CA 证书添加到信任捆绑包中，然后更新信任捆绑包：

$ cp /opt/registry/certs/<my_root_ca>.crt /etc/pki/ca-trust/source/anchors/
$ update-ca-trust extract
$ oc adm drain <node>
$ systemctl reboot

(BZ#1784201)

集群代理配置 HTTP_PROXY 仅适用于 OpenShift Container Platform 组件，不适用于用户应用程序。这个问题的一个解决方案是，您必须运行以下命令为用户应用程序启用集群代理配置：

$ oc set env dc/jenkins \
    http_proxy=$(oc get proxy cluster -o jsonpath='{.status.httpProxy}') \
    https_proxy=$(oc get proxy cluster -o jsonpath='{.status.httpsProxy}') \
    no_proxy=$(oc get proxy cluster -o jsonpath='{.status.noProxy}')

(BZ#1780125)

当把 OpenShift Container Platform 集群从版本 4.3 更新 至版本 4.4 时，etcd Operator 有时可能会因为处于降级状态而无法升级，。这是因为 InstallerPod 失败所致。这个问题的一个解决方案是，您必须在 etcd 上强制一个新修订版本来修复 InstallerPod 故障，这样可以让 etcd Operator 恢复：

Topology Manager 中 存在一个问题，如果在同一节点上同时创建保证 QoS pod，可能会导致 NUMA 资源无法与同一 NUMA 节点一致。因此，pod 规格中请求的资源可能会 MUMA 不一致。

为了避免在 4.4 中出现这个问题，请不要同时在节点上启动带有 Guaranteed QoS 的多个 pod。

如果您遇到这个问题，请先删除然后再重新创建 pod。(BZ#1834979)

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

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

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

## 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)