1.8. 已知问题

在 OpenShift Container Platform 4.19 中，使用 IPsec 进行网络加密的集群可能会遇到 pod 到 pod 连接的问题。这可防止某些节点上的某些 pod 访问其他节点上的服务，从而导致连接超时。内部测试无法在具有 120 个节点或更少的集群中重现此问题。这个问题还没有临时解决方案。(OCPBUGS-55453)
在墨西哥中心区域 mx-central-1 的 AWS 上安装的 OpenShift Container Platform 集群无法销毁。(OCPBUGS-56020)
在 Azure 上安装集群时，如果您将任何 compute.platform.azure.identity.type、controlplane.platform.azure.identity.type 或 platform.azure.defaultMachinePlatform.identity.type 字段值设置为 None，您的集群无法从 Azure Container Registry 拉取镜像。您可以通过提供用户身份或将 identity 字段留空来避免此问题。在这两种情况下，安装程序会生成用户分配的身份。(OCPBUGS-56008)
在以前的版本中，kubelet 不会考虑在 syncPod 方法中运行的探测，它会定期检查 pod 的状态，并在正常探测外进行就绪度探测。在这个版本中，当 kubelet 错误地计算 readinessProbe 周期时，会修复一个程序错误。但是，pod 作者可能会看到配置了就绪度探测的 pod 的就绪度延迟可能会增加。这个行为对于配置的探测更为准确。如需更多信息，请参阅(OCPBUGS-50522)
当 grandmaster 时钟 (T-GM) 过渡到 Locked 状态时，存在一个已知问题。这会在 Digital Phase-Locked Loop (DPLL) 完成其过渡到 Locked-HO-Acquired 状态之前，并在全局导航 Satellite 系统(GNSS)时间源恢复后进行。(OCPBUGS-49826)
在 AWS 上安装集群时，如果您在运行任何 openshift-install create 命令前没有配置 AWS 凭证，安装程序会失败。(OCPBUGS-56658)
must-gather 工具不会收集从 OpenShift Container Platform 4.14 升级的集群的 IPsec 信息。出现这个问题的原因是 networks.operator.openshift.io cluster CR 中的 ipsecConfig 配置有一个空的构造 {}。空构造传递给 OpenShift Container Platform 的升级版本。这个问题的一个临时解决方案是，在 Cluster Network Operator (CNO) CR 中运行以下命令，使用 ipsecConfig 配置：
```
oc patch networks.operator.openshift.io cluster --type=merge -p \
  '{
```
```
$ oc patch networks.operator.openshift.io cluster --type=merge -p \
  '{
  "spec":{
    "defaultNetwork":{
      "ovnKubernetesConfig":{
        "ipsecConfig":{
          "mode":"Full"
        }}}}}'
```
Copy to Clipboard Toggle word wrap
运行命令后，CNO 会收集您可以检查的 must-gather 日志。
(OCPBUGS-52367)
网关 API 和 Amazon Web Services (AWS)、Google Cloud Platform (GCP)和 Microsoft Azure 私有集群中存在一个已知问题。为网关置备的负载均衡器始终配置为外部，这可能会导致错误或意外行为：
- 在 AWS 私有集群中，负载均衡器会处于 pending 状态，并报告错误： Error sync load balancer: failed to ensure load balancer: could not find any appropriate subnets for the ELB。
- 在 GCP 和 Azure 私有集群中，当负载均衡器没有外部 IP 地址时，使用外部 IP 地址置备负载均衡器。
这个问题不支持临时解决方案。(OCPBUGS-57440)

如果崩溃，mlx5_core NIC 驱动程序会导致内存不足问题，kdump 不会将 vmcore 文件保存在 /var/crash 中。要保存 vmcore 文件，请使用 crashkernel 设置为 kdump 内核保留 1024 MB 内存。(OCPBUGS-54520,RHEL-90663)
在 4 代 Intel Xeon 处理器上存在一个已知问题。(OCPBUGS-42495)

目前，使用 guaranteed QoS 类和请求整个 CPU 的 pod 可能无法在节点重启或 kubelet 重启后自动重启。此问题可能会在配置了静态 CPU Manager 策略的节点并使用 full-pcpus-only 的规格中发生，当节点上的大多数或所有 CPU 都已由此类工作负载分配时。作为临时解决方案，请手动删除并重新创建受影响的 pod。(OCPBUGS-43280)
目前，当 irqbalance 服务在特定 AArch64 机器上运行时，缓冲区溢出问题可能会导致服务崩溃。因此，对延迟敏感的工作负载可能会受到在 CPU 中没有正确分布的非受管中断的影响，从而导致性能下降。当前没有解决此问题的方法。(RHEL-89986)
目前，在配置了 SR-IOV 网络虚拟功能的集群中，负责网络设备重命名和由 Node Tuning Operator 管理的 TuneD 服务的系统服务之间可能会出现竞争条件。因此，在节点重启后 TuneD 配置集可能会降级，从而导致性能下降。作为临时解决方案，重启 TuneD pod 以恢复配置集状态。(OCPBUGS-41934)

由于 RHEL-83435，运行 OpenShift Container Platform 4.19 的集群无法挂载从 VMware vSAN Files 导出的 NFS 卷。要避免这个问题，请确保在 8.0 P05 或更高版本的最新版本中运行 VMware ESXi 和 vSAN。(OCPBUGS-55978)

返回顶部

1.8. 已知问题

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links