Container Service for Kubernetes:Enable the CPU Burst performance optimization policy

How it works

CPU is a time-sharing resource. The kernel uses the Completely Fair Scheduler (CFS) to allocate CPU time in fixed scheduling cycles. The cycle length is controlled by cpu.cfs_period_us (typically 100 ms). The CPU time a container can use per cycle is controlled by cpu.cfs_quota_us. A container with a CPU limit of 4 gets 400 ms of CPU time per 100-ms cycle.

The problem is that CPU usage is bursty at the millisecond level, even when second-level averages look low. The chart below illustrates this: the purple line shows per-second CPU usage staying well below 4 cores, while the green line shows millisecond-level usage spiking above 4 cores in some periods. When those spikes exhaust the CFS quota, the kernel throttles the container.

Throttling forces threads to wait for the next scheduling cycle, which increases response time (RT) and causes long-tail latency. The table below shows what this looks like in practice for a web service container with a CPU limit of 2 on a 4-core node.

<table> <thead> <tr> <td><p>Even when overall CPU usage over the last second is low, throttling forces Thread 2 to wait for the next scheduling cycle to finish processing req 2. This increases request RT. This is a common cause of long-tail RT.<img></p></td> <td><p>After enabling CPU Burst, the container accumulates unused CPU time. It uses that time during bursts. This boosts performance and lowers latency.<img></p><p></p></td> </tr> </thead> <colgroup></colgroup> <colgroup></colgroup> <tbody></tbody> </table>

When demand spikes beyond what accumulated quota can cover—such as a sudden traffic surge—ack-koordinator resolves the CPU bottleneck within seconds while keeping total node load within safe limits.

Use cases

Throttling despite low average utilization. CPU usage stays below the CPU limit most of the time, but short bursts within scheduling cycles still trigger throttling. CPU Burst lets the container spend accumulated quota during those bursts, reducing throttling and improving service quality.

Slow startup due to CPU-intensive initialization. The container needs high CPU during startup and loading, then settles at a lower steady state. CPU Burst lets the container use extra CPU time during startup without requiring a permanently high CPU limit.

Billing

ack-koordinator is free to install and use. Extra charges may apply in these two cases:

• Worker node resources: ack-koordinator is an unmanaged component. After installation, it runs on your worker nodes and consumes their resources. Configure resource requests for each module during installation.

• Prometheus metrics: ack-koordinator exposes resource profiling and scheduling metrics in Prometheus format. If you enable the Enable Prometheus monitoring metrics for ACK-Koordinator option and use Alibaba Cloud Prometheus, these metrics count as custom metrics and incur charges. Review the Prometheus instance pricing before enabling, and use usage queries to monitor consumption.

Prerequisites

Before you begin, ensure that you have:

• An ACK managed cluster Pro edition running Kubernetes 1.18 or later. See Create an ACK managed cluster and Manually upgrade a cluster.

• ack-koordinator version 0.8.0 or later installed on the cluster. See ack-koordinator.

Enable CPU Burst

CPU Burst can be enabled at three scopes. Configuration at a narrower scope takes precedence: pod annotations override namespace-level ConfigMaps, which override the cluster-level ConfigMap.

annotations:
  # Enable CPU Burst for this pod.
  koordinator.sh/cpuBurst: '{"policy": "auto"}'
  # Disable CPU Burst for this pod.
  koordinator.sh/cpuBurst: '{"policy": "none"}'

Verify with a load test

This example uses an Apache HTTP Server pod to demonstrate that CPU Burst reduces access latency.

1. Create apache-demo.yaml with the following content. The annotation enables CPU Burst for this pod.

   apiVersion: v1
   kind: Pod
   metadata:
     name: apache-demo
     annotations:
       koordinator.sh/cpuBurst: '{"policy": "auto"}'   # Enable 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 # Replace with the actual node name.
     hostNetwork: False
     restartPolicy: Never
     schedulerName: default-scheduler

2. Deploy the Apache HTTP Server.

   kubectl apply -f apache-demo.yaml

3. Run a load test using wrk2. Replace $target_ip_address with the IP address of the Apache pod.

   # Download and extract the open-source wrk2 tool. See https://github.com/giltene/wrk2.
   # The Apache image has Gzip compression enabled to simulate server-side request processing.
   # Adjust QPS pressure by changing the -R parameter.
   ./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

Advanced configuration

