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

3.8. 电信核心集群常见使用模型工程注意事项

  • 集群工作负载在"应用程序工作负载"中详细介绍。

  • Worker 节点应在以下任何 CPU 上运行：

    • 当 OpenShift Container Platform 支持时，Intel 3rd Generation Xeon (IceLake) CPU 或具有 silicon 安全漏洞(Spectre 和类似)缓解的 CPU 被关闭。当启用 Spectre 和类似的缓解方案时，S Skylake 和旧的 CPU 可能会出现 40% 的事务性能下降。
    • OpenShift Container Platform 支持 AMD EPYC Zen 4 CPU (Genoa、Bergamo) 或 AMD EPYC Zen 5 CPU (Turin)。
    • OpenShift Container Platform 支持时的 Intel Sierra Forest CPU。
    • 在 worker 节点上启用 IRQ 平衡。PerformanceProfile CR 将 globallyDisableIrqLoadBalancing 参数设置为 false 的值。保证的 QoS pod 被注解以确保隔离，如"CPU 分区和性能调优"中所述。

  • 所有集群节点应具有以下功能：

    • 启用超线程
    • 具有 x86_64 CPU 架构
    • 启用了普通（非实时）内核
    • 没有为工作负载分区配置

  • 电源管理和最大性能之间的平衡因集群中的机器配置池而异。以下配置应该与机器配置池组中的所有节点一致。

    • 集群扩展。如需更多信息，请参阅"可扩展性"。
    • 集群应该可以扩展到至少 120 个节点。
  • CPU 分区使用 PerformanceProfile CR 配置，并应用于每个 MachineConfigPool 的节点。如需了解更多注意事项，请参阅"CPU 分区和性能调整"。

  • OpenShift Container Platform 的 CPU 要求取决于配置的功能集和应用程序工作负载特征。对于根据 kube-burner node-density 测试创建的 3000 pod 的模拟工作负载配置的集群，会验证以下 CPU 要求：

    • control plane 和 worker 节点的最小保留 CPU 数量是每个 NUMA 节点 2 个 CPU (4 个超线程)。
    • 用于非 DPDK 网络流量的 NIC 应配置为在最多 32 RX/TX 队列中使用。

    • 具有大量 pod 或其他资源的节点可能需要额外的保留 CPU。剩余的 CPU 可用于用户工作负载。

      注意

      OpenShift Container Platform 配置、工作负载大小和工作负载特征的不同需要额外分析，以确定对 OpenShift 平台所需 CPU 数量的影响。

3.8.1. 应用程序工作负载
复制链接

在电信核心集群中运行的应用程序工作负载可包括高性能云原生网络功能(CNF)和传统的最佳 pod 工作负载。

保证因为性能或安全要求而需要专用或专用使用 CPU 的 pod 有保证的 QoS 调度可用。通常，使用 user plane 网络（如 DPDK）运行高性能或延迟敏感 CNF 的 pod 需要通过节点调整和保证 QoS 调度来独占使用专用的整个 CPU。在创建需要专用 CPU 的 pod 配置时，请注意超线程系统的潜在影响。当整个内核(2 超线程)必须分配给 pod 时，Pod 应该请求 2 个 CPU 的倍数。

运行不需要高吞吐量和低延迟网络的网络功能的 Pod 通常使用最佳或突发的 QoS pod 调度，且不需要专用或隔离的 CPU 内核。

工程考虑

使用以下信息来规划电信核心工作负载和集群资源：

  • 从 OpenShift Container Platform 4.19 开始，cgroup v1 不再被支持并已被删除。现在，所有工作负载必须与 cgroup v2 兼容。如需更多信息，请参阅 Red Hat OpenShift 工作负载上下文中的 Red Hat Enterprise Linux 9 更改。
  • CNF 应用程序应该符合 Kubernetes 的最新版本。

  • 根据您的应用程序需要，使用最佳数量和突发的 QoS pod。

    • 使用带有正确配置节点的 PerformanceProfile CR 中的保留或隔离 CPU 的保证 QoS pod。
    • 保证的 QoS Pod 必须包含完全隔离 CPU 的注解。
    • 最佳工作和突发 pod 无法保证专用 CPU 使用量。工作负载可能被其他工作负载、操作系统守护进程或内核任务抢占。

  • 使用 exec probe 静默，且仅在没有其他合适的选项时才使用

    • 如果 CNF 使用 CPU 固定，则不要使用 exec 探测。使用其他探测实施，如 httpGet 或 tcpSocket。
    • 当您需要使用 exec 探测时，限制 exec 探测频率和数量。exec 探测的最大数量必须保持在 10 以下，且频率不得小于 10 秒。
    • 您可以使用启动探测，因为它们不会在 steady-state 操作中使用大量资源。exec 探测的限制主要适用于存活度和就绪度探测。与其它探测类型相比，执行探测会导致管理内核 CPU 使用率高得多，因为它们需要进程分叉。
  • 使用预停止 hook 允许应用程序工作负载在 pod 中断预算前执行必要的操作，比如在升级或节点维护过程中。hook 使 pod 能够将状态保存到持久性存储，从服务卸载流量，或向其他 Pod 卸载流量。

3.8.2. 信号工作负载
复制链接

信号工作负载通常使用 SCTP、REST、gRPC 或类似的 TCP 或 UDP 协议。信号工作负载支持使用配置为 MACVLAN 或 SR-IOV 接口的辅助 multus CNI 支持每秒数以千计的事务(TPS)。这些工作负载可以在带有保证或突发 QoS 的 pod 中运行。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat