Skip to content

CPU pinning with cpuset in Kubernetes

CPU pinning in Kubernetes is a performance optimization feature that binds a Pod's containers to specific CPU cores. Unlike the default CPU sharing mechanism (cpushare), which allows containers to compete for CPU time across available cores, CPU pinning utilizes the Linux cpuset cgroup to grant a container exclusive access to a dedicated set of CPU cores^[400-devops__06-Kubernetes__k8s-paas__原理及源码解析__Kubernetes调度机制.md].

This dedicated binding significantly reduces the overhead associated with CPU context switching between processes, leading to substantial performance improvements for latency-sensitive or compute-intensive applications^[400-devops__06-Kubernetes__k8s-paas__原理及源码解析__Kubernetes调度机制.md].

Configuration Requirements

To enable CPU pinning, a Pod must satisfy specific configuration rules regarding its CPU resource requests and limits^[400-devops__06-Kubernetes__k8s-paas__原理及源码解析__Kubernetes调度机制.md]:

  1. Guaranteed QoS: The Pod must be classified as Guaranteed. This requires that every container in the Pod specifies both requests and limits for CPU, and that these values are equal^[400-devops__06-Kubernetes__k8s-paas__原理及源码解析__Kubernetes调度机制.md].
  2. Integer Value: The CPU requests and limits must be set to an equal integer value (e.g., 2, 4). Fractional values (e.g., 500m) or non-equal values will result in the default shared CPU behavior^[400-devops__06-Kubernetes__k8s-paas__原理及源码解析__Kubernetes调度机制.md].

Example Manifest

The following configuration creates a Pod that is pinned to 2 exclusive CPU cores. The specific cores are selected and allocated automatically by the kubelet^[400-devops__06-Kubernetes__k8s-paas__原理及源码解析__Kubernetes调度机制.md].

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "200Mi"
        cpu: "2"

Operational Considerations

When implementing CPU pinning, it is important to consider the stability of critical system components. Pods managed by [[DaemonSet]]s are particularly strong candidates for this configuration^[400-devops__06-Kubernetes__k8s-paas__原理及源码解析__Kubernetes调度机制.md].

Because DaemonSet Pods typically must run on every node in the cluster (or a specific subset), they should be configured with a Guaranteed QoS to prevent them from being evicted during resource contention. If a DaemonSet Pod is not Guaranteed and the node encounters memory pressure, the Pod might be evicted and immediately recreated, causing unnecessary churn and rendering the resource recovery action ineffective^[400-devops__06-Kubernetes__k8s-paas__原理及源码解析__Kubernetes调度机制.md].

Sources

^[400-devops__06-Kubernetes__k8s-paas__原理及源码解析__Kubernetes调度机制.md]