Configure advanced parameters in either a pod annotation or a ConfigMap. Pod annotations take precedence, followed by namespace-level ConfigMaps, then the cluster-level ConfigMap.

# Example ConfigMap ack-slo-config.
data:
  cpu-burst-config: |
    {
      "clusterStrategy": {
        "policy": "auto",
        "cpuBurstPercent": 1000,
        "cfsQuotaBurstPercent": 300,
        "sharePoolThresholdPercent": 50,
        "cfsQuotaBurstPeriodSeconds": -1
      }
    }

# Example pod annotation.
  koordinator.sh/cpuBurst: '{"policy": "auto", "cpuBurstPercent": 1000, "cfsQuotaBurstPercent": 300, "cfsQuotaBurstPeriodSeconds": -1}'

<table> <thead> <tr> <td><p><b>Parameter</b></p></td> <td><p><b>Type</b></p></td> <td><p><b>Description</b></p></td> <td><p><b>Annotation</b></p></td> <td><p><b>ConfigMap</b></p></td> </tr> </thead> <colgroup></colgroup> <colgroup></colgroup> <colgroup></colgroup> <colgroup></colgroup> <colgroup></colgroup> <tbody> <tr> <td><p><code>policy</code></p></td> <td><p>string</p></td> <td> <ul> <li><p><code>none</code> (default): Disable CPU Burst. All related parameters reset to their initial values.</p></li> <li><p><code>cpuBurstOnly</code>: Enable only the Alibaba Cloud Linux kernel-level CPU Burst elasticity.</p></li> <li><p><code>cfsQuotaBurstOnly</code>: Enable only CFS quota elasticity. Works with all kernel versions.</p></li> <li><p><code>auto</code>: Automatically enable both elasticities—Alibaba Cloud Linux kernel features and CFS quota elasticity.</p></li> </ul></td> <td><p><img></p></td> <td><p><img></p></td> </tr> <tr> <td><p><code>cpuBurstPercent</code></p></td> <td><p>int</p></td> <td><p>Default: <code>1000</code>. Unit: percent.</p><p>For Alibaba Cloud Linux kernel-level CPU Burst elasticity, this sets how much CPU Burst amplifies beyond the CPU limit. Maps to the cgroup parameter <code>cpu.cfs_burst_us</code>. For details, see <a href="https://www.alibabacloud.com/help/en/document_detail/306980.html#task-2108025">Enable CPU Burst using the cgroup v1 interface</a>.</p><p>For example, with the default setting, <code>CPU Limit = 1</code> sets <code>cpu.cfs_quota_us</code> to 100,000. Then <code>cpu.cfs_burst_us</code> becomes 1,000,000—a 10x increase.</p></td> <td><p><img></p></td> <td><p><img></p></td> </tr> <tr> <td><p><code>cfsQuotaBurstPercent</code></p></td> <td><p>int</p></td> <td><p>Default: <code>300</code>. Unit: percent.</p><p>When CFS quota elasticity is enabled, this sets the maximum allowed increase for the cgroup parameter <code>cpu.cfs_quota_us</code>. Default is 3x.</p></td> <td><p><img></p></td> <td><p><img></p></td> </tr> <tr> <td><p><code>cfsQuotaBurstPeriodSeconds</code></p></td> <td><p>int</p></td> <td><p>Default: <code>-1</code>. Unit: seconds. -1 means unlimited.</p><p>When CFS quota elasticity is enabled, this sets how long a pod can consume CPU at the increased quota (<code>cfsQuotaBurstPercent</code>). After this period, the pod's <code>cpu.cfs_quota_us</code> resets to its original value. Other pods are unaffected.</p></td> <td><p><img></p></td> <td><p><img></p></td> </tr> <tr> <td><p><code>sharePoolThresholdPercent</code></p></td> <td><p>int</p></td> <td><p>Default: <code>50</code>. Unit: percent.</p><p>When CFS quota elasticity is enabled, this sets the safe CPU usage threshold for the node. If usage exceeds this threshold, all pods with increased <code>cpu.cfs_quota_us</code> reset to their original values.</p></td> <td><p><img></p></td> <td><p><img></p></td> </tr> </tbody> </table>

FAQ

References

Alibaba Cloud Linux extends the cgroup v1 interface with CPU Burst support. To enable CPU Burst at the cgroup level and query statistics, see Enable CPU Burst using the cgroup v1 interface.