Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

3.8. 电信核心 RDS 组件

以下小节描述了用于配置和部署集群来运行电信核心工作负载的各种 OpenShift Container Platform 组件和配置。

3.8.1. CPU 分区和性能调整
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新。
描述
CPU 分区通过将敏感工作负载与通用任务、中断和驱动程序工作队列分离来提高性能并降低延迟。分配给这些辅助进程的 CPU 在以下部分中称为 reserved。在启用了超线程的系统中，CPU 是一个超线程。
限制和要求

  • 操作系统需要一定数量的 CPU 来执行所有支持任务，包括内核网络。

    • 仅具有 user plane 网络应用程序(DPDK)的系统至少需要为操作系统和基础架构组件保留一个核心(2 超线程)。
  • 在启用了 Hyper-Threading 的系统中，内核同级线程必须始终处于相同的 CPU 池中。
  • 保留和隔离的内核集合必须包含所有 CPU 内核。
  • 每个 NUMA 节点的核心 0 必须包含在保留的 CPU 集中。
  • 低延迟工作负载需要特殊配置，以避免受到平台中断、内核调度程序或其他部分影响。如需更多信息，请参阅"创建性能配置集"。
工程考虑
  • 从 OpenShift Container Platform 4.19 开始，cgroup v1 不再被支持并已被删除。现在，所有工作负载必须与 cgroup v2 兼容。如需更多信息，请参阅 Red Hat OpenShift 工作负载上下文中的 Red Hat Enterprise Linux 9 更改（红帽知识库）。
  • 根据红帽知识库 Which amount of CPU and memory are recommended to reserve for the system in OCP 4 nodes? 的指导，需要的最少保留的容量（systemReserved）。
  • 实际所需的保留 CPU 容量取决于集群配置和工作负载属性。
  • 保留的 CPU 值必须向上舍入到完整内核(2 超线程)。
  • 对 CPU 分区的更改会导致相关机器配置池中包含的节点排空并重启。
  • 保留的 CPU 减少了 pod 密度，因为保留的 CPU 已从 OpenShift Container Platform 节点的可分配容量中删除。

  • 应该为实时工作负载启用实时工作负载提示。

    • 应用实时工作负载 Hint 设置会导致应用 nohz_full 内核命令行参数来提高高性能应用程序的性能。当您应用 workloadHint 设置时，任何没有 cpu-quota.crio.io: "disable" 注解和正确的 runtimeClassName 值的隔离或 burstable pod 都会受到 CRI-O 速率限制。当您设置 workloadHint 参数时，请注意提高性能和 CRI-O 速率限制的潜在影响之间的权衡。确保正确注解所需的 pod。
  • 没有 IRQ 关联性支持的硬件会影响隔离的 CPU。所有服务器硬件都必须支持 IRQ 关联性，以确保具有保证 CPU QoS 的 pod 可以充分利用分配的 CPU。
  • OVS 动态管理其 cpuset 条目，以适应网络流量的需求。您不需要保留额外的 CPU 来处理主 CNI 上的高网络吞吐量。
  • 如果集群中运行的工作负载使用内核级别网络，则参与 NIC 的 RX/TX 队列数应设置为 16 或 32 个队列（如果硬件允许）。请注意默认队列计数。如果没有配置，每个在线 CPU 默认队列数是一个 RX/TX 队列，这可能会导致分配太多的中断。

  • irdma 内核模块可能会导致在具有高内核数的系统上分配太多中断向量。要防止这种情况，参考配置会阻止这个内核模块通过 PerformanceProfile 中的内核命令行参数加载。通常，核心工作负载不需要这个内核模块。

    注意

    有些驱动程序在减少队列计数后也不会取消分配中断。

3.8.2. 服务网格
复制链接

描述
电信核心云原生功能(CNF)通常需要一个服务网格实施。特定的服务网格功能和性能要求取决于应用程序。服务网格实施和配置选择超出了本文档的范围。您必须考虑服务网格对集群资源使用情况和性能的影响，包括在实现中 pod 网络中引入的额外延迟。

