容器服务 Kubernetes 版 ACK：CPU Burst性能优化策略

费用说明

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

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

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

使用场景

以下是此CPU Burst功能可以应用的几个示例：

• 容器CPU资源用量低于Limit限制，但容器CPU Throttled指标仍然时常出现，影响应用性能表现。开启CPU Burst可以有效解决CPU Throttled限流问题，提升应用服务质量。

• 容器应用在启动加载阶段CPU资源消耗较高，但在加载完成后的日常状态下其CPU用量相对正常。开启CPU Burst一方面可以满足应用启动阶段的资源需求，另一方面可以避免为容器设置过高的资源规格，减少资源浪费。

原理说明

Kubernetes为容器资源管理提供了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提供了CPU Burst功能，允许容器在空闲时积累一些CPU时间片，用于满足突发时的资源需求，进而可以提升容器性能、降低延迟指标。更多信息，请参见在cgroup v1接口开启CPU Burst功能。

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

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

Alibaba Cloud Linux提供的内核级CPU Burst策略具有更高的灵敏度，我们强烈建议您为延迟敏感型应用（Latency Sensitive）开启该特性。

使用方式

通过Pod Annotation开启CPU Burst

通过Pod Annotation配置的CPU Burst策略针对指定Pod生效。

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策略默认针对全集群生效。

1. 使用以下ConfigMap示例，创建configmap.yaml文件。

   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

2. 查看命名空间kube-system下是否存在ConfigMapack-slo-config。

   • 若存在ConfigMapack-slo-config，使用PATCH方式进行更新，避免干扰ConfigMap中其他配置项。

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

   • 若不存在ConfigMapack-slo-config，执行以下命令进行创建ConfigMap。

     kubectl apply -f configmap.yaml

指定Namespace开启部分Pod的CPU Burst

通过指定Namespace，为部分Pod配置CPU Burst策略时，针对指定命名空间生效。

apiVersion: v1
kind: ConfigMap
metadata:
  name: ack-slo-pod-config
  namespace: koordinator-system # 首次使用时需要先手动创建该Namespace。
data:
  #单独开启或关闭部分Namespace的Pod。
  cpu-burst: |
    {
      "enabledNamespaces": ["white-ns"],
      "disabledNamespaces": ["black-ns"]
    }

CPU Burst策略高级配置参数

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

验证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 # 注意修改模板中指定节点的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 Throttled及利用率指标，可以看到开启CPU Burst能力后，CPU Throttled情况得到了消除，同时Pod整体利用率基本保持不变。

FAQ

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

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

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

开启CPU Burst配置后，为什么Pod仍有CPU Throttled现象出现？

通常会有以下几个原因，您可以参考以下说明进行调整。

• 配置格式错误，导致CPU Burst策略没有生效，请参考CPU Burst策略高级配置参数修改并验证。

• CPU利用率达到cfsQuotaBurstPercent配置的上限时，由于CPU资源不足，仍会出现CPU Throttled现象，建议根据应用实际需求情况调整Reqeuest和Limit规格。

• CPU Burst策略会调整Pod的两个cgroup参数：cpu.cfs_quota_us和cpu.cfs_burst_us，详见CPU Burst策略高级配置参数。其中cpu.cfs_quota_us是在ack-koordinator感知到CPU Throttled后才会进行设置，所以会有少许延迟；而cpu.cfs_burst_us会直接参考配置进行设置，效果更灵敏。建议搭配Alibaba Cloud Linux获取最佳的使用效果。

• CPU Burst策略在调整cpu.cfs_quota_us时会有保护机制，对应整机安全水位阈值配置sharePoolThresholdPercent，当整机利用率过高时，为了避免单个Pod产生更多干扰，cpu.cfs_quota_us会被重置为初始值。建议结合自身应用的实际情况，合理设置整机安全水位阈值，避免因整机利用率过高而影响应用性能。