When should Kubernetes workloads use CPU limits?

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.

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.

“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.

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.