启用CPU Burst性能优化策略

为什么需要启用CPU Burst

Kubernetes集群使用CPU Limit资源约束机制，用于限制容器可以使用的最大CPU资源量，以确保了多个容器之间的资源分配的公平性，防止某个容器过度消耗CPU资源，从而影响其他容器的性能。

CPU是一种分时复用型资源，即多个进程或容器可以共享一个CPU时间片。容器配置了CPU Limit后，操作系统内核会根据CFS (Completely Fair Scheduler) 来控制容器在每个时间周期内（cpu.cfs_period_us）的CPU使用量（cpu.cfs_quota_us）。例如，如果一个容器的CPU Limit = 4，操作系统内核会限制该容器在每段时间周期内（通常是100 ms）最多使用400 ms的CPU时间片。

费用说明

ack-koordinator组件本身的安装和使用是免费的，不过需要注意的是，在以下场景中可能产生额外的费用：

• ack-koordinator是非托管组件，安装后将占用Worker节点资源。您可以在安装组件时配置各模块的资源申请量。

• ack-koordinator默认会将资源画像、精细化调度等功能的监控指标以Prometheus的格式对外透出。若您配置组件时开启了ACK-Koordinator开启Prometheus监控指标选项并使用了阿里云Prometheus服务，这些指标将被视为自定义指标并产生相应费用。具体费用取决于您的集群规模和应用数量等因素。建议您在启用此功能前，仔细阅读阿里云Prometheus计费说明，了解自定义指标的免费额度和收费策略。您可以通过账单和用量查询，监控和管理您的资源使用情况。

配置说明

您可以通过Pod Annotation为指定的Pod开启CPU Burst功能，也可以通过ConfigMap在集群或命名空间维度开启。

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

操作步骤

本示例以一个Web服务型应用为例，展示开启CUP Burst策略前后的访问延迟情况，验证CPU Burst策略带来的优化效果。

验证步骤

1. 使用以下示例应用的YAML内容，创建名为apache-demo.yaml文件。

   在Pod对象的metadata字段下配置Annotation，为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 # 修改为实际的节点名称。
     hostNetwork: False
     restartPolicy: Never
     schedulerName: default-scheduler

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

   kubectl apply -f apache-demo.yaml

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

   # 下载wrk2开源测试工具并解压安装。具体操作，请参见https://github.com/giltene/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压力。

结果分析

以下数据分别展示了Alibaba Cloud Linux和社区CentOS在CPU Burst策略开启前后的表现情况。

• 全部关闭表示CPU Burst策略为none。

• 全部开启表示CPU Burst策略为auto。

由以上对比数据可知：

• 开启CPU Burst能力后，应用的RT指标的p99分位值有明显优化。

• 对开启CPU Burst能力后，CPU Throttled情况大幅减少，而同时Pod整体CPU利用率基本保持不变。

高级参数配置

CPU Burst策略的高级配置参数支持在ConfigMap参数中配置，也支持在Pod Annotation中配置。对于同时在Pod Annotation和ConfigMap配置的参数，Pod Annotation配置优先级大于ConfigMap配置。如果Pod Annotation中没有对应配置，ack-koordinator会进一步参考Namespace维度的ConfigMap配置；如果Namespace维度也没有对应配置，ack-koordinator会以集群维度的ConfigMap配置为准。

配置示例如下。

# 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策略的相关高级参数：

FAQ