3.8.3. 网络
复制链接

下图显示了电信核心参考设计网络配置。

图 3.2. 电信核心参考设计网络配置

电信核心参考设计网络配置概述
这个版本中的新内容
  • 使用 pod 级别绑定扩展电信核心验证。
  • 支持 SR-IOV operator 的 resource injector 中移动失败的策略。
注意

如果您在 metallb-system 命名空间中有自定义 FRRConfiguration CR，您必须将它们移到 openshift-network-operator 命名空间中。

描述
  • 集群是为双栈 IP (IPv4 和 IPv6)配置的。
  • 验证的物理网络配置由两个双端口 NIC 组成。一个 NIC 在主 CNI (OVN-Kubernetes)和 IPVLAN 和 MACVLAN 流量间共享，而第二个 NIC 专用于基于 SR-IOV VF 的 pod 流量。
  • Linux 绑定接口(bond0)是在主动-主动 IEEE 802.3ad LACP 模式中创建的，并附加两个 NIC 端口。顶尖网络设备必须支持，并为多机链路聚合 (mLAG) 技术进行配置。
  • VLAN 接口在 bond0 上创建，包括用于主 CNI。
  • 在安装过程的网络配置阶段，会在集群安装过程中创建绑定和 VLAN 接口。除了主 CNI 使用的 vlan0 VLAN 外，其它所有 VLAN 可以在第 2 天活动期间使用 Kubernetes NMstate Operator 创建。
  • MACVLAN 和 IPVLAN 接口使用对应的 CNI 创建。它们不共享相同的基本接口。如需更多信息，请参阅"Cluster Network Operator"。
  • SR-IOV VF 由 SR-IOV Network Operator 管理。
  • 为确保 LoadBalancer Service 后面的 pod 一致源 IP 地址，请配置 EgressIP CR 并指定 podSelector 参数。

  • 您可以通过执行以下操作实现服务流量分离：

    1. 使用 NodeNetworkConfigurationPolicy CR 在节点上配置 VLAN 接口和特定内核 IP 路由。
    2. 为每个 VLAN 创建一个 MetalLB BGPPeer CR，以与远程 BGP 路由器建立对等。
    3. 定义 MetalLB BGPAdvertisement CR，以指定哪些 IP 地址池应公告为所选 BGPPeer 资源列表。下图演示了如何通过特定的 VLAN 接口向外公告特定的服务 IP 地址。服务路由在 BGPAdvertisement CR 中定义，并使用 IPAddressPool1 和 BGPPeer1 字段的值进行配置。

图 3.3. 电信核心参考设计 MetalLB 服务分离

电信核心参考设计 MetalLB 服务分离

3.8.3.1. Cluster Network Operator
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新
描述

Cluster Network Operator (CNO)会在集群安装过程中部署和管理集群网络组件，包括默认的 OVN-Kubernetes 网络插件。CNO 允许配置主接口 MTU 设置，OVN 网关设置可为 pod 出口使用节点路由表，以及 MACVLAN 等其他二级网络。

支持网络流量分离，通过 CNO 配置多个网络接口。定向到这些接口的流量通过使用 NMState Operator 应用的静态路由来配置。为确保 pod 流量被正确路由，OVN-K 被配置为启用了 routingViaHost 选项。此设置使用内核路由表，以及应用的静态路由，而不是 OVN 用于 pod 出口流量。

Whereabouts CNI 插件用于为其他 pod 网络接口提供动态 IPv4 和 IPv6 寻址，而无需使用 DHCP 服务器。

