1.8. 已知问题

对于将--cloud -provider=external 选项设置为 cloud-provider-vsphere 的云控制器管理器(CCM)，在具有多个子网的联网环境中存在一个已知问题。
当您将集群从 OpenShift Container Platform 4.12 升级到 OpenShift Container Platform 4.13 时，CCM 会选择一个错误的节点 IP 地址，此操作会在 namespaces/openshift-cloud-controller-manager/pods/vsphere-cloud-controller-manager 日志中生成错误消息。错误消息表示节点 IP 地址和集群中的 vsphere-cloud-controller-manager pod IP 地址不匹配。
已知问题可能会影响集群升级操作，但您可以在 nodeNetworking.external.networkSubnetCidr 和 nodeNetworking.internal.networkSubnetCidr 中为集群用于其网络要求的 nodeNetworking 对象设置正确的 IP 地址。

在 OpenShift Container Platform 4.1 中，匿名用户可以访问发现端点。之后的版本会取消对这端点的访问，以减少可能的安全漏洞攻击面。一些发现端点被转发到聚合的 API 服务器。但是，升级的集群中会保留未经身份验证的访问，因此现有用例不会中断。
如果您是一个从 OpenShift Container Platform 4.1 升级到 4.13 的集群的集群管理员，您可以撤销或继续允许未经身份验证的访问。除非对未经身份验证的访问有特殊需要，否则您应该撤销它。如果您继续允许未经身份验证的访问，请注意相关的风险。
警告
如果您的应用程序依赖未经身份验证的访问，在撤销了未经身份验证的访问后可能会收到 HTTP 403 错误。
使用以下脚本撤销对发现端点的未经身份验证的访问：
```
## 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
```
此脚本从以下集群角色绑定中删除未经身份验证的对象：
- cluster-status-binding
- discovery
- system:basic-user
- system:discovery
- system:openshift:discovery
(BZ#1821771)

oc annotate 命令不适用于包含了等号（=）的 LDAP 组名称，因为命令使用等号作为注释名称和值之间的分隔符。作为临时解决方案，使用 oc patch 或 oc edit 添加注解。(BZ#1917280)
添加 Git 存储库并使用 GitLab 和 Bitbucket pipeline-as-code 存储库进行配置，会创建一个无效的存储库资源。因此，对于 GitLab 和 Bitbucket 提供程序，删除了 spec.git_provider.url Git 供应商 URL。
临时解决方案：为 Bitbucket 添加必需的 spec.git_provider.user 字段。另外，选择 Git 访问令牌或 Git 访问令牌 secret 来继续添加 Git 存储库。(OCPBUGS-7036)
目前，当您在 macOS 上运行安装程序以便在 VMware vSphere 上安装 OpenShift Container Platform 集群时，存在一个证书合规问题，特别是 x509: certificate is not standards compliant。这个问题与 golang 编译器的已知问题相关，其中编译器无法识别新支持的 macOS 证书标准。这个问题不存在临时解决方案。(OSDOCS-5694)
当您在 ControlPlaneMachineSet 定义中包含超过三个故障域时，负载均衡算法不会优先选择现有的 control plane 机器。如果您添加一个第四个故障域，其优先级高于定义的现有三个故障域，则第四个故障域优先于任何现有故障域。此行为可将滚动更新应用到 control plane 机器。您可以通过将现有的 in-use 故障域设置为高于新的和未使用的故障域来防止这个问题。此操作在向定义中添加多个故障域时，设置每个 control plane 机器。(OCPBUGS-11968)
在单节点 OpenShift 实例上，重新引导而不排空节点以删除所有正在运行的 pod 可能会导致工作负载容器恢复出现问题。重启后，工作负载会在所有设备插件就绪前重启，从而导致资源不可用或在错误的 NUMA 节点上运行的工作负载。当所有设备插件在重启恢复过程中重新注册时，可以重启工作负载 pod。(OCPBUGS-2180)
删除使用 SR-IOV netdevice 的 pod 时可能会出现错误。这个错误是由 RHEL 9 中的更改造成的，其中之前网络接口的名称会在重命名时添加到其替代名称列表中。因此，当删除附加到 SR-IOV 虚拟功能 (VF) 的 pod 时，VF 会返回到具有新意外名称的池，如 dev69，而不是其原始名称，如 ensf0v2。虽然这个错误不是致命的，但 Multus 和 SR-IOV 日志可能会在系统自行恢复时显示错误。由于这个错误，删除 pod 可能需要几秒钟。(OCPBUGS-11281)
在守护进程集的 YAML 定义中有一个不正确的优先级类名称和语法错误，负责更新特定于接口的安全 sysctl 可防止使用 openshift-multus 命名空间中的 cni-sysctl-allowlist 配置映射为接口修改安全 sysctl 列表。
临时解决方案：手动或使用守护进程集，修改节点上的文件 /etc/cni/tuning/allowlist.conf 来解决这个问题。(OCPBUGS-11046)
OpenShift Container Platform 4.12 中引入的一项新功能，它允许 UDP GRO 导致所有 veth 设备为每个可用 CPU 都有一个 RX 队列（以前每个 veth 都有一个队列）。这些队列由 Open Virtual Network 动态配置，延迟调整和此队列创建之间没有同步。延迟调优逻辑监控 veth NIC 创建事件，并在所有队列被正确创建前开始配置 RPS 队列 cpu 掩码。这意味着没有配置某些 RPS 队列掩码。因为不是所有 NIC 队列都正确配置，实时应用程序（使用对时间敏感的 cpu 与其它容器中的服务进行通信）可能会有延迟激增的问题。不使用内核网络堆栈的应用程序不会受到影响。(OCPBUGS-4194)
Cluster Network Operator (CNO) 控制器监控的资源超过需要的资源。因此，协调器会太频繁地触发，从而导致 API 请求的比率比实际需要的要高。大约有 1 个配置映射访问请求每秒发出。这会增加 CNO 和 kube-apiserver 的负载。(OCPBUGS-11565)
对于 OpenShift Container Platform 4.13，Driver Toolkit (DTK) 容器镜像需要 ubi9 镜像作为构建驱动程序容器的软件堆栈的第二层。如果您尝试使用 ubi8 镜像作为软件堆栈中的第二层，您将收到构建错误。(OCPBUGS-11120)
在使用 CSI 驱动程序时 vSphere 平台上的一些 OpenShift Container Platform 安装中，vSphere CSI 驱动程序可能无法正确出现，因为在启动过程中它无法从 vCenter 检索节点的信息，因此 CSI 驱动程序不会重试。
临时解决方案：通过使用 SSH 连接到作为 vsphere-syncer 进程的当前领导节点，并重启 vsphere-syncer 容器（使用 crictl），可以缓解这个问题，驱动程序可以成功启动。(OCPBUGS-13385)
对于 OpenShift Container Platform 4.13，在带有 baremetal worker 的 Red Hat OpenStack Platform (RHOSP) 16.2 上安装 4.13 版本会失败，因为 baremetal worker 无法从 OpenShift 4.13 附带的 Red Hat Enterprise Linux CoreOS (RHCOS)镜像引导。基本问题是 RHCOS 镜像缺少字节顺序标记。计划对下一个 16.2 构建进行这些修复。(OCPBUGS-13395)
由于 RHEL 9.2 中存在一个已知问题，所以无法在带有机密虚拟机的 GCP 集群中使用持久性卷。(OCPBUGS-7582)
在升级到 OpenShift Container Platform 4.13 时，在带有 openvswitch2.15 的 OpenShift Container Platform 4.12 集群中运行的 Red Hat Enterprise Linux (RHEL) worker 会失败。upgrade.yml playbook 失败，并显示以下错误消息 package openvswitch2.17-2.17.0-88.el8fdp.x86_64 conflicts with openvswitch2.15 provided by openvswitch2.15-2.15.0-136.el8fdp.x86_64。
要临时解决这个问题，在升级到 OpenShift Container Platform 4.13 之前，手动删除 openvswitch2.15 软件包并安装 openvswitch2.17 软件包。然后，运行 upgrade.yml playbook 以更新 RHEL worker 并完成更新过程。(OCPBUGS-11677)
将将存储附加到工作负载时，会出现磁盘延迟问题。(OCPBUGS-11149)
当从 OpenShift Container Platform 4.12 更新至 4.13 时，Mella NIC 将 SR-IOV 网络节点策略（如 ens7f0） 重命名为 ens7f0np0。这个名称更改是因为对 RHEL 9 内核的更新。因此，无法创建虚拟功能 (VF)，因为无法找到接口。您的 SR-IOV 网络节点策略必须考虑这个重命名。例如，如果您的策略中引用了 ens7f0，请在更新前将 ens7f0np0 添加到您的策略中。
要临时解决这个问题，您必须手动编辑 SriovNetworkNodePolicy 自定义资源 (CR) 以添加 ens7f0np0，然后才能升级到 OpenShift Container Platform 4.13。(OCPBUGS-13186) 以下代码提供了一个策略更新示例，其中两个名称都添加到 SriovNetworkNodePolicy 中，以确保兼容性：
```
  # ...
  deviceType: netdevice
  nicSelector:
    deviceID: “101d”
    pfNames:
      - ens7f0
      - ens7f0np0
    vendor: ‘15b3’
  nodeSelector:
    feature.node.kubernetes.io/sriov-capable: ‘true’
  numVfs: 4
 # ...
```
对于 Intel E810 NIC，在 pod 删除时重置 SR-IOV 虚拟功能 (VF) 上的 MAC 地址可能会失败。因此，在 Intel E810 NIC 卡上使用 SR-IOV VF 创建 pod 可能需要 2 分钟。(OCPBUGS-5892)

如果您在用于执行集群升级的订阅策略中指定无效的订阅频道，则 Topology Aware Lifecycle Manager (TALM) 表示在 TALM 强制策略后升级会立即成功，因为 Subscription 资源保持在 AtLatestKnown 状态。(OCPBUGS-9239)
系统崩溃后，kdump 无法在 HPE Edgeline e920t 和 HPE DL110 Gen10 服务器上生成 vmcore 崩溃转储文件，安装有 Intel E810 NIC 和 ice 驱动程序。(RHELPLAN-138236)
在 GitOps ZTP 中，当使用 SiteConfig CR 置备包含多个节点的受管集群时，当一个或多个节点在 SiteConfig CR 中配置了一个 diskPartition 资源时，磁盘分区会失败。(OCPBUGS-9272)
在配置了 PTP 边界时钟 (T-BC) 和部署的 DU 应用程序的集群中，消息不会从 vDU 主机上的 T-BC 的后续接口发送，最多 40 秒。日志中的错误率可能会有所不同。错误日志示例如下：
输出示例
```
2023-01-15T19:26:33.017221334+00:00 stdout F phc2sys[359186.957]: [ptp4l.0.config] nothing to synchronize
```
(RHELPLAN-145492)
当使用 GitOps ZTP 安装单节点 OpenShift 集群时，并使用 HTTP 传输配置 PTP 和裸机事件，linuxptp-daemon 守护进程 pod 会间歇性部署。所需的 PersistentVolumeClaim (PVC) 资源已创建，但不会挂载到 pod 中。报告以下卷挂载错误：
输出示例
```
mount: /var/lib/kubelet/plugins/kubernetes.io/local-volume/mounts/local-pv-bc42d358: mount(2) system call failed: Structure needs cleaning.
```
要解决这个问题，删除 cloud-event-proxy-store-storage-class-http-events PVC CR 并重新部署 PTP Operator。(OCPBUGS-12358)

在 GitOps Zero Touch Provisioning (ZTP) 置备一个在 SiteConfig CR 中启用了安全引导的单节点 OpenShift 受管集群的置备过程中，在托管置备时会为 BareMetalHost CR 报告多个 ProvisioningError 错误。这个错误代表，安全引导设置在 Baseboard Management Controller (BMC) 中被成功应用，但主机在应用了 BareMetalHost CR 后无法开机。要解决这个问题，请执行以下步骤：
1. 重启主机。这可确保 GitOps ZTP 管道应用了安全引导设置。
2. 使用相同配置重启集群的 GitOps ZTP 置备。
(OCPBUGS-8434)
安装双栈 GitOps ZTP hub 集群后，启用双栈虚拟 IP 地址(VIP)，并在 Provisioning CR 中启用 virtualMediaViaExternalNetwork 标志，IRONIC_EXTERNAL_URL_V6 环境变量会被错误地被分配一个 IPv4 地址。(OCPBUGS-4248)
ZT 服务器将 BiosRegistry 语言设置为 en-US 而不是 en。这会导致受管集群主机的 GitOps ZTP 置备过程中出现问题。为 ZT 服务器生成的 FirmwareSchema CR 没有包括 allowable_values,attribute_type, 和 read_only 字段。(OCPBUGS-4388)
在 OpenShift Container Platform 版本 4.13.0 中，当您尝试使用基于 Agent 的安装程序安装集群时会出现一个错误。在读取磁盘阶段后，会返回一个错误，集群安装的过程会卡住。HPEconfirm Gen10 服务器上已检测到此错误。(OCPBUGS-13138)
RFC2544 性能测试显示数据包的 Max delay 值以遍历网络超过最小阈值。此回归可在运行 Telco RAN DU 配置集的 OpenShift Container Platform 4.13 集群中找到。(OCPBUGS-13224)
性能测试在安装了 OpenShift Container Platform 4.13 的单节点 OpenShift 集群上运行，显示 oslat 最大延迟结果大于 20 微秒。(RHELPLAN-155443)
性能测试在安装了 OpenShift Container Platform 4.13 的单节点 OpenShift 集群上运行，显示 cyclictest 最大延迟结果超过 20 微秒。(RHELPLAN-155460)
在为 DPDK 禁用 CPU 负载均衡功能中介绍的与低延迟微调相关联的 cpu-load-balancing.crio.io: "disable" 注解在没有配置负载分区的系统上无法正常工作。更具体地说，这会影响基础架构不会将 cpuPartitioningMode 设置为 AllNodes 值的集群，如 Workload partitioning 所述。
这会影响此类集群的可选项延迟，并可能会阻止正确操作低延迟工作负载。(OCPBUGS-13163)
如果 Nutanix 平台缺少了 Nutanix Cloud Control Manager (CCM) 所需的配置，则 Nutanix 平台上的 OpenShift Container Platform 4.12 集群可能会有 Upgradeable=False 条件。要解决这个问题，请参阅：在使用 Nutanix 作为平台时，如何创建升级到 OpenShift 4.13 所需的 ConfigMap 和 Secret。
目前，当使用包含大量文件的持久性卷 (PV) 时，pod 可能无法启动，或者可能需要很长时间才能启动。如需更多信息，请参阅此知识库文章。(BZ1987112)
使用调度到 control plane 节点的 Azure File NFS 卷创建 pod 会导致挂载被拒绝。(OCPBUGS-18581)
要临时解决这个问题：如果您的 control plane 节点可以调度，pod 可以在 worker 节点上运行，使用 nodeSelector 或 Affinity 将 pod 调度到 worker 节点上。
由于删除节点污点失败，在 vSphere 上安装基于代理的会失败，这会导致安装处于待处理状态。单节点 OpenShift 集群不会受到影响。您可以运行以下命令来手动删除节点污点，从而解决这个问题：
```
$ oc adm taint nodes <node_name> node.cloudprovider.kubernetes.io/uninitialized:NoSchedule-
```
(OCPBUGS-20049)
当使用静态 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)

1.8. 已知问题

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links