14.3. 置备实时和低延迟工作负载
许多企业需要高性能计算和低可预测延迟,特别是在金融和电信行业中。
OpenShift Container Platform 提供 Node Tuning Operator 来实现自动性能优化,以便为 OpenShift Container Platform 应用程序实现低延迟性能和响应时间。您可以使用性能配置集配置进行这些更改。您可以将内核更新至 kernel-rt,为集群和操作系统日常任务保留 CPU,包括 pod infra 容器,为应用程序容器隔离 CPU 来运行工作负载,并禁用未使用的 CPU 来减少功耗。
在编写应用程序时,请遵循 RHEL for Real Time 进程和线程中介绍的常规建议。
其他资源
14.3.1. 将低延迟工作负载调度到具有实时功能的 worker
您可以将低延迟工作负载调度到应用实时功能的 worker 节点上。
要将工作负载调度到特定的节点上,请使用 Pod
自定义资源(CR)中的标签选择器。标签选择器必须与附加到机器配置池的节点匹配,这些池是为低延迟配置的。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您已以具有
cluster-admin
权限的用户身份登录。 - 您已在集群中应用了性能配置集,用于针对低延迟工作负载调整 worker 节点。
流程
为低延迟工作负载创建
Pod
CR,并在集群中应用它,例如:配置为使用实时处理的
Pod
规格示例apiVersion: v1 kind: Pod metadata: name: dynamic-low-latency-pod annotations: cpu-quota.crio.io: "disable" 1 cpu-load-balancing.crio.io: "disable" 2 irq-load-balancing.crio.io: "disable" 3 spec: securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault containers: - name: dynamic-low-latency-pod image: "registry.redhat.io/openshift4/cnf-tests-rhel8:v4.15" command: ["sleep", "10h"] resources: requests: cpu: 2 memory: "200M" limits: cpu: 2 memory: "200M" securityContext: allowPrivilegeEscalation: false capabilities: drop: [ALL] nodeSelector: node-role.kubernetes.io/worker-cnf: "" 4 runtimeClassName: performance-dynamic-low-latency-profile 5 # ...
-
以 performance-<profile_name> 格式输入 pod
runtimeClassName
,其中 <profile_name> 是来自PerformanceProfile
YAML 中的名称
。在上例中,名称
是performance-dynamic-low-latency-profile
。 确保 pod 正确运行。状态应该为
running
,并应正确设置了 cnf-worker 节点:$ oc get pod -o wide
预期输出
NAME READY STATUS RESTARTS AGE IP NODE dynamic-low-latency-pod 1/1 Running 0 5h33m 10.131.0.10 cnf-worker.example.com
获取为 IRQ 动态负载均衡配置的 pod 运行 CPU:
$ oc exec -it dynamic-low-latency-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"
预期输出
Cpus_allowed_list: 2-3
验证
确保正确应用节点配置。
登录节点以验证配置。
$ oc debug node/<node-name>
验证可以使用节点文件系统:
sh-4.4# chroot /host
预期输出
sh-4.4#
确保默认系统 CPU 关联性掩码不包括
dynamic-low-latency-pod
CPU,如 CPU 2 和 3。sh-4.4# cat /proc/irq/default_smp_affinity
输出示例
33
确定系统 IRQ 没有配置为在
dynamic-low-latency-pod
CPU 上运行:sh-4.4# find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;
输出示例
/proc/irq/0/smp_affinity_list: 0-5 /proc/irq/1/smp_affinity_list: 5 /proc/irq/2/smp_affinity_list: 0-5 /proc/irq/3/smp_affinity_list: 0-5 /proc/irq/4/smp_affinity_list: 0 /proc/irq/5/smp_affinity_list: 0-5 /proc/irq/6/smp_affinity_list: 0-5 /proc/irq/7/smp_affinity_list: 0-5 /proc/irq/8/smp_affinity_list: 4 /proc/irq/9/smp_affinity_list: 4 /proc/irq/10/smp_affinity_list: 0-5 /proc/irq/11/smp_affinity_list: 0 /proc/irq/12/smp_affinity_list: 1 /proc/irq/13/smp_affinity_list: 0-5 /proc/irq/14/smp_affinity_list: 1 /proc/irq/15/smp_affinity_list: 0 /proc/irq/24/smp_affinity_list: 1 /proc/irq/25/smp_affinity_list: 1 /proc/irq/26/smp_affinity_list: 1 /proc/irq/27/smp_affinity_list: 5 /proc/irq/28/smp_affinity_list: 1 /proc/irq/29/smp_affinity_list: 0 /proc/irq/30/smp_affinity_list: 0-5
当您调整节点以实现低延迟时,执行探测与需要保证 CPU 的应用程序一起使用可能会导致延迟激增。使用其他探测(如正确配置的一组网络探测作为替代方案)。
14.3.2. 创建具有保证 QoS 类的 pod
在创建带有 Guaranteed
类的 QoS 类的 pod 时请注意以下几点:
- pod 中的每个容器都必须具有内存限制和内存请求,且它们必须相同。
- pod 中的每个容器都必须具有 CPU 限制和 CPU 请求,且它们必须相同。
以下示例显示了一个容器的 pod 的配置文件。容器设置了内存限制和内存请求,均为 200 MiB。容器具有 CPU 限制和 CPU 请求,均为 1 CPU。
apiVersion: v1 kind: Pod metadata: name: qos-demo namespace: qos-example spec: securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault containers: - name: qos-demo-ctr image: <image-pull-spec> resources: limits: memory: "200Mi" cpu: "1" requests: memory: "200Mi" cpu: "1" securityContext: allowPrivilegeEscalation: false capabilities: drop: [ALL]
创建 pod:
$ oc apply -f qos-pod.yaml --namespace=qos-example
查看有关 pod 的详细信息:
$ oc get pod qos-demo --namespace=qos-example --output=yaml
输出示例
spec: containers: ... status: qosClass: Guaranteed
注意如果您为容器指定了内存限值,但没有指定内存请求,OpenShift Container Platform 会自动分配与限制匹配的内存请求。同样,如果您为容器指定 CPU 限值,但没有指定 CPU 请求,OpenShift Container Platform 会自动分配与限制匹配的 CPU 请求。
14.3.3. 在 Pod 中禁用 CPU 负载均衡
禁用或启用 CPU 负载均衡的功能在 CRI-O 级别实现。CRI-O 下的代码仅在满足以下要求时禁用或启用 CPU 负载均衡。
pod 必须使用
performance-<profile-name>
运行时类。您可以通过查看性能配置集的状态来获得正确的名称,如下所示:apiVersion: performance.openshift.io/v2 kind: PerformanceProfile ... status: ... runtimeClass: performance-manual
目前,cgroup v2 不支持禁用 CPU 负载均衡。
Node Tuning Operator 负责在相关节点下创建高性能运行时处理器配置片断,并在集群下创建高性能运行时类。它将具有与默认运行时处理程序相同的内容,但它启用了 CPU 负载均衡配置功能。
要禁用 pod 的 CPU 负载均衡,Pod
规格必须包括以下字段:
apiVersion: v1 kind: Pod metadata: #... annotations: #... cpu-load-balancing.crio.io: "disable" #... #... spec: #... runtimeClassName: performance-<profile_name> #...
仅在启用了 CPU 管理器静态策略,以及带有保证 QoS 使用整个 CPU 的 pod 时,禁用 CPU 负载均衡。否则,禁用 CPU 负载均衡会影响集群中其他容器的性能。
14.3.4. 为高优先级 pod 禁用节能模式
您可以配置 pod,以确保在为工作负载运行的节点配置节能时,高优先级工作负载不受影响。
当您使用节能配置配置节点时,您必须使用 pod 级别的性能配置高优先级工作负载,这意味着配置适用于 pod 使用的所有内核。
通过在 pod 级别上禁用 P-states 和 C-states,您可以配置高优先级工作负载以获得最佳性能和最低延迟。
注解 | 可能的值 | 描述 |
---|---|---|
|
|
此注解允许您为每个 CPU 启用或禁用 C-states。另外,您还可以为 C-states 指定最大延迟(以微秒为单位)。例如,启用最大延迟为 10 微秒的 C-states,设置 |
|
任何支持的 |
为每个 CPU 设置 |
先决条件
- 您已为调度高优先级工作负载 pod 的节点在性能配置集中配置了节能。
流程
将所需的注解添加到高优先级工作负载 pod。注解会覆盖
默认
设置。高优先级工作负载注解示例
apiVersion: v1 kind: Pod metadata: #... annotations: #... cpu-c-states.crio.io: "disable" cpu-freq-governor.crio.io: "performance" #... #... spec: #... runtimeClassName: performance-<profile_name> #...
- 重启 pod 以应用注解。
14.3.5. 禁用 CPU CFS 配额
要消除固定 pod 的 CPU 节流,请使用 cpu-quota.crio.io: "disable"
注解创建一个 pod。此注解在 pod 运行时禁用 CPU 完全公平调度程序(CFS)配额。
禁用 cpu-quota.crio.io
的 pod 规格示例
apiVersion: v1 kind: Pod metadata: annotations: cpu-quota.crio.io: "disable" spec: runtimeClassName: performance-<profile_name> #...
仅在启用了 CPU 管理器静态策略,以及带有保证 QoS 使用整个 CPU 的 pod 时禁用 CPU CFS 配额。例如,包含 CPU 固定容器的 pod。否则,禁用 CPU CFS 配额可能会影响集群中其他容器的性能。
其他资源
14.3.6. 为固定容器运行的 CPU 禁用中断处理
为实现低延迟,一些容器需要固定的 CPU 不处理设备中断。pod 注解 irq-load-balancing.crio.io
用于定义在固定容器运行的 CPU 上是否处理设备中断。配置后,CRI-O 禁用运行 pod 容器的设备中断。
要禁用属于各个 pod 的容器的中断处理,请确保在性能配置集中将 globallyDisableIrqLoadBalancing
设置为 false
。然后,在 pod 规格中,将 irq-load-balancing.crio.io
pod 注解设置为 disable
。
以下 pod 规格包含此注解:
apiVersion: performance.openshift.io/v2 kind: Pod metadata: annotations: irq-load-balancing.crio.io: "disable" spec: runtimeClassName: performance-<profile_name> ...