全部产品
Search
文档中心

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

更新时间:Feb 27, 2024

CPU Burst策略是ACK提供的差异化SLO能力之一,目的是提升延迟敏感型应用的容器性能表现。受CPU Limit约束,容器在微观层面会频繁遭遇内核资源分配的限流,进而导致应用服务受损。ack-koordinator通过对CPU Throttled的动态感知,以及容器参数的自适应调节,可以有效提升延迟敏感型应用的服务质量。本文介绍CPU Burst策略的原理、使用方式以及效果分析。

前提条件

  • 此功能仅适用于ACK Pro版集群,使用前请先创建该集群。具体操作,请参见创建ACK Pro版集群

  • 已安装ack-koordinator。具体操作,请参见ack-koordinator

使用限制

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

组件

版本要求

Kubernetes

≥v1.18

ack-koordinator

≥0.8.0

费用说明

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

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

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

使用场景

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

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

  2. 容器应用在启动加载阶段CPU资源消耗较高,但在加载完成后的日常状态下其CPU用量相对正常。开启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长尾现象严重的原因之一。

ack-slo-manager example.png

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

CPU Burst.png

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

说明

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

上述自动调节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: koordinator-system # 首次使用时需要先手动创建该namespace
    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设置为cfsQuotaBurstOnlyauto),容器CPU Limit在节点上对应的参数(cfs quota)会随CPU Throttled情况动态调整。

    • 在对容器进行压测时,建议您同时保持对容器CPU用量的观察,或者临时关闭CFS quota的自动调整(policy设置为cpuBurstOnlynone),以便在生产环境保持更好的资源弹性。

验证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压测工具发送请求。

  4. # 下载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 2、CentOS 7在CPU Burst策略开启前后的表现情况:

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

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

Alibaba Cloud Linux 2

全部关闭

全部开启

apache RT-p99

107.37 ms

67.18 ms(-37.4%)

CPU Throttled Ratio

33.3%

0%

Pod CPU平均利用率

31.8%

32.6%

CentOS 7

全部关闭

全部开启

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 Throttled及利用率指标,可以看到开启CPU Burst能力后,CPU Throttled情况得到了消除,同时Pod整体利用率基本保持不变。

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

支持

支持