2.3. 电信核心参考设计规格
2.3.1. Telco RAN DU 4.16 参考设计概述
电信核心参考设计规格(RDS)配置在商业硬件上运行的 OpenShift Container Platform 集群,以托管电信核心工作负载。
2.3.2. 电信核心 4.16 使用模型概述
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。
2.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 实现和配置超出此规格的范围。
2.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 分区和性能调整"子部分。
2.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 中运行。
2.3.3. 电信核心参考设计组件
以下小节描述了用于配置和部署集群来运行电信核心工作负载的各种 OpenShift Container Platform 组件和配置。
2.3.3.1. CPU 分区和性能调整
- 这个版本中的新内容
- 在本发行版本中,OpenShift Container Platform 部署默认使用 Control Groups 版本 2 (cgroup v2)。因此,集群中的性能配置集将 cgroup v2 用于底层资源管理层。
- 描述
-
CPU 分区允许将敏感工作负载与通用目的、辅助进程、中断和驱动程序工作队列分离,以实现更高的性能和延迟。分配给这些辅助进程的 CPU 在以下部分中称为
reserved
。在超线程系统中,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"
当使用
PerformanceProfile.workloadHints.perPodPowerManagement
启用每个 pod 电源管理时,如果保证 QoS pod 需要完全使用 CPU,则必须将以下注解附加到 pod:cpu-c-states.crio.io: "disable" cpu-freq-governor.crio.io: "performance"
- 工程考虑
-
所需的最少保留容量(
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。
-
所需的最少保留容量(
2.3.3.2. Service Mesh
- 描述
- 电信核心 CNF 通常需要服务网格实施。所需的特定功能和性能取决于应用程序。服务网格实施和配置选择超出了本文档的范围。服务网格对集群资源利用率和性能的影响(包括 pod 网络中引入的额外延迟)必须在整个解决方案工程中考虑。
2.3.3.3. 网络
OpenShift Container Platform 网络是一个功能生态系统、插件和高级网络功能,它使用高级网络相关功能来扩展 Kubernetes 网络,集群需要为其一个或多个混合集群管理网络流量。
其他资源
2.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 出口流量由内核路由表使用
2.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) 配置集中的参数值应保持接近默认值。较短的值可能会导致假的负值并影响性能。
2.3.3.3.3. SR-IOV
- 这个版本中的新内容
-
在这个版本中,您可以使用 SR-IOV Network Operator 配置 QinQ (802.1ad 和 802.1q)标记。QinQ 标记通过启用内部和外部 VLAN 标签来提供高效的流量管理。外部 VLAN 标记是硬件加速,从而提高网络性能。此更新会扩展到 SR-IOV Network Operator 本身。现在,您可以使用
nmstate
在外部管理的 VF 上配置 QinQ。QinQ 支持因不同的 NIC 而异。有关特定 NIC 模型的已知限制的完整列表,请参阅官方文档。 - 在这个版本中,您可以将 SR-IOV Network Operator 配置为在网络策略更新过程中并行排空节点,从而显著加快设置过程。这会实现显著的时间节省,特别是对于之前需要几小时甚至几天完成的大型集群部署。
-
在这个版本中,您可以使用 SR-IOV Network Operator 配置 QinQ (802.1ad 和 802.1q)标记。QinQ 标记通过启用内部和外部 VLAN 标签来提供高效的流量管理。外部 VLAN 标记是硬件加速,从而提高网络性能。此更新会扩展到 SR-IOV Network Operator 本身。现在,您可以使用
- 描述
- SR-IOV 允许将物理网络接口(PF)划分为多个虚拟功能(VF)。然后 VF 可以分配给多个 pod,以实现更高的吞吐量性能,同时使 pod 保持隔离。SR-IOV Network Operator 置备并管理 SR-IOV CNI、网络设备插件和 SR-IOV 堆栈的其他组件。
- 限制和要求
- 支持的网络接口控制器在 支持的设备中列出
- BIOS 中的 SR-IOV 和 IOMMU 启用 :SR-IOV Network Operator 会在内核命令行中自动启用 IOMMU。
- SR-IOV VF 不会从 PF 接收链路状态更新。如果需要链接检测,必须在协议级别进行。
-
MultiNetworkPolicy
CR 只能应用到netdevice
网络。这是因为,实施使用iptables
工具,它无法管理vfio
接口。
- 工程考虑
-
vfio
模式中的 SR-IOV 接口通常用于为需要高吞吐量或低延迟的应用程序启用额外的二级网络。 -
如果您从部署中排除
SriovOperatorConfig
CR,则不会自动创建 CR。
-
2.3.3.3.4. NMState Operator
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
- NMState Operator 提供了一个 Kubernetes API,用于在集群节点间执行网络配置。它在二级接口上启用网络接口配置、静态 IP 和 DNS、VLAN、中继、绑定、静态路由、MTU 并启用混杂模式。集群节点定期向 API 服务器报告每个节点的网络接口状态。
- 限制和要求
- Not applicable
- 工程考虑
-
初始网络配置是使用安装 CR 中的
NMStateConfig
内容应用。NMState Operator 仅在网络更新需要时才使用。 -
当 SR-IOV 虚拟功能用于主机网络时,使用
NodeNetworkConfigurationPolicy
的 NMState Operator 用于配置这些 VF 接口,如 VLAN 和 MTU。
-
初始网络配置是使用安装 CR 中的
2.3.3.4. 日志记录
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
- Cluster Logging Operator 启用收集并提供与节点相关的日志,以进行远程归档和分析。参考配置使用 Kafka 将审计和基础架构日志发送到远程存档。
- 限制和要求
- Not applicable
- 工程考虑
- 集群 CPU 使用的影响取决于生成的日志的数量或大小以及配置的日志过滤量。
- 参考配置不包括应用程序日志的发布。将应用程序日志包含在配置中,需要评估应用程序日志记录率以及分配给保留集合的足够额外 CPU 资源。
其他资源
2.3.3.5. 电源管理
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
Performance Profile 可以用来以高电源、低电源或混合模式配置集群。电源模式的选择取决于集群中运行的工作负载的特征,特别是对延迟敏感度。使用每个 pod 电源管理 C-states 功能,为低延迟 pod 配置最大延迟。
如需更多信息,请参阅为节点配置节能。
- 限制和要求
- 电源配置依赖于适当的 BIOS 配置,例如启用 C-states 和 P-states。配置因硬件供应商而异。
- 工程考虑
-
延迟 :为了确保对延迟敏感的工作负载满足其要求,您需要一个高电源配置或每个 pod 电源管理配置。每个 pod 电源管理仅适用于带有专用固定 CPU 的
Guaranteed
QoS Pod。
-
延迟 :为了确保对延迟敏感的工作负载满足其要求,您需要一个高电源配置或每个 pod 电源管理配置。每个 pod 电源管理仅适用于带有专用固定 CPU 的
2.3.3.6. Storage
- 概述
云原生存储服务可由多种解决方案提供,包括来自红帽或第三方的 OpenShift Data Foundation。
OpenShift Data Foundation 是基于 Ceph 的软件定义的存储解决方案。它提供块存储、文件系统存储和内部对象存储,可针对持久性和非持久性数据要求动态置备。电信核心应用程序需要持久性存储。
注意所有存储数据可能无法加密。要降低风险,请将存储网络与其他集群网络隔离。存储网络不能从其他集群网络访问或路由。只有直接附加到存储网络的节点才应允许访问它。
2.3.3.6.1. OpenShift Data Foundation
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
- Red Hat OpenShift Data Foundation 是容器的软件定义的存储服务。对于 Telco 核心集群,存储支持由外部运行到应用程序工作负载集群的 OpenShift Data Foundation 存储服务提供。OpenShift Data Foundation 支持使用二级 CNI 网络来分离存储流量。
- 限制和要求
- 在 IPv4/IPv6 双栈网络环境中,OpenShift Data Foundation 使用 IPv4 地址。如需更多信息,请参阅使用 IPv4 支持 OpenShift Data Foundation 的 OpenShift 双堆栈。
- 工程考虑
- OpenShift Data Foundation 网络流量应该与专用网络上的其他流量隔离,例如使用 VLAN 隔离。
2.3.3.6.2. 其他存储
其他存储解决方案可用于为核心集群提供持久性存储。这些解决方案的配置和集成超出了电信核心 RDS 的范围。将存储解决方案集成至核心集群必须包含正确的大小和性能分析,以确保存储满足整体性能和资源利用率要求。
2.3.3.7. 监控
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
Cluster Monitoring Operator (CMO) 默认包括在所有 OpenShift 集群中,并为平台组件和可选用户项目提供监控(指标、仪表板和警报)。
配置监控 Operator 允许自定义,包括:
- 默认保留周期
- 自定义警报规则
pod CPU 和内存指标的默认处理基于上游 Kubernetes
cAdvisor
,并权衡优先处理过时的数据,而不是指标准确性。这会导致 spiky 数据,这些数据将通过用户指定的阈值创建假的警报触发。OpenShift 支持 opt-in 专用服务监控功能,它创建了一组不会受到 spiky 行为的另一组 pod CPU 和内存指标。如需更多信息,请参阅此解决方案指南。除了默认配置外,还应该为电信核心集群配置以下指标:
- 用户工作负载的 Pod CPU 和内存指标和警报
- 限制和要求
- 监控配置必须启用专用服务监控功能,以准确表示 pod 指标
- 工程考虑
- Prometheus 保留周期由用户指定。使用的值是根据 CPU 和存储资源维护集群中的历史数据的操作要求之间的权衡。保留周期较长,增加存储需求,并需要额外的 CPU 来管理数据的索引。
其他资源
2.3.3.8. 调度
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
- 调度程序是一个集群范围的组件,负责为给定工作负载选择正确的节点。它是平台的核心部分,不需要在常见部署场景中进行任何特定的配置。但是,在以下部分中描述了一些特定的用例。可以通过 NUMA Resources Operator 启用 NUMA 感知调度。如需更多信息,请参阅调度 NUMA 感知工作负载。
- 限制和要求
默认调度程序不了解工作负载的 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 分区和性能调整。
-
您可以通过在
SriovNetworkNodePolicy
CR 中使用excludeTopology
字段,将 SR-IOV 虚拟功能 NUMA 关联性配置为在调度期间被忽略。
其他资源
2.3.3.9. 安装
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
可以使用基于代理的安装程序(ABI)安装电信核心集群。此方法允许用户在裸机服务器上安装 OpenShift Container Platform,而无需额外的服务器或虚拟机来管理安装。ABI 安装程序可以在任何系统上运行,例如笔记本电脑来生成 ISO 安装镜像。此 ISO 用作集群 supervisor 节点的安装介质。可使用任何具有网络连接的系统到 supervisor 节点的 API 接口的 ABI 工具监控进度。
- 从声明性 CR 安装
- 不需要额外的服务器来支持安装
- 支持在断开连接的环境中安装
- 限制和要求
- 断开连接的安装需要一个可访问 registry,其中包含所有所需内容。
- 工程考虑
- 网络配置应该在安装过程中作为 NMState 配置应用到第 2 天配置,使用 NMState Operator。
2.3.3.10. 安全性
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
电信操作器是安全的考虑,需要针对多个攻击向量强化集群。在 OpenShift Container Platform 中,没有单一组件或功能负责保护集群。本节详细介绍了此规格中涵盖的使用模型的面向安全特性和配置。
- SecurityContextConstraints:所有工作负载 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" 部分。
- 限制和要求
Rootless DPDK pod 需要以下额外的配置步骤:
-
使用
container_t
SELinux 上下文配置TAP 插件。 -
在主机上启用
container_use_devices
SELinux 布尔值。
-
使用
- 工程考虑
-
对于无根 DPDK pod 支持,必须在主机上启用 SELinux 布尔值
container_use_devices
,才能创建TAP 设备。这引入了一个安全风险,可在短期内使用。将探索其他解决方案。
-
对于无根 DPDK pod 支持,必须在主机上启用 SELinux 布尔值
其他资源
2.3.3.11. 可扩展性
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
集群将扩展到 limits 和 requirements 部分中列出的大小。
使用模型部分描述了工作负载的扩展。
- 限制和要求
- 集群扩展到至少 120 个节点
- 工程考虑
- Not applicable
2.3.3.12. 其他配置
2.3.3.12.1. 断开连接的环境
- 描述
电信核心集群预期会在网络中安装,而无需直接访问互联网。安装、配置和 Operator 所需的所有容器镜像都必须在断开连接的 registry 中提供。这包括 OpenShift Container Platform 镜像、第 2 天 Operator Lifecycle Manager (OLM) Operator 镜像和应用程序工作负载镜像。使用断开连接的环境提供多个优点,例如:
- 为安全限制对集群的访问
- curated content: registry 基于集群的策展和批准的更新进行填充
- 限制和要求
- 所有自定义 CatalogSource 都需要一个唯一名称。不要重复使用默认目录名称。
- 必须将有效的时间源配置为集群安装的一部分。
- 工程考虑
- Not applicable
其他资源
2.3.3.12.2. 内核
- 这个版本中的新内容
- 这个版本没有参考设计更新
- 描述
用户可以使用
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
2.3.4. 电信核心 4.16 参考配置 CR
使用以下自定义资源(CR)来使用电信核心配置集配置和部署 OpenShift Container Platform 集群。使用 CR 组成所有特定使用模型中使用的通用基准,除非另有说明。
2.3.4.1. 提取电信核心引用设计 CR
您可以从 telco-core-rds-rhel9
容器镜像中提取电信核心配置集的完整自定义资源(CR)集合。容器镜像具有电信核心配置集所需的 CR 和可选 CR。
先决条件
-
已安装
podman
。
流程
运行以下命令,从
lecommunications-core-rds-rhel9
容器镜像中提取内容:$ mkdir -p ./out
$ podman run -it registry.redhat.io/openshift4/telco-core-rds-rhel9:v4.16 | base64 -d | tar xv -C out
验证
out
目录具有以下文件夹结构:您可以查看out/telco-core-rds/
目录中的电信核心 CR。输出示例
out/ └── telco-core-rds ├── configuration │ └── reference-crs │ ├── optional │ │ ├── logging │ │ ├── networking │ │ │ └── multus │ │ │ └── tap_cni │ │ ├── other │ │ └── tuning │ └── required │ ├── networking │ │ ├── metallb │ │ ├── multinetworkpolicy │ │ └── sriov │ ├── other │ ├── performance │ ├── scheduling │ └── storage │ └── odf-external └── install
2.3.4.2. Resource Tuning 参考 CR
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
系统保留容量 | 是 | 否 | |
系统保留容量 | 是 | 否 |
2.3.4.3. 存储引用 CR
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
外部 ODF 配置 | 否 | 否 | |
外部 ODF 配置 | 否 | 否 | |
外部 ODF 配置 | 否 | 否 | |
外部 ODF 配置 | 否 | 否 | |
外部 ODF 配置 | 否 | 否 |
2.3.4.4. 网络引用 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 | 否 | 否 |
2.3.4.5. 调度引用 CR
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
NUMA 感知调度程序 | 否 | 否 | |
NUMA 感知调度程序 | 否 | 否 | |
NUMA 感知调度程序 | 否 | 否 | |
NUMA 感知调度程序 | 否 | 否 | |
NUMA 感知调度程序 | 否 | 否 | |
NUMA 感知调度程序 | 否 | 是 |
2.3.4.6. 其他引用 CR
组件 | 参考 CR | 选填 | 这个版本中的新内容 |
---|---|---|---|
其他内核模块 | 是 | 否 | |
其他内核模块 | 是 | 否 | |
其他内核模块 | 是 | 否 | |
集群日志记录 | 否 | 否 | |
集群日志记录 | 否 | 否 | |
集群日志记录 | 否 | 否 | |
集群日志记录 | 否 | 否 | |
集群日志记录 | 否 | 否 | |
断开连接的配置 | 否 | 否 | |
断开连接的配置 | 否 | 否 | |
断开连接的配置 | 否 | 否 | |
监控和可观察性 | 是 | 否 | |
电源管理 | 否 | 否 |
2.3.4.7. YAML 参考
2.3.4.7.1. Resource Tuning 参考 YAML
control-plane-system-reserved.yaml
# optional # count: 1 apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: autosizing-master spec: autoSizingReserved: true machineConfigPoolSelector: matchLabels: pools.operator.machineconfiguration.openshift.io/master: ""
pid-limits-cr.yaml
# optional # count: 1 apiVersion: machineconfiguration.openshift.io/v1 kind: ContainerRuntimeConfig metadata: name: 99-change-pidslimit-custom spec: machineConfigPoolSelector: matchLabels: # Set to appropriate MCP pools.operator.machineconfiguration.openshift.io/master: "" containerRuntimeConfig: pidsLimit: $pidsLimit # Example: #pidsLimit: 4096
2.3.4.7.2. 存储引用 YAML
01-rook-ceph-external-cluster-details.secret.yaml
# required # count: 1 --- apiVersion: v1 kind: Secret metadata: name: rook-ceph-external-cluster-details namespace: openshift-storage type: Opaque data: # encoded content has been made generic external_cluster_details: eyJuYW1lIjoicm9vay1jZXBoLW1vbi1lbmRwb2ludHMiLCJraW5kIjoiQ29uZmlnTWFwIiwiZGF0YSI6eyJkYXRhIjoiY2VwaHVzYTE9MS4yLjMuNDo2Nzg5IiwibWF4TW9uSWQiOiIwIiwibWFwcGluZyI6Int9In19LHsibmFtZSI6InJvb2stY2VwaC1tb24iLCJraW5kIjoiU2VjcmV0IiwiZGF0YSI6eyJhZG1pbi1zZWNyZXQiOiJhZG1pbi1zZWNyZXQiLCJmc2lkIjoiMTExMTExMTEtMTExMS0xMTExLTExMTEtMTExMTExMTExMTExIiwibW9uLXNlY3JldCI6Im1vbi1zZWNyZXQifX0seyJuYW1lIjoicm9vay1jZXBoLW9wZXJhdG9yLWNyZWRzIiwia2luZCI6IlNlY3JldCIsImRhdGEiOnsidXNlcklEIjoiY2xpZW50LmhlYWx0aGNoZWNrZXIiLCJ1c2VyS2V5IjoiYzJWamNtVjAifX0seyJuYW1lIjoibW9uaXRvcmluZy1lbmRwb2ludCIsImtpbmQiOiJDZXBoQ2x1c3RlciIsImRhdGEiOnsiTW9uaXRvcmluZ0VuZHBvaW50IjoiMS4yLjMuNCwxLjIuMy4zLDEuMi4zLjIiLCJNb25pdG9yaW5nUG9ydCI6IjkyODMifX0seyJuYW1lIjoiY2VwaC1yYmQiLCJraW5kIjoiU3RvcmFnZUNsYXNzIiwiZGF0YSI6eyJwb29sIjoib2RmX3Bvb2wifX0seyJuYW1lIjoicm9vay1jc2ktcmJkLW5vZGUiLCJraW5kIjoiU2VjcmV0IiwiZGF0YSI6eyJ1c2VySUQiOiJjc2ktcmJkLW5vZGUiLCJ1c2VyS2V5IjoiIn19LHsibmFtZSI6InJvb2stY3NpLXJiZC1wcm92aXNpb25lciIsImtpbmQiOiJTZWNyZXQiLCJkYXRhIjp7InVzZXJJRCI6ImNzaS1yYmQtcHJvdmlzaW9uZXIiLCJ1c2VyS2V5IjoiYzJWamNtVjAifX0seyJuYW1lIjoicm9vay1jc2ktY2VwaGZzLXByb3Zpc2lvbmVyIiwia2luZCI6IlNlY3JldCIsImRhdGEiOnsiYWRtaW5JRCI6ImNzaS1jZXBoZnMtcHJvdmlzaW9uZXIiLCJhZG1pbktleSI6IiJ9fSx7Im5hbWUiOiJyb29rLWNzaS1jZXBoZnMtbm9kZSIsImtpbmQiOiJTZWNyZXQiLCJkYXRhIjp7ImFkbWluSUQiOiJjc2ktY2VwaGZzLW5vZGUiLCJhZG1pbktleSI6ImMyVmpjbVYwIn19LHsibmFtZSI6ImNlcGhmcyIsImtpbmQiOiJTdG9yYWdlQ2xhc3MiLCJkYXRhIjp7ImZzTmFtZSI6ImNlcGhmcyIsInBvb2wiOiJtYW5pbGFfZGF0YSJ9fQ==
02-ocs-external-storagecluster.yaml
# required # count: 1 --- apiVersion: ocs.openshift.io/v1 kind: StorageCluster metadata: name: ocs-external-storagecluster namespace: openshift-storage spec: externalStorage: enable: true labelSelector: {} status: phase: Ready
odfNS.yaml
# required: yes # count: 1 --- apiVersion: v1 kind: Namespace metadata: name: openshift-storage annotations: workload.openshift.io/allowed: management labels: openshift.io/cluster-monitoring: "true"
odfOperGroup.yaml
# required: yes # count: 1 --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-storage-operatorgroup namespace: openshift-storage spec: targetNamespaces: - openshift-storage
odfSubscription.yaml
# required: yes # count: 1 --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: odf-operator namespace: openshift-storage spec: channel: "stable-4.14" name: odf-operator source: redhat-operators-disconnected sourceNamespace: openshift-marketplace installPlanApproval: Automatic status: state: AtLatestKnown
2.3.4.7.3. 网络引用 YAML
Network.yaml
# required # count: 1 apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: defaultNetwork: ovnKubernetesConfig: gatewayConfig: routingViaHost: true # additional networks are optional and may alternatively be specified using NetworkAttachmentDefinition CRs additionalNetworks: [$additionalNetworks] # eg #- name: add-net-1 # namespace: app-ns-1 # rawCNIConfig: '{ "cniVersion": "0.3.1", "name": "add-net-1", "plugins": [{"type": "macvlan", "master": "bond1", "ipam": {}}] }' # type: Raw #- name: add-net-2 # namespace: app-ns-1 # rawCNIConfig: '{ "cniVersion": "0.4.0", "name": "add-net-2", "plugins": [ {"type": "macvlan", "master": "bond1", "mode": "private" },{ "type": "tuning", "name": "tuning-arp" }] }' # type: Raw # Enable to use MultiNetworkPolicy CRs useMultiNetworkPolicy: true
networkAttachmentDefinition.yaml
# optional # copies: 0-N apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: $name namespace: $ns spec: nodeSelector: kubernetes.io/hostname: $nodeName config: $config #eg #config: '{ # "cniVersion": "0.3.1", # "name": "external-169", # "type": "vlan", # "master": "ens8f0", # "mode": "bridge", # "vlanid": 169, # "ipam": { # "type": "static", # } #}'
addr-pool.yaml
# required # count: 1-N apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: $name # eg addresspool3 namespace: metallb-system annotations: metallb.universe.tf/address-pool: $name # eg addresspool3 spec: ############## # Expected variation in this configuration addresses: [$pools] #- 3.3.3.0/24 autoAssign: true ##############
bfd-profile.yaml
# required # count: 1-N apiVersion: metallb.io/v1beta1 kind: BFDProfile metadata: name: bfdprofile namespace: metallb-system spec: ################ # These values may vary. Recommended values are included as default receiveInterval: 150 # default 300ms transmitInterval: 150 # default 300ms #echoInterval: 300 # default 50ms detectMultiplier: 10 # default 3 echoMode: true passiveMode: true minimumTtl: 5 # default 254 # ################
bgp-advr.yaml
# required # count: 1-N apiVersion: metallb.io/v1beta1 kind: BGPAdvertisement metadata: name: $name # eg bgpadvertisement-1 namespace: metallb-system spec: ipAddressPools: [$pool] # eg: # - addresspool3 peers: [$peers] # eg: # - peer-one # communities: [$communities] # Note correlation with address pool, or Community # eg: # - bgpcommunity # - 65535:65282 aggregationLength: 32 aggregationLengthV6: 128 localPref: 100
bgp-peer.yaml
# required # count: 1-N apiVersion: metallb.io/v1beta2 kind: BGPPeer metadata: name: $name namespace: metallb-system spec: peerAddress: $ip # eg 192.168.1.2 peerASN: $peerasn # eg 64501 myASN: $myasn # eg 64500 routerID: $id # eg 10.10.10.10 bfdProfile: bfdprofile passwordSecret: {}
community.yaml
--- apiVersion: metallb.io/v1beta1 kind: Community metadata: name: bgpcommunity namespace: metallb-system spec: communities: [$comm]
metallb.yaml
# required # count: 1 apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system spec: nodeSelector: node-role.kubernetes.io/worker: ""
metallbNS.yaml
# required: yes # count: 1 --- apiVersion: v1 kind: Namespace metadata: name: metallb-system annotations: workload.openshift.io/allowed: management labels: openshift.io/cluster-monitoring: "true"
metallbOperGroup.yaml
# required: yes # count: 1 --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: metallb-operator namespace: metallb-system
metallbSubscription.yaml
# required: yes # count: 1 --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: metallb-operator-sub namespace: metallb-system spec: channel: stable name: metallb-operator source: redhat-operators-disconnected sourceNamespace: openshift-marketplace installPlanApproval: Automatic status: state: AtLatestKnown
mc_rootless_pods_selinux.yaml
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 99-worker-setsebool spec: config: ignition: version: 3.2.0 systemd: units: - contents: | [Unit] Description=Set SELinux boolean for tap cni plugin Before=kubelet.service [Service] Type=oneshot ExecStart=/sbin/setsebool container_use_devices=on RemainAfterExit=true [Install] WantedBy=multi-user.target graphical.target enabled: true name: setsebool.service
NMState.yaml
apiVersion: nmstate.io/v1 kind: NMState metadata: name: nmstate spec: {}
NMStateNS.yaml
apiVersion: v1 kind: Namespace metadata: name: openshift-nmstate annotations: workload.openshift.io/allowed: management
NMStateOperGroup.yaml
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-nmstate namespace: openshift-nmstate spec: targetNamespaces: - openshift-nmstate
NMStateSubscription.yaml
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: kubernetes-nmstate-operator namespace: openshift-nmstate spec: channel: "stable" name: kubernetes-nmstate-operator source: redhat-operators-disconnected sourceNamespace: openshift-marketplace installPlanApproval: Automatic status: state: AtLatestKnown
sriovNetwork.yaml
# optional (though expected for all) # count: 0-N apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: $name # eg sriov-network-abcd namespace: openshift-sriov-network-operator spec: capabilities: "$capabilities" # eg '{"mac": true, "ips": true}' ipam: "$ipam" # eg '{ "type": "host-local", "subnet": "10.3.38.0/24" }' networkNamespace: $nns # eg cni-test resourceName: $resource # eg resourceTest
sriovNetworkNodePolicy.yaml
# optional (though expected in all deployments) # count: 0-N apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: $name namespace: openshift-sriov-network-operator spec: {} # $spec # eg #deviceType: netdevice #nicSelector: # deviceID: "1593" # pfNames: # - ens8f0np0#0-9 # rootDevices: # - 0000:d8:00.0 # vendor: "8086" #nodeSelector: # kubernetes.io/hostname: host.sample.lab #numVfs: 20 #priority: 99 #excludeTopology: true #resourceName: resourceNameABCD
SriovOperatorConfig.yaml
# required # count: 1 --- apiVersion: sriovnetwork.openshift.io/v1 kind: SriovOperatorConfig metadata: name: default namespace: openshift-sriov-network-operator spec: configDaemonNodeSelector: node-role.kubernetes.io/worker: "" enableInjector: true enableOperatorWebhook: true disableDrain: false logLevel: 2
SriovSubscription.yaml
# required: yes # count: 1 apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: sriov-network-operator-subscription namespace: openshift-sriov-network-operator spec: channel: "stable" name: sriov-network-operator source: redhat-operators-disconnected sourceNamespace: openshift-marketplace installPlanApproval: Automatic status: state: AtLatestKnown
SriovSubscriptionNS.yaml
# required: yes # count: 1 apiVersion: v1 kind: Namespace metadata: name: openshift-sriov-network-operator annotations: workload.openshift.io/allowed: management
SriovSubscriptionOperGroup.yaml
# required: yes # count: 1 apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: sriov-network-operators namespace: openshift-sriov-network-operator spec: targetNamespaces: - openshift-sriov-network-operator
2.3.4.7.4. 调度引用 YAML
nrop.yaml
# Optional # count: 1 apiVersion: nodetopology.openshift.io/v1 kind: NUMAResourcesOperator metadata: name: numaresourcesoperator spec: nodeGroups: - config: # Periodic is the default setting infoRefreshMode: Periodic machineConfigPoolSelector: matchLabels: # This label must match the pool(s) you want to run NUMA-aligned workloads pools.operator.machineconfiguration.openshift.io/worker: ""
NROPSubscription.yaml
# required # count: 1 apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: numaresources-operator namespace: openshift-numaresources spec: channel: "4.14" name: numaresources-operator source: redhat-operators-disconnected sourceNamespace: openshift-marketplace
NROPSubscriptionNS.yaml
# required: yes # count: 1 apiVersion: v1 kind: Namespace metadata: name: openshift-numaresources annotations: workload.openshift.io/allowed: management
NROPSubscriptionOperGroup.yaml
# required: yes # count: 1 apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: numaresources-operator namespace: openshift-numaresources spec: targetNamespaces: - openshift-numaresources
sched.yaml
# Optional # count: 1 apiVersion: nodetopology.openshift.io/v1 kind: NUMAResourcesScheduler metadata: name: numaresourcesscheduler spec: #cacheResyncPeriod: "0" # Image spec should be the latest for the release imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-rhel9:v4.14.0" #logLevel: "Trace" schedulerName: topo-aware-scheduler
Scheduler.yaml
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: name: cluster spec: # non-schedulable control plane is the default. This ensures # compliance. mastersSchedulable: false policy: name: ""
2.3.4.7.5. 其他引用 YAML
control-plane-load-kernel-modules.yaml
# optional # count: 1 apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: 40-load-kernel-modules-control-plane spec: config: # Release info found in https://github.com/coreos/butane/releases ignition: version: 3.2.0 storage: files: - contents: source: data:, mode: 420 overwrite: true path: /etc/modprobe.d/kernel-blacklist.conf - contents: source: data:text/plain;charset=utf-8;base64,aXBfZ3JlCmlwNl90YWJsZXMKaXA2dF9SRUpFQ1QKaXA2dGFibGVfZmlsdGVyCmlwNnRhYmxlX21hbmdsZQppcHRhYmxlX2ZpbHRlcgppcHRhYmxlX21hbmdsZQppcHRhYmxlX25hdAp4dF9tdWx0aXBvcnQKeHRfb3duZXIKeHRfUkVESVJFQ1QKeHRfc3RhdGlzdGljCnh0X1RDUE1TUwo= mode: 420 overwrite: true path: /etc/modules-load.d/kernel-load.conf
sctp_module_mc.yaml
# optional # count: 1 apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: load-sctp-module spec: config: ignition: version: 2.2.0 storage: files: - contents: source: data:, verification: {} filesystem: root mode: 420 path: /etc/modprobe.d/sctp-blacklist.conf - contents: source: data:text/plain;charset=utf-8;base64,c2N0cA== filesystem: root mode: 420 path: /etc/modules-load.d/sctp-load.conf
worker-load-kernel-modules.yaml
# optional # count: 1 apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 40-load-kernel-modules-worker spec: config: # Release info found in https://github.com/coreos/butane/releases ignition: version: 3.2.0 storage: files: - contents: source: data:, mode: 420 overwrite: true path: /etc/modprobe.d/kernel-blacklist.conf - contents: source: data:text/plain;charset=utf-8;base64,aXBfZ3JlCmlwNl90YWJsZXMKaXA2dF9SRUpFQ1QKaXA2dGFibGVfZmlsdGVyCmlwNnRhYmxlX21hbmdsZQppcHRhYmxlX2ZpbHRlcgppcHRhYmxlX21hbmdsZQppcHRhYmxlX25hdAp4dF9tdWx0aXBvcnQKeHRfb3duZXIKeHRfUkVESVJFQ1QKeHRfc3RhdGlzdGljCnh0X1RDUE1TUwo= mode: 420 overwrite: true path: /etc/modules-load.d/kernel-load.conf
ClusterLogForwarder.yaml
# required # count: 1 apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputs: - type: "kafka" name: kafka-open url: tcp://10.11.12.13:9092/test pipelines: - inputRefs: - infrastructure #- application - audit labels: label1: test1 label2: test2 label3: test3 label4: test4 label5: test5 name: all-to-default outputRefs: - kafka-open
ClusterLogging.yaml
# required # count: 1 apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: collection: type: vector managementState: Managed
ClusterLogNS.yaml
--- apiVersion: v1 kind: Namespace metadata: name: openshift-logging annotations: workload.openshift.io/allowed: management
ClusterLogOperGroup.yaml
--- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: cluster-logging namespace: openshift-logging spec: targetNamespaces: - openshift-logging
ClusterLogSubscription.yaml
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: cluster-logging namespace: openshift-logging spec: channel: "stable" name: cluster-logging source: redhat-operators-disconnected sourceNamespace: openshift-marketplace installPlanApproval: Automatic status: state: AtLatestKnown
catalog-source.yaml
# required # count: 1..N apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: redhat-operators-disconnected namespace: openshift-marketplace spec: displayName: Red Hat Disconnected Operators Catalog image: $imageUrl publisher: Red Hat sourceType: grpc # updateStrategy: # registryPoll: # interval: 1h status: connectionState: lastObservedState: READY
icsp.yaml
# required # count: 1 apiVersion: operator.openshift.io/v1alpha1 kind: ImageContentSourcePolicy metadata: name: disconnected-internal-icsp spec: repositoryDigestMirrors: [] # - $mirrors
operator-hub.yaml
# required # count: 1 apiVersion: config.openshift.io/v1 kind: OperatorHub metadata: name: cluster spec: disableAllDefaultSources: true
monitoring-config-cm.yaml
# optional # count: 1 --- apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: retention: 15d volumeClaimTemplate: spec: storageClassName: ocs-external-storagecluster-ceph-rbd resources: requests: storage: 100Gi alertmanagerMain: volumeClaimTemplate: spec: storageClassName: ocs-external-storagecluster-ceph-rbd resources: requests: storage: 20Gi
PerformanceProfile.yaml
# required # count: 1 apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: $name annotations: # Some pods want the kernel stack to ignore IPv6 router Advertisement. kubeletconfig.experimental: | {"allowedUnsafeSysctls":["net.ipv6.conf.all.accept_ra"]} spec: cpu: # node0 CPUs: 0-17,36-53 # node1 CPUs: 18-34,54-71 # siblings: (0,36), (1,37)... # we want to reserve the first Core of each NUMA socket # # no CPU left behind! all-cpus == isolated + reserved isolated: $isolated # eg 1-17,19-35,37-53,55-71 reserved: $reserved # eg 0,18,36,54 # Guaranteed QoS pods will disable IRQ balancing for cores allocated to the pod. # default value of globallyDisableIrqLoadBalancing is false globallyDisableIrqLoadBalancing: false hugepages: defaultHugepagesSize: 1G pages: # 32GB per numa node - count: $count # eg 64 size: 1G machineConfigPoolSelector: # For SNO: machineconfiguration.openshift.io/role: 'master' pools.operator.machineconfiguration.openshift.io/worker: '' nodeSelector: # For SNO: node-role.kubernetes.io/master: "" node-role.kubernetes.io/worker: "" workloadHints: realTime: false highPowerConsumption: false perPodPowerManagement: true realTimeKernel: enabled: false numa: # All guaranteed QoS containers get resources from a single NUMA node topologyPolicy: "single-numa-node" net: userLevelNetworking: false
2.3.5. 电信核心参考配置软件规格
以下信息描述了电信核心参考设计规格(RDS)验证的软件版本。
2.3.5.1. 软件堆栈
以下软件版本用于验证电信核心参考设计规范:
组件 | 软件版本 |
---|---|
Cluster Logging Operator | 5.9.1 |
OpenShift Data Foundation | 4.16 |
SR-IOV Operator | 4.16 |
MetalLB | 4.16 |
NMState Operator | 4.16 |
NUMA 感知调度程序 | 4.16 |