3.3. 电信核心参考设计规格
3.3.1. 电信核心 4.17 参考设计概述 复制链接链接已复制到粘贴板!
电信核心参考设计规格(RDS)配置在商业硬件上运行的 OpenShift Container Platform 集群,以托管电信核心工作负载。
3.3.1.1. 电信核心集群基于服务的架构和网络拓扑 复制链接链接已复制到粘贴板!
Telco 核心参考设计规格(RDS)描述了支持大型电信应用程序(包括 control plane 功能)的平台,如信号和聚合。它还包括一些集中式数据平面功能,如 user plane 功能 (UPF)。这些功能通常需要可扩展性、复杂的网络支持、弹性的软件定义存储并支持比 RAN 等远端部署限制的性能要求。
图 3.3. 电信核心集群基于服务的架构和网络拓扑
电信核心集群基于服务的构架由以下组件组成:
- 网络数据分析功能 (NWDAF)
- 网络片段选择功能 (NSFF)
- 身份验证服务器功能 (AUSF)
- 统一数据管理 (UDM)
- 网络仓库功能 (NRF)
- 网络公开功能 (NEF)
- 应用程序功能 (AF)
- 访问和移动性功能 (AMF)
- 会话管理功能 (SMF)
- 策略控制功能 (PCF)
- 计费功能 (CHF)
- 用户设备 (UE)
- 无线访问网络 (RAN)
- 用户平面功能 (UPF)
- 数据平面网络(DN)
3.3.2. 电信核心 4.17 使用模型概述 复制链接链接已复制到粘贴板!
电信核心集群配置为标准三个 control plane 集群,其 worker 节点配置了库存非实时(RT)内核。
要支持具有不同网络和性能要求的工作负载,worker 节点使用 MachineConfigPool
CR 分段。例如,这是将非用户数据平面节点与高吞吐量的节点分开的。为了支持所需的电信操作功能,集群安装了一组标准的 Operator Lifecycle Manager (OLM)第 2 天 Operator。
电信核心功能的网络先决条件是不同的,包含一系列网络属性和性能基准。IPv6 是必需的,且双栈配置被预先评估。某些功能需要最大吞吐量和事务率,需要 user plane 网络支持,如 DPDK。其他功能遵循传统的云原生模式,并且可以使用 OVN-K、内核网络和负载平衡等解决方案。
电信核心使用模型架构
3.3.2.1. 常见基准模型 复制链接链接已复制到粘贴板!
以下配置和使用模型描述适用于所有电信核心用例。
- Cluster
集群符合以下要求:
- 高可用性(3+ 超级节点) control plane
- 不可调度的 supervisor 节点
-
多个
MachineConfigPool
资源
- Storage
- 核心用例需要由外部 OpenShift Data Foundation 提供的持久性存储。如需更多信息,请参阅"参考核心设计组件"中的"存储"部分。
- 网络
电信核心集群网络符合这些要求:
- 双堆栈 IPv4/IPv6
- 完全断开连接:集群在其生命周期中都无法访问公共网络。
- 多个网络:分割网络在 OAM、信号和存储流量之间提供隔离。
- Cluster network type:支持 IPv6 需要 OVN-Kubernetes。
核心集群在以下"网络"部分中详述了底层 RHCOS、SR-IOV Operator、Load Balancer 和其他组件的多个层。在高级别上,这些层包括:
Cluster network :集群网络配置通过安装配置进行定义并应用。对配置的更新可以通过 NMState Operator 在第 2 天完成。初始配置可用于建立:
- 主机接口配置
- Active/Active 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. 电信核心 RDS 工程考虑 复制链接链接已复制到粘贴板!
以下工程考虑与电信核心常见使用模型相关。
- Worker 节点
Worker 节点应在 Intel 3rd Generation Xeon (IceLake) 处理器或更新版本上运行。
注意或者,如果您的 worker 节点有 Skylake 或更早的处理器,您必须为 silicon 安全漏洞(如 Spectre)禁用缓解方案。否则可能会导致事务性能降低 40%。
-
为 worker 节点启用 IRQ Balancing。将
PerformanceProfile
自定义资源 (CR) 中的globallyDisableIrqLoadBalancing
字段设置为false
。使用Guaranteed
的 QoS 类注解 pod,以确保它们被隔离。如需更多信息,请参阅"CPU 分区和性能调整"。
- 集群中的所有节点
- 为所有节点启用超线程。
-
确保 CPU 架构仅为
x86_64
。 - 确保节点正在运行正常(非 RT)内核。
- 确保没有为工作负载分区配置节点。
- 电源管理和性能
-
电源管理和最大性能之间的平衡因集群中的
MachineConfigPool
资源而异。
-
电源管理和最大性能之间的平衡因集群中的
- 集群扩展
- 将集群节点数量扩展到至少 120 个节点。
- CPU 分区
-
CPU 分区使用
PerformanceProfile
CR 配置,每个MachineConfigPool
CR 对应一个。如需更多信息,请参阅"CPU 分区和性能调整"。
-
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 分区和性能调整 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
- 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
) 的信息包括在在 OpenShift 4 节点上为系统保留量的 CPU和内存 - 实际所需的保留 CPU 容量取决于集群配置和工作负载属性。
- 保留的 CPU 值必须向上舍入到完整内核(2 超线程)。
- 对 CPU 分区的更改将排空并重新引导 MCP 中的节点。
- 保留的 CPU 减少了 pod 密度,因为保留的 CPU 已从 OpenShift 节点的可分配容量中删除。
- 如果工作负载实时功能,则应启用实时工作负载提示。
- 没有中断请求(IRQ)关联性支持的硬件将影响隔离的 CPU。为确保具有保证 CPU QoS 的 pod 完全使用分配的 CPU,服务器中的所有硬件都必须支持 IRQ 关联性。
-
OVS 动态管理其
cpuset
配置,以适应网络流量的需求。您不需要保留额外的 CPU 来处理主 CNI 上的高网络吞吐量。 - 如果集群中运行的工作负载需要 cgroups v1,您可以将节点配置为使用 cgroups v1 作为初始集群部署的一部分。如需更多信息,请参阅"在安装过程中启用 Linux cgroup v1"。
-
所需的最少保留容量(
3.3.3.2. Service Mesh 复制链接链接已复制到粘贴板!
- 描述
电信核心云原生功能(CNF)通常需要一个服务网格实施。
注意特定的服务网格功能和性能要求取决于应用程序。服务网格实施和配置选择超出了本文档的范围。您必须考虑服务网格对集群资源使用情况和性能的影响,包括在实现中 pod 网络中引入的额外延迟。
3.3.3.3. 网络 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 电信核心验证现在使用绑定、MACVLAN、IPVLAN 和 SR-IOV 网络场景进行扩展。
- 描述
- 集群在双栈 IP 配置 (IPv4 和 IPv6) 中配置。
- 验证的物理网络配置由两个双端口 NIC 组成。一个 NIC 在主 CNI (OVN-Kubernetes) 和 IPVLAN 和 MACVLAN 流量间共享,第二个 NIC 专用于基于 SR-IOV VF 的 Pod 流量。
Linux 绑定接口 (
bond0
) 是在主动-主动 LACPIEEE 802.3ad
配置中创建的,并附加两个 NIC 端口。注意顶尖网络设备必须支持,并为多机链路聚合 (mLAG) 技术进行配置。
-
VLAN 接口在
bond0
上创建,包括用于主 CNI。 -
在网络配置期间,会在安装时创建绑定和 VLAN 接口。除了主 CNI 使用的 VLAN (
VLAN0
) 外,也可以使用 Kubernetes NMState Operator 在第 2 天上创建其他 VLANS。 - MACVLAN 和 IPVLAN 接口使用对应的 CNI 创建。它们不共享相同的基本接口。
SR-IOV VF 由 SR-IOV Network Operator 管理。下图显示了 SR-IOV NIC 共享概述:
图 3.4. SR-IOV NIC 共享
3.3.3.4. 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 集群支持需要将连接的网络设备设置为相同的或更大值。
-
MACVLAN 和 IPVLAN 无法在同一主接口上并置,因为它们依赖于相同的底层内核机制,特别是
rx_handler
。此处理程序允许第三方模块处理传入的数据包,主机处理它们之前,每个网络接口只能注册一个这样的处理程序。由于 MACVLAN 和 IPVLAN 都需要注册自己的rx_handler
才能正常工作,所以它们不会冲突,且无法在同一接口上共存。详情请查看 ipvlan/ipvlan_main.c""L82 和 net/macvlan.c""L1260。 备选 NIC 配置包括将共享 NIC 拆分为多个 NIC 或使用单个双端口 NIC。
重要将共享 NIC 拆分为多个 NIC 或使用单一双端口 NIC 尚未经过电信核心参考设计进行验证。
- 未验证单堆栈 IP 集群。
- 工程考虑
-
Pod 出口流量由内核路由表使用
routingViaHost
选项处理。主机上必须配置适当的静态路由。
-
Pod 出口流量由内核路由表使用
3.3.3.5. 负载均衡器 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
-
在 OpenShift Container Platform 4.17 中,
frr-k8s
现在是默认的,并被完全支持的边框网关协议 (BGP) 后端。弃用的frr
BGP 模式仍然可用。您应该升级集群以使用frr-k8s
后端。
-
在 OpenShift Container Platform 4.17 中,
- 描述
MetalLB 是一个负载均衡器的实现,用于裸机集群使用标准路由协议。它可让 Kubernetes 服务获取外部 IP 地址,该地址也添加到集群中的主机网络中。
注意有些用例可能需要 MetalLB 中不提供的功能,如有状态负载均衡。如有必要,使用外部第三方负载均衡器。外部负载均衡器的选择和配置已超出此文档的范围。使用外部第三方负载均衡器时,请确保它满足所有性能和资源利用率要求。
- 限制和要求
- MetalLB 不支持有状态负载均衡。如果这是工作负载 CNF 的要求,则必须使用备用负载均衡器实现。
- 网络基础架构必须确保外部 IP 地址可以从客户端路由到集群的主机网络。
- 工程考虑
- 在 BGP 模式下,MetalLB 仅用于核心用例模型。
-
对于内核使用模型,只有 OVN-Kubernetes 网络插件的
ovnKubernetesConfig.gatewayConfig
规格中设置了routingViaHost=true
时,MetalLB 才支持。 - MetalLB 中的 BGP 配置根据网络和对等点的要求而有所不同。
- 可以根据需要配置地址池,允许地址、聚合长度、自动分配和其他相关参数的不同。
-
MetalLB 仅将 BGP 用于公告路由。只有
transmitInterval
和minimumTtl
参数在此模式中相关。BFD 配置集中的其他参数应保持接近默认设置。较短的值可能会导致错误并影响性能。
3.3.3.6. SR-IOV 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
- SR-IOV 允许将物理网络接口(PF)划分为多个虚拟功能(VF)。然后 VF 可以分配给多个 pod,以实现更高的吞吐量性能,同时使 pod 保持隔离。SR-IOV Network Operator 置备并管理 SR-IOV CNI、网络设备插件和 SR-IOV 堆栈的其他组件。
- 限制和要求
- 支持的网络接口控制器在"支持设备"中列出。
- SR-IOV Network Operator 在内核命令行中自动启用 IOMMU。
- SR-IOV VF 不会从 PF 接收链路状态更新。如果需要链接检测,必须在协议级别进行。
-
MultiNetworkPolicy
CR 只能应用到netdevice
网络。这是因为,实施使用iptables
工具,它无法管理vfio
接口。
- 工程考虑
-
vfio
模式中的 SR-IOV 接口通常用于为需要高吞吐量或低延迟的应用程序启用额外的二级网络。 -
如果您从部署中排除
SriovOperatorConfig
CR,则不会自动创建 CR。 不支持安全引导或内核锁定下固件更新的 NIC 必须预先配置为启用足够的 VF,以支持应用程序工作负载所需的 VF 数量。
注意可能需要使用未包括在文档中的
disablePlugins
选项禁用这些 NIC 的 SR-IOV Network Operator 插件。
-
3.3.3.7. NMState Operator 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
- NMState Operator 提供了一个 Kubernetes API,用于在集群节点间执行网络配置。
- 限制和要求
- Not applicable
- 工程考虑
-
初始网络配置是使用安装 CR 中的
NMStateConfig
内容应用。NMState Operator 仅在网络更新需要时才使用。 -
当 SR-IOV 虚拟功能用于主机网络时,使用
NodeNetworkConfigurationPolicy
的 NMState Operator 用于配置这些 VF 接口,如 VLAN 和 MTU。
-
初始网络配置是使用安装 CR 中的
3.3.3.8. 日志记录 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 更新您现有的实现,以适应 Cluster Logging Operator 6.0 的新 API。您必须使用策略删除旧的 Operator 工件。如需更多信息,请参阅附加资源。
- 描述
- Cluster Logging Operator 启用收集并提供与节点相关的日志,以进行远程归档和分析。参考配置使用 Kafka 将审计和基础架构日志发送到远程存档。
- 限制和要求
- Not applicable
- 工程考虑
- 集群 CPU 使用的影响取决于生成的日志的数量或大小以及配置的日志过滤量。
- 参考配置不包括应用程序日志的发布。将应用程序日志包含在配置中,需要评估应用程序日志记录率以及分配给保留集合的足够额外 CPU 资源。
3.3.3.9. 电源管理 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
- 使用 Performance Profile 配置具有高电源模式、低电源模式或混合模式的集群。电源模式的选择取决于集群中运行的工作负载的特征,特别是对延迟敏感度。
- 限制和要求
- 电源配置依赖于适当的 BIOS 配置,例如启用 C-states 和 P-states。配置因硬件供应商而异。
- 工程考虑
-
延迟 :为了确保对延迟敏感的工作负载满足其要求,您需要一个高电源配置或每个 pod 电源管理配置。每个 pod 电源管理仅适用于带有专用固定 CPU 的
Guaranteed
QoS Pod。
-
延迟 :为了确保对延迟敏感的工作负载满足其要求,您需要一个高电源配置或每个 pod 电源管理配置。每个 pod 电源管理仅适用于带有专用固定 CPU 的
3.3.3.10. Storage 复制链接链接已复制到粘贴板!
云原生存储服务可由多种解决方案提供,包括来自红帽或第三方的 OpenShift Data Foundation。
3.3.3.10.1. OpenShift Data Foundation 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
- Red Hat OpenShift Data Foundation 是容器的软件定义的存储服务。对于 Telco 核心集群,存储支持由外部运行到应用程序工作负载集群的 OpenShift Data Foundation 存储服务提供。
- 限制和要求
- 在 IPv4/IPv6 双栈网络环境中,OpenShift Data Foundation 使用 IPv4 地址。如需更多信息,请参阅使用 IPv4 支持 OpenShift Data Foundation 的 OpenShift 双堆栈。
- 工程考虑
- OpenShift Data Foundation 网络流量应该与专用网络上的其他流量隔离,例如使用 VLAN 隔离。
其他存储解决方案可用于为核心集群提供持久性存储。
注意这些解决方案的配置和集成超出了电信核心 RDS 的范围。将存储解决方案集成至核心集群必须包含正确的大小和性能分析,以确保存储满足整体性能和资源利用率要求。
3.3.3.11. 电信核心部署组件 复制链接链接已复制到粘贴板!
以下小节描述了您使用 Red Hat Advanced Cluster Management (RHACM) 配置 hub 集群的各种 OpenShift Container Platform 组件和配置。
3.3.3.11.1. Red Hat Advanced Cluster Management 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
Red Hat Advanced Cluster Management (RHACM) 为部署的集群提供 Multi Cluster Engine (MCE) 安装和持续生命周期管理功能。您可以通过在维护窗口期间将
Policy
自定义资源 (CR) 应用到集群来声明管理集群配置和升级。您可以使用 RHACM 策略控制器应用策略,如 Topology Aware Lifecycle Manager (TALM)。
安装受管集群时,RHACM 将标签和初始 ignition 配置应用到各个节点,以支持自定义磁盘分区、分配角色和分配到机器配置池。您可以使用
SiteConfig
或ClusterInstance
CR 定义这些配置。- 限制和要求
- 工程考虑
- 使用 RHACM 策略 hub 侧模板来更好地扩展集群配置。您可以使用单个组策略或少量常规组策略(其中组和每个集群值替换)来显著减少策略数量。
-
集群特定的配置:受管集群通常具有一些特定于单个集群的配置值。这些配置应该使用 RHACM 策略 hub 侧模板来管理,其值基于集群名称从
ConfigMap
CR 中拉取。
3.3.3.11.2. Topology Aware Lifecycle Manager 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
- Topology Aware Lifecycle Manager (TALM)是一个仅在 hub 集群上运行的 Operator,用于管理集群和 Operator 升级、配置等变化是如何部署到网络中。
- 限制和要求
- TALM 支持以 400 批量进行并发集群部署。
- 预缓存和备份功能仅适用于单节点 OpenShift 集群。
- 工程考虑
-
在初始集群安装过程中,只有带有
ran.openshift.io/ztp-deploy-wave
注解的策略才会由 TALM 自动应用。 -
您可以创建进一步的
ClusterGroupUpgrade
CR,以控制 TALM 修复的策略。
-
在初始集群安装过程中,只有带有
3.3.3.11.3. GitOps 和 GitOps ZTP 插件 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
GitOps 和 GitOps ZTP 插件提供了一个基于 GitOps 的基础架构,用于管理集群部署和配置。集群定义和配置在 Git 中作为声明状态进行维护。您可以将
ClusterInstance
CR 应用到 hub 集群,其中SiteConfig
Operator 会将它们呈现为安装 CR。另外,您可以使用 GitOps ZTP 插件直接从SiteConfig
CR 生成安装 CR。GitOps ZTP 插件支持根据PolicyGenTemplate
CR 在策略中自动嵌套配置 CR。注意您可以使用基准引用配置 CR 在受管集群中部署和管理多个 OpenShift Container Platform 版本。您可以使用自定义 CR 和基线(baseline)CR。
要同时维护多个针对每个版本的策略,请使用 Git 管理源 CR 和策略 CR (
PolicyGenTemplate
或PolicyGenerator
) 的版本。将引用 CR 和自定义 CR 保留在不同的目录中。这样,您可以通过简单的替换所有目录内容来修补和更新引用 CR,而无需涉及自定义 CR。
- Limits
-
每个 ArgoCD 应用程序 300 个
SiteConfig
CR。您可以使用多个应用程序来实现单个 hub 集群支持的最大集群数量。 -
Git 中的
/source-crs
文件夹的内容会覆盖 GitOps ZTP 插件容器中提供的内容。Git 在搜索路径中具有优先权。 在与
kustomization.yaml
文件相同的目录中添加/source-crs
文件夹,其中包含PolicyGenTemplate
作为生成器。注意此上下文中不支持
/source-crs
目录的备用位置。-
SiteConfig
CR 的extraManifestPath
字段已从 OpenShift Container Platform 4.15 及之后的版本中弃用。使用新的extraManifests.searchPaths
字段替代。
-
每个 ArgoCD 应用程序 300 个
- 工程考虑
-
对于多节点集群升级,您可以通过将
paused
字段设置为true
,在维护窗口期间暂停MachineConfigPool
(MCP
) CR。您可以通过在MCP
CR 中配置maxUnavailable
设置来增加每个MCP
更新的节点数量。MaxUnavailable
字段定义了,在MachineConfig
更新期间,池中可以同时不可用的节点的百分比。将maxUnavailable
设置为最大可容忍的值。这可减少升级过程中的重启次数,从而缩短升级时间。当您最终取消暂停MCP
CR 时,所有更改的配置都会使用单个重启来应用。 -
在集群安装过程中,您可以通过将
paused
字段设置为true
并将maxUnavailable
设置为 100% 以改进安装时间来暂停自定义MCP
CR。 -
为了避免在更新内容时避免混淆或意外覆盖文件,请在
/source-crs
文件夹和 Git 中额外清单中使用唯一的和可分辨名称。 -
SiteConfig
CR 允许多个 extra-manifest 路径。当在多个目录路径中找到具有相同名称的文件时,找到的最后一个文件将具有优先权。这可让您将特定于版本的整个版本 0 清单 (extra-manifests) 放在 Git 中,并从SiteConfig
CR 引用它们。使用此功能,您可以同时将多个 OpenShift Container Platform 版本部署到受管集群。
-
对于多节点集群升级,您可以通过将
3.3.3.11.4. 基于代理的安装程序 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
您可以使用基于代理的安装程序(ABI)在裸机服务器上安装电信核心集群,而无需额外的服务器或虚拟机来管理安装。ABI 支持在断开连接的环境中安装。使用 ABI 时,您可以使用声明性自定义资源(CR)安装集群。
注意基于代理的安装程序是一个可选组件。推荐的安装方法是使用 Red Hat Advanced Cluster Management 或 multicluster engine for Kubernetes Operator。
- 限制和要求
- 您需要有一个断开连接的镜像 registry,其中包含所有必要的内容,才能在断开连接的环境中进行基于代理的安装。
- 工程考虑
-
网络配置应在集群安装过程中作为
NMState
自定义资源 (CR) 应用。
-
网络配置应在集群安装过程中作为
3.3.3.12. 监控 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
Cluster Monitoring Operator (CMO) 默认包含在 OpenShift Container Platform 中,并为平台组件和可选用户项目提供监控(指标、仪表板和警报)。
注意pod CPU 和内存指标的默认处理基于上游 Kubernetes
cAdvisor
,并权衡优先处理过时的数据,而不是指标准确性。这会导致 spiky 数据,这些数据将通过用户指定的阈值创建假的警报触发。OpenShift 支持 opt-in 专用服务监控功能,它创建了一组不会受到 spiky 行为的另一组 pod CPU 和内存指标。如需更多信息,请参阅专用服务监控器 - 问题和答案。- 限制和要求
- 监控配置必须启用专用服务监控功能,以准确表示 pod 指标
- 工程考虑
- 您可以配置 Prometheus 保留周期。使用的值是根据 CPU 和存储资源维护集群中的历史数据的操作要求之间的权衡。保留周期较长,增加存储需求,并需要额外的 CPU 来管理数据的索引。
3.3.3.13. 调度 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
- 调度程序是一个集群范围的组件,负责为给定工作负载选择正确的节点。它是平台的核心部分,不需要在常见部署场景中进行任何特定的配置。但是,在以下部分中描述了一些特定的用例。可以通过 NUMA Resources Operator 启用 NUMA 感知调度。如需更多信息,请参阅"有效的 NUMA 感知工作负载"。
- 限制和要求
默认调度程序不了解工作负载的 NUMA 本地性。它仅了解 worker 节点上所有可用资源的总和。当调度到将拓扑管理器策略设置为
single-numa-node
或restricted
的节点上时,这可能会导致工作负载被拒绝。- 例如,考虑请求 6 个 CPU 的 pod,并调度到每个 NUMA 节点有 4 个 CPU 的空节点。节点的可分配容量总数为 8 个 CPU,调度程序会将 pod 放置到其中。但是,节点本地准入将失败,因为每个 NUMA 节点中只有 4 个 CPU 可用。
-
具有多 NUMA 节点的所有集群都需要使用 NUMA Resources Operator。使用
KubeletConfig
CR 中的machineConfigPoolSelector
字段选择需要 NUMA 校准调度的所有节点。
- 所有机器配置池都必须具有一致的硬件配置,例如所有节点都应该具有相同的 NUMA 区计数。
- 工程考虑
- Pod 可能需要注解才能正确调度和隔离。如需有关注解的更多信息,请参阅"CPU 分区和性能调优"。
-
您可以通过在
SriovNetworkNodePolicy
CR 中使用excludeTopology
字段,将 SR-IOV 虚拟功能 NUMA 关联性配置为在调度期间被忽略。
3.3.3.14. 节点配置 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 容器挂载命名空间封装和 kdump 现在包括在电信核心 RDS 中。
- 描述
- 容器挂载命名空间封装会创建一个容器挂载命名空间,它减少了系统挂载扫描,并对 kubelet 和 CRI-O 可见。
- kdump 是一个可选配置,它默认在内核 panic 时捕获调试信息。启用 kdump 的参考 CR 根据参考配置中包含的驱动程序和内核模块集合增加内存保留。
- 限制和要求
- 使用 kdump 和容器挂载命名空间封装通过额外的内核模块提供。您应该分析这些模块,以确定对 CPU 负载、系统性能以及满足所需 KPI 的影响。
- 工程考虑
使用
MachineConfig
CR 安装以下内核模块。这些模块为云原生功能 (CNF) 提供扩展的内核功能。- 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
3.3.3.15. 主机固件和引导装载程序配置 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 现在,建议在使用电信核心参考设计配置的集群主机中使用安全引导。
- 工程考虑
启用安全引导是推荐的配置。
注意启用安全引导后,内核只载入签名的内核模块。不支持树外驱动程序。
3.3.3.16. 断开连接的环境 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
- 电信核心集群预期会在网络中安装,而无需直接访问互联网。安装、配置和 Operator 所需的所有容器镜像都必须在断开连接的 registry 中提供。这包括 OpenShift Container Platform 镜像、第 2 天 Operator Lifecycle Manager (OLM) Operator 镜像和应用程序工作负载镜像。
- 限制和要求
- 所有自定义 CatalogSource 都需要一个唯一名称。不要重复使用默认目录名称。
- 必须将有效的时间源配置为集群安装的一部分。
3.3.3.17. 安全性 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 现在,为电信核心集群推荐使用安全引导主机固件设置。如需更多信息,请参阅"主机固件和引导装载程序配置"。
- 描述
您应该针对多个攻击向量强化集群。在 OpenShift Container Platform 中,没有单一组件或功能用来负责保护集群。使用以下面向安全的功能和配置来保护集群:
-
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" 部分。
-
SecurityContextConstraints (SCC) :所有工作负载 Pod 都应使用
- 限制和要求
Rootless DPDK pod 需要以下额外的配置步骤:
-
使用
container_t
SELinux 上下文配置TAP 插件。 -
在主机上启用
container_use_devices
SELinux 布尔值。
-
使用
- 工程考虑
-
对于无根 DPDK pod 支持,必须在主机上启用 SELinux 布尔值
container_use_devices
,才能创建TAP 设备。这引入了一个安全风险,可在短期内使用。将探索其他解决方案。
-
对于无根 DPDK pod 支持,必须在主机上启用 SELinux 布尔值
3.3.3.18. 可扩展性 复制链接链接已复制到粘贴板!
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 限制和要求
- 集群应扩展到至少 120 个节点。
3.3.4. 电信核心 4.17 参考配置 CR 复制链接链接已复制到粘贴板!
使用以下自定义资源(CR)来使用电信核心配置集配置和部署 OpenShift Container Platform 集群。使用 CR 组成所有特定使用模型中使用的通用基准,除非另有说明。
3.3.4.1. 提取电信核心引用设计 CR 复制链接链接已复制到粘贴板!
您可以从 telco-core-rds-rhel9
容器镜像中提取电信核心配置集的完整自定义资源(CR)集合。容器镜像具有电信核心配置集所需的 CR 和可选 CR。
先决条件
-
已安装
podman
。
流程
运行以下命令,从
lecommunications-core-rds-rhel9
容器镜像中提取内容:mkdir -p ./out
$ mkdir -p ./out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.17 | base64 -d | tar xv -C out
$ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.17 | base64 -d | tar xv -C out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
out
目录具有以下文件夹结构:您可以查看out/telco-core-rds/
目录中的电信核心 CR。输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.4.2. 网络引用 CR 复制链接链接已复制到粘贴板!
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
Baseline | 是 | 否 | |
Baseline | 是 | 否 | |
负载均衡器 | 否 | 否 | |
负载均衡器 | 否 | 否 | |
负载均衡器 | 否 | 否 | |
负载均衡器 | 否 | 否 | |
负载均衡器 | 是 | 否 | |
负载均衡器 | 否 | 否 | |
负载均衡器 | 否 | 否 | |
负载均衡器 | 否 | 否 | |
负载均衡器 | 否 | 否 | |
Multus - 用于无根 DPDK pod 的 Tap CNI | 否 | 否 | |
NMState Operator | 否 | 否 | |
NMState Operator | 否 | 否 | |
NMState Operator | 否 | 否 | |
NMState Operator | 否 | 否 | |
Cluster Network Operator | 否 | 否 | |
Cluster Network Operator | 否 | 否 | |
Cluster Network Operator | 否 | 否 | |
Cluster Network Operator | 否 | 否 | |
Cluster Network Operator | 否 | 否 | |
Cluster Network Operator | 否 | 否 |
3.3.4.3. 节点配置参考 CR 复制链接链接已复制到粘贴板!
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
其他内核模块 | 是 | 否 | |
其他内核模块 | 是 | 否 | |
其他内核模块 | 是 | 否 | |
容器挂载命名空间隐藏 | 否 | 是 | |
容器挂载命名空间隐藏 | 否 | 是 | |
kdump 启用 | 否 | 是 | |
kdump 启用 | 否 | 是 |
3.3.4.4. 其他引用 CR 复制链接链接已复制到粘贴板!
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
集群日志记录 | 是 | 否 | |
集群日志记录 | 是 | 否 | |
集群日志记录 | 是 | 否 | |
集群日志记录 | 是 | 是 | |
集群日志记录 | 是 | 是 | |
集群日志记录 | 是 | 是 | |
集群日志记录 | 是 | 否 | |
断开连接的配置 | 否 | 否 | |
断开连接的配置 | 否 | 否 | |
断开连接的配置 | 否 | 否 | |
监控和可观察性 | 是 | 否 | |
电源管理 | 否 | 否 |
3.3.4.5. 资源调优引用 CR 复制链接链接已复制到粘贴板!
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
系统保留容量 | 是 | 否 |
3.3.4.6. 调度引用 CR 复制链接链接已复制到粘贴板!
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
NUMA 感知调度程序 | 否 | 否 | |
NUMA 感知调度程序 | 否 | 否 | |
NUMA 感知调度程序 | 否 | 否 | |
NUMA 感知调度程序 | 否 | 否 | |
NUMA 感知调度程序 | 否 | 否 | |
NUMA 感知调度程序 | 否 | 否 |
3.3.4.7. 存储引用 CR 复制链接链接已复制到粘贴板!
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
外部 ODF 配置 | 否 | 否 | |
外部 ODF 配置 | 否 | 否 | |
外部 ODF 配置 | 否 | 否 | |
外部 ODF 配置 | 否 | 否 | |
外部 ODF 配置 | 否 | 否 |
3.3.4.8. YAML 参考 复制链接链接已复制到粘贴板!
3.3.4.8.1. 网络引用 YAML 复制链接链接已复制到粘贴板!
Network.yaml
networkAttachmentDefinition.yaml
addr-pool.yaml
bfd-profile.yaml
bgp-advr.yaml
bgp-peer.yaml
community.yaml
metallb.yaml
metallbNS.yaml
metallbOperGroup.yaml
metallbSubscription.yaml
mc_rootless_pods_selinux.yaml
NMState.yaml
apiVersion: nmstate.io/v1 kind: NMState metadata: name: nmstate spec: {}
apiVersion: nmstate.io/v1
kind: NMState
metadata:
name: nmstate
spec: {}
NMStateNS.yaml
NMStateOperGroup.yaml
NMStateSubscription.yaml
sriovNetwork.yaml
sriovNetworkNodePolicy.yaml
SriovOperatorConfig.yaml
SriovSubscription.yaml
SriovSubscriptionNS.yaml
SriovSubscriptionOperGroup.yaml
3.3.4.8.2. 节点配置参考 YAML 复制链接链接已复制到粘贴板!
control-plane-load-kernel-modules.yaml
sctp_module_mc.yaml
worker-load-kernel-modules.yaml
mount_namespace_config_master.yaml
mount_namespace_config_worker.yaml
kdump-master.yaml
kdump-worker.yaml
3.3.4.8.3. 其他引用 YAML 复制链接链接已复制到粘贴板!
ClusterLogForwarder.yaml
ClusterLogNS.yaml
ClusterLogOperGroup.yaml
ClusterLogServiceAccount.yaml
ClusterLogServiceAccountAuditBinding.yaml
ClusterLogServiceAccountInfrastructureBinding.yaml
ClusterLogSubscription.yaml
catalog-source.yaml
icsp.yaml
operator-hub.yaml
monitoring-config-cm.yaml
PerformanceProfile.yaml
3.3.4.8.4. 资源调优参考 YAML 复制链接链接已复制到粘贴板!
control-plane-system-reserved.yaml
3.3.4.8.5. 调度引用 YAML 复制链接链接已复制到粘贴板!
nrop.yaml
NROPSubscription.yaml
NROPSubscriptionNS.yaml
NROPSubscriptionOperGroup.yaml
sched.yaml
Scheduler.yaml
3.3.4.8.6. 存储引用 YAML 复制链接链接已复制到粘贴板!
01-rook-ceph-external-cluster-details.secret.yaml
02-ocs-external-storagecluster.yaml
odfNS.yaml
odfOperGroup.yaml
odfSubscription.yaml
3.3.5. 电信核心参考配置软件规格 复制链接链接已复制到粘贴板!
以下信息描述了电信核心参考设计规格(RDS)验证的软件版本。
3.3.5.1. 电信核心参考配置软件规格 复制链接链接已复制到粘贴板!
Red Hatlecommunications core 4.17 解决方案已使用 OpenShift Container Platform 集群的以下红帽软件产品进行验证。
组件 | 软件版本 |
---|---|
Cluster Logging Operator | 6.0 |
OpenShift Data Foundation | 4.17 |
SR-IOV Operator | 4.17 |
MetalLB | 4.17 |
NMState Operator | 4.17 |
NUMA 感知调度程序 | 4.17 |