Kubernetes allows you to deploy multiple types of containerized applications on the same host. This causes applications with different priorities to compete for CPU resources. As a result, the performance of the applications with high priorities cannot be guaranteed. The ack-koordinator component allows you to use quality of service (QoS) classes to guarantee CPU resources for applications with high priorities. This topic describes how to configure the CPU QoS feature for pods.
Background information
To make full use of computing resources, workloads of different priorities are usually deployed on the same node. For example, a latency-sensitive (LS) workload (with a high priority) and a best-effort (BE) workload (with a low priority) can be deployed on the same node. However, this may cause these workloads to compete for computing resources. In Kubernetes, CPU requests and CPU limits are used to control the amount of CPU resources that pods can use. However, pods may still compete for CPU resources. For example, BE pods and LS pods can share CPU cores or vCPU cores. When the loads of the BE pods increase, the performance of the LS pods is compromised. As a result, the response latency of the application that uses the LS pods increases.
To reserve CPU resources for LS pods and prevent BE pods from competing for resources, you can use the CPU QoS feature provided by the ack-koordinator component. The CPU QoS feature is based on Alibaba Cloud Linux. The ack-koordinator component allows you to use the group identity feature to configure Linux scheduling priorities for pods. In an environment where LS pods and BE pods are colocated, you can set the priority of LS pods to high and the priority of BE pods to low to avoid resource contention. The LS pods are prioritized to use the limited CPU resources. This ensures the service quality of the LS workloads. For more information, see Group identity feature.
You can gain the following benefits after you enable the CPU QoS feature:
The wake-up latency of tasks for LS workloads is minimized.
Waking up tasks for BE workloads does not adversely affect the performance of LS pods.
Tasks for BE workloads cannot use the simultaneous multithreading (SMT) scheduler to share CPU cores. This further reduces the impact on the performance of LS pods.
Prerequisites
A Container Service for Kubernetes (ACK) Pro cluster is created. Only ACK Pro clusters support the CPU QoS feature. For more information, see Create an ACK Pro cluster.
ack-koordinator (FKA ack-slo-manager) is installed. For more information, see ack-koordinator (ack-slo-manager).
Limits
The following table describes the versions of the system components that are required to enable the CPU QoS feature for containers.
Component | Required version |
Kubernetes | ≥ 1.18 |
≥ 0.8.0 | |
Helm | ≥ 3.0 |
OS | Alibaba Cloud Linux (For more information, see Group identity feature) |
The ack-koordinator component also allows you to configure the CPU Suppress feature to limit CPU usage and ensure application performance if your node does not run Alibaba Cloud Linux. For more information, see CPU Suppress.
Billing rules
No fee is charged when you install and use the ack-koordinator component. However, fees may be charged in the following scenarios:
ack-koordinator is an 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 as 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 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.
Procedure
Create a file named configmap.yaml based on the following ConfigMap content:
# Example of the ack-slo-config ConfigMap. apiVersion: v1 kind: ConfigMap metadata: name: ack-slo-config namespace: kube-system data: # Enable the CPU QoS feature. resource-qos-config: | { "clusterStrategy": { "lsClass": { "cpuQOS": { "enable": true, "groupIdentity": 2 } }, "beClass": { "cpuQOS": { "enable": true, "groupIdentity": -1 } } } }
Specify
lsClass
andbeClass
to assign the LS and BE classes to different pods.cpuQOS
includes the CPU QoS parameters. The following table describes the parameters.Parameter
Type
Valid value
Description
enable
Boolean
true
false
true: enables the CPU QoS feature for all containers in the cluster.
false: disables the CPU QoS feature for all containers in the cluster.
groupIdentity
Int
-1~2
Specify group identities for CPU scheduling. By default, the group identity of LS pods is 2 and the group identity of BE pods is -1. A value of 0 indicates that no group identity is assigned.
A greater
group identity
value indicates a higher priority in CPU scheduling. For example, you can setcpu.bvt_warp_ns=2
for LS pods and setcpu.bvt_warp_ns=-1
for BE pods because the priority of LS pods is higher than that of BE pods. For more information, see Group identity feature.NoteIf
koordinator.sh/qosClass
is not specified for a pod, the ack-koordinator component configures the pod based on the original QoS class of the pod. The component uses the BE settings in the preceding ConfigMap if the original QoS class is BE. The component uses the LS settings in the preceding ConfigMap if the original QoS class is not BE.Check whether the
ack-slo-config
ConfigMap exists in thekube-system
namespace.If the
ack-slo-config
ConfigMap exists, we recommend that you run the kubectl patch command to update the ConfigMap. This avoids changing other settings in the ConfigMap.kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)"
If the
ack-slo-config
ConfigMap does not exist, run the following command to create a ConfigMap named ack-slo-config:kubectl apply -f configmap.yaml
Create a file named ls-pod-demo.yaml and copy the following content to the file:
apiVersion: v1 kind: Pod metadata: name: ls-pod-demo labels: koordinator.sh/qosClass: 'LS' # Set the QoS class of the pod to LS. 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 restartPolicy: Never schedulerName: default-scheduler
Run the following command to deploy the ls-pod-demo pod in the cluster:
kubectl apply -f ls-pod-demo.yaml
Run the following command to check whether the CPU group identity of the LS pod in the control group (cgroup) of the node takes effect:
cat /sys/fs/cgroup/cpu/kubepods.slice/kubepods-pod1c20f2ad****.slice/cpu.bvt_warp_ns
Expected output:
# The group identity of the LS pod is 2 (high priority). 2
Create a file named be-pod-demo.yaml and copy the following content to the file:
apiVersion: v1 kind: Pod metadata: name: be-pod-demo labels: koordinator.sh/qosClass: 'BE' # Set the QoS class of the pod to BE. spec: containers: - args: - '-c' - '1' - '--vm' - '1' command: - stress image: polinux/stress imagePullPolicy: Always name: stress restartPolicy: Always schedulerName: default-scheduler
Run the following command to deploy the be-pod-demo pod in the cluster:
kubectl apply -f be-pod-demo.yaml
Run the following command to check whether the CPU group identity of the BE pod in the cgroup of the node takes effect:
cat /sys/fs/cgroup/cpu/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod4b6e96c8****.slice/cpu.bvt_warp_ns
Expected output:
# The group identity of the BE pod is -1 (low priority). -1
The output shows that the priority of the LS pod is high and the priority of the BE pod is low. CPU resources are preferably scheduled to the LS pod to ensure the service quality.
FAQ
Is the CPU QoS feature that is enabled based on the earlier version of the ack-slo-manager protocol supported after I upgrade from ack-slo-manager to ack-koordinator?
In an earlier version (≤ 0.8.0) of the ack-slo-manager protocol, the alibabacloud.com/qosClass
pod annotation is used.
ack-koordinator is compatible with the earlier versions of the ack-slo-manager protocol. You can seamlessly upgrade from ack-slo-manager to ack-koordinator. ack-koordinator is compatible with the earlier protocol versions until July 30, 2023. We recommend that you upgrade the resource parameters in an earlier protocol version to the latest version.
The following table describes the compatibility between different versions of ack-koordinator and the CPU QoS feature.
ack-koordinator version | alibabacloud.com protocol | koordinator.sh protocol |
≥ 0.5.2 and < 0.8.0 | Supported | Not supported |
≥ 0.8.0 | Supported | Supported |