限制和要求
  • IPv6 支持需要 OVN-Kubernetes。
  • 大型 MTU 集群支持需要将连接的网络设备设置为相同的或更大值。支持 MTU 大小最多 8900。

  • MACVLAN 和 IPVLAN 无法在同一主接口上并置，因为它们依赖于相同的底层内核机制，特别是 rx_handler。此处理程序允许第三方模块处理传入的数据包，主机处理它们之前，每个网络接口只能注册一个这样的处理程序。由于 MACVLAN 和 IPVLAN 都需要注册自己的 rx_handler 才能正常工作，所以它们不会冲突，且无法在同一接口上共存。查看源代码了解更多详情：

  • 备用 NIC 配置包括将共享 NIC 拆分为多个 NIC 或使用一个双端口 NIC，尽管它们尚未经过测试和验证。
  • 带有单堆栈 IP 配置的集群不会被验证。
  • Network CR 中的 reachabilityTotalTimeoutSeconds 参数配置 EgressIP 节点可访问性检查总超时（以秒为单位）。建议的值是 1 秒。
  • Pod 级别 SR-IOV 绑定模式必须设置为 active-backup，并且必须设置 miimon 的值（建议使用100 ）。
工程考虑
  • Pod 出口流量由内核路由表使用 routingViaHost 选项处理。主机上必须配置适当的静态路由。

3.8.3.2. 负载均衡器
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新。
重要

如果您在 metallb-system 命名空间中有自定义 FRRConfiguration CR，您必须将它们移到 openshift-network-operator 命名空间中。

描述
MetalLB 是使用标准路由协议的裸机 Kubernetes 集群的负载均衡器实现。它可让 Kubernetes 服务获取外部 IP 地址，该地址也添加到集群中的主机网络中。MetalLB Operator 部署并管理集群中 MetalLB 实例的生命周期。有些用例可能需要 MetalLB 中没有提供的功能，如有状态负载均衡。如有必要，您可以使用外部第三方负载均衡器。外部负载均衡器的选择和配置已超出此规格的范围。使用外部第三方负载均衡器时，集成工作必须包含足够的分析，以确保满足所有性能和资源利用率要求。
限制和要求
  • MetalLB 不支持有状态负载均衡。如果这是工作负载 CNF 的要求，则必须使用备用负载均衡器实现。
  • 您必须确保外部 IP 地址可以从客户端路由到集群的主机网络。
工程考虑
  • MetalLB 仅在 BGP 模式下用于电信内核使用模型。
  • 对于电信内核使用模型，只有 OVN-Kubernetes 网络插件的 ovnKubernetesConfig.gatewayConfig 规格中设置了 routingViaHost=true 时，才会支持 MetalLB。请参阅 "Cluster Network Operator" 中的 routingViaHost。

  • MetalLB 中的 BGP 配置应该根据网络和对等点的要求而有所不同。

    • 您可以使用地址、聚合长度、自动分配等变化来配置地址池。
    • MetalLB 仅将 BGP 用于公告路由。只有 transmitInterval 和 minimumTtl 参数在此模式中相关。BFD 配置集中的其他参数应保持接近默认值，因为较短的值可能会导致假的负值并影响性能。

3.8.3.3. SR-IOV
复制链接

这个版本中的新内容
  • 支持 SR-IOV operator 的 resource injector 中移动失败的策略。
描述
SR-IOV 允许将物理功能(PF)划分为多个虚拟功能(VF)。然后 VF 可以分配给多个 pod，以实现更高的吞吐量性能，同时使 pod 保持隔离。SR-IOV Network Operator 置备并管理 SR-IOV CNI、网络设备插件和 SR-IOV 堆栈的其他组件。
限制和要求
  • 仅支持某些网络接口。如需更多信息，请参阅"支持设备"。
  • 启用 SR-IOV 和 IOMMU ：SR-IOV Network Operator 会在内核命令行中自动启用 IOMMU。
  • SR-IOV VF 不会从 PF 接收链路状态更新。如果需要链接降级检测，它必须在协议级别进行。
  • MultiNetworkPolicy CR 只能应用到 netdevice 网络。这是因为，实施使用 iptables，它无法管理 vfio 接口。
