支持控制台（Console）开发人员开始试用联系人

1.8. 已知问题

  • libreswan 中存在一个回归问题，会导致某些启用了 IPsec 的节点丢失与同一集群中其他节点上的 pod 的通信。要解决这个问题，请考虑为集群禁用 IPsec。(OCPBUGS-42952)

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

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

    警告

    如果您的应用程序依赖未经身份验证的访问，在撤销了未经身份验证的访问后可能会收到 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)

  • 如果安装程序无法获取与 Google Cloud Platform (GCP)服务帐户关联的所有项目，安装会失败，并显示 context deadline exceeded 错误消息。

    当满足以下条件时会出现这种情况：

    • 服务帐户可以访问过多的项目。

    • 安装程序使用以下命令之一运行：

      • openshift-install create install-config

        错误消息

        FATAL failed to fetch Install Config: failed to fetch dependency of "Install Config": failed to fetch dependency of "Base Domain": failed to generate asset "Platform": failed to get projects: context deadline exceeded

      • openshift-install create cluster 没有现有安装配置文件 (install-config.yaml)

        错误消息

        FATAL failed to fetch Metadata: failed to fetch dependency of "Metadata": failed to fetch dependency of "Cluster ID": failed to fetch dependency of "Install Config": failed to fetch dependency of "Base Domain": failed to generate asset "Platform": failed to get projects: context deadline exceeded

      • 带有现有安装配置文件创建清单的 openshift-install

        错误消息

        ERROR failed to fetch Master Machines: failed to load asset "Install Config": failed to create install config: platform.gcp.project: Internal error: context deadline exceeded

        作为临时解决方案，如果您有一个安装配置文件，使用特定的项目 ID 更新该文件，使其使用 platform.gcp.projectID。否则，手动创建安装配置文件，并输入特定的项目 ID。再次运行安装程序，指定该文件。(OCPBUGS-15238)

  • 在大型计算节点上引导失败。(OCPBUGS-20075)
  • 当您在 IBM Power® 上部署带有 Network Type 为 OVNKubernetes 的集群时，计算节点可能会因为内核堆栈溢出而重启。作为临时解决方案，您可以使用 Network Type 为 OpenShiftSDN 部署集群。(RHEL-3901)

  • 以下已知问题适用于使用版本 candidate 3 或 4 将 OpenShift Container Platform 部署更新至版本 4.14 的用户：

    在引入节点识别功能后，一些以 root 身份运行的 pod 会被更新为运行非特权。对于升级到 OpenShift Container Platform 4.14 的早期访问版本的用户，试图升级到官方版本的 4.14 可能无法进行。在这种情况下，Network Operator 报告以下状态，表示更新的问题：DaemonSet "/openshift-network-node-identity/network-node-identity" update is rolling。

    作为临时解决方案，您可以通过运行以下命令来删除 openshift-network-node-identify 命名空间中的所有 pod：oc delete --force=true -n openshift-network-node-identity --all pods。运行此命令后，更新将继续。

    有关早期访问的更多信息，candidate-4.14 频道。

  • 目前，用户无法通过更新 openshift-multus 命名空间中的 cni-sysctl-allowlist 配置映射来修改特定于接口的安全 sysctl 列表。作为临时解决方案，您可以手动修改或使用 DaemonSet，也可以修改节点或节点上的 /etc/cni/tuning/allowlist.conf 文件。(OCPBUGS-11046)

  • 在 OpenShift Container Platform 4.14 中，所有节点都使用 Linux 控制组版本 2 (cgroup v2) 进行内部资源管理，以便与默认的 RHEL 9 配置保持一致。但是，如果您在集群中应用性能配置集，与性能配置集关联的低延迟调整功能不支持 cgroup v2。

    因此，如果您应用一个性能配置集，集群的所有节点都会重启，并切回到 cgroup v1 配置。此重启包括 control plane 节点和不是由性能配置集为目标的 worker 节点。

    要将集群中的所有节点恢复到 cgroups v2 配置，您必须编辑 Node 资源。如需更多信息，请参阅配置 Linux cgroup v2。您无法通过删除最后一个性能配置集将集群恢复到 cgroups v2 配置。(OCPBUGS-16976)

  • AWS M4 和 C4 实例可能无法在使用 OpenShift Container Platform 4.14 安装的集群中正确引导。没有当前的临时解决方案。(OCPBUGS-17154)
  • 本发行版本中存在一个已知问题，可防止使用安装程序置备的基础架构在 Alibaba Cloud 上安装集群。在 Alibaba Cloud 上安装集群是本发行版本中的技术预览功能。(OCPBUGS-20552)
  • 对于具有根卷可用区且在升级到 4.14 的 RHOSP 上运行的集群，您必须将 control plane 机器聚合到一个服务器组中，然后才能启用 control plane 机器集。要进行必要的更改，请按照知识库文章中的说明操作。(OCPBUGS-13300)
  • 对于配置有至少一个区且在 RHOSP 上运行的计算区的集群，它只适用于版本 4.14，根卷现在还必须配置至少一个区。如果没有更改此配置更改，则无法为集群生成 control plane 机器集。要进行必要的更改，请按照知识库文章中的说明操作。(OCPBUGS-15997)
  • 目前，当删除使用 SR-IOV 网络设备的 pod 时，可能会出现错误。这个错误是由 RHEL 9 中的更改造成的，其中之前网络接口的名称会在重命名时添加到其替代名称列表中。因此，当删除附加到 SR-IOV 虚拟功能 (VF) 的 pod 时，VF 会返回具有新的意外名称的池，如 dev69，而不是其原始名称，如 ensf0v2。虽然这个错误不严重，但 Multus 和 SR-IOV 日志可能会在系统自行恢复时显示错误。由于这个错误，删除 pod 可能需要几秒钟时间。(OCPBUGS-11281, OCPBUGS-18822, RHEL-5988)
  • 从 RHEL 5.14.0-284.28.1.el9_2 开始，如果您使用特定的 MAC 地址配置 SR-IOV 虚拟功能，则 i40e 驱动程序中可能会出现配置错误。因此，Intel 7xx 系列 NIC 可能会有连接问题。作为临时解决方案，请避免在 Pod 资源的 metadata.annotations 字段中指定 MAC 地址。反之，使用驱动程序分配给虚拟功能的默认地址。(RHEL-7168, OCPBUGS-19536, OCPBUGS-19407, OCPBUGS-18873)
  • 目前，在 Tuned 资源的 profile 字段中使用斜杠（如绑定设备）定义 sysctl 值可能无法正常工作。sysctl 选项名称中的斜杠值没有正确映射到 /proc 文件系统。作为临时解决方案，创建一个 MachineConfig 资源，该资源使用 /etc/sysctl.d 节点目录中的所需值放置配置文件。(RHEL-3707)

  • 目前，由于 Kubernetes 存在问题，CPU Manager 无法将来自最后一个 pod 的 CPU 资源从接受到节点返回到可用 CPU 资源池。如果后续 pod 被接受到节点，则可以分配这些资源。但是，这会变为最后一个 pod，再次显示 CPU 管理器无法将此 pod 的资源返回到可用的池。

    此问题会影响 CPU 负载均衡功能，因为这些功能取决于 CPU Manager 将 CPU 释放到可用池。因此，非保证的 pod 可能会以较少的 CPU 运行。作为临时解决方案，请在受影响节点上调度具有 best-effort CPU Manager 策略的 pod。此 pod 将是最后允许的一个 pod，确保资源已正确释放到可用池。(OCPBUGS-17792)

  • 目前，Machine Config Operator (MCO) 可能会为自定义池应用不正确的 cgroup 版本参数，因为 MCO 如何处理 worker 池和自定义池的机器配置。因此，自定义池中的节点可能具有不正确的 cgroup 内核参数，从而导致行为无法预计。作为临时解决方案，请只为 worker 和 control plane 池指定 cgroup 版本内核参数。(OCPBUGS-19352)
  • 目前，由于物理网络设备上的 udev 规则应用程序和默认请求的每秒应用程序(RPS)掩码到所有网络设备之间有一个竞争条件，一些物理网络设备可能具有错误的 RPS 掩码配置。因此，性能下降可能会影响带有错误 RPS 掩码配置的物理网络设备。预计即将推出的 z-stream 版本会包括此问题的一个修复。(OCPBUGS-21845)
  • 在传统的单根 I/O 虚拟化 (SR-IOV) 中的 Broadcom 网络接口控制器不支持 SRIOV VLAN 的服务质量 (QoS) 和标签协议标识符 (TPID) 设置。这会影响 Broadcom BCM57414、Broadcom BCM57508 和 Broadcom BCM57504。(RHEL-9881)

  • 当您在使用双栈网络的环境中创建托管集群时，您可能会遇到以下与 DNS 相关的问题：

    • service-ca-operator pod 中的 CrashLoopBackOff 状态：当 pod 试图通过托管的 control plane 访问 Kubernetes API 服务器时，pod 无法访问服务器，因为 kube-system 命名空间中的 data plane 代理无法解析请求。出现这个问题的原因是，前端使用 IP 地址，后端使用 pod 无法解析的 DNS 名称。
    • Pod 处于 ContainerCreating 状态 ：出现这个问题，因为 openshift-service-ca-operator 无法生成 DNS pod 需要 DNS 解析的 metrics-tls secret。因此，pod 无法解析 Kubernetes API 服务器。

    要解决这个问题，请按照 为双堆栈网络配置 DNS 中的指南来配置 DNS 服务器设置。(OCPBUGS-22753, OCPBUGS-23234)

  • 在 OpenShift Container Platform 托管的 control plane 中，没有测试以下 Operator 和组件(OCPSTRAT-605)：

    • Performance Addon Operator
    • OpenShift 沙盒容器
    • Red Hat OpenShift GitOps
    • Red Hat OpenShift Service Mesh
    • Red Hat OpenShift Pipelines
    • Red Hat OpenShift Dev Spaces
    • 红帽单点登录技术
    • OpenShift Container Platform Web 控制台中的 Web 终端
    • 应用程序的迁移工具包
  • 在 OpenShift Container Platform 托管的 control plane 中，在托管集群中安装 File Integrity Operator 会失败。(OCPBUGS-3410)
  • 在 OpenShift Container Platform 托管的 control plane 中，Vertical Pod Autoscaler Operator 无法在一个托管的集群中安装。(PODAUTO-65)
  • 在托管 OpenShift Container Platform 的 control plane 中，在裸机和 OpenShift Virtualization 平台上，自动修复功能被禁用。(OCPBUGS-20028)
  • 在 OpenShift Container Platform 托管 control plane 中，不支持使用带有 AWS Secrets Manager 或 AWS Systems Manager Parameter Store 的 Secrets Store CSI Driver Operator。(OCPBUGS-18711)
  • 在 OpenShift Container Platform 托管的 control plane 中，default, kube-system, 和 kube-public 命名空间没有正确排除在 pod 安全准入中。(OCPBUGS-22379)
  • 在 OpenShift Virtualization 上的托管 control plane 中，worker 节点重启后可能会丢失网络连接。(OCPBUGS-23208)
  • 在 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)

  • 由于删除节点污点失败，在 vSphere 上安装基于代理的会失败，这会导致安装处于待处理状态。单节点 OpenShift 集群不会受到影响。您可以运行以下命令来手动删除节点污点，从而解决这个问题： 

    $ oc adm taint nodes <node_name> node.cloudprovider.kubernetes.io/uninitialized:NoSchedule-

    (OCPBUGS-20049)

  • 使用 Azure 机密虚拟机存在一个已知问题，本发行版本中是一个技术预览功能。不支持将集群配置为加密受管磁盘以及 Azure VM Guest State (VMGS) blob，并带有平台管理的密钥(PMK)或客户管理的密钥(CMK)。要避免这个问题，请通过将 securityEncryptionType 参数的值设置为 VMGuestStateOnly 来启用 VMGS blob 的加密。(OCPBUGS-18379)

  • 使用 Azure 机密虚拟机存在一个已知问题，本发行版本中是一个技术预览功能。安装配置为使用这个功能的集群会失败，因为 control plane 置备过程会在 30 分钟后超时。

    如果出现这种情况，您可以第二次运行 openshift-install create cluster 命令来完成安装。

    要避免这个问题，您可以使用机器集在现有集群上启用机密虚拟机。(OCPBUGS-18488)

  • 当您在裸机平台上为 OpenShift Container Platform 运行托管的 control plane 时，如果 worker 节点失败，另一个节点也不会自动添加到托管集群中，即使其他代理可用。作为临时解决方案，请手动删除与故障 worker 节点关联的机器。(MGMT-15939)
  • 由于源目录捆绑包了一个特定于架构的 opm 二进制文件，因此您必须从该架构运行镜像。例如，如果要镜像 ppc64le 目录，则必须从 ppc64le 架构上运行的系统运行 oc-mirror。(OCPBUGS-22264)
  • 如果多个 OpenShift Container Platform 组指向同一 LDAP 组，则只同步一个 OpenShift Container Platform 组。当多个组指向同一 LDAP 组时，oc adm groups sync 命令会显示一个警告，表示只有一个组有资格映射。(OCPBUGS-11123)
  • 当在禁用安全引导的节点中安装 bootMode 设置为 UEFISecureBoot 的 OpenShift Container Platform 时，安装会失败。后续尝试安装启用了安全引导机制的 OpenShift Container Platform 通常会进行。(OCPBUGS-19884)
  • 在 OpenShift Container Platform 4.14 中，带有 Ignition 版本 3.4 的 MachineConfig 对象可能无法扫描带有 CrashLoopBackOff 错误的 api-collector pod，从而导致 Compliance Operator 无法按预期工作。(OCPBUGS-18025)
  • 在 OpenShift Container Platform 4.14 中，不支持将 IPv6 出口 IP 分配给不是主网络接口的网络接口。这是一个已知问题，并将在以后的 OpenShift Container Platform 版本中解决。(OCPBUGS-17637)
  • 当您在 OpenShift Container Platform 集群上运行 CNF 延迟测试时，oslat 测试有时会返回大于 20 微秒的结果。这会导致 oslat 测试失败。(RHEL-9279)
  • 当您将 preempt-rt 补丁与实时内核一起使用，并更新网络中断的 SMP 关联性时，对应的 IRQ 线程不会立即接收更新。相反，更新会在收到下一个中断时生效，然后线程会迁移到正确的内核。(RHEL-9148)
  • 依赖于高分辨率计时器的低延迟应用程序来唤醒线程可能会遇到比预期更高的延迟。虽然预期的唤醒延迟时间为 20us，但运行 cyclictest 工具的 cyclictest 工具时可能会看到超过这个值的延迟 (24 小时或更长)。测试表明，对于抽样的 99.999999%，唤醒延迟都低于 20us。(RHELPLAN-138733)

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

  • 在来自 GNSS 的 PTP grandmaster 时钟中，当 GNSS 信号丢失时，数字阶段锁定循环(DPLL)时钟状态可能会以 2 种方式改变：它可以过渡到解锁，或者可以进入 holdover 状态。目前，驱动程序默认将 DPLL 状态转换为解锁。上游更改目前正在开发来处理冻结状态功能，并配置使用哪些状态机器处理。(RHELPLAN-164754)
  • DPLL 子系统和 DPLL 支持目前没有在 Intel Westport Channel e810 NIC ice 驱动程序中启用。(RHELPLAN-165955)
  • 当前 grandmaster 时钟(T-GM)实现具有来自 GNSS 的单一 NMEA 句子生成器，而无需备份 NMEA 生成器。如果在到 e810 NIC 的过程中 NMEA 句子丢失，则 T-GM 无法同步网络同步链中的设备，而 PTP Operator 会报告错误。当 NMEA 字符串丢失时，可以报告 FREERUN 事件。(OCPBUGS-19838)
  • 目前，由于设置容器的 cgroup 层次结构的不同，使用 crun OCI 运行时的容器以及 PerformanceProfile 配置会遇到性能下降。作为临时解决方案，请使用 runc OCI 容器运行时。虽然 runc 容器运行时在容器启动、关闭操作和 exec 探测过程中的性能较低，但 crun 和 runc 容器运行时的功能相同。预计即将推出的 z-stream 版本会包括此问题的一个修复。(OCPBUGS-20492)
  • 在运行时启用和禁用 IPsec 后存在一个已知问题，导致集群处于不健康状态，并显示错误消息：an unknown error has occurred: MultipleErrors。(OCPBUGS-19408)

  • 使用调度到 control plane 节点的 Microsoft Azure File NFS 卷创建 pod 会导致挂载被拒绝。

    要临时解决这个问题：如果您的 control plane 节点可以调度，pod 可以在 worker 节点上运行，使用 nodeSelector 或 Affinity 将 pod 调度到 worker 节点上。(OCPBUGS-18581)

  • 对于在 RHOSP 17.1 上运行并使用网络功能虚拟化 (NFV) 的集群，RHOSP 中的已知问题会阻止成功部署。这个问题还没有临时解决方案。联系红帽支持以请求热修补代码。(BZ2228643)
  • 不支持 RHOSP 17.1 上的 Kuryr 安装。

  • 目前，在 OpenShift Container Platform 4.14 中升级到 HAProxy 版本 2.6.13 会导致对重新加密流量的 P99 延迟增加。当入口流量的卷将 IngressController 自定义资源 (CR) 的 HAProxy 组件置于可考虑的负载下时，会观察到这个行为。延迟增加并不会影响整体吞吐量，它仍然是一致的。

    默认 IngressController CR 配置有 4 个 HAProxy 线程。如果您在高入口流量条件中遇到了 P99 延迟，特别是使用重新加密流量，建议增加 HAProxy 线程的数量来缩短延迟。(OCPBUGS-18936)

  • 对于 4.14 和 Google Cloud Platform (GCP) 上的单节点 OpenShift，Cloud Network Config Controller (CNCC) 进入 CrashLoopBackOff 状态存在一个已知问题。当 CNCC 试图访问 GCP 内部负载均衡器地址时，生成的 hairpin 流量不会在 GCP 上的 OVN-Kubernetes 共享网关模式中正确阻止，从而导致它被丢弃。在这种情况下，Cluster Network Operator 会显示 Progressing=true 状态。目前，这个问题还没有临时解决方案。(OCPBUGS-20554)
  • 在有保证 CPU 且禁用中断请求(IRQ)负载平衡的单节点 OpenShift 上，容器启动时可能会出现大量延迟激增。(OCPBUGS-22901)
  • 在部署具有大量 pod 的应用程序时，一些配置了 CPU 限制，部署可能会失败。解决办法是重新部署应用程序。(RHEL-7232)

  • 在禁用功能的单节点 OpenShift 中，openshift-controller-manager-operator 可能会持续重启。作为临时解决方案，请启用构建功能，或者手动创建 builds.config.openshift.io CRD。

    执行以下步骤手动创建 builds.config.openshift.io CRD：

    1. 运行以下命令来提取发行清单： 

      $ oc adm release extract --to manifests

    2. 在 manifests 目录和子目录中搜索 builds.config.openshift.io ： 

      $ grep -r builds.config.openshift.io manifests

      预期输出

      manifests/0000_10_openshift-controller-manager-operator_01_build.crd.yaml:  name: builds.config.openshift.io

    3. 应用 0000_10_openshift-controller-manager-operator_01_build.crd.yaml 中指定的配置： 

      $ oc apply -f manifests/0000_10_openshift-controller-manager-operator_01_build.crd.yaml

    (OCPBUGS-21778)

  • 存在一个已知问题：防止在 Microsoft Azure Stack Hub 上将集群安装到此版本的 OpenShift Container Platform。如需了解更多详细信息和临时解决方案，请参阅红帽知识库文章。(OCPBUGS-20548)

  • Microsoft Azure 集群在版本 4.14.2 之前在 OpenShift Container Platform 4.14 版本中使用 Azure AD Workload Identity 存在一个已知问题。最近更改 eastus 区域中新 Azure 存储帐户的默认安全设置会阻止安装在该区域中使用 Azure AD Workload Identity 的集群。目前，其他区域不会受到影响，但将来可能会受到影响。

    这个问题已在 OpenShift Container Platform 4.14.2 中解决。

    要临时解决这个问题，请在 配置 Azure 集群以使用简短凭证的 步骤中手动创建允许在运行 ccoctl azure create-all 前允许公共访问权限的存储帐户。

    执行以下步骤：

    1. 运行以下 Azure CLI 命令，为存储帐户创建资源组： 

      $ az group create --name <oidc_resource_group_name> --location <azure_region>

    2. 运行以下 Azure CLI 命令，创建一个允许公共访问的存储帐户： 

      $ az storage account create --name <storage_account_name> --resource-group <oidc_resource_group_name> --location <azure_region> --sku Standard_LRS --kind StorageV2 --allow-blob-public-access true

    3. 当使用 ccoctl 工具通过运行以下命令来处理所有 CredentialsRequest 对象时，您必须指定上一步中创建的资源。 

      $ ccoctl azure create-all \
  --name=<azure_infra_name> \
  --output-dir=<ccoctl_output_dir> \
  --region=<azure_region> \
  --subscription-id=<azure_subscription_id> \
  --credentials-requests-dir=<path_to_credentials_requests_directory> \
  --dnszone-resource-group-name=<azure_dns_zone_resource_group_name> \
  --tenant-id=<azure_tenant_id> \
  --storage-account-name=<storage_account_name> \
  --oidc-resource-group-name=<oidc_resource_group-name>

    (OCPBUGS-22651)

  • 当使用静态 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-17895)

  • 此发行版本中存在一个已知问题，会阻止在 Web Terminal Operator 安装后访问它。这个问题将在以后的 OpenShift Container Platform 发行版本中解决。(OCPBUGS-14463)
  • 将 Cluster Network Operator 从版本 4.13 升级到 4.14 时存在一个已知问题。转换为新的 OVN Kubernetes 互连多区架构可能会导致数据包丢弃，从而导致网络中断。其影响是本地网关模式中的 East/West 流量，并将 routingViaHost 设置为 true。(OCPBUGS-38891)
  • OpenShift Container Platform 4.14 中的 HAProxy 存在一个已知问题，涉及发送无效的 Transfer-Encoding 标头的应用程序。这个问题会导致在 pod 公开发送这些无效标头的路由时丢失对 pod 的外部访问。如需了解更多详细信息，请参阅红帽知识库文章。(OCPBUGS-43095)
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.