14.5. 使用性能配置集调整节点以实现低延迟
性能配置集可让您控制属于特定机器配置池的节点的延迟调整方面。指定设置后，PerformanceProfile 对象将编译为执行实际节点级别调整的多个对象：
-
操作节点的
MachineConfig文件。 -
用于配置拓扑管理器、CPU Manager 和 OpenShift Container Platform 节点的
KubeletConfig文件。 - 配置 Node Tuning Operator 的 Tuned 配置集。
您可以使用性能配置集指定是否将内核更新至 kernel-rt，分配大页面，以及划分 CPU 以执行内务处理或运行工作负载。
您可以手动创建 PerformanceProfile 对象，或使用 Performance Profile Creator (PPC) 生成性能配置集。有关 PPC 的更多信息，请参见以下的其他资源。
性能配置集示例
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: cpu: isolated: "5-15" 1 reserved: "0-4" 2 hugepages: defaultHugepagesSize: "1G" pages: - size: "1G" count: 16 node: 0 realTimeKernel: enabled: true 3 numa: 4 topologyPolicy: "best-effort" nodeSelector: node-role.kubernetes.io/worker-cnf: "" 5
其他资源
- 有关使用 Performance Profile Creator (PPC) 生成性能配置集的详情，请参考创建性能配置集。
14.5.1. 配置巨页
节点必须预先分配在 OpenShift Container Platform 集群中使用的巨页。使用 Performance Addon Operator 在指定节点上分配巨页。
OpenShift Container Platform 提供了创建和分配巨页的方法。Performance Addon Operator 提供了一种更易于使用性能配置集的方法。
例如，在性能配置集的 hugepages pages 部分，您可以指定多个块的 size、count 以及可选的 node:
hugepages:
defaultHugepagesSize: "1G"
pages:
- size: "1G"
count: 4
node: 0 1- 1
node是分配巨页的 NUMA 节点。如果省略了node，该页面将平均分布在所有 NUMA 节点中。
等待显示更新已完成的相关机器配置池状态。
这些是分配巨页的唯一配置步骤。
验证
要验证配置，请查看节点上的
/proc/meminfo文件：$ oc debug node/ip-10-0-141-105.ec2.internal
# grep -i huge /proc/meminfo
输出示例
AnonHugePages: ###### ## ShmemHugePages: 0 kB HugePages_Total: 2 HugePages_Free: 2 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: #### ## Hugetlb: #### ##
使用
oc describe报告新大小：$ oc describe node worker-0.ocp4poc.example.com | grep -i huge
输出示例
hugepages-1g=true hugepages-###: ### hugepages-###: ###
14.5.2. 分配多个巨页大小
您可以在同一容器下请求具有不同大小的巨页。这样，您可以定义由具有不同巨页大小的容器组成的更复杂的 pod。
例如，您可以把大小定义为 1G 和 2M，Performance Addon Operator 会在节点上配置这两个大小，如下所示：
spec:
hugepages:
defaultHugepagesSize: 1G
pages:
- count: 1024
node: 0
size: 2M
- count: 4
node: 1
size: 1G14.5.3. 为 infra 和应用程序容器限制 CPU
通用内务处理和工作负载任务使用 CPU 的方式可能会影响对延迟敏感的进程。默认情况下，容器运行时使用所有在线 CPU 一起运行所有容器，这可能导致上下文切换和延迟激增。对 CPU 进行分区可防止无状态进程通过相互分离来干扰对延迟敏感的进程。下表描述了在使用 Performance Add-On Operator 调整节点后在 CPU 上运行的进程：
表 14.1. 进程的 CPU 分配
| 进程类型 | 详情 |
|---|---|
|
| 在除了运行低延迟工作负载外的任意 CPU 上运行 |
| 基础架构 pod | 在除了运行低延迟工作负载外的任意 CPU 上运行 |
| 中断 | 重定向到保留的 CPU（OpenShift Container Platform 4.7 及更新的版本中的可选） |
| 内核进程 | 固定保留的 CPU |
| 对延迟敏感的工作负载 pod | 固定到隔离池中的特定专用 CPU |
| OS 进程/systemd 服务 | 固定保留的 CPU |
在一个节点上的对于所有 QoS 进程类型（ Burstable、BestEffort 或 Guaranteed ）的 pod 的可分配容量等于隔离池的容量。保留池的容量已从节点的总内核容量中删除，供集群和操作系统日常任务使用。
示例 1
节点具有 100 个内核的容量。通过使用性能配置集，集群管理员将 50 个内核分配给隔离池，将 50 个内核分配给保留池。集群管理员为 QoS 为 BestEffort 或 Burstable 的 pod 分配 25 个内核，为 Guaranteed 的 pod 分配 25 个内核。这与隔离池的容量匹配。
示例 2
节点具有 100 个内核的容量。通过使用性能配置集，集群管理员将 50 个内核分配给隔离池，将 50 个内核分配给保留池。集群管理员为 QoS 为 BestEffort 或 Burstable 的 pod 分配一个内核，为 Guaranteed 的 pod 分配 50 个内核。这超过了隔离池容量一个内核。Pod 调度因为 CPU 容量不足而失败。
使用的确切分区模式取决于许多因素，如硬件、工作负载特性和预期的系统负载。以下是一些用例示例：
- 如果对延迟敏感的工作负载使用特定的硬件，如网络接口控制器(NIC)，请确保隔离池中的 CPU 尽可能地与这个硬件接近。至少，您应该将工作负载放在同一个非统一内存访问 (NUMA) 节点中。
- 保留的池用于处理所有中断。根据系统网络，分配一个足够大小的保留池来处理所有传入的数据包中断。在 4.9 及更新的版本中，可以选择性地将工作负载标记为敏感。
在决定哪些特定 CPU 用于保留和隔离分区时，需要详细分析和测量。设备和内存的 NUMA 紧密度等因素扮演了角色。选择也取决于工作负载架构和具体的用例。
保留和隔离的 CPU 池不得重叠，并且必须一起跨越 worker 节点中的所有可用内核。
为确保内务处理任务和工作负载不会相互干扰，请在性能配置集的 spec 部分指定两组 CPU。
-
isolated- 指定应用程序容器工作负载的 CPU。这些 CPU 的延迟最低。这个组中的进程没有中断，例如，可以达到更高的 DPDK 零数据包丢失带宽。 -
reserved- 为集群和操作系统日常任务指定 CPU。reserved组中的线程经常会比较繁忙。不要在reserved组中运行对延迟敏感的应用程序。对延迟敏感的应用程序在isolated组中运行。
流程
- 创建适合环境硬件和拓扑的性能配置集。
使用您想要为 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: ""
