1.8. 已知问题

oc annotate 命令不适用于包含了等号（=）的 LDAP 组名称，因为命令使用等号作为注释名称和值之间的分隔符。作为临时解决方案，使用 oc patch 或 oc edit 添加注解。(BZ#1917280)
当使用静态 IP 地址（技术预览）在 VMware vSphere 上安装集群时，安装程序可将不正确的配置应用到 control plane 机器集(CPMS)。这可能导致在不定义静态 IP 地址的情况下重新创建 control plane 机器。(OCPBUGS-28236)
安装 Azure 集群时不支持指定标准 Ebdsv5 或 Ebsv5 系列机器类型实例。这个限制是 Azure terraform 供应商不支持这些机器类型的结果。(OCPBUGS-18690)
当运行启用了 FIPS 的集群时，您可能会在 RHEL 9 系统上运行 OpenShift CLI (oc)时收到以下错误：FIPS mode is enabled, but the required OpenSSL backend is unavailable。作为临时解决方案，请使用 OpenShift Container Platform 集群提供的 oc 二进制代码。(OCPBUGS-23386)
在 4.15 中，在 Red Hat OpenStack Platform (RHOSP) 环境中运行 IPv6 网络，使用 endpointPublishingStrategy.type=LoadBalancerService YAML 属性配置的 IngressController 对象将无法正常工作。(BZ""2263550, BZ""2263552)
在 4.15 中，在 Red Hat OpenStack Platform (RHOSP) 环境中运行 IPv6 网络，使用 IPv6 ovn-octavia 负载均衡器创建的运行状况监控器将无法正常工作。(OCPBUGS-29603)
在 4.15 中，在 Red Hat OpenStack Platform (RHOSP) 环境中运行 IPv6 网络，不允许使用多个服务共享 IPv6 负载均衡器，因为错误地将 IPv6 负载均衡器标记为集群内部。(OCPBUGS-29605)
当使用静态 IP 寻址和 Tang 加密安装 OpenShift Container Platform 集群时，节点在没有网络设置的情况下启动。此条件可防止节点访问 Tang 服务器，从而导致安装失败。要解决此条件，您必须将每个节点的网络设置设置为 ip 安装程序参数。
1. 对于安装程序置备的基础架构，在安装前通过执行以下步骤为每个节点提供 ip 安装程序参数。
  1. 创建清单。
  2. 对于每个节点，使用注解修改 BareMetalHost 自定义资源，使其包含网络设置。例如：
    $ cd ~/clusterconfigs/openshift $ vim openshift-worker-0.yaml
    apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: annotations: bmac.agent-install.openshift.io/installer-args: '["--append-karg", "ip=<static_ip>::<gateway>:<netmask>:<hostname_1>:<interface>:none", "--save-partindex", "1", "-n"]' 1 2 3 4 5 inspect.metal3.io: disabled bmac.agent-install.openshift.io/hostname: <fqdn> 6 bmac.agent-install.openshift.io/role: <role> 7 generation: 1 name: openshift-worker-0 namespace: mynamespace spec: automatedCleaningMode: disabled bmc: address: idrac-virtualmedia://<bmc_ip>/redfish/v1/Systems/System.Embedded.1 8 credentialsName: bmc-secret-openshift-worker-0 disableCertificateVerification: true bootMACAddress: 94:6D:AE:AB:EE:E8 bootMode: "UEFI" rootDeviceHints: deviceName: /dev/sda
    对于 ip 设置，替换：
    1
    <static_ip>，使用节点的静态 IP 地址，例如 192.168.1.100
    2
    <gateway>，使用网络网关的 IP 地址，例如 192.168.1.1
    3
    <netmask>，使用网络掩码，例如 255.255.255.0
    4
    <hostname_1>，使用节点主机名，如 node1.example.com
    5
    <interface>，使用网络接口的名称，如 eth0
    6
    <fqdn>，使用节点的完全限定域名
    7
    <role>，使用 worker 或 master，以反映节点的角色
    8
    <bmc_ip>，使用 BMC IP 地址，以及 BMC 的协议和路径。
  3. 将文件保存到 clusterconfigs/openshift 目录中。
  4. 创建集群。
2. 当使用 Assisted Installer 安装时，在安装前使用 API 修改每个节点的安装程序参数，以将网络设置附加为 ip 安装程序参数。例如：
```
$ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${infra_env_id}/hosts/${host_id}/installer-args \
-X PATCH \
-H "Authorization: Bearer ${API_TOKEN}" \
-H "Content-Type: application/json" \
-d '
    {
      "args": [
        "--append-karg",
        "ip=<static_ip>::<gateway>:<netmask>:<hostname_1>:<interface>:none", 1 2 3 4 5
        "--save-partindex",
        "1",
        "-n"
      ]
    }
  ' | jq
```
  对于以前的网络设置，替换：
  1
  <static_ip>，使用节点的静态 IP 地址，例如 192.168.1.100
  2
  <gateway>，使用网络网关的 IP 地址，例如 192.168.1.1
  3
  <netmask>，使用网络掩码，例如 255.255.255.0
  4
  <hostname_1>，使用节点主机名，如 node1.example.com
  5
  <interface>，使用网络接口的名称，如 eth0。

联系红帽支持以获取更多详细信息和帮助。

(OCPBUGS-23119)

在 OpenShift Container Platform 4.15 中，所有节点都使用 Linux 控制组版本 2 (cgroup v2) 进行内部资源管理，以便与默认的 RHEL 9 配置保持一致。但是，如果您在集群中应用性能配置集，与性能配置集关联的低延迟调整功能不支持 cgroup v2。
因此，如果您应用一个性能配置集，集群的所有节点都会重启，并切回到 cgroup v1 配置。此重启包括 control plane 节点和不是由性能配置集为目标的 worker 节点。
要将集群中的所有节点恢复到 cgroups v2 配置，您必须编辑 Node 资源。如需更多信息，请参阅配置 Linux cgroup v2。您无法通过删除最后一个性能配置集将集群恢复到 cgroups v2 配置。(OCPBUGS-16976)
目前，当删除使用 SR-IOV 网络设备的 pod 时，可能会出现错误。这个错误是由 RHEL 9 中的更改造成的，其中之前网络接口的名称会在重命名时添加到其替代名称列表中。因此，当删除附加到 SR-IOV 虚拟功能 (VF) 的 pod 时，VF 会返回具有新的意外名称的池，如 dev69，而不是其原始名称，如 ensf0v2。虽然这个错误不严重，但 Multus 和 SR-IOV 日志可能会在系统自行恢复时显示错误。由于这个错误，删除 pod 可能需要几秒钟时间。(OCPBUGS-11281, OCPBUGS-18822, RHEL-5988)
当您在 OpenShift Container Platform 集群上运行 Cloud-native Network Function (CNF) 延迟测试时，oslat 测试有时会返回大于 20 微秒的结果。这会导致 oslat 测试失败。(RHEL-9279)
当您将 preempt-rt 补丁与实时内核一起使用，并更新网络中断的 SMP 关联性时，对应的中断请求(IRQ)线程不会立即接收更新。相反，更新会在收到下一个中断时生效，然后线程会迁移到正确的内核。(RHEL-9148)
Intel Westport Channel e810 NIC 中的全局导航 satellite 系统(GNSS)模块配置为 grandmaster 时钟(T-GM)可以报告 GPS FIX 状态以及 GNSS 模块和 GNSS constellation satellites 之间的 GNSS 偏移。
当前 T-GM 实现不使用 ubxtool CLI 来探测 ublox 模块来读取 GNSS 偏移和 GPS FIX 值。相反，它使用 gpsd 服务来读取 GPS FIX 信息。这是因为 ubxtool CLI 的当前实现需要 2 秒才能接收响应，每个调用都会增加 CPU 用量 3 倍。(OCPBUGS-17422)
当前 grandmaster 时钟(T-GM)实现具有来自 GNSS 的单一 NMEA 句子生成器，而无需备份 NMEA 生成器。如果在到 e810 NIC 的过程中 NMEA 句子丢失，则 T-GM 无法同步网络同步链中的设备，而 PTP Operator 会报告错误。当 NMEA 字符串丢失时，可以报告 FREERUN 事件。(OCPBUGS-19838)
目前，当安装了 multicluster engine for Kubernetes operator (MCE)时，Web 控制台中一些页面的 YAML 标签页会在一些浏览器中意外停止。此时会显示以下信息："Oh no!Something went wrong." (OCPBUGS-29812)
如果在集群中启用了 IPsec，则必须在升级到 OpenShift Container Platform 4.15 前禁用它。存在一个已知问题：在升级到 4.15 时 pod 到 pod 的通信可能会中断或丢失，而无需禁用 IPsec。有关禁用 IPsec 的详情，请参考配置 IPsec 加密。(OCPBUGS-43323)
如果您在集群和外部节点之间启用了 IPsec 加密，则停止外部节点上的 IPsec 连接会导致外部节点的连接。由于连接的 OpenShift Container Platform 端，IPsec 隧道关闭无法识别此连接丢失。(RHEL-24802)
如果您在集群中启用了 IPsec，且集群是 OpenShift Container Platform 集群的托管 control plane，则 pod 到 pod 流量的 IPsec 隧道的 MTU 不会被自动进行。(OCPBUGS-28757)
如果在集群中启用了 IPsec，则无法将现有 IPsec 隧道修改为您创建的外部主机。OpenShift Container Platform 无法识别现有的 NMState Operator NodeNetworkConfigurationPolicy 对象来调整现有的 IPsec 配置来加密到外部主机的流量。(RHEL-22720)
如果您在集群中启用了 IPsec，在托管 north-south IPsec 连接的节点上，重启 ipsec.service systemd 单元或重启 ovn-ipsec-host pod 会导致 IPsec 连接丢失。(RHEL-26878)
目前，Operator 目录镜像存在一个已知问题。oc-mirror 重建目录并根据 imagesetconfig 目录过滤规格重新生成其内部缓存。此操作需要使用目录中所含的 opm 二进制文件。在 OpenShift Container Platform 4.15 中，Operator 目录包含 opm RHEL 9 二进制文件，这会导致在 RHEL 8 系统中镜像过程失败。(OCPBUGS-31536)

目前存在一个已知问题：OpenShift Container Platform 4.15 中发布的 opm CLI 工具版本不支持 RHEL 8。作为临时解决方案，RHEL 8 用户可以进入 OpenShift 镜像站点并下载 OpenShift Container Platform 4.14 发布的 tarball 的最新版本。

本发行版本中存在一个已知问题，在以 kubeadmin 身份登录集群时无法创建 Web 终端。终端会返回信息：Error Loading OpenShift command line terminal: User is not a owner of the requested workspace.这个问题将在以后的 OpenShift Container Platform 发行版本中解决。(WTO-262)

目前，在 Tuned 资源的 profile 字段中使用斜杠（如绑定设备）定义 sysctl 值可能无法正常工作。sysctl 选项名称中的斜杠值没有正确映射到 /proc 文件系统。作为临时解决方案，创建一个 MachineConfig 资源，该资源使用 /etc/sysctl.d 节点目录中的所需值放置配置文件。(RHEL-3707)
由于 Kubernetes 存在问题，CPU Manager 无法从最后一个 pod 返回到可用 CPU 资源池的最后一个 pod 资源。如果后续 pod 被接受到该节点，则这些资源可分配。但是，这会变为最后一个 pod，然后 CPU 管理器无法将此 pod 的资源返回到可用的池。
此问题会影响 CPU 负载均衡功能，因为这些功能取决于 CPU Manager 将 CPU 释放到可用池。因此，非保证的 pod 可能会以较少的 CPU 运行。作为临时解决方案，请在受影响节点上调度具有 best-effort CPU Manager 策略的 pod。此 pod 将是最后一个接受的 pod，这样可确保资源正确分发到可用池。(OCPBUGS-17792)
当节点重启时，所有 pod 都会以随机顺序重启。在这种情况下，tuned pod 可能会在工作负载 pod 后启动。这意味着工作负载 pod 从部分调优开始，这可能会影响性能，甚至会导致工作负载失败。(OCPBUGS-26400)
当额外清单文件夹中存在性能配置集，并以主或 worker 池为目标时，OpenShift Container Platform 安装可能会失败。这是因为内部安装排序导致在创建默认主和 worker MachineConfigPool 前处理性能配置集。您可以通过在额外 manifests 文件夹中包含库存主或 worker MachineConfigPool 的副本来解决这个问题。(OCPBUGS-27948) (OCPBUGS-18640)
在 OpenShift Container Platform 托管的 control plane 中，HyperShift Operator 仅在 Operator 初始化过程中提取发行版本元数据一次。当您在管理集群中进行更改或创建托管集群时，HyperShift Operator 不会刷新发行版本元数据。作为临时解决方案，请通过删除 pod 部署来重启 HyperShift Operator。(OCPBUGS-29110)
在 OpenShift Container Platform 托管的 control plane 中，当您在断开连接的环境中为 ImageDigestMirrorSet 和 ImageContentSourcePolicy 对象创建自定义资源定义 (CRD) 时，Hy HyperShift Operator 只为 ImageDigestMirrorSet CRD 创建对象，忽略 ImageContentSourcePolicy CRD。作为临时解决方案，在 ImageDigestMirrorSet CRD 中复制 ImageContentSourcePolicies 对象配置。(OCPBUGS-29466)
在 OpenShift Container Platform 托管 control plane 中，当在断开连接的环境中创建托管集群时，如果您没有明确在 HostedCluster 资源中设置 hypershift.openshift.io/control-plane-operator-image 注解，则托管集群部署会失败，并显示错误。(OCPBUGS-29494)

1.8. 已知问题

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links