1.8. 已知问题

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

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

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

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

升级到 OpenShift Container Platform 4.9 时，Cluster Version Operator 会在有故障条件检查时会阻止升级大约五分钟。错误文本 It may not be safe to apply this update 可能会造成误导。当一个或多个 precondition 检查失败时，会出现这个错误。在某些情况下，这些 precondition 检查可能无法在短时间内失败（例如在 etcd 备份过程中）。在这些情况下，Cluster Version Operator 和对应的 Operator 将会根据设计自动解决失败的条件检查，CVO 可以成功启动升级。

用户应检查其 Cluster Operator 的状态和条件。如果 Cluster Version Operator 显示 It may not be safe to apply this update，则这些状态和条件会提供有关消息严重性的更多信息。如需更多信息，请参阅 BZ#1999777, BZ#2061444, BZ#2006611。

集群管理员可以为 503、404 或两个错误页面指定自定义 HTTP 错误代码响应页面。如果没有为自定义错误代码响应页面指定正确的格式，则会出现路由器 pod 中断且无法解析。路由器不会重新加载来反映自定义错误代码页面更新。作为临时解决方案，您可以使用 oc rsh 命令在本地访问路由器 pod。然后，在服务自定义 http 错误代码页面的所有路由器 pod 中运行 reload-haproxy ：

$ oc -n openshift-ingress rsh router-default-6647d984d8-q7b58
sh-4.4$ bash -x /var/lib/haproxy/reload-haproxy

或者，您可以注释路由来强制重新加载。(BZ#1990020), (BZ#2003961)

集群管理员可以为 503、404 或两个错误页面指定自定义 HTTP 错误代码响应页面。路由器不会重新加载来反映自定义错误代码页面更新。作为临时解决方案，路由器 pod 中的 rsh 在为自定义 http 错误代码页面提供服务的所有路由器 pod 中运行 reload-haproxy ：

$ oc -n openshift-ingress rsh router-default-6647d984d8-q7b58
sh-4.4$ bash -x /var/lib/haproxy/reload-haproxy

或者，您可以注释路由来强制重新加载。(BZ#1990020)

由于某些高品质监控指标被意外丢弃，因此在此发行版本中不提供以下容器性能输入和输出指标： pod、qos 和 System。

这个问题不存在临时解决方案。要跟踪生产工作负载的这些指标，请不要升级到初始 4.9 版本。(BZ#2008120)

Operator Lifecycle Manager (OLM) 结合使用时间戳检查和过时的 API 调用，这些调用不适用于 skipRange 升级，以确定是否需要对特定订阅执行升级。对于使用 skipRange 升级的 Operator，升级过程中会有一个延迟，可能需要长达 15 分钟才能完成解决，并可能会在更长时间内被阻止。

作为临时解决方案，集群管理员可以删除 openshift-operator-lifecycle-manager 命名空间中的 catalog-operator pod。这会导致自动重新创建 pod，从而导致触发 skipRange 升级。(BZ#2002276)

在 OpenShift Container Platform 4.6 及之后的版本中，pull 的镜像引用必须指定以下红帽 registry：

否则，如果没有指定这些 registry，则构建 Pod 无法拉取镜像。

作为临时解决方案，在镜像拉取规格中使用完全限定名称，如 registry.redhat.io/ubi8/ubi:latest 和 registry.access.redhat.com/rhel7.7:latest。

另外，您还可以通过添加允许镜像短名称的 registry 来更新镜像 registry 设置。(BZ#2011293)

在 OpenShift Container Platform 4.8 之前，默认的负载平衡算法是 leastconn。在 OpenShift Container Platform 4.8.0 中，对于非透传的路由，默认设置为 random。切换到 random 与需要使用长时间运行的 websocket 连接的环境不兼容，因为它显著提高了这些环境中的内存消耗。为缓解这种显著内存消耗，在 OpenShift Container Platform 4.9 中默认负载均衡算法被恢复为 leastconn。一旦有一个不会产生大量内存用量的解决方案可用后，在以后的 OpenShift Container Platform 发行版本中，默认值将更改为 random。

您可以输入以下命令来检查默认设置：

$ oc get deployment -n openshift-ingress router-default -o yaml | grep -A 2 ROUTER_LOAD_BALANCE_ALGORITHM
        - name: ROUTER_LOAD_BALANCE_ALGORITHM
          value: leastconn

random 选项仍然可用。但是，受益于此算法选择的路由必须通过输入以下命令在注解中明确设置该选项：

$ oc annotate -n <NAMESPACE> route/<ROUTE-NAME> "haproxy.router.openshift.io/balance=random"

(BZ#2015829)

在 OpenShift Container Platform 单一节点配置中，使用实时内核(kernel-rt)时 pod 创建时间比使用非实时内核时慢两倍。使用 kernel-rt 时，较慢的 pod 创建时间会影响支持的最大 pod 数量，因为节点重启后会影响到恢复时间。

作为临时解决方案，当使用 kernel-rt 时，您可以通过使用 rcupdate.rcu_normal_after_boot=0 内核参数引导来缩短恢复时间。这需要一个实时内核版本 kernel-rt-4.18.0-305.16.1.rt7.88.el8_4 或更高版本。这个已知问题适用于 OpenShift Container Platform 版本 4.8.15 及更新的版本。(BZ#1975356)

有时，在 DU 节点安装零接触置备(ZTP)安装过程中，Operator 安装会失败。InstallPlan API 报告了错误。报告的错误消息为： Bundle unpacking failed。Reason: DeadlineExceeded。如果 Operator 安装任务超过 600 秒，则会出现错误。

作为临时解决方案，请通过对失败 Operator 运行以下 oc 命令来重试 Operator 安装：

SR-IOV Operator 和 Machine Config Operator (MCO) 之间存在一个竞争条件，这会在 DU 节点的 ZTP 安装过程中以不同的方式出现，并且以不同的方式列出其自身。竞争条件可能会导致以下错误：