When should Kubernetes workloads use CPU limits?
Asked by
VelvetPine42
The common advice is to avoid CPU limits, set requests, and let workloads burst when spare capacity is available. I understand the concern that CFS throttling can create latency and timeouts, but I'm wondering where the practical boundary is.
Why are CPU limits still a first-class Kubernetes feature if they're generally discouraged? For a multi-tenant SaaS platform, each pricing tier may be sold a fixed amount of CPU. If the workloads have been profiled and their resource needs are understood, would setting requests equal to limits and using Guaranteed QoS be a sensible way to provide isolation and prevent noisy neighbors?
Is the better rule "don't set CPU limits by default, but use them when you intentionally need a hard cap"? I'd like to hear about situations where CPU limits have worked well, as well as cases where they caused problems.
Answers
Be careful with runtimes that size themselves from the node’s total CPU count. Java, .NET, and some Go workloads can create too many workers or garbage-collection threads on a large node when the container only has a small intended allocation. That can cause high CPU usage and poor performance.
A CPU limit may make the runtime see the intended cgroup budget, but it’s usually better to configure the runtime explicitly with environment variables or startup options, such as the JVM’s CPU settings or Go’s GOMAXPROCS. Otherwise, removing the limit can fix throttling while leaving the application badly over-threaded.
Reply to this answer
“Don’t set CPU limits” is a useful default, not a universal law. Requests let the scheduler and Linux prioritize workloads fairly, while limits can throttle a process even when the node has spare CPU. That can turn a short burst into long request latency, especially for interactive services.
Limits make more sense when isolation, fairness, or predictable billing matters more than burst performance: fixed SaaS tiers, shared clusters with untrusted workloads, batch jobs, queue consumers, backups, and other workloads that can tolerate being slowed down. The important part is to set them deliberately and monitor throttling alongside application latency.
Reply to this answer
The kernel’s CPU quota enforcement is the main reason limits get a bad reputation. A container with a low quota can run briefly and then be throttled for the rest of the scheduling period. For a compute job that may be harmless; for a service making synchronous requests, those pauses can show up as timeouts and terrible tail latency.
Requests already influence CPU shares, so when the node is busy they provide a basis for fair scheduling without imposing a hard ceiling. Use limits when you truly need a ceiling or a QoS/isolation guarantee, and make sure you have metrics for throttled time, latency, in-flight requests, and saturation.
Reply to this answer
CPU limits are also useful for containing a runaway process. A busy loop or badly behaved pod can consume every available cycle and make the node unhealthy, even though other pods have requests. A generously sized limit is sometimes a practical compromise: it protects the node while still allowing normal bursts.
For latency-sensitive APIs, requests-only is often safer. For customer-facing workloads that promise a fixed CPU allocation, requests equal to limits can be reasonable—but only if the limit is high enough to avoid starving the application during normal spikes.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions