15.7. 为 infra 和应用程序容器限制 CPU
通用内务处理和工作负载任务使用 CPU 的方式可能会影响对延迟敏感的进程。默认情况下，容器运行时使用所有在线 CPU 一起运行所有容器，这可能导致上下文切换和延迟激增。对 CPU 进行分区可防止无状态进程通过相互分离来干扰对延迟敏感的进程。下表描述了在使用 Performance Addon Operator 调整节点后的进程如何在 CPU 上运行：
| 进程类型 | 详情 |
|---|---|
|
| 在除了运行低延迟工作负载外的任意 CPU 上运行 |
| 基础架构 pod | 在除了运行低延迟工作负载外的任意 CPU 上运行 |
| 中断 | 重定向至保留的 CPU（在 OpenShift Container Platform 4.6 及更新的版本中可选） |
| 内核进程 | 固定保留的 CPU |
| 对延迟敏感的工作负载 pod | 固定到隔离池中的特定专用 CPU |
| OS 进程/systemd 服务 | 固定保留的 CPU |
对于所有 QoS 进程类型（ Burstable、BestEffort 或 Guaranteed ）的 pod 的 pod 的可分配容量等于隔离池的容量。保留池的容量已从节点的总内核容量中删除，供集群和操作系统日常任务使用。
示例 1
节点具有 100 个内核的容量。通过使用性能配置集，集群管理员将 50 个内核分配给隔离池，将 50 个内核分配给保留池。集群管理员为 BestEffort 或 Burstable pod 为 QoS Guaranteed pod 和 25 个内核分配 25 个内核。这与隔离池的容量匹配。
示例 2
节点具有 100 个内核的容量。通过使用性能配置集，集群管理员将 50 个内核分配给隔离池，将 50 个内核分配给保留池。集群管理员为 QoS Guaranteed pod 分配 50 个内核，并为 BestEffort 或 Burstable pod 分配一个核心。这会由一个内核超过隔离池的容量。Pod 调度因为 CPU 容量不足而失败。
使用的确切分区模式取决于许多因素，如硬件、工作负载特性和预期的系统负载。以下是一些用例示例：
- 如果对延迟敏感的工作负载使用特定的硬件，如网络接口卡(NIC)，请确保隔离池中的 CPU 与这个硬件尽可能接近。至少，您应该将工作负载放在同一个非统一内存访问 (NUMA) 节点中。
- 保留的池用于处理所有中断。根据系统网络，分配一个足够大小的保留池来处理所有传入的数据包中断。在 4.6 及更新的版本中，可以选择性地将工作负载标记为敏感。在决定哪些特定 CPU 用于保留和隔离分区时，需要详细分析和测量。设备和内存的 NUMA 紧密度等因素扮演了角色。选择也取决于工作负载架构和具体的用例。
保留和隔离的 CPU 池不得重叠，并且必须一起跨越 worker 节点中的所有可用内核。
为确保内务处理任务和工作负载不会相互干扰，请在性能配置集的 spec 部分指定两组 CPU。
-
isolated- 指定应用程序容器工作负载的 CPU。在这些 CPU 上运行的工作负载遇到最低的延迟，以及零中断，例如达到高零数据包丢失带宽。 reserved- 为集群和操作系统日常任务指定 CPU。reserved组中的线程经常会比较繁忙。不要在reserved组中运行对延迟敏感的应用程序。延迟敏感的应用程序在隔离组中运行。Procedure- 创建适合环境硬件和拓扑的性能配置集。
使用您想要为 infra 和应用程序容器保留和隔离的 CPU 添加
reserved和isolated参数：apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: infra-cpus spec: cpu: reserved: "0-4,9" 1 isolated: "5-8" 2 nodeSelector: 3 node-role.kubernetes.io/worker: ""
