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

Benefits

CPU usage is a key metric for monitoring container health. Cluster administrators often use it to set CPU limits. Compared to second-level metrics, millisecond-level CPU usage shows more pronounced spikes and short-term fluctuations. In the chart below, CPU usage measured per second (purple line) appears well below 4 cores. But at the millisecond level (green line), usage exceeds 4 cores during some periods. If the CPU limit is set to 4 cores, throttling suspends threads—and increases response latency (RT). This is a major cause of long-tail RT issues.

The next image shows CPU resource allocation for a web service container with a CPU limit of 2 on a 4-core node. The left side shows normal behavior. The right side shows behavior after enabling CPU Burst.

CPU Burst also helps when CPU demand spikes suddenly. For example, if service traffic surges, ack-koordinator resolves CPU bottlenecks within seconds—while keeping total node load safe.

Scenarios

Typical use cases for CPU Burst include the following:

• CPU usage stays below the CPU limit most of the time—but throttling still occurs and hurts application performance. Enabling CPU Burst lets the container use accumulated CPU time during bursts. This solves throttling and improves service quality.

• The container uses high CPU during startup and loading. After loading completes, CPU usage drops to a low, steady level. With CPU Burst enabled, you do not need to set an overly high CPU limit. The container uses extra CPU time during startup—and starts faster.

Verification steps

1. Create a file named apache-demo.yaml using the YAML below.

   Add the CPU Burst annotation under the metadata field to enable 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 as the test application.

   kubectl apply -f apache-demo.yaml

3. Use wrk2 to send requests.

   # 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.
   # Run the load test. Replace $target_ip_address with the IP address of the Apache pod.
   ./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

   Note

   • Replace the target address in the command with the Apache pod’s IP address.

   • Adjust the QPS pressure by changing the -R parameter.

Results analysis

The tables below compare performance on Alibaba Cloud Linux and community CentOS—with and without CPU Burst.

• All disabled means the CPU Burst policy is set to none.

• All enabled means the CPU Burst policy is set to auto.

These results show:

• Enabling CPU Burst significantly improves the p99 RT metric.

• Enabling CPU Burst greatly reduces CPU throttling. Average Pod CPU utilization stays nearly unchanged.

I used CPU Burst with the older ack-slo-manager protocol. Does it still work after upgrading to ack-koordinator?

The older pod annotation used alibabacloud.com/cpuBurst. ack-koordinator fully supports this legacy protocol. You can upgrade seamlessly.

ack-koordinator is compatible with the following protocol versions.

Why does CPU throttling still occur after enabling CPU Burst?

Common causes and fixes:

• Invalid configuration syntax prevents CPU Burst from taking effect. See Advanced configuration to correct and verify.

• Throttling still occurs when CPU usage hits the cfsQuotaBurstPercent limit due to insufficient CPU resources.

  Adjust your CPU request and limit values to match your application’s real needs.

• CPU Burst adjusts two cgroup parameters: cpu.cfs_quota_us and cpu.cfs_burst_us. See Advanced configuration. cpu.cfs_quota_us updates only after ack-koordinator detects throttling—so there is a small delay. cpu.cfs_burst_us updates immediately from the configured value—so it responds faster.

  For best results, use Alibaba Cloud Linux.

• The CPU Burst policy has a protection mechanism when adjusting cpu.cfs_quota_us, which is the overall safety watermark threshold setting sharePoolThresholdPercent. When the overall utilization is excessively high, to prevent an individual pod from causing more interference, cpu.cfs_quota_us is reset to its initial value.

  You should set an appropriate machine safety threshold based on your application's actual conditions to prevent high machine utilization from affecting application performance.

Do I need to use Alibaba Cloud Linux to enable the CPU Burst policy?

ack-koordinator CPU Burst works on all Alibaba Cloud Linux and CentOS open-source kernels. We recommend Alibaba Cloud Linux. Its kernel features let ack-koordinator provide finer-grained CPU elasticity. For details, see Enable CPU Burst using the cgroup v1 interface.

After enabling CPU Burst, why does my application report different thread counts?

This is because the working mechanism of CPU Burst conflicts with how certain applications obtain system resources. ack-koordinator dynamically adjusts the underlying cgroup parameter of the container, cpu.cfs_quota_us, when implementing CPU Burst. This value represents the available CPU time quota for the container within the current scheduling cycle. ack-koordinator dynamically scales this quota based on the application's load.

Many applications, such as Java's Runtime.getRuntime().availableProcessors(), directly read cpu.cfs_quota_us to calculate the number of available CPU cores. Therefore, when the CPU quota is dynamically adjusted, the number of cores obtained by the application also changes, causing parameters that depend on this value, such as the thread pool size, to become unstable.

Instead, make your application rely on the fixed limits.cpu value defined in the pod spec.

1. Inject an environment variable: Use resourceFieldRef to inject the pod’s limits.cpu value into the container.

   env: 
     - name: CPU_LIMIT 
       valueFrom: 
         resourceFieldRef: 
           resource: limits.cpu

2. Update your application code: Change the startup logic to read CPU_LIMIT first when calculating and setting thread pool size. This ensures stable, reliable behavior—even when CPU Burst changes the quota.