CPU Burst性能优化策略

使用限制

系统组件版本要求具体如下表所示。

原理说明

K8s为容器资源管理提供了Limit（约束）的语义描述，对于CPU这类分时复用型的资源，当容器指定了CPU Limit，操作系统会按照一定的时间周期约束资源使用。例如对于CPU Limit = 2的容器，操作系统内核会限制容器在每100 ms周期内最多使用200 ms的CPU时间片。

CPU使用率是衡量容器运行状态的关键指标，管理员通常会参考该指标来设置容器CPU Limit。相较于常用的秒级别指标，百毫秒级别下容器的CPU使用率往往呈现更为明显的毛刺特征。若容器在100 ms内将CPU Limit消耗完成，线程会因限流（CPU Throttled）而被操作系统挂起，如下图所示。

下图展示了一台4核节点、某CPU Limit = 2的Web服务类容器，在收到请求（req）后各线程（Thread）的CPU资源分配情况。可以看出，即使容器在最近1s内整体的CPU使用率较低，受CPU Throttled机制的影响，Thread 2仍需要等待下一个周期才能继续将req 2处理完成，进而导致请求的响应时延（RT）变大，这通常就是容器RT长尾现象严重的原因之一。

Alibaba Cloud Linux 2在内核版本4.19.91-22.al7中提供了CPU Burst功能，允许容器在空闲时积累一些CPU时间片，用于满足突发时的资源需求，进而可以提升容器性能、降低延迟指标。

对于尚未支持CPU Burst策略的内核版本，ack-koordinator会通过类似的原理，监测容器CPU Throttled状态，并动态调节容器的CPU Limit，实现与内核CPU Burst策略类似的效果。

上述自动调节CFS quota的策略，还可用于满足容器CPU资源需求突增的场景。例如当业务流量突然上涨，ack-koordinator可以在保障整机负载水位安全的前提下，秒级别内快速解决CPU的资源瓶颈。

Alibaba Cloud Linux提供的内核级CPU Burst策略有着更高的灵敏度，我们强烈建议您为延迟敏感型应用（Latency Sensitive）开启该特性。关于CPU Burst的更多介绍，请参见阿里云在KubeCon 2021的演讲CPU Burst：摆脱不必要的节流，同时实现高CPU使用率和高应用程序性能。

使用方式

• 通过Pod Annotation开启CPU Burst
  重要

  • 针对Pod对象，您需要在metadata下配置annotations。
  • 针对Depolyment对象，您需要在template.metadata下配置Pod的annotations。

  annotations:
    # 设置为auto， 表示开启该Pod的cpu burst功能。
    koordinator.sh/cpuBurst: '{"policy": "auto"}'
    # 设置为none， 表示关闭该Pod的cpu burst功能。
    #koordinator.sh/cpuBurst: '{"policy": "none"}'

• 通过ConfigMap全局开启CPU Burst

  使用以下ConfigMap示例，默认开启全集群的CPU Burst策略。

  apiVersion: v1
  data:
    cpu-burst-config: '{"clusterStrategy": {"policy": "auto"}}'
    #cpu-burst-config: '{"clusterStrategy": {"policy": "cpuBurstOnly"}}'
    #cpu-burst-config: '{"clusterStrategy": {"policy": "none"}}'
  kind: ConfigMap
  metadata:
    name: ack-slo-config
    namespace: kube-system

  为避免干扰ConfigMap中其他配置项，建议使用PATCH方式更新，命令如下所示。

  kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)

• 指定Namespace开启部分容器的CPU Burst

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: ack-slo-pod-config
    namespace: kube-system
  data:
    #单独开启或关闭部分Namespace的Pod。
    cpu-burst: |
      {
        "enabledNamespaces": ["white-ns"],
        "disabledNamespaces": ["black-ns"]
      }

