3.3. 电信核心参考设计规格
3.3.1. 电信核心 4.14 参考设计概述 复制链接链接已复制到粘贴板!
电信核心参考设计规格(RDS)配置在商业硬件上运行的 OpenShift Container Platform 集群,以托管电信核心工作负载。
3.3.1.1. 用于电信内核的 OpenShift Container Platform 4.14 功能 复制链接链接已复制到粘贴板!
OpenShift Container Platform 4.14 中包含的以下功能,并由电信核心参考设计规格 (RDS) 使用。
功能 | 描述 |
---|---|
支持使用 TAP CNI 插件运行带有内核访问权限的无根数据平面开发套件(DPDK)工作负载 | 将流量注入内核的 DPDK 应用程序可以通过 TAP CNI 插件在非特权 pod 中运行。 |
OVS 的非保留 CPU 的动态使用 |
在这个版本中,Open vSwitch (OVS) 网络堆栈可以动态使用非保留 CPU。在性能调整的集群中,非保留 CPU 的动态使用会在性能调整集群中进行,并将 CPU Manager 策略设置为 |
为每个 pod 启用对 C-states 的更多控制 |
|
排除 NUMA 感知调度的 SR-IOV 网络拓扑 | 您可以将 SR-IOV 网络的 Non-Uniform Memory Access (NUMA) 节点排除到 Topology Manager。如果没有为 SR-IOV 网络公告 NUMA 节点,您可以在 NUMA 感知 pod 调度过程中允许更灵活的 SR-IOV 网络部署。 例如,在某些情况下,您想要灵活地部署 pod。通过使用不向 pod 的 SR-IOV 网络资源的拓扑管理器提供 NUMA 节点提示,拓扑管理器可以将 SR-IOV 网络资源和 pod CPU 和内存资源部署到不同的 NUMA 节点。在以前的 OpenShift Container Platform 版本中,Topology Manager 会尝试将所有资源放在同一个 NUMA 节点上。 |
出口服务资源以管理负载均衡器后面的 pod 的出口流量(技术预览) |
在这个版本中,您可以使用
您可以使用以下方法使用
|
3.3.2. 电信核心 4.14 使用模型概述 复制链接链接已复制到粘贴板!
Telco 核心参考设计规格(RDS)描述了支持大型电信应用程序(包括 control plane 功能)的平台,如信号和聚合。它还包括一些集中式数据平面功能,如 user plane 功能 (UPF)。这些功能通常需要可扩展性、复杂的网络支持、弹性的软件定义存储并支持比 RAN 等远端部署限制的性能要求。
电信核心使用模型架构
电信核心功能的网络先决条件是不同的,包含一系列网络属性和性能基准。IPv6 是必需的,且双栈配置被预先评估。某些功能需要最大吞吐量和事务率,需要 user plane 网络支持,如 DPDK。其他功能遵循传统的云原生模式,并且可以使用 OVN-K、内核网络和负载平衡等解决方案。
电信核心集群配置为标准三个 control plane 集群,其 worker 节点配置了库存非实时(RT)内核。要支持具有不同网络和性能要求的工作负载,worker 节点使用 MachineConfigPool
CR 分段。例如,这是将非用户数据平面节点与高吞吐量的节点分开的。为了支持所需的电信操作功能,集群安装了一组标准的 Operator Lifecycle Manager (OLM)第 2 天 Operator。
3.3.2.1. 常见基准模型 复制链接链接已复制到粘贴板!
以下配置和使用模型描述适用于所有电信核心用例。
- Cluster
集群符合以下要求:
- 高可用性(3+ 超级节点) control plane
- 不可调度的 supervisor 节点
- Storage
- 核心用例需要由外部 OpenShift Data Foundation 提供的持久性存储。如需更多信息,请参阅"参考核心设计组件"中的"存储"部分。
- 网络
电信核心集群网络符合这些要求:
- 双堆栈 IPv4/IPv6
- 完全断开连接:集群在其生命周期中都无法访问公共网络。
- 多个网络:分割网络在 OAM、信号和存储流量之间提供隔离。
- Cluster network type:支持 IPv6 需要 OVN-Kubernetes。
核心集群在以下"网络"部分中详述了底层 RHCOS、SR-IOV Operator、Load Balancer 和其他组件的多个层。在高级别上,这些层包括:
Cluster network :集群网络配置通过安装配置进行定义并应用。对配置的更新可以通过 NMState Operator 在第 2 天完成。初始配置可用于建立:
- 主机接口配置
- A/A Bonding (Link Aggregation Control Protocol (LACP))
二级网络:OpenShift CNI 通过 Network
additionalNetworks
或 NetworkAttachmentDefinition CR 配置。- MACVLAN
- 应用程序工作负载:User plane 网络在云原生网络功能(CNF)中运行。
- Service Mesh
- 电信 CNFs 的 Service Mesh 使用非常常见。预期所有核心集群都包括 Service Mesh 实现。Service Mesh 实现和配置超出此规格的范围。
3.3.2.1.1. 工程注意事项常见使用模型 复制链接链接已复制到粘贴板!
以下工程考虑与常见用途模型相关。
- Worker 节点
- Worker 节点在 Intel 3rd Generation Xeon (IceLake)处理器或更新版本上运行。或者,如果使用 Skylake 或更早的处理器,则必须禁用 silicon 安全漏洞(如 Spectre)的缓解方案;无法这样做可能会导致事务性能显著降低 40%。
-
在 worker 节点上启用 IRQ Balancing。
PerformanceProfile
设置globallyDisableIrqLoadBalancing: false
。保证的 QoS Pod 被注解以确保隔离,如"参考内核设计组件"部分中的"CPU 分区和性能调优"子中所述。
- 所有节点
- 在所有节点上都启用超线程
-
CPU 架构仅为
x86_64
- 节点运行库存(非 RT)内核
- 没有为工作负载分区配置节点
电源管理和集群中 MachineConfigPool
之间节点配置平衡会有所不同。此配置对于 MachineConfigPool
中的所有节点是一致的。
- CPU 分区
-
CPU 分区使用 PerformanceProfile 配置,并基于每个
MachineConfigPool
应用。请参阅"参考核心设计组件"中的"CPU 分区和性能调整"子部分。
3.3.2.1.2. 应用程序工作负载 复制链接链接已复制到粘贴板!
在核心集群中运行的应用程序工作负载可能包括高性能网络 CNF 和传统最佳 pod 工作负载的组合。
保证因为性能或安全要求而需要专用或专用使用 CPU 的 pod 有保证的 QoS 调度可用。通常,使用带有 DPDK 的 user plane 网络托管高性能和低延迟功能(CNF)的 pod 需要整个 CPU 的独占利用。这可以通过节点调整和保证服务质量(QoS)调度来实现。对于需要专用使用 CPU 的 pod,请注意超线程系统的潜在影响,并在整个内核(2 超线程)必须分配给 pod 时请求 2 个 CPU 的倍数。
运行不需要高吞吐量和低延迟网络的网络功能的 Pod 通常使用最佳或突发的 QoS 调度,且不需要专用或隔离的 CPU 内核。
- 限制描述
- CNF 应用程序应该遵循最新版本的红帽最佳实践 Kubernetes 指南。
对于最佳和突发的 QoS pod 的组合。
-
可以使用保证的 QoS pod,但在
PerformanceProfile
中需要正确配置保留的和隔离的 CPU。 - 保证的 QoS Pod 必须包含完全隔离 CPU 的注解。
- 最佳工作和突发 pod 无法保证对 CPU 的独占使用。工作负载可能被其他工作负载、操作系统守护进程或内核任务抢占。
-
可以使用保证的 QoS pod,但在
除非不存在可行的替代选择,否则应该避免使用 exec 探测。
- 如果 CNF 正在使用 CPU 固定,则不要使用 exec 探测。
-
应该使用其他探测实施,如
httpGet/tcpSocket
。
注意在 steady-state 操作过程中启动探测需要最少的资源。exec 探测的限制主要适用于存活度和就绪度探测。
- 信号工作负载
- 信号工作负载通常使用 SCTP、REST、gRPC 或类似的 TCP 或 UDP 协议。
- 每秒的事务(TPS)采用数百万个使用配置为 MACVLAN 或 SR-IOV 的辅助 CNI (multus)的顺序。
- 信号工作负载在带有保证或突发 QoS 的 pod 中运行。
3.3.3. 电信核心参考设计组件 复制链接链接已复制到粘贴板!
以下小节描述了用于配置和部署集群来运行电信核心工作负载的各种 OpenShift Container Platform 组件和配置。
3.3.3.1. CPU 分区和性能调整 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- Open vSwitch (OVS) 已从 CPU 分区中删除。OVS 动态管理其 cpuset,以自动适应网络流量需求。用户不再需要保留额外的 CPU 来处理主容器网络接口 (CNI) 上的高网络吞吐量。对此更改所需的配置没有影响。
- 描述
CPU 分区允许将敏感工作负载与通用目的、辅助进程、中断和驱动程序工作队列分离,以实现更高的性能和延迟。分配给这些辅助进程的 CPU 在以下部分中称为
reserved
。在超线程系统中,CPU 是一个超线程。如需更多信息,请参阅为 infra 和应用程序容器限制 CPU。
配置系统级性能。有关推荐的设置,请参阅为低延迟和高性能配置主机固件。
- 限制和要求
操作系统需要一定数量的 CPU 来执行包括内核网络在内的所有支持任务。
- 仅具有 user plane 网络应用程序(DPDK)的系统至少需要为操作系统和基础架构组件保留一个核心(2 超线程)。
- 启用 Hyper-Threading 的系统必须始终将所有内核同级线程设置为相同的 CPU 池。
- 保留和隔离的内核集合必须包含所有 CPU 内核。
- 每个 NUMA 节点的核心 0 必须包含在保留的 CPU 集中。
隔离的内核可能会受到中断的影响。如果保证 QoS pod 需要完全使用 CPU,则必须将以下注解附加到 pod:
cpu-load-balancing.crio.io: "disable" cpu-quota.crio.io: "disable" irq-load-balancing.crio.io: "disable"
cpu-load-balancing.crio.io: "disable" cpu-quota.crio.io: "disable" irq-load-balancing.crio.io: "disable"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当使用
PerformanceProfile.workloadHints.perPodPowerManagement
启用每个 pod 电源管理时,如果保证 QoS pod 需要完全使用 CPU,则必须将以下注解附加到 pod:cpu-c-states.crio.io: "disable" cpu-freq-governor.crio.io: "performance"
cpu-c-states.crio.io: "disable" cpu-freq-governor.crio.io: "performance"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 工程考虑
-
所需的最少保留容量(
systemReserved
) 的信息包括在在 OCP 4 节点上为系统保留量的 CPU和内存 - 实际所需的保留 CPU 容量取决于集群配置和工作负载属性。
- 保留的 CPU 值必须向上舍入到完整内核(2 超线程)。
- 对 CPU 分区的更改将排空并重新引导 MCP 中的节点。
- 保留的 CPU 减少了 pod 密度,因为保留的 CPU 已从 OpenShift 节点的可分配容量中删除。
- 如果工作负载实时功能,则应启用实时工作负载提示。
- 没有中断请求(IRQ)关联性支持的硬件将影响隔离的 CPU。为确保具有保证 CPU QoS 的 pod 完全使用分配的 CPU,服务器中的所有硬件都必须支持 IRQ 关联性。
-
所需的最少保留容量(
3.3.3.2. Service Mesh 复制链接链接已复制到粘贴板!
- 描述
- 电信核心 CNF 通常需要服务网格实施。所需的特定功能和性能取决于应用程序。服务网格实施和配置选择超出了本文档的范围。服务网格对集群资源利用率和性能的影响(包括 pod 网络中引入的额外延迟)必须在整个解决方案工程中考虑。
3.3.3.3. 网络 复制链接链接已复制到粘贴板!
OpenShift Container Platform 网络是一个功能生态系统、插件和高级网络功能,它使用高级网络相关功能来扩展 Kubernetes 网络,集群需要为其一个或多个混合集群管理网络流量。
3.3.3.3.1. Cluster Network Operator (CNO) 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 不适用。
- 描述
CNO 在 OpenShift Container Platform 集群安装过程中部署和管理集群网络组件,包括默认的 OVN-Kubernetes 网络插件。它允许配置主接口 MTU 设置、OVN 网关模式,将节点路由表用于 pod 出口,以及 MACVLAN 等其他二级网络。
支持网络流量分离,通过 CNO 配置多个网络接口。定向到这些接口的流量通过使用 NMState Operator 应用的静态路由来配置。为确保 pod 流量被正确路由,OVN-K 被配置为启用了
routingViaHost
选项。此设置使用内核路由表,以及应用的静态路由,而不是 OVN 用于 pod 出口流量。Whereabouts CNI 插件用于为其他 pod 网络接口提供动态 IPv4 和 IPv6 寻址,而无需使用 DHCP 服务器。
- 限制和要求
- IPv6 支持需要 OVN-Kubernetes。
- 大型 MTU 集群支持需要将连接的网络设备设置为相同的或更大值。
- 工程考虑
-
Pod 出口流量由内核路由表使用
routingViaHost
选项处理。主机上必须配置适当的静态路由。
-
Pod 出口流量由内核路由表使用
3.3.3.3.2. Load Balancer 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 不适用。
- 描述
MetalLB 是使用标准路由协议的裸机 Kubernetes 集群的负载均衡器实现。它可让 Kubernetes 服务获取外部 IP 地址,该地址也添加到集群中的主机网络中。
有些用例可能需要 MetalLB 中不提供的功能,如有状态负载均衡。如有必要,您可以使用外部第三方负载均衡器。外部负载均衡器的选择和配置已超出此规格的范围。使用外部第三方负载均衡器时,集成工作必须包含足够的分析,以确保满足所有性能和资源利用率要求。
- 限制和要求
- MetalLB 不支持有状态负载均衡。如果这是工作负载 CNF 的要求,则必须使用备用负载均衡器实现。
- 网络基础架构必须确保外部 IP 地址可以从客户端路由到集群的主机网络。
- 工程考虑
- 在 BGP 模式下,MetalLB 仅用于核心用例模型。
-
对于内核使用模型,MetalLB 仅支持本地网关模式中使用的 OVN-Kubernetes 网络供应商。请参阅"Cluster Network Operator"部分中的
routingViaHost
。 - MetalLB 中的 BGP 配置根据网络和对等点的要求而有所不同。
- 可以根据需要配置地址池,允许地址、聚合长度、自动分配和其他相关参数的不同。
- Bi-Directional Forwarding Detection (BFD) 配置集中的参数值应保持接近默认值。较短的值可能会导致假的负值并影响性能。
3.3.3.3.3. SR-IOV 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- Not applicable
- 描述
- SR-IOV 允许将物理网络接口(PF)划分为多个虚拟功能(VF)。然后 VF 可以分配给多个 pod,以实现更高的吞吐量性能,同时使 pod 保持隔离。SR-IOV Network Operator 置备并管理 SR-IOV CNI、网络设备插件和 SR-IOV 堆栈的其他组件。
- 限制和要求
- 支持的网络接口控制器在 OCP 支持的 SR-IOV 设备中列出
- BIOS 中的 SR-IOV 和 IOMMU 启用 :SR-IOV Network Operator 会在内核命令行中自动启用 IOMMU。
- SR-IOV VF 不会从 PF 接收链路状态更新。如果需要链接检测,必须在协议级别进行。
- 工程考虑
-
vfio
模式中的 SR-IOV 接口通常用于为需要高吞吐量或低延迟的应用程序启用额外的二级网络。
-
3.3.3.3.4. NMState Operator 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- Not applicable
- 描述
- NMState Operator 提供了一个 Kubernetes API,用于在集群节点间执行网络配置。它在二级接口上启用网络接口配置、静态 IP 和 DNS、VLAN、中继、绑定、静态路由、MTU 并启用混杂模式。集群节点定期向 API 服务器报告每个节点的网络接口状态。
- 限制和要求
- Not applicable
- 工程考虑
-
初始网络配置是使用安装 CR 中的
NMStateConfig
内容应用。NMState Operator 仅在网络更新需要时才使用。 -
当 SR-IOV 虚拟功能用于主机网络时,使用
NodeNetworkConfigurationPolicy
的 NMState Operator 用于配置这些 VF 接口,如 VLAN 和 MTU。
-
初始网络配置是使用安装 CR 中的
3.3.3.4. 日志记录 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- Not applicable
- 描述
- Cluster Logging Operator 启用收集并提供与节点相关的日志,以进行远程归档和分析。参考配置使用 Kafka 将审计和基础架构日志发送到远程存档。
- 限制和要求
- Not applicable
- 工程考虑
- 集群 CPU 使用的影响取决于生成的日志的数量或大小以及配置的日志过滤量。
- 参考配置不包括应用程序日志的发布。将应用程序日志包含在配置中,需要评估应用程序日志记录率以及分配给保留集合的足够额外 CPU 资源。
3.3.3.5. 电源管理 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 在使用每个 pod 电源管理时,您可以为低延迟 pod 指定最大延迟。在以前的版本中,只有每个 pod 都可以完全禁用 C-states。
- 描述
- Performance Profile 可以用来以高电源、低电源或混合(根据每个 pod 的电源管理)模式配置集群。电源模式的选择取决于集群中运行的工作负载的特征,特别是对延迟敏感度。
- 限制和要求
- 电源配置依赖于适当的 BIOS 配置,例如启用 C-states 和 P-states。配置因硬件供应商而异。
- 工程考虑
-
延迟 :为了确保对延迟敏感的工作负载满足其要求,您需要一个高电源配置或每个 pod 电源管理配置。每个 pod 电源管理仅适用于带有专用固定 CPU 的
Guaranteed
QoS Pod。
-
延迟 :为了确保对延迟敏感的工作负载满足其要求,您需要一个高电源配置或每个 pod 电源管理配置。每个 pod 电源管理仅适用于带有专用固定 CPU 的
3.3.3.6. Storage 复制链接链接已复制到粘贴板!
- 概述
云原生存储服务可由多种解决方案提供,包括来自红帽或第三方的 OpenShift Data Foundation。
OpenShift Data Foundation 是基于 Ceph 的软件定义的存储解决方案。它提供块存储、文件系统存储和内部对象存储,可针对持久性和非持久性数据要求动态置备。电信核心应用程序需要持久性存储。
注意所有存储数据可能无法加密。要降低风险,请将存储网络与其他集群网络隔离。存储网络不能从其他集群网络访问或路由。只有直接附加到存储网络的节点才应允许访问它。
3.3.3.6.1. OpenShift Data Foundation 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- Not applicable
- 描述
- Red Hat OpenShift Data Foundation 是容器的软件定义的存储服务。对于 Telco 核心集群,存储支持由外部运行到应用程序工作负载集群的 OpenShift Data Foundation 存储服务提供。OpenShift Data Foundation 支持使用二级 CNI 网络来分离存储流量。
- 限制和要求
- 在 IPv4/IPv6 双栈网络环境中,OpenShift Data Foundation 使用 IPv4 地址。如需更多信息,请参阅使用 IPv4 支持带有 ODF 的 OpenShift 双堆栈。
- 工程考虑
- OpenShift Data Foundation 网络流量应该与专用网络上的其他流量隔离,例如使用 VLAN 隔离。
3.3.3.6.2. 其他存储 复制链接链接已复制到粘贴板!
其他存储解决方案可用于为核心集群提供持久性存储。这些解决方案的配置和集成超出了电信核心 RDS 的范围。将存储解决方案集成至核心集群必须包含正确的大小和性能分析,以确保存储满足整体性能和资源利用率要求。
3.3.3.7. 监控 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- Not applicable
- 描述
Cluster Monitoring Operator (CMO) 默认包括在所有 OpenShift 集群中,并为平台组件和可选用户项目提供监控(指标、仪表板和警报)。
配置监控 Operator 允许自定义,包括:
- 默认保留周期
- 自定义警报规则
pod CPU 和内存指标的默认处理基于上游 Kubernetes
cAdvisor
,并权衡优先处理过时的数据,而不是指标准确性。这会导致 spiky 数据,这些数据将通过用户指定的阈值创建假的警报触发。OpenShift 支持 opt-in 专用服务监控功能,它创建了一组不会受到 spiky 行为的另一组 pod CPU 和内存指标。如需更多信息,请参阅此解决方案指南。除了默认配置外,还应该为电信核心集群配置以下指标:
- 用户工作负载的 Pod CPU 和内存指标和警报
- 限制和要求
- 监控配置必须启用专用服务监控功能,以准确表示 pod 指标
- 工程考虑
- Prometheus 保留周期由用户指定。使用的值是根据 CPU 和存储资源维护集群中的历史数据的操作要求之间的权衡。保留周期较长,增加存储需求,并需要额外的 CPU 来管理数据的索引。
3.3.3.8. 调度 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 使用 NUMA Resources Operator 的 NUMA 感知调度现在包括在 OpenShift Container Platform 4.14 中。
-
在这个版本中,您可以将 SR-IOV 网络的 Non-Uniform Memory Access (NUMA)节点公告到拓扑管理器。如果没有为 SR-IOV 网络公告 NUMA 节点,您可以在 NUMA 感知 pod 调度过程中允许更灵活的 SR-IOV 网络部署。要将 SR-IOV 网络资源的 NUMA 节点公告到 Topology Manager,请在
SriovNetworkNodePolicy
CR 中将值excludeTopology
设置为true
。如需更多信息,请参阅排除 NUMA 感知调度的 SR-IOV 网络拓扑。
- 描述
- 调度程序是一个集群范围的组件,负责为给定工作负载选择正确的节点。它是平台的核心部分,不需要在常见部署场景中进行任何特定的配置。但是,在以下部分中描述了一些特定的用例。
- 限制和要求
默认调度程序不了解工作负载的 NUMA 本地性。它仅了解 worker 节点上所有可用资源的总和。当调度到将 Topology Manager 策略设置为
single-numa-node
或restricted
的节点上时,这可能会导致工作负载被拒绝。- 例如,考虑请求 6 个 CPU 的 pod,并调度到每个 NUMA 节点有 4 个 CPU 的空节点。节点的可分配容量总数为 8 个 CPU,调度程序会将 pod 放置到其中。但是,节点本地准入将失败,因为每个 NUMA 节点中只有 4 个 CPU 可用。
-
具有多 NUMA 节点的所有集群都需要使用 NUMA Resources Operator。NUMA Resources Operator 的
machineConfigPoolSelector
必须选择需要 NUMA 校准调度的所有节点。
- 所有机器配置池都必须具有一致的硬件配置,例如所有节点都应该具有相同的 NUMA 区计数。
- 工程考虑
- Pod 可能需要注解才能正确调度和隔离。有关注解的更多信息,请参阅"CPU 分区和性能调优"部分。
3.3.3.9. 安装 复制链接链接已复制到粘贴板!
- 这个版本中的新内容, 描述
可以使用基于代理的安装程序(ABI)安装电信核心集群。此方法允许用户在裸机服务器上安装 OpenShift Container Platform,而无需额外的服务器或虚拟机来管理安装。ABI 安装程序可以在任何系统上运行,例如笔记本电脑来生成 ISO 安装镜像。此 ISO 用作集群 supervisor 节点的安装介质。可使用任何具有网络连接的系统到 supervisor 节点的 API 接口的 ABI 工具监控进度。
- 从声明性 CR 安装
- 不需要额外的服务器来支持安装
- 支持在断开连接的环境中安装
- 限制和要求
- 断开连接的安装需要一个可访问 registry,其中包含所有所需内容。
- 工程考虑
- 网络配置应该在安装过程中作为 NMState 配置应用到第 2 天配置,使用 NMState Operator。
3.3.3.10. 安全性 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 将流量注入内核的 DPDK 应用程序可以通过 TAP CNI 插件在非特权 pod 中运行。另外,在这个 4.14 发行版本中,基于容器命名空间中的 master 接口创建 MAC-VLAN、IP-VLAN 和 VLAN 子接口已正式发布。
- 描述
电信操作器是安全的考虑,需要针对多个攻击向量强化集群。在 OpenShift Container Platform 中,没有单一组件或功能负责保护集群。本节详细介绍了此规格中涵盖的使用模型的面向安全特性和配置。
- SecurityContextConstraints:所有工作负载 Pod 都应使用 restricted-v2 或 restricted SCC 运行。
-
seccomp :所有 pod 都应使用
RuntimeDefault
(或更强大的)seccomp 配置集运行。 - Rootless DPDK pod: 许多用户-plane 网络(DPDK) CNFs 需要 pod 使用 root 权限运行。使用此功能,可在不需要 root 特权的情况下运行符合 DPDK pod。
- 存储 :存储网络应该被隔离且不可路由到其他集群网络。详情请查看 "Storage" 部分。
- 限制和要求
Rootless DPDK pod 需要以下额外的配置步骤:
-
使用
container_t
SELinux 上下文配置TAP 插件。 -
在主机上启用
container_use_devices
SELinux 布尔值。
-
使用
- 工程考虑
-
对于无根 DPDK pod 支持,必须在主机上启用 SELinux 布尔值
container_use_devices
,才能创建TAP 设备。这引入了一个安全风险,可在短期内使用。将探索其他解决方案。
-
对于无根 DPDK pod 支持,必须在主机上启用 SELinux 布尔值
3.3.3.11. 可扩展性 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- Not applicable
- 描述
集群将扩展到 limits 和 requirements 部分中列出的大小。
使用模型部分描述了工作负载的扩展。
- 限制和要求
- 集群扩展到至少 120 个节点
- 工程考虑
- Not applicable
3.3.3.12. 其他配置 复制链接链接已复制到粘贴板!
3.3.3.12.1. 断开连接的环境 复制链接链接已复制到粘贴板!
- 描述
电信核心集群预期会在网络中安装,而无需直接访问互联网。安装、配置和 Operator 所需的所有容器镜像都必须在断开连接的 registry 中提供。这包括 OpenShift Container Platform 镜像、第 2 天 Operator Lifecycle Manager (OLM) Operator 镜像和应用程序工作负载镜像。使用断开连接的环境提供多个优点,例如:
- 为安全限制对集群的访问
- curated content: registry 基于集群的策展和批准的更新进行填充
- 限制和要求
- 所有自定义 CatalogSource 都需要一个唯一名称。不要重复使用默认目录名称。
- 必须将有效的时间源配置为集群安装的一部分。
- 工程考虑
- Not applicable
3.3.3.12.2. 内核 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- Not applicable
- 描述
用户可以使用
MachineConfig
安装以下内核模块,为 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
- 限制和要求
- 必须通过这些内核模块使用的功能必须由用户分析,以确定对 CPU 负载、系统性能以及保持 KPI 的影响。
注意不支持在树外驱动程序中。
- 工程考虑
- Not applicable
3.3.4. 电信核心 4.14 参考配置 CR 复制链接链接已复制到粘贴板!
使用以下自定义资源(CR)来使用电信核心配置集配置和部署 OpenShift Container Platform 集群。使用 CR 组成所有特定使用模型中使用的通用基准,除非另有说明。
3.3.4.1. Resource Tuning 参考 CR 复制链接链接已复制到粘贴板!
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
系统保留容量 | 是 | 否 | |
系统保留容量 | 是 | 否 |
3.3.4.2. 存储引用 CR 复制链接链接已复制到粘贴板!
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
外部 ODF 配置 | 否 | 是 | |
外部 ODF 配置 | 否 | 否 | |
外部 ODF 配置 | 否 | 否 | |
外部 ODF 配置 | 否 | 否 |
3.3.4.3. 网络引用 CR 复制链接链接已复制到粘贴板!
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
Baseline | 否 | 否 | |
Baseline | 是 | 是 | |
负载均衡器 | 否 | 否 | |
负载均衡器 | 否 | 否 | |
负载均衡器 | 否 | 否 | |
负载均衡器 | 否 | 否 | |
负载均衡器 | 否 | 否 | |
负载均衡器 | 是 | 否 | |
负载均衡器 | 是 | 否 | |
负载均衡器 | 否 | 否 | |
Multus - 用于无根 DPDK pod 的 Tap CNI | 否 | 否 | |
Cluster Network Operator | 是 | 否 | |
Cluster Network Operator | 否 | 是 | |
Cluster Network Operator | 否 | 是 | |
Cluster Network Operator | 否 | 否 | |
Cluster Network Operator | 否 | 否 | |
Cluster Network Operator | 否 | 否 |
3.3.4.4. 调度引用 CR 复制链接链接已复制到粘贴板!
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
NUMA 感知调度程序 | 否 | 否 | |
NUMA 感知调度程序 | 否 | 否 | |
NUMA 感知调度程序 | 否 | 否 | |
NUMA 感知调度程序 | 否 | 否 | |
NUMA 感知调度程序 | 否 | 否 |
3.3.4.5. 其他引用 CR 复制链接链接已复制到粘贴板!
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
其他内核模块 | 是 | 否 | |
其他内核模块 | 是 | 否 | |
其他内核模块 | 是 | 否 | |
集群日志记录 | 否 | 否 | |
集群日志记录 | 否 | 否 | |
集群日志记录 | 否 | 否 | |
集群日志记录 | 否 | 否 | |
集群日志记录 | 否 | 是 | |
断开连接的配置 | 否 | 否 | |
断开连接的配置 | 否 | 否 | |
断开连接的配置 | 否 | 否 | |
监控和可观察性 | 是 | 否 | |
电源管理 | 否 | 否 |
3.3.4.6. YAML 参考 复制链接链接已复制到粘贴板!
3.3.4.6.1. 资源调优参考 YAML 复制链接链接已复制到粘贴板!
control-plane-system-reserved.yaml
pid-limits-cr.yaml
3.3.4.6.2. 存储引用 YAML 复制链接链接已复制到粘贴板!
01-rook-ceph-external-cluster-details.secret.yaml
02-ocs-external-storagecluster.yaml
odfNS.yaml
odfOperGroup.yaml
3.3.4.6.3. 网络引用 YAML 复制链接链接已复制到粘贴板!
Network.yaml
networkAttachmentDefinition.yaml
addr-pool.yaml
bfd-profile.yaml
bgp-advr.yaml
bgp-peer.yaml
metallb.yaml
metallbNS.yaml
metallbOperGroup.yaml
metallbSubscription.yaml
mc_rootless_pods_selinux.yaml
sriovNetwork.yaml
sriovNetworkNodePolicy.yaml
SriovOperatorConfig.yaml
SriovSubscription.yaml
SriovSubscriptionNS.yaml
SriovSubscriptionOperGroup.yaml
3.3.4.6.4. 调度引用 YAML 复制链接链接已复制到粘贴板!
nrop.yaml
NROPSubscription.yaml
NROPSubscriptionNS.yaml
NROPSubscriptionOperGroup.yaml
sched.yaml
3.3.4.6.5. 其他引用 YAML 复制链接链接已复制到粘贴板!
control-plane-load-kernel-modules.yaml
sctp_module_mc.yaml
worker-load-kernel-modules.yaml
ClusterLogForwarder.yaml
ClusterLogging.yaml
ClusterLogNS.yaml
ClusterLogOperGroup.yaml
ClusterLogSubscription.yaml
catalog-source.yaml
icsp.yaml
operator-hub.yaml
monitoring-config-cm.yaml
PerformanceProfile.yaml