使用CPU Burst性能优化策略提升延迟敏感型应用容器性能表现 - 容器服务 Kubernetes 版 ACK

受CPU Limit约束，容器在运行过程中可用的CPU资源会受到限制，当真实用量触发上限时，内核会对其限流（Throttling），进而导致服务质量受损。CPU Burst功能能够动态感知CPU Throttled现象并对容器参数进行自适应调节。在出现突发负载时，CPU Burst可以为容器临时提供额外的CPU资源，缓解CPU限制带来的性能瓶颈，以保障并提升应用（尤其是延迟敏感型应用）的服务质量。

说明

为了帮助您更好地理解本文档并使用本功能，推荐您提前了解CFS Scheduler、节点CPU管理策略等相关概念。

为什么需要启用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时间片。

功能优势

CPU使用率是衡量容器运行状态的关键指标，集群管理员通常会参考该指标来配置容器的CPU Limit。相较于常用的秒级别指标，百毫秒级别下容器的CPU使用率往往呈现更为明显的毛刺特征，展示出更多瞬时变化。以下图为例，如果以秒级别为单位（紫色折线），CPU用量明显少于4核；而如果以毫秒级别为单位（绿色折线），那么容器CPU用量在部分时段会超出4核，若将CPU Limit配置为4核，就会导致线程因CPU限流而被操作系统挂起。

原理说明

下方图片展示了在一台4核节点上，一个CPU Limit = 2的Web服务容器在收到请求（req）后，各个线程（Thread）的CPU资源分配情况。左图为常规情况，右图为开启CPU Burst后的情况。

即使容器在最近1s内整体的CPU使用率较低，但受CPU限流的影响，Thread 2仍需要等待下一个时间周期才能继续将req 2处理完成，导致请求的响应时延（RT）变大。这是容器RT长尾问题的一个重要原因。 ack-slo-manager example.png

启用CPU Burst功能后，容器可以在空闲时积累一些CPU时间片，用于满足突发时的资源需求，进而可以提升容器性能，降低延迟指标。 CPU Burst.png

除了上述场景之外，CPU Burst还适用于容器CPU资源需求突增的场景。例如，当业务流量突然上涨时，ack-koordinator可以在保障整机负载水位安全的前提下，在秒级别内快速解决CPU的资源瓶颈。

说明

ack-koordinator的调节仅涉及节点cgroup参数中的cfs quota，并不会修改Pod Spec的CPU Limit字段。

使用场景

CPU Burst功能的典型使用场景如下。

容器在大多数时间内CPU资源用量低于设置的CPU Limit，但容器CPU Throttled仍然时常出现，影响应用性能表现。开启CPU Burst可以让容器在突发负载时使用积累的时间片，有效解决CPU Throttled限流问题，提升应用服务质量。
容器应用在启动加载阶段CPU资源消耗较高，但在加载完成并进入稳定运行状态后，其CPU用量会降到一个较低且稳定的水平。开启CPU Burst后，您无需为容器配置过高的CPU Limit，即可让应用在启动阶段使用更多时间片，确保应用能够快速启动。

费用说明

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

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

前提条件

已创建ACK集群Pro版且集群版本为1.18及以上，请参见创建ACK托管集群、手动升级集群。
说明
推荐使用Alibaba Cloud Linux作为操作系统，请参见开启CPU Burst策略是否必须使用Alibaba Cloud Linux操作系统？。
已安装ack-koordinator组件，且组件版本为0.8.0及以上，请参见ack-koordinator。

配置说明

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

通过Annotation为指定Pod开启

通过Pod YAML的metadata字段下配置CPU Burst策略的Annotation，针对指定Pod生效。

说明

如需在工作负载（例如Deployment）中配置，请在template.metadata字段下配置Pod对应的Annotation。

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

通过ConfigMap在集群维度开启

通过ConfigMap配置的CPU Burst策略默认针对全集群生效。

使用以下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

查看命名空间kube-system下是否存在ConfigMapack-slo-config。
- 存在：使用PATCH方式进行更新，避免干扰ConfigMap中其他配置项。
```
kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)
```
- 不存在：执行以下命令进行创建ConfigMap。
```
kubectl apply -f configmap.yaml
```

通过ConfigMap在Namespace维度开启

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

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: ack-slo-pod-config
  namespace: koordinator-system # 首次使用时需要先手动创建该Namespace。
data:
  # 单独开启或关闭部分Namespace的Pod。
  cpu-burst: |
    {
      "enabledNamespaces": ["allowed-ns"], 
      "disabledNamespaces": ["blocked-ns"]
    }
  # 为allowed-ns命名空间下的所有Pod开启了CPU Burst策略，对应policy为auto。
  # 为blocked-ns命名空间下的所有Pod关闭了CPU Burst策略，对应policy为none。

