OpenShift 文档正在迁移，很快将只能在 docs.redhat.com（所有 Red Hat 产品文档的所在地）访问。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

配置实时低延迟工作负载

许多组织需要高性能计算和低、可预测的延迟，尤其是在金融和电信行业。

OpenShift Container Platform提供节点调优操作符，以实现自动调优，从而为OpenShift Container Platform应用程序实现低延迟性能和一致的响应时间。您可以使用性能配置文件配置来进行这些更改。您可以将内核更新到kernel-rt，为集群和操作系统维护任务（包括Pod基础架构容器）保留CPU，隔离CPU以运行应用程序容器的工作负载，并禁用未使用的CPU以减少功耗。

编写应用程序时，请遵循RHEL for Real Time进程和线程中描述的一般建议。
其他资源

将低延迟工作负载调度到具有实时功能的工作节点上

您可以将低延迟工作负载调度到应用了配置实时功能的性能配置文件的工作节点上。

要在特定节点上调度工作负载，请在Pod自定义资源 (CR) 中使用标签选择器。标签选择器必须与附加到由节点调优操作符为低延迟配置的机器配置池的节点匹配。
先决条件

  • 您已安装OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录。

  • 您已在集群中应用了为低延迟工作负载调整工作节点的性能配置文件。

步骤

  1. 为低延迟工作负载创建一个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.17"
    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)
# ...
    1 在Pod运行时禁用CPU完全公平调度程序 (CFS) 配额。
    2 禁用CPU负载均衡。
    3 使Pod不在节点上进行中断处理。
    4 nodeSelector标签必须与您在Node CR中指定的标签匹配。
    5 runtimeClassName必须与在集群中配置的性能配置文件的名称匹配。

  2. 输入Pod的runtimeClassName，格式为performance-<profile_name>，其中<profile_name>是PerformanceProfile YAML中的name。在前面的示例中，name为performance-dynamic-low-latency-profile。

  3. 确保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

  4. 获取配置为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
验证

确保节点配置正确应用。

  1. 登录到节点以验证配置。

    $ oc debug node/<node-name>

  2. 验证您可以使用节点文件系统

    sh-4.4# chroot /host
    预期输出
    sh-4.4#

  3. 确保默认系统CPU亲和性掩码不包含dynamic-low-latency-pod CPU，例如CPU 2和3。

    sh-4.4# cat /proc/irq/default_smp_affinity
    示例输出
    33

  4. 确保系统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的应用程序使用执行探针会导致延迟峰值。请使用其他探针，例如正确配置的一组网络探针，作为替代方案。
其他资源

创建具有Guaranteed 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]

  1. 创建 Pod

    $ oc  apply -f qos-pod.yaml --namespace=qos-example

  2. 查看 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 请求。

禁用 Pod 中的 CPU 负载均衡

禁用或启用 CPU 负载均衡的功能在 CRI-O 层面实现。CRI-O 下的代码仅在满足以下要求时才禁用或启用 CPU 负载均衡。

  • Pod 必须使用`performance-`运行时类。您可以通过查看性能配置文件的状态来获取正确的名称，如下所示

    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
...
status:
  ...
  runtimeClass: performance-manual

节点调优操作员负责在相关节点下创建高性能运行时处理程序配置片段，并在集群下创建高性能运行时类。它的内容与默认运行时处理程序相同，只是它启用了 CPU 负载均衡配置功能。

要禁用 Pod 的 CPU 负载均衡，`Pod`规范必须包含以下字段

apiVersion: v1
kind: Pod
metadata:
  #...
  annotations:
    #...
    cpu-load-balancing.crio.io: "disable"
    #...
  #...
spec:
  #...
  runtimeClassName: performance-<profile_name>
  #...

仅当启用 CPU 管理器静态策略且对于使用完整 CPU 的具有保证 QoS 的 Pod 时，才禁用 CPU 负载均衡。否则，禁用 CPU 负载均衡可能会影响集群中其他容器的性能。

为高优先级 Pod 禁用省电模式

您可以配置 Pod 以确保在为工作负载运行所在的节点配置省电功能时，高优先级工作负载不受影响。

配置具有省电配置的节点时，必须在 Pod 级别为高优先级工作负载配置性能配置，这意味着该配置适用于 Pod 使用的所有核心。

通过在 Pod 级别禁用 P 状态和 C 状态，您可以为高优先级工作负载配置最佳性能和最低延迟。

表 1. 高优先级工作负载配置
注释 可能的值 描述

cpu-c-states.crio.io

  • "启用"

  • "禁用"

  • "max_latency:微秒"

此注释允许您启用或禁用每个 CPU 的 C 状态。或者，您还可以为 C 状态指定最大延迟（以微秒为单位）。例如，使用设置`cpu-c-states.crio.io`: `"max_latency:10"`启用最大延迟为 10 微秒的 C 状态。将值设置为`"禁用"`可为 Pod 提供最佳性能。

cpu-freq-governor.crio.io

任何受支持的`cpufreq 调节器`。

设置每个 CPU 的`cpufreq` 调节器。“性能”调节器推荐用于高优先级工作负载。
先决条件

  • 您已在高优先级工作负载 Pod 调度的节点的性能配置文件中配置了省电功能。

步骤

  1. 将所需的注释添加到您的高优先级工作负载 Pod。这些注释会覆盖`默认`设置。

    高优先级工作负载注释示例
    apiVersion: v1
kind: Pod
metadata:
  #...
  annotations:
    #...
    cpu-c-states.crio.io: "disable"
    cpu-freq-governor.crio.io: "performance"
    #...
  #...
spec:
  #...
  runtimeClassName: performance-<profile_name>
  #...

  2. 重启 Pod 以应用注释。

其他资源

为运行并置的高优先级和低优先级工作负载的节点配置省电功能

禁用 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 管理器静态策略且对于使用完整 CPU 的具有保证 QoS 的 Pod 时，才禁用 CPU CFS 配额。例如，包含 CPU 固定容器的 Pod。否则，禁用 CPU CFS 配额可能会影响集群中其他容器的性能。
其他资源

禁用固定容器运行的 CPU 的中断处理

为了实现工作负载的低延迟，某些容器要求其固定的 CPU 不处理设备中断。Pod 注释`irq-load-balancing.crio.io`用于定义是否在固定容器运行的 CPU 上处理设备中断。配置后，CRI-O 会禁用 Pod 容器运行所在的设备中断。

要禁用属于单个 Pod 的容器固定的 CPU 的中断处理，请确保在性能配置文件中将`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>
...
其他资源