Updated on 2024-11-12 GMT+08:00

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.

  1. Log in to the CCE console and click the cluster name to access the cluster console.
  2. Choose Nodes in the navigation pane and click the Node Pools tab on the right. Locate the target node pool and choose More > Manage.
  3. On the Manage Configurations page, change the cpu-manager-policy value to static in the kubelet area.

  4. Click OK.

Allowing Pods to Exclusively Use the CPU Resources

Prerequisites:

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.

Example YAML:
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.

Log in to the node where the workload is running and check the /var/lib/kubelet/cpu_manager_state output.
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.