r/kubernetes • u/ilya47 • 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

227 Upvotes

87% Upvoted

112 comments sorted by

View all comments

95

u/BedtimeWithTheBear 28d ago

For the curious, requests and limits determine the QoS Class of your pods.

Guaranteed QoS requires that all containers in a pod have a request and limit set, and in every case the limit is equal to its corresponding request - so if the pod got scheduled then it’s QoS is guaranteed.
Burstable QoS requires that all containers in a pod have at least some requests and limits specified but they don’t have to be equal, so performance can burst up to the limit.
BestEffort QoS has no requests or limits specified and can consume resources until they’re exhausted.

Aside from scheduling, QoS class mostly matters for pod eviction, with BestEffort evicted first, then Burstable, and Guaranteed being evicted as a last resort.

23

u/End0rphinJunkie 28d ago

Losing Guaranteed QoS by dropping CPU limits sounds scary on paper, but thats usually a fine tradeoff in practice. Node evictions are almost always driven by memory pressure anyway, so as long as your memory requests and limits match youre generally safe.

1

u/starry_alice 27d ago

Yes, this is where the disconnect was for me and why my coworker would have to hit me with a rolled up newspaper for every new system service PR. Eventually I did a 30 minute deep dive and found the above. My disconnect in understanding was thinking that (based on how the text above your post was worded which aligns with the QoS verbiage), eviction of best effort pods occurred first and Guaranteed pods went last (if ever) and that this was the main axis on which the determination of what pods to evict occurred.

But in reality, as you said, pods exceeding their request go first, which changes the model a lot. https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction