Container Service for Kubernetes:Enable CPU Burst

Why CPU Burst is developed

In Kubernetes clusters, the CPU limit of a container specifies the maximum amount of CPU resources that the container can use. This ensures fair CPU allocation among containers and prevents performance degradation when CPU resources are exhausted by individual containers.

CPU resources are time-sharing. Multiple processes or containers can share one CPU time slice. After you specify the CPU limit of a container, the OS kernel uses Completely Fair Scheduler (CFS) to configure the maximum amount of CPU resources (cpu.cfs_quota_us) the container can use within each time period cpu.cfs_period_us. For example, you set the CPU limit of a container to 4. The OS kernel limits the CPU time slices that the container can use to 400 milliseconds within each time period (usually each 100-millisecond period).

Billing

No fee is charged when you install or use the ack-koordinator component. However, fees may be charged in the following scenarios:

• ack-koordinator is a non-managed component that occupies worker node resources after it is installed. You can specify the amount of resources requested by each module when you install the component.

• By default, ack-koordinator exposes the monitoring metrics of features such as resource profiling and fine-grained scheduling as Prometheus metrics. If you enable Prometheus metrics for ack-koordinator and use Managed Service for Prometheus, these metrics are considered custom metrics and fees are charged for these metrics. The fee depends on factors such as the size of your cluster and the number of applications. Before you enable Prometheus metrics, we recommend that you read the Billing topic of Managed Service for Prometheus to learn about the free quota and billing rules of custom metrics. For more information about how to monitor and manage resource usage, see Query the amount of observable data and bills.

Usage notes

You can use an annotation to enable CPU Burst for a pod. You can also use a ConfigMap to enable CPU Burst for pods in a namespace or cluster.

annotations:
  # Set the value to auto to enable CPU Burst for a pod. 
  koordinator.sh/cpuBurst: '{"policy": "auto"}'
  # Set the value to none to disable CPU Burst for a pod. 
  koordinator.sh/cpuBurst: '{"policy": "none"}'

Procedure

The following example uses a web application to show how CPU Burst reduces access latency and improves application performance.

Verification steps

1. Create a file named apache-demo.yaml and copy the following content to the file.

   To enable CPU Burst for the pod, add a specific annotation to the metadata section of the pod configurations.

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

2. Run the following command to create an application by using Apache HTTP Server:

   kubectl apply -f apache-demo.yaml

3. Use the wrk2 tool to perform stress tests.

   # Download, decompress, and then install the wrk2 package. For more information, visit https://github.com/giltene/wrk2. 
   # Gzip compression is enabled in the Apache image to simulate the request processing logic of the server. 
   # Run the following command to send requests. Replace the IP address in the command with the IP address of the application. 
   ./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 IP address in the command with the pod IP address of the Apache application.

   • You can modify the -R parameter to change the number of queries per unit time from the sender.

Analyze the result

The following tables show metrics before and after CPU Burst is enabled for Alibaba Cloud Linux and CentOS.

• The Disabled column shows the metrics when the CPU Burst policy is set to none.

• The Enabled column shows the metrics when the CPU Burst policy is set to auto.

The preceding metrics indicate the following information:

• After CPU Burst is enabled, the P99 latency is greatly reduced.

• After CPU Burst is enabled, CPU throttling events are greatly reduced and the average pod CPU utilization remains approximately at the same value.

Advanced configurations

You can specify advanced configurations in the ConfigMap or by adding annotations to the pod configurations. Some parameters can be configured by adding annotations and modifying the ConfigMap. In this case, the annotations take precedence over the ConfigMap. When no annotation is added to configure such a parameter, ack-koordinator uses the corresponding parameter in the namespace-level ConfigMap. If the parameter is not specified in the namespace-level ConfigMap, ack-koordinator uses the parameter in the cluster-level ConfigMap.

The following code block is an example:

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

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

The following table describes the advanced parameters of CPU Burst.

FAQ