工程考虑
  • vfio 模式中的 SR-IOV 接口通常用于为需要高吞吐量或低延迟的应用程序启用额外的二级网络。
  • 必须明确创建 SriovOperatorConfig CR。此 CR 包含在引用配置策略中，这会导致在初始部署期间创建它。
  • 不支持使用 UEFI 安全引导或内核锁定进行固件更新的 NIC 必须预先配置，并启用了足够的虚拟功能(VF)来支持应用程序工作负载所需的 VF 数量。对于 Mellanox NIC，您必须在 SR-IOV Network Operator 中禁用 Mellanox vendor 插件。如需更多信息，请参阅"配置 SR-IOV 网络设备"。
  • 要在 pod 启动后更改 VF 的 MTU 值，请不要配置 SriovNetworkNodePolicy MTU 字段。反之，使用 Kubernetes NMState Operator 设置相关 PF 的 MTU。

3.8.3.4. NMState Operator
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新
描述
Kubernetes NMState Operator 提供了一个 Kubernetes API，用于在集群节点中执行状态驱动的网络配置。它在二级接口上启用网络接口配置、静态 IP 和 DNS、VLAN、中继、绑定、静态路由、MTU 并启用混杂模式。集群节点定期向 API 服务器报告每个节点的网络接口状态。
限制和要求
Not applicable
工程考虑
  • 初始网络配置是使用安装 CR 中的 NMStateConfig 内容应用。NMState Operator 仅在网络更新需要时才使用。
  • 当 SR-IOV 虚拟功能用于主机网络时，使用 NMState Operator （通过 nodeNetworkConfigurationPolicy CR）来配置 VF 接口，如 VLAN 和 MTU。

3.8.4. 日志记录
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新
描述
Cluster Logging Operator 启用收集并提供与节点相关的日志，以进行远程归档和分析。参考配置使用 Kafka 将审核和基础架构日志发送到远程归档。
限制和要求
Not applicable
工程考虑
  • 集群 CPU 使用的影响取决于生成的日志的数量或大小以及配置的日志过滤量。
  • 参考配置不包括应用程序日志的发布。将应用程序日志包含在配置中，需要评估应用程序日志记录率以及分配给保留集合的足够额外 CPU 资源。

3.8.5. 电源管理
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新
描述
使用 Performance Profile 配置具有高电源模式、低电源模式或混合模式的集群。电源模式的选择取决于集群中运行的工作负载的特征，特别是对延迟敏感度。使用每个 pod 电源管理 C-states 功能，为低延迟 pod 配置最大延迟。
限制和要求
  • 电源配置依赖于适当的 BIOS 配置，例如启用 C-states 和 P-states。配置因硬件供应商而异。
工程考虑
  • 延迟 ：为了确保对延迟敏感的工作负载满足要求，您需要一个高电源或每个 pod 电源管理配置。每个 pod 电源管理仅适用于具有专用固定 CPU 的 Guaranteed QoS pod。

3.8.6. 存储
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新
描述

云原生存储服务可由 OpenShift Data Foundation 或其他第三方解决方案提供。

OpenShift Data Foundation 是面向容器的基于 Red Hat Ceph Storage 的存储解决方案。它提供块存储、文件系统存储和内部对象存储，可针对持久性和非持久性数据要求动态置备。电信核心应用程序需要持久性存储。

注意

所有存储数据可能无法加密。要降低风险，请将存储网络与其他集群网络隔离。存储网络不能从其他集群网络访问或路由。只有直接附加到存储网络的节点才应允许访问它。

3.8.6.1. OpenShift Data Foundation
复制链接

这个版本中的新内容
  • 与外部模式和 RDS 建议相比，内部清晰化。
描述

OpenShift Data Foundation 是容器的软件定义的存储服务。OpenShift Data Foundation 可以部署为两种模式之一：在内部模式中，OpenShift Data Foundation 软件组件作为软件容器直接部署到 OpenShift Container Platform 集群节点上，以及其他容器化应用程序。* 外部模式，其中 OpenShift Data Foundation 部署到专用存储集群中，通常是在 Red Hat Enterprise Linux (RHEL)上运行的独立 Red Hat Ceph Storage 集群。这些存储服务在应用程序工作负载集群外部运行。

