1.8. 已知问题

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

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

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

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

当使用用户置备的基础架构在 vSphere 上打开虚拟机时，扩展节点的过程可能无法正常工作。虚拟机监控程序配置中的一个已知问题会导致在虚拟机监控程序中创建机器，但不会开机。如果在扩展机器集后某个节点可能处于 Provisioning 状态，您可以调查 vSphere 实例本身中的虚拟机状态。使用 VMware 命令 govc tasks 和 govc events 来确定虚拟机的状态。检查类似以下内容的错误消息：

[Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize(8192). ]

您可以使用 VMware KBase 文章中的步骤解决这个问题。如需更多信息，请参阅红帽知识库解决方案 [UPI vSphere] 节点扩展功能无法按预期工作。（BZ#1918383）

如果您在使用 x86_64 架构的 VMware 上运行集群，且 install-config.yaml 文件中设置了 platform: none 字段，则在 OpenShift Container Platform 集群版本 4.7 或从集群版本 4.6 升级到版本 4.7 上可能会失败。当集群使用通过虚拟硬件版本 14 或更高版本配置的虚拟机时，会出现这个失败。作为临时解决方案，您可以将虚拟机配置为使用虚拟硬件版本 13。

部署到 VMware Cloud（VMC）的集群不会遇到虚拟硬件版本 14 或更高版本的问题。（BZ#1941714）

启动和停止 pod 迅速可能会导致 pod 处于 Terminating 状态。作为临时解决方案，您必须运行以下命令删除卡住的 pod：

$ oc delete --force -n <project_name> <pod_name>

此问题将在 OpenShift Container Platform 以后的发行版本中解决。（BZ#1929463）

将 Performance Addon Operator 从 4.6 升级到 4.7 会失败并显示以下错误：

"Warning  TooManyOperatorGroups  11m   operator-lifecycle-manager  csv created in namespace with multiple operatorgroups, can't pick one automatically"

在升级前，请按照在以前安装到特定命名空间时升级 Performance Addon Operator 中的步骤进行操作。

（BZ#1913826）

有时需要重启来在支持的 NIC 上实现 SR-IOV 更改。SR-IOV 目前会在重新引导时执行。如果此重启与 Machine Config 策略中的更改一致，则该节点可能会处于未确定的状态。Machine Config Operator 假设没有应用更新后的策略。

为了避免这个问题，应该按顺序完成需要 MCO 和 SR-IOV 更改的新节点。首先，应用所有 MCO 配置并等待节点发生。然后，应用 SR-IOV 配置。

如果一个新节点被添加到包含 SR-IOV 的机器配置池中，可以通过从 Machine Config Pool 中删除 SR-IOV 策略来避免此问题，然后添加新的 worker。然后，重新应用 SR-IOV 策略。

（BZ#1921321）

精度时间协议（PTP）错误会在适配器卡 Mellanox MT27800 系列 [ConnectX-5] 中观察到。在 ptp4l 日志中会出现与时钟同步相关的错误。

这些错误会因为 NIC 硬件时钟被重置而导致系统时钟更新大于正常的情况。造成此问题的根原因未知，目前还没有临时解决方案。

（BZ#1913279）

当在使用最新的 Dell 固件（04.40.00.00）节点在裸机中尝试 IPI 安装时，不会部署节点，并在它们的状态中显示错误。这是因为 Dell Firmware（4.40.00.00）使用 eHTML5 作为虚拟控制台插件。

要临时解决这个问题，请将虚拟控制台插件改为 HTML5 并再次运行部署。现在，节点应该可以被成功部署。如需更多信息，请参阅使用虚拟介质安装的固件要求。

（BZ#1915828）

在使用 Kuryr 的 RHOSP 上安装集群会超时，并在 bootstrapping 过程中出现以下信息：

INFO Waiting up to 20m0s for the Kubernetes API at https://api.ostest.shiftstack.com:6443...
INFO API v1.20.0+ba45583 up
INFO Waiting up to 30m0s for bootstrapping to complete...
ERROR Attempted to gather ClusterOperator status after wait failure: listing ClusterOperator objects: Get "https://api.ostest.shiftstack.com:6443/apis/config.openshift.io/v1/clusteroperators": dial tcp 10.46.44.166:6443: connect: connection refused
INFO Use the following commands to gather logs from the cluster
INFO openshift-install gather bootstrap --help
FATAL failed to wait for bootstrapping to complete: timed out waiting for the condition

超时是因为 Kuryr 检测集群节点的 RHOSP Networking 服务（neutron）子网变化的方式造成的。

作为临时解决方案，请不要删除 control plane 机器清单，如安装文档中的"创建 Kubernetes 清单和 Ignition 配置文件" 部分所述。当您被指示要运行以下命令时：

$ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml

运行这个命令替代：

$ rm -f openshift/99_openshift-cluster-api_worker-machineset-*.yaml

（BZ#1927244）

如果您的集群通过管理员置备的外部负载均衡器公开默认 Ingress Controller，将所有 HTTP 流量重定向到 HTTPS，则必须修补新的明文 Ingress Canary 路由，以便在 4.6 升级到 4.7 升级过程中使用边缘终止（edge termination）。

$ oc patch route/canary -n openshift-ingress-canary -p '{"spec":{"tls":{"termination":"edge","insecureEdgeTerminationPolicy":"Redirect"}}}'

（BZ#1932401）

对 openvswitch ("net: openvswitch: reorder masks array based on usage") 代码的更新会导致 openvswitch et/openvswitch/flow_table::flow_lookup 访问 preemptible（和 migratable）项中的 per-cpu 数据条件，从而会导致一个实时内核l panic。因此，kernel-rt 不稳定，并会影响低延迟应用程序。

在这个问题被解决前，建议不要升级到 OpenShift Container Platform 4.7。

(BZ#1918456)

SR-IOV 设备插件不允许作为资源公开节点上的 VFIO 设备。这会导致在 Intel 设备中阻止 DPDK 工作负载。

在修复这个问题之前，建议 SR-IOV 用户不要升级到 OpenShift Container Platform 4.7。

（BZ#1930469）

在 OpenShift Container Platform 4.7 中，添加到 Operator 基础架构代码中的 ConfigInformers 对象无法成功启动。因此，ConfigObserver 对象无法同步缓存。当发生这种情况时，oVirt CSI Driver Operator 会在几分钟后关闭，这会导致持续重启。作为临时解决方案，您可以执行以下步骤：

因此，oVirt CSI Driver Operator 不会再不断重启。（BZ#1929777）