CPU Policy
Application Scenarios
By default, kubelet uses CFS quotas to enforce pod CPU limits. When a node runs many CPU-bound pods, the workload can move to different CPU cores depending on whether the pod is throttled and which CPU cores are available at scheduling time. Many workloads are not sensitive to this migration and thus work fine without any intervention. Some applications are CPU-sensitive. They are sensitive to:
- CPU throttling
- Context switching
- Processor cache misses
- Cross-socket memory access
- Hyperthreads that are expected to run on the same physical CPU card
If your workloads are sensitive to any of these items, you can use Kubernetes CPU management policies to allocate dedicated CPU cores (through CPU core binding) to these workloads. This will shorten scheduling latency and improve application performance. The CPU manager preferentially allocates resources on a socket and full physical cores to avoid interference.
A CPU management policy is specified by using kubelet --cpu-manager-policy. By default, Kubernetes supports the following policies:
- none: the default policy. The none policy explicitly enables the existing default CPU affinity scheme, providing no affinity beyond what the OS scheduler does automatically.
- static: The static policy allows containers in guaranteed pods with integer CPU requests to be use dedicated CPU resources on nodes through CPU core binding.
Notes and Constraints
The CPU management policy cannot take effect on physical cloud server nodes.
Enabling CPU Management for the Default Node Pool
When creating a cluster, you can enable CPU management in Advanced Settings.
- If this function is enabled, the static Kubernetes policy is used, where CPU core binding is used.
- If this function is disabled, the none Kubernetes policy is used, where CPU core binding is not used.
Enabling CPU Management for a Custom Node Pool
You can configure a CPU management policy in a custom node pool. After the configuration, the kubelet parameter --cpu-manager-policy will be automatically modified on the node in the node pool.
- Log in to the CCE console and click the cluster name to access the cluster console.
- Choose Nodes in the navigation pane and click the Node Pools tab on the right. Locate the target node pool and choose More > Manage.
- On the Manage Configurations page, change the cpu-manager-policy value to static in the kubelet area.
- Click OK.
Allowing Pods to Exclusively Use the CPU Resources
Prerequisites:
- Enable the static policy on the node. For details, see Enabling CPU Management for the Default Node Pool.
- Both requests and limits must be configured in pods and their values must be the same integer.
- If an init container needs to exclusively use CPUs, set its requests to the same as that of the service container. Otherwise, the service container does not inherit the CPU allocation result of the init container, and the CPU manager reserves more CPU resources than supposed. For more information, see App Containers can't inherit Init Containers CPUs - CPU Manager Static Policy.
You can use node affinity scheduling to schedule the configured pods to the nodes where the static policy is enabled. In this way, the pods can exclusively use the CPU resources.
kind: Deployment apiVersion: apps/v1 metadata: name: test spec: replicas: 1 selector: matchLabels: app: test template: metadata: labels: app: test spec: containers: - name: container-1 image: nginx:alpine resources: requests: cpu: 2 # The value must be an integer and must be the same as that in limits. memory: 2048Mi limits: cpu: 2 # The value must be an integer and must be the same as that in requests. memory: 2048Mi imagePullSecrets: - name: default-secret
Verification
Take a node with 8 vCPUs and 16 GiB of memory as an example. Deploy a workload whose CPU request and limit are both 2 on the node beforehand.
cat /var/lib/kubelet/cpu_manager_state
The command output is as follows:
{"policyName":"static","defaultCpuSet":"0-1,4-7","entries":{"de14506d-0408-411f-bbb9-822866b58ae2":{"container-1":"2-3"}},"checksum":3744493798}
- If the policyName is static, the policy has been configured.
- Value 2-3 indicates the set of CPUs that can be used by containers in the pod.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.