对于电信核心集群，存储支持由 OpenShift Data Foundation 存储服务在外部模式中运行，原因如下：

  • 在 OpenShift Container Platform 和 Ceph 操作间分离依赖项允许独立的 OpenShift Container Platform 和 OpenShift Data Foundation 更新。
  • 分离存储和 OpenShift Container Platform 基础架构层的操作功能是电信核心用例的典型客户要求。
  • 外部 Red Hat Ceph Storage 集群可由在同一区域部署的多个 OpenShift Container Platform 集群重新使用。

OpenShift Data Foundation 支持使用二级 CNI 网络来分离存储流量。

限制和要求
  • 在 IPv4/IPv6 双栈网络环境中，OpenShift Data Foundation 使用 IPv4 地址。如需更多信息，请参阅 IPv6 支持。
工程考虑
  • OpenShift Data Foundation 网络流量应该与专用网络上的其他流量隔离，例如使用 VLAN 隔离。
  • 在将多个 OpenShift Container Platform 集群附加到外部 OpenShift Data Foundation 集群前，必须有范围，以确保有足够的吞吐量、带宽和性能 KPI。

3.8.6.2. 其他存储解决方案
复制链接

您可以使用其他存储解决方案为电信核心集群提供持久性存储。这些解决方案的配置和集成超出了参考设计规格(RDS)的范围。

将存储解决方案集成至电信核心集群必须包含正确的大小和性能分析，以确保存储满足整体性能和资源使用量要求。

3.8.7. 电信核心部署组件
复制链接

以下小节描述了您使用 Red Hat Advanced Cluster Management (RHACM) 配置 hub 集群的各种 OpenShift Container Platform 组件和配置。

3.8.7.1. Red Hat Advanced Cluster Management
复制链接

这个版本中的新内容
  • 使用 RHACM 和 PolicyGenerator CR 是管理和部署策略的建议方法。这将替换 PolicyGenTemplate CR 用于此目的。
描述

RHACM 为部署的集群提供多集群引擎(MCE)安装和持续 GitOps ZTP 生命周期管理。您可以通过在维护窗口期间将 Policy 自定义资源 (CR) 应用到集群来声明管理集群配置和升级。

您可以使用 RHACM 策略控制器应用策略，由 TALM 管理。配置、升级和集群状态通过策略控制器进行管理。

安装受管集群时，RHACM 将标签和初始 ignition 配置应用到各个节点，以支持自定义磁盘分区、分配角色和分配到机器配置池。您可以使用 SiteConfig 或 ClusterInstance CR 定义这些配置。

限制和要求
工程考虑
  • 当管理每个安装、站点或部署具有唯一内容的集群时，强烈建议使用 RHACM hub 模板。RHACM hub 模板允许您在为每个安装提供唯一值时对集群应用一致的策略集合。

3.8.7.2. Topology Aware Lifecycle Manager
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新。
描述

TALM 是一个仅在 hub 集群上运行的 Operator。TALM 管理如何将集群和 Operator 升级、配置等更改部署到网络中的受管集群。TALM 具有以下核心功能：

  • 提供由集群策略定义的集群配置和升级(OpenShift Container Platform 和 Operator)的序列更新。
  • 提供用于延迟集群更新的应用程序。
  • 支持对用户可配置的批处理中的集群集合进行策略更新进度发布。
  • 通过在集群中添加 ztp-done 或类似用户定义的标签来允许针对每个集群的操作。
限制和要求
  • 支持以 400 批处理中的并发集群部署
工程考虑
  • 在初始集群安装过程中，TALM 只应用带有 ran.openshift.io/ztp-deploy-wave 注解的策略。
  • TALM 控制用户创建的 ClusterGroupUpgrade CR 时可以修复任何策略。

3.8.7.3. GitOps Operator 和 ZTP 插件
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新。
描述

GitOps Operator 提供了一个 GitOps 驱动的基础架构，用于管理集群部署和配置。集群定义和配置在 Git 仓库中维护。

