Pinning exclusive CPU cores to a pod

WHAT THIS TESTS This is an advanced node-tuning question. It checks whether you know that CPU pinning requires a specific kubelet policy plus a precise pod QoS class, and the strict resource-definition prerequisites.

A GOOD ANSWER COVERS The kubelet must run with the static CPU Manager policy, set via cpuManagerPolicy=static; the default is none, which only uses CFS shares and quotas. For a pod to receive exclusive cores under the static policy, it must be in the Guaranteed QoS class. That requires every container to specify CPU and memory limits equal to their requests, and critically the CPU value must be a whole integer, such as 2 not 1500m. When these conditions hold, the kubelet removes those cores from the shared pool and assigns them exclusively to that container, avoiding context switches and improving cache locality and tail latency. Reserved system cores stay protected via kubeReserved and systemReserved.

COMMON WRONG ANSWERS Saying fractional CPU like 1500m works is wrong; only integer requests qualify for exclusive cores. Claiming a Burstable pod, where requests do not equal limits, gets pinned cores is incorrect. Forgetting that changing the policy requires draining the node and clearing CPU Manager state is an operational miss.

LIKELY FOLLOW-UPS How Topology Manager aligns CPU and device NUMA affinity. What full-pcpus-only option does. Why you must drain a node to change the policy.

ONE CONCRETE EXAMPLE A market-data feed container requests and limits cpu: 4 and memory: 8Gi. With static policy enabled, the kubelet hands it four dedicated physical cores, isolating it from noisy neighbors and slashing scheduling jitter.