• 高级配置参数
  ConfigMap的参数配置，以及在Pod对象的metadata下配置annotations的可扩展字段，配置示例如下：

  # ConfigMap ack-slo-config样例。
  data:
    cpu-burst-config: |
      {
        "clusterStrategy": {
          "policy": "auto",
          "cpuBurstPercent": 1000,
          "cfsQuotaBurstPercent": 300,
          "sharePoolThresholdPercent": 50,
          "cfsQuotaBurstPeriodSeconds": -1
        }
      }
  
  # Pod Annotation样例。
    koordinator.sh/cpuBurst: '{"policy": "auto", "cpuBurstPercent": 1000, "cfsQuotaBurstPercent": 300, "cfsQuotaBurstPeriodSeconds": -1}'

  以下为CPU Burst策略的相关高级参数：

  参数	类型	说明
  policy	string	（默认值）none：关闭CPU Busrt策略，相关参数会被恢复为创建初始值。 cpuBurstOnly：仅开启Alibaba Cloud Linux 2内核的CPU Burst特性。 cfsQuotaBurstOnly：仅开启通用版本下CFS quota的自动弹性能力。 auto：自动开启所有CPU Burst能力，包括Ali Linux内核特性，以及通用版本下CFS quota的自动弹性能力。
  cpuBurstPercent	int	默认值为1000，单位为百分比。 对应Alibaba Cloud Linux 2内核CPUBurst策略，表示相较于CPU Limit，CPU Burst放大的百分比。例如CPU Limit = 1，按默认配置CPU Burst为10倍。更多信息，请参见在cgroup v1接口开启CPU Burst功能。
  cfsQuotaBurstPercent	int	默认值为300，单位为百分比。 通用内核版本的CPU Limit弹性能力，容器cgroup参数（cfs_quota）可上调的最大比例，默认为3倍。
  cfsQuotaBurstPeriodSeconds	int	默认值为-1，表示不限制，单位为秒。 通用内核版本的CPU Limit弹性能力，容器可以按上限（cfsQuotaBurstPercent）持续消耗CPU的时间限制。
  sharePoolThresholdPercent	int	默认值为50，单位为百分比。 通用内核版本下的CPU Limit弹性策略，节点CPU使用率的安全水位阈值，超出阈值后，已经上调的容器的cgroup参数（cfs_quota）会被恢复。

  重要

  • 当您开启CFS quota的自动调整时（policy设置为cfsQuotaBurstOnly或auto），容器CPU Limit在节点上对应的参数（cfs quota）会随CPU Throttled情况动态调整。
  • 在对容器进行压测时，建议您同时保持对容器CPU用量的观察，或者临时关闭CFS quota的自动调整（policy设置为cpuBurstOnly或none），以便在生产环境保持更好的资源弹性。

验证CPU Burst效果

1. 使用以下示例应用的YAML内容，创建名为apache-demo.yaml文件。
   在Pod对象的metadata下配置annotations，为Pod单独开启CPU Burst策略。

   apiVersion: v1
   kind: Pod
   metadata:
     name: apache-demo
     annotations:
       koordinator.sh/cpuBurst: '{"policy": "auto"}'   #增加了Cpu Burst策略的开关。
   spec:
     containers:
     - command:
       - httpd
       - -D
       - FOREGROUND
       image: registry.cn-zhangjiakou.aliyuncs.com/acs/apache-2-4-51-for-slo-test:v0.1
       imagePullPolicy: Always
       name: apache
       resources:
         limits:
           cpu: "4"
           memory: 10Gi
         requests:
           cpu: "4"
           memory: 10Gi
     nodeName: # $nodeName 注意修改模板中指定节点的nodeName。
     hostNetwork: False
     restartPolicy: Never
     schedulerName: default-scheduler

2. 执行以下命令，部署Apache HTTP Server作为目标评测应用。

   kubectl apply -f apache-demo.yaml

3. 使用wrk2压测工具发送请求。

   #下载wrk2开源测试工具并解压安装。
   
   #在Apache配置中开启了Gzip压缩模块，用于模拟服务端处理请求的计算逻辑。
   #执行发压命令，注意修改目标应用的IP地址。
   ./wrk -H "Accept-Encoding: deflate, gzip" -t 2 -c 12 -d 120 --latency --timeout 2s -R 24 http://$target_ip_address:8010/static/file.1m.test

   说明

   • 注意修改命令中的目标地址为Apache Pod的IP地址。
   • 通过修改“-R”参数来调节发送端的QPS压力。

结果分析

由以上对比数据可得：

• 在开启CPU Burst能力后，应用的RT指标的p99分位值得到了明显的优化。
• 对比CPU Throttled及利用率指标，可以看到开启CPU Burst能力后，CPU Throttled情况得到了消除，同时Pod整体利用率基本保持不变。

FAQ

当前已通过ack-slo-manager的旧版本协议使用了CPU Burst功能，升级为ack-koordinator后是否继续支持？

旧版本的Pod协议要求在Annotation中填写alibabacloud.com/cpuBurst，ack-koordinator对此旧版本协议完全兼容，您可将组件无缝升级至新版本。

ack-koordinator对各版本协议的适配如下。