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 节点。

流程

  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.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
    # ...

    1
    在 pod 运行时禁用 CPU 完全公平调度程序(CFS)配额。
    2
    禁用 CPU 负载均衡。
    3
    选择 pod 不在节点上的中断处理。
    4
    nodeSelector 标签必须与您在 Node CR 中指定的标签匹配。
    5
    runtimeClassName 必须与集群中配置的性能配置集的名称匹配。
  2. 以 performance-<profile_name> 格式输入 pod runtimeClassName,其中 <profile_name> 是来自 PerformanceProfile YAML 中的 名称。在上例中,名称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 的应用程序一起使用可能会导致延迟激增。使用其他探测(如正确配置的一组网络探测作为替代方案)。

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]
  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 请求。

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,您可以配置高优先级工作负载以获得最佳性能和最低延迟。

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

cpu-c-states.crio.io:

  • "enable"
  • "disable"
  • "max_latency:microseconds"

此注解允许您为每个 CPU 启用或禁用 C-states。另外,您还可以为 C-states 指定最大延迟(以微秒为单位)。例如,启用最大延迟为 10 微秒的 C-states,设置 cpu-c-states.crio.io: "max_latency:10"。将值设为 "disable" 来为 pod 提供最佳性能。

cpu-freq-governor.crio.io:

任何支持的 cpufreq 调控器

为每个 CPU 设置 cpufreq 调控器。对于高优先级的工作负载,建议使用 "performance" governor。

先决条件

  • 您已为调度高优先级工作负载 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 以应用注解。

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>
...
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.