Stop Using CPU Limits in Kubernetes: They Make Apps Slow and Costly
For the love of god stop using CPU limits in Kubernetes
A platform engineering analysis tests the same app with and without a CPU limit, finding that limits freeze apps many times per second even when the node has idle CPU, wrecking tail latency and slowing startup by 2x. The author argues that CPU limits provide no protection that requests don't already offer, while wasting idle capacity and driving up costs. They recommend removing CPU limits, keeping requests, and keeping memory limits, with a rollout plan and cost model showing potential savings of tens of thousands of dollars per cluster per year.
A limit low enough to actually trip only harms the pod it is attached to, never the neighbor it was meant to protect.
- conradludgate
While I agree that CPU limits tend to make your performance worse, I don't think the delivery of the post is all too convincing (and is pretty heavy on the LLM-isms that it's putting me off from reading).
It mentions that a cpu request is a guarantee, but how is that enforced? If I have 32 pods running on a 32 core machine, each with 1cpu requested, what stops one of those pods using an unfair share? I assume we just rely on the Linux scheduler. If I have 16 pods with 1cpu and 1 pod with 16cpu, does the Linux scheduler make sure to give the 16cpu pod more time? Or are we back to using cgroups.
- sjbzbeiks
This always sounds good on paper and this is very common lore, but then when you get into production escalations a very common problem is a lot of software depends on limits for autoconfiguration of thread pools and even several runtimes (go and java for example, at least .net is mentioned in the article), yes you can usually set them with a flag but people have to know this, communicate it, enforce it. Basically replace adhoc what limits is doing for you automatically configuration wise
So this just all assumes you have a setup where all teams communicate the necessary information perfectly.. what happens in practice is workloads degrade at edge cases because there are 256 threads running for a thread pool instead of 4.
- dwedge
Just give me the prompt
- inigyou
AI wrote most of this
- aairey
How is this “news”?
It was already the case in 2018.
Also, no mention of the scheduler overhead.
And the maintenance overhead is the worst.