1.10. 已知问题

本节包括 OpenShift Container Platform 4.21 的几个已知问题。

目前，因为一个已知问题，OpenShift Container Platform 4.21 版本的 Cluster Resource Override Operator 和 DPU Operator 将在后续的 4.21 维护发行版本中提供。(OCPBUGS-74224)
如果您使用 oc adm release mirror 命令将 OpenShift Container Platform 发行镜像镜像到断开连接的环境的 registry 中，则发行镜像 Sigstore 签名不会与镜像进行镜像。
这在 OpenShift Container Platform 4.21 中存在问题，因为 openshift 集群镜像策略现在默认部署到集群中。此策略会导致 CRI-O 在拉取镜像时自动验证 Sigstore 签名。(OCPBUGS-70297)
如果没有 Sigstore 签名，在断开连接的环境中升级到 OpenShift Container Platform 4.21 后，将来的 Cluster Version Operator pod 可能无法运行。您可以通过安装 oc-mirror 插件 v2 并使用 oc mirror 命令镜像 OpenShift Container Platform 发行镜像来避免此问题。oc-mirror 插件 v2 将发行镜像及其 Sigstore 签名从您的镜像 registry 镜像到您的断开连接的环境中。
如果无法使用 oc-mirror 插件 v2，您可以使用 oc image mirror 命令将 Sigstore 签名镜像(mirror)到镜像 registry 中，方法是使用类似如下的命令：
```
$ oc image mirror "quay.io/openshift-release-dev/ocp-release:${RELEASE_DIGEST}.sig" "${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${RELEASE_DIGEST}.sig"
```
其中：
RELEASE_DIGEST
使用 : 字符替换的摘要镜像指定您的摘要镜像。例如： sha256:884e1ff5effeaa04467fab9725900e7f0ed1daa89a7734644f14783014cebdee 变为 sha256-884e1ff5effeaa04467fab9725900e7f0ed1daa89a7734644f14783014cebdee.sig。
如需有关 oc-mirror v2 插件的信息，请参阅使用 oc-mirror 插件 v2 为断开连接的安装镜像镜像。
从 OpenShift Container Platform 4.21 开始，容器的默认最大打开文件软限制会下降。因此，最终用户可能会遇到应用程序失败。要临时解决这个问题，请使用您选择的方法（如 ulimit 命令）增加容器运行时(CRI-O) ulimit 配置。请注意，如果您将集群从 OpenShift Container Platform 4.20 升级到 4.21，则会保留现有的最大打开文件限制。(OCPBUGS-62095)
目前，在配置了 SR-IOV 网络虚拟功能的集群中，负责网络设备重命名和由 Node Tuning Operator 管理的 TuneD 服务的系统服务之间可能会出现竞争条件。因此，在节点重启后 TuneD 配置集可能会降级，从而导致性能下降。作为临时解决方案，重启 TuneD pod 以恢复配置集状态。(OCPBUGS-41934)
目前，使用 guaranteed QoS 类和请求整个 CPU 的 pod 可能无法在节点重启或 kubelet 重启后自动重启。此问题可能会在配置了静态 CPU Manager 策略的节点并使用 full-pcpus-only 的规格中发生，当节点上的大多数或所有 CPU 都已由此类工作负载分配时。作为临时解决方案，请手动删除并重新创建受影响的 pod。(OCPBUGS-43280)
在使用特定的 AMD EPYC 处理器的系统上，一些低级别系统中断（如 AMD-Vi ）可能包含 CPU 掩码中与 CPU 固定工作负载重叠的 CPU。此行为是因为硬件设计。这些特定错误报告中断通常不活跃，目前没有已知的性能影响。(OCPBUGS-57787)
虽然裸机主机的第 2 天固件更新和 BIOS 属性重新配置通常可用于这个版本，但 Bare Metal Operator (BMO)不提供原生机制来取消固件更新请求。如果 HostFirmwareComponents 或 HostFirmwareSettings 资源的固件更新或设置更改失败，返回一个错误或无限期卡住，您可以按照以下步骤尝试恢复：
- 删除 HostFirmwareComponents 和 HostFirmwareSettings 资源的更改。
- 将节点设置为 online: false 以触发重新引导。
- 如果问题仍然存在，删除 Ironic pod。
以后的发行版本可能会计划提供操作的原生中止功能。
存在一个已知问题：在 AWS 集群中配置 gp3 存储卷的最大吞吐量。此功能不适用于 control plane 机器集。这个问题还没有临时解决方案，但它已在 4.21.1 中解决。(OCPBUGS-74478)
当使用用户置备的 DNS 在 Google Cloud 上安装私有集群时，您可能会遇到显示 bootstrap 无法完成或集群初始化失败的安装错误。在这两种情况下，安装可以成功，从而导致集群健康。作为临时解决方案，请在与要部署的集群相同的虚拟私有云(VPC)中安装私有集群。(OCPBUGS-54901)
目前，NUMA Resources Operator (NRO)提供的 topo-aware-scheduler 不支持基于 Kubernetes 优先级的抢占。当可用节点上的所有 NUMA 区域都完全被较低优先级 pod 使用时，具有 PreemptLowerPriority 策略的高优先级 pod 会一直处于 Pending 状态，而不是抢占较低优先级 pod。因此，在使用 topo-aware-scheduler 时，依赖于基于优先级的抢占调度恢复的工作负载无法正常工作。(OCPBUGS-77930)

1.10. 已知问题

学习

尝试、购买和销售

社区

關於紅帽

让开源更具包容性

关于红帽文档

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links