ZTP 插件支持从 SiteConfig CR 生成 Installation CR，并根据 RHACM PolicyGenerator CR 在策略中自动嵌套配置 CR。

SiteConfig Operator 改进了从 ClusterInstance CR 生成 Installation CR 的支持。

重要

使用 ClusterInstance CR 进行集群安装优先于使用 ZTP 插件方法的 SiteConfig 自定义资源。

您应该根据发行版本构建 Git 仓库，其中包含所有必要的工件(SiteConfig、ClusterInstance、PolicyGenerator 和 PolicyGenTemplate，并支持引用 CR)。这可让同时部署和管理多个 OpenShift Container Platform 版本和配置版本。

推荐的 Git 结构将引用 CR 保留在独立于客户或合作伙伴提供的内容的目录中。这意味着，您可以通过只覆盖现有内容来导入引用更新。客户或合作伙伴提供的 CR 可以在参考 CR 的并行目录中提供，以便轻松包含在生成的配置策略中。

限制和要求
  • 每个 ArgoCD 应用程序都支持最多 1000 个节点。可以使用多个 ArgoCD 应用程序来实现单个 hub 集群支持的最大集群数量。

  • SiteConfig CR 必须使用 extraManifests.searchPaths 字段来引用引用清单。

    注意

    从 OpenShift Container Platform 4.15 开始，spec.extraManifestPath 字段已弃用。

工程考虑

  • 在集群升级维护窗口中将 MachineConfigPool (MCP) CR paused 字段设置为 true，并将 maxUnavailable 字段设置为最大可容忍的值。这可防止在升级过程中重启多个集群节点，这会使整体升级较短。当您取消暂停 mcp CR 时，所有配置更改都使用一次重启来应用。

    注意

    在安装过程中，自定义 MCP CR 可以暂停，并将 maxUnavailable 设置为 100% 以改进安装时间。

  • 为了避免在更新内容时造成混淆或意外覆盖，您应该在 core-overlay 和 extra manifests 下的 reference-crs/ 目录中的自定义 CR 使用唯一的和可分辨名称。
  • SiteConfig CR 允许多个 extra-manifest 路径。当文件名在多个目录路径中有重叠时，目录顺序列表中的最后一个文件将具有优先权。

3.8.7.4. 监控
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新。
描述

Cluster Monitoring Operator (CMO) 默认包含在 OpenShift Container Platform 中，并为平台组件和可选用户项目提供监控（指标、仪表板和警报）。

您可以自定义默认日志保留周期、自定义警报规则等。

基于上游 Kubernetes 和 cAdvisor 的默认 pod CPU 和内存指标的处理，与指标准确性相比，它是一种权衡的数据。这会导致报告高峰，它可以根据用户指定的阈值创建 false 警报。

OpenShift Container Platform 支持 opt-in Dedicated Service Monitor 功能，它创建一组不会影响此行为的 pod CPU 和内存指标。如需更多信息，请参阅红帽知识库解决方案 Dedicated Service Monitors - 问题和回答。

除了默认配置外，还应该为电信核心集群配置以下指标：

  • 用户工作负载的 Pod CPU 和内存指标和警报
限制和要求
  • 您必须启用 Dedicated Service Monitor 功能，以便准确表示 pod 指标。
工程考虑
  • Prometheus 保留周期由用户指定。使用的值是根据 CPU 和存储资源维护集群中的历史数据的操作要求之间的权衡。保留周期较长，增加存储需求，并需要额外的 CPU 来管理数据的索引。

3.8.8. 调度
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新。
描述

调度程序是一个集群范围的组件，负责为给定工作负载选择正确的节点。它是平台的核心部分，不需要在常见部署场景中进行任何特定的配置。但是，在以下部分中描述了一些特定的用例。

可以通过 NUMA Resources Operator 启用 NUMA 感知调度。如需更多信息，请参阅"有效的 NUMA 感知工作负载"。

