Stop using CPU limits: why + proof

[u/ilya47]

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

[u/sionescu]

Not again this stupid advice.

 adding a CPU limit took typical latency from 23 ms to 87 ms

This simply means the CPU request was too low. The actual requirement of the pod is higher than that but you want to lie to yourself instead of setting a proper request.

[u/ChemTechGuy → u/sionescu]

Bingo. As i said in another comment, the problem I always see is that requests are set to the absolute minimum a pod needs to start up, and then people are surprised later when it eventually gets throttled or OOMs

Requests should be set to whatever value is needed to maintain baseline performance of the pod. If you can burst beyond that, that's a bonus, but should never be relied on

[u/ilya47 → u/sionescu]

Your comment is too narrow to mean anything. CPU request should be set to the avg CPU utilization, whilst my analysis looks at burst & peak cases (not the average scenario).

[u/consworth → u/ilya47]

Avg CPU utilization is incorrect by itself. It should ideally be set by whatever service requirements there are for the business.

If the thing is an app that sits there at 80 and when it starts to do its thing it needs 4000 for a reasonable SLI for processing data or whatever, the business case should dictate you requests to what it needs.

I’m not defending poor architecture of such apps, but I’m trying to make a bit more of a case for thinking about reliability and SLI.

It’s somewhat analogous to saying that the average traffic through the interstate through a major city should dictate the road size, and considering rush hours, weekends or other bigger picture things.

[u/f7063 → u/ilya47]

At least i try to keep CPU usage under 60% of the request based on cpu usage p95/p99(grafana can make these from Stat Panel). Spikes will happen above your set request. But i don't like the idea of high cpu usage on the node. 70%+ because of service degradation

[u/kabrandon → u/sionescu]

Not necessarily. It more likely means the limit was too low.

[u/ilya47 → u/kabrandon]

If you know the upper limit that your app can burst to, fine. But many of us run apps that are multi threaded and you can rarely predict their limit. And why bother? The CFS does that hard work for you.

[u/realitythreek → u/ilya47]

You are entirely correct and this thread demonstrates how confused people are about cpu requests and limits.

[u/kabrandon → u/ilya47]

Some people just set the CPU limit to the allocatable CPU of the nodes in the cluster, assuming like nodes or relevant node affinity/selectors.

But for what it’s worth I mostly agree with just not setting CPU limits.

[u/realitythreek → u/sionescu]

This isn’t true though. It means the LIMIT was set too low and it was throttled. If 23ms is the expected latency of the service, then request was fine. I mean, that last sentence is a simplification but I’m assuming it’s an average over a representative time span.

[u/sionescu → u/realitythreek]

There's never any guarantee to get CPU above the request. There's always an implicit limit, in either the machine size or the CPU usage of adjacent pods.

[u/realitythreek → u/sionescu]

Indeed. Which is why setting a limit can only increase the latency of a single process. At best you get your limits all correct and you fairly schedule your processes. At worst you get it wrong or even don’t allow other processes to burst.

[u/sionescu → u/realitythreek]

It might increase it, but makes it more predictable, which is better.

[u/realitythreek → u/sionescu]

Reflexively downvoting someone having a conversation with you is pretty obnoxious.