CPU Requests Place Pods; CPU Limits Throttle Them

A Pod can fit on a node and still have its CPU use slowed later. The two decisions happen at different times. Kubernetes uses CPU requests when scheduling a Pod. On Linux, the kernel enforces CPU limits by throttling after a container starts.

Requests decide where a Pod can run

A CPU request tells the scheduler how much CPU to account for when placing a Pod. The scheduler compares the requests of Pods already assigned to a node with the CPU available to Pods there. It can reject a placement even when current CPU use is low. For a Pod with several containers, their CPU requests contribute to the Pod’s total request.

A request is also relevant after placement. On a contended Linux node, a larger CPU request typically gives a container a larger share of CPU time. When spare capacity exists, a container can use more CPU than it requested. The request alone does not set a runtime ceiling. These behaviors are described in the Kubernetes resource guide.

Limits cap CPU time during execution

A CPU limit sets a hard ceiling for a running container. The kubelet passes the limit to the container runtime. On Linux, the runtime typically configures a control group, and the kernel delays further execution when the container uses its allowed CPU time within a scheduling interval. That delay is CPU throttling. A node can have spare CPU while a container is throttled by its own limit. See the Kubernetes explanation of enforcement.

Consider a container with a request of 250m and a limit of 500m. The request accounts for one quarter of a CPU unit at placement. The container may use more while CPU is available, but the limit caps it at half a CPU unit. Kubernetes uses these same quantities in its container example. If you set only a CPU limit, Kubernetes copies it into the request unless an admission mechanism has already supplied a default request.

What to do

1. Set a CPU request for each container based on the CPU it needs during normal operation. Check the sum against node allocatable CPU and existing requests with kubectl describe nodes.
2. If a Pod stays pending, inspect its events with kubectl describe pod. An insufficient CPU event points to a placement problem, even if current use looks low.
3. Decide whether each container needs a CPU limit. If it does, test the workload under its expected bursts and watch for throttling. Adjust the limit when it restricts useful work.

The Kubernetes troubleshooting guide shows the node and Pod checks.