限制和要求

  • 默认调度程序不了解工作负载的 NUMA 本地性。它仅了解 worker 节点上所有可用资源的总和。当调度到将拓扑管理器策略设置为 single-numa-node 或 restricted 的节点时，这可能会导致工作负载被拒绝。如需更多信息，请参阅"Topology Manager 策略"。

    例如，考虑请求 6 个 CPU 的 pod，并调度到每个 NUMA 节点有 4 个 CPU 的空节点。节点的可分配容量总数为 8 个 CPU。调度程序将 pod 放置到空节点上。但是，节点本地准入将失败，因为每个 NUMA 节点中只有 4 个 CPU 可用。

  • 具有多 NUMA 节点的所有集群都需要使用 NUMA Resources Operator。如需更多信息，请参阅"安装 NUMA Resources Operator"。使用 KubeletConfig CR 中的 machineConfigPoolSelector 字段选择需要 NUMA 校准调度的所有节点。
  • 所有机器配置池都必须具有一致的硬件配置。例如，所有节点都应该具有相同的 NUMA 区域计数。
工程考虑
  • Pod 可能需要注解才能正确调度和隔离。有关注解的更多信息，请参阅"CPU 分区和性能调优"。
  • 您可以通过在 SriovNetworkNodePolicy CR 中使用 excludeTopology 字段，将 SR-IOV 虚拟功能 NUMA 关联性配置为在调度期间被忽略。

3.8.9. 节点配置
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新。
限制和要求

  • 分析其他内核模块，以确定对 CPU 负载、系统性能以及满足 KPI 的能力的影响。

    Expand
    表 3.1. 其他内核模块
    功能描述

    其他内核模块

    使用 MachineConfig CR 安装以下内核模块，为 CNFs 提供扩展的内核功能。

    • sctp
    • ip_gre
    • ip6_tables
    • ip6t_REJECT
    • ip6table_filter
    • ip6table_mangle
    • iptable_filter
    • iptable_mangle
    • iptable_nat
    • xt_multiport
    • xt_owner
    • xt_REDIRECT
    • xt_statistic
    • xt_TCPMSS

    容器挂载命名空间隐藏

    减少 kubelet 内务处理和驱除监控的频率，以减少 CPU 用量。创建容器挂载命名空间，对 kubelet 和 CRI-O 可见，以减少系统挂载扫描资源使用情况。

    kdump 启用

    可选配置（默认为启用）

3.8.10. 主机固件和引导装载程序配置
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新。
工程考虑

  • 启用安全引导是推荐的配置。

    注意

    启用安全引导后，内核只载入签名的内核模块。不支持树外驱动程序。

3.8.11. 断开连接的环境
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新。
Descrption

电信核心集群预期会在网络中安装，而无需直接访问互联网。安装、配置和操作集群所需的所有容器镜像都必须在断开连接的 registry 中提供。这包括 OpenShift Container Platform 镜像、第 2 天 OLM Operator 镜像和应用程序工作负载镜像。断开连接的环境的使用提供多种优点，包括：

  • 安全 - 限制对集群的访问
  • 策展的内容 - registry 根据集群的策展和批准更新填充
限制和要求
  • 所有自定义 CatalogSource 资源都需要一个唯一名称。不要重复使用默认目录名称。
工程考虑
  • 必须将有效的时间源配置为集群安装的一部分

3.8.12. 基于代理的安装程序
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新。
描述

可使用基于代理的安装程序安装电信核心集群。此方法允许用户在裸机服务器上安装 OpenShift Container Platform，而无需额外的服务器或虚拟机来管理安装。基于代理的安装程序可以在任何系统上运行（例如，从笔记本电脑中）来生成 ISO 安装镜像。此 ISO 用作集群 supervisor 节点的安装介质。可使用基于代理的安装程序从任何带有网络连接的系统到 supervisor 节点的 API 接口来监控进度。

基于代理的安装程序支持以下内容：

  • 从声明性 CR 安装。
  • 在断开连接的环境中安装。
  • 不使用其他服务器安装来支持安装，如 bastion 节点。
