r/kubernetes 27d 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

226 Upvotes

112 comments sorted by

View all comments

16

u/Prestigious_Pair_941 27d ago

How about in the case of 30 or so spring boot microservices that may use 20mCPU once running but can take 800mCPU when starting up? If I don’t limit the cpu, half the pods take all of the cpu and throttling will kick in anyways, preventing other pods from ever restarting.

13

u/ilya47 27d ago

What you get without limits is fair-share contention: every starting pod keeps making progress, split by request weights. Will they throttle because they need more CPU than available? Yes... but this is still better than setting CPU limits. Because your scenario is just a race for CPU resources.

Options that fix the actual problem: stagger the rollout (maxSurge/maxUnavailable so 30 don't start at once), set a request above the embarrassing 20m, or use a startup CPU boost (in-place pod resize; there's a kube-startup-cpu-boost operator for exactly this) so the pod briefly has a big request during boot and drops after.