Kubernetes CPU Management: Static vs. None Policy

WHY IT EXISTS: The default Linux CPU scheduler (CFS) is designed for fairness, frequently moving tasks between CPU cores to give every process a turn. For most applications, this is fine. But for latency-sensitive workloads like real-time data processing or telco networking, this context switching causes performance-killing jitter and CPU cache misses.

THE MENTAL MODEL: Think of CPU allocation like seating in a movie theater. The default none policy is general admission: you grab any open seat, and might be asked to move. It's efficient for filling the theater. The static policy is like having a reserved, numbered seat: it's yours exclusively for the entire show, guaranteeing an undisturbed experience, but might leave other seats empty.

HOW IT WORKS: The policy is set on the kubelet for each node. The two main options are none and static. The none policy is the default, letting the operating system's scheduler manage all processes. The static policy creates two pools of CPUs. One pool is for pods that meet strict criteria: they must be in the Guaranteed Quality of Service (QoS) class and request a whole number of CPUs (e.g., 1, 2, 4). The kubelet pins these pods to exclusive CPUs. All other pods (BestEffort, Burstable, or fractional-CPU Guaranteed) are constrained to the second, shared pool of CPUs.

WHEN TO USE IT: Use the static policy for workloads where predictable low latency is more important than overall node utilization. This includes high-frequency trading (HFT), scientific high-performance computing (HPC), and Network Functions Virtualization (NFV) where processing jitter is unacceptable. Use the default none policy for the vast majority of general-purpose workloads like web servers and APIs.

WHEN NOT TO USE IT: Avoid the static policy if your primary goal is maximizing pod density. It can lead to CPU fragmentation, where a node has free cores, but not enough to satisfy a new Guaranteed pod's request, leaving those cores unused. This trades utilization for performance.

ONE CANONICAL EXAMPLE: A real-time packet processing application for a 5G network must run with minimal jitter. It is deployed as a Guaranteed pod with requests.cpu: "2" and limits.cpu: "2". On a node with the kubelet configured with --cpu-manager-policy=static, this pod will be granted two exclusive physical CPU cores, ensuring it is never preempted by other pods.