查看命名空间kube-system下是否存在ConfigMapack-slo-config。
- 存在：使用PATCH方式进行更新，避免干扰ConfigMap中其他配置项。
```
kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)
```
- 不存在：执行以下命令创建ConfigMap。
```
kubectl apply -f configmap.yaml
```

操作步骤

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

验证步骤

使用以下示例应用的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

执行以下命令，部署Apache HTTP Server作为目标评测应用。
```
kubectl apply -f apache-demo.yaml
```

使用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。

重要

以下数据仅为理论值，实际请以您的操作环境为准。

Alibaba Cloud Linux	全部关闭	全部开启
apache RT-p99	107.37 ms	67.18 ms（-37.4%）
CPU Throttled Ratio	33.3%	0%
Pod CPU平均利用率	31.8%	32.6%

CentOS	全部关闭	全部开启
apache RT-p99	111.69 ms	71.30 ms （-36.2%）
CPU Throttled Ratio	33%	0%
Pod CPU平均利用率	32.5%	33.8%

由以上对比数据可知：

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

说明

Annotation和ConfigMap两列分别代表是否允许通过Pod Annotation或ConfigMap进行配置。其中，代表支持，代表不支持。

参数	类型	说明	Annotation	ConfigMap
`policy`	string	`none`（默认值）：关闭CPU Burst策略，相关参数会被恢复为创建初始值。 `cpuBurstOnly`：仅开启Alibaba Cloud Linux内核级别的CPU Burst弹性。 `cfsQuotaBurstOnly`：仅开启CFS quota的自动弹性能力，支持所有内核版本。 `auto`：自适应开启以上两种弹性能力，包括Alibaba Cloud Linux内核特性，以及CFS quota的自动弹性能力。
`cpuBurstPercent`	int	默认值为`1000`，单位为百分比。 Alibaba Cloud Linux内核级别的CPU Burst弹性，表示相较于CPU Limit，CPU Burst放大的百分比。对应Pod的cgroup参数`cpu.cfs_burst_us`。更多信息，请参见在cgroup v1接口开启CPU Burst功能。例如，按默认配置，`CPU Limit = 1`对应的`cpu.cfs_quota_us`为100,000，`cpu.cfs_burst_us`会放大10倍为1,000,000。
`cfsQuotaBurstPercent`	int	默认值为`300`，单位为百分比。开启CFS quota弹性能力时，Pod的cgroup参数（`cpu.cfs_quota_us`）可上调的最大比例，默认为3倍。
`cfsQuotaBurstPeriodSeconds`	int	默认值为`-1`，表示不限制，单位为秒。开启CFS quota弹性能力时，Pod可以按上限（`cfsQuotaBurstPercent`）持续消耗CPU的时间限制。单个Pod超出时限后，其已经上调的cgroup参数（`cpu.cfs_quota_us`）会被恢复为原始值，其他Pod不受影响。
`sharePoolThresholdPercent`	int	默认值为`50`，单位为百分比。开启CFS quota弹性能力时，节点CPU使用率的安全水位阈值。超出阈值后，节点中所有已经上调的Pod的cgroup参数（`cpu.cfs_quota_us`）会被恢复为创建初始值。

说明

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

FAQ

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

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

说明

ack-koordinator对旧版本协议的兼容期限截止至2023年07月30日。强烈建议您将原协议资源字段及时升级到新版本。

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

ack-koordinator版本	alibabacloud.com协议	koordinator.sh协议
≥0.2.0	支持	不支持
≥0.8.0	支持	支持

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

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

配置格式错误，导致CPU Burst策略没有生效，请参见高级参数配置修改并验证。
CPU利用率达到cfsQuotaBurstPercent配置的上限时，由于CPU资源不足，仍会出现CPU Throttled现象。
建议您根据应用实际需求情况调整Reqeuest和Limit值。
CPU Burst策略会调整Pod的两个cgroup参数：cpu.cfs_quota_us和cpu.cfs_burst_us，详情请参见高级参数配置。其中，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会被重置为初始值。
建议您结合自身应用的实际情况，合理设置整机安全水位阈值，避免因整机利用率过高而影响应用性能。

开启CPU Burst策略是否必须使用Alibaba Cloud Linux操作系统？

ack-koordinator的CPU Burst策略适用于所有Alibaba Cloud Linux及CentOS开源内核。推荐您使用Alibaba Cloud Linux操作系统。借助Alibaba Cloud Linux内核特性，ack-koordinator可以提供更加细粒度的CPU弹性管理机制。更多信息，请参见在cgroup v1接口开启CPU Burst功能。