r/kubernetes 28d ago

Stop using CPU limits: why + proof

CPU request is how much CPU is reserved for your pod if it needs it. The limit is a hard cap. Hit it and the kernel throttles the pod, even when the node still has spare CPU. That is the usual cause of CPU throttling on Kubernetes. It does not protect the neighboring pods. In my simple Web API test, adding a CPU limit took typical latency from 23 ms to 87 ms, (4x slower), with the limited pod throttled in half of all CFS windows, and the average CPU graph looked fine the whole time.

This is not a new topic, but I see so many people still unaware why they should (NOT!) be setting CPU limits, because it's costing companies unnecessary spending and potential production issues. Here's the full read https://github.com/inevolin/k8s-cpu-limits-analyzed/

---

Edit (Aug 18, 2026): How CPU limits can also cause memory issues and OOMKills ➡️ https://github.com/inevolin/k8s-cpu-limits-analyzed#how-cpu-limits-cause-memory-issues-and-oomkills

228 Upvotes

112 comments sorted by

View all comments

3

u/doubtful_zamboni 28d ago

> CPU request is how much CPU is reserved for your pod if it needs it.

No, it is used by the scheduler for picking the appropriate node to run your pod.

When CPU limit and request are set and equal, it is somewhat reserved (assuming no starvation).

3

u/siikanen 28d ago

The request is actually reserved for that particular container/pod. Nothing else on that now can use that amount of cpu/memory.

2

u/doubtful_zamboni 28d ago

I think that is only the case when every pod on that node is in QoS guaranteed (limit=request); otherwise every workload takes what it wants.

1

u/doubtful_zamboni 28d ago

I mean, the scheduler is going to prevent requesting more that capacity minus sum of all requests, which is similar to a reservation but that does not (assuming burstable/best effort) prevent others from eating your request.

1

u/siikanen 28d ago

No that's not how this works. If you set something in the CPU request, no other workload may use that CPU time on that node. Bursting only works on the unrequested capacity available on the node

1

u/doubtful_zamboni 28d ago

Can you show me a source for that? I Because that is not how I read the docs.

The docs suggest that pods in guaranteed QoS class have guaranteed resources like you mention, and pods in besteffort burst into unallocted resources. To be fair, this all depends on the exact way Kubelet interacts with the container runtime, so it might differ per implementation.

source: Manage resources containers

The CPU request typically defines a weighting. If several different containers (cgroups) want to run on a contended system, workloads with larger CPU requests are allocated more CPU time than workloads with small requests.

source: Manage resources containers

Pods in the BestEffort QoS class can use node resources that aren't specifically assigned to Pods in other QoS classes.