限制和要求
  • 断开连接的安装需要一个 registry，其中包含所有需要的内容，并可从安装的主机访问。
工程考虑
  • 网络配置应该在安装过程中作为 NMState 配置应用。不支持使用 NMState Operator 的第 2 天网络配置。

3.8.13. 安全性
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新。
描述

电信客户安全隐患，需要针对多个攻击向量强化集群。在 OpenShift Container Platform 中，没有单一组件或功能用来负责保护集群。以下是电信核心 RDS 中涵盖的使用模型的各种面向安全特性和配置。

  • SecurityContextConstraints (SCC) ：所有工作负载 Pod 都应使用 restricted-v2 或 restricted SCC 运行。
  • Seccomp ：所有 pod 都应使用 RuntimeDefault （或更强大的）seccomp 配置集运行。
  • Rootless DPDK pod: 许多用户-plane 网络(DPDK) CNFs 需要 pod 使用 root 权限运行。使用此功能，可在不需要 root 特权的情况下运行符合 DPDK pod。Rootless DPDK pod 在 rootless pod 中创建 tap 设备，将 DPDK 应用程序的流量注入内核。
  • 存储 ：存储网络应该被隔离且不可路由到其他集群网络。详情请查看 "Storage" 部分。

如需了解在 OpenShift 集群节点中实施自定义 nftables 防火墙规则的支持方法，请参阅 OpenShift 中的自定义 nftable 防火墙规则。本文面向在 OpenShift Container Platform 环境中管理网络安全策略的集群管理员。

在部署此方法前，请仔细考虑操作影响，包括：

  • 早期应用程序 ：规则在引导时应用，在网络完全运行之前。确保规则不会意外阻止引导过程中所需的必要服务。
  • 错误配置的风险 ：自定义规则中的错误可能会导致意外的结果，这可能会导致性能影响或阻止合法流量或隔离节点。在将规则部署到主集群之前，在非生产环境中完全测试您的规则。
  • 外部端点 ：OpenShift Container Platform 需要访问外部端点才能正常工作。如需有关防火墙允许列表的更多信息，请参阅"为 OpenShift Container Platform 配置防火墙"。确保集群节点有权访问这些端点。

  • 节点重新引导 ：配置了无盘节点中断策略，使用所需防火墙设置应用 MachineConfig CR 会导致节点重新引导。请注意，这个影响并相应地调度维护窗口。如需更多信息，请参阅使用节点中断策略来最大程度降低机器配置变化的中断。

    注意

    OpenShift Container Platform 4.17 及更新的版本中提供了节点中断策略。

  • 网络流列表 ：有关管理入口流量的更多信息，请参阅"OpenShift Container Platform 网络流列表"。您可以将入口流量限制为基本流以提高网络安全性。该列表提供了对基础集群服务的见解，但排除 day-2 Operator 生成的流量。
  • 集群版本更新和升级 ：在更新或升级 OpenShift Container Platform 集群时非常谨慎。对平台防火墙要求的最新更改可能需要调整网络端口权限。虽然文档提供了指南，但请注意这些要求可能会随着时间而演变。要最小化中断，您应该在生产环境中测试任何更新或升级，然后再在生产环境中应用它们。这有助于您识别并解决与防火墙配置更改相关的潜在兼容性问题。
限制和要求

  • Rootless DPDK pod 需要以下额外配置：

    • 为 tap 插件配置 container_t SELinux 上下文。
    • 为集群主机启用 container_use_devices SELinux 布尔值。
工程考虑
  • 对于无根 DPDK pod 支持，请在主机上启用 SELinux container_use_devices 布尔值，以允许创建 tap 设备。这会带来可接受的安全风险。

3.8.14. 可扩展性
复制链接

这个版本中的新内容
  • 这个版本没有参考设计更新。
描述
扩展集群，如 "Limits and requirements" 所述。"应用程序工作负载"中描述了工作负载扩展。
限制和要求
  • 集群可以扩展到至少 120 个节点。
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2026 Red Hat返回顶部