Kubernetes CPU Limits Can Trigger Application Freezes and Latency Spikes
Technical analysis shows that hard CPU limits often cause throttling and collapsed tail latency, even when underlying nodes have idle capacity.
Setting hard CPU limits in Kubernetes may be counterproductive, potentially causing applications to freeze multiple times per second and severely degrading performance. A technical analysis published by inevolin demonstrates that these limits often lead to collapsed tail latency during traffic peaks, regardless of whether the underlying node has available CPU capacity.
According to the research, this performance degradation is driven by the Linux kernel's Completely Fair Scheduler (CFS) quota mechanism. When a container exceeds its defined CPU limit within a specific time slice, the CFS quota throttles the process, effectively freezing the application. This occurs even if the rest of the system is idle, meaning a safety measure intended to protect the cluster actually penalizes the application. The research highlights that CPU-bound startup work can finish approximately twice as fast when these limits are removed.
The Mechanics of Requests vs. Limits
To understand this impact, it is necessary to distinguish between 'requests' and 'limits' in Kubernetes. CPU requests define the minimum amount of CPU a container is guaranteed, providing the actual protection by ensuring each application receives its required share of resources. In contrast, limits define the maximum consumption allowed. While many platform engineers implement limits to prevent 'noisy neighbors' from consuming all node resources, the CFS mechanism transforms these limits into hard ceilings that trigger throttling.
Why Performance Suffers
This distinction is critical because the resulting latency spikes can lead to unstable production environments. When an application is throttled, P99 tail latency typically spikes, making the service feel sluggish or unresponsive to users during peak loads. This creates a paradox where applications become slower and more costly to run because engineers may over-provision resources to compensate for the performance hits caused by the limits themselves.
Recommended Configuration
Based on the findings, the author recommends removing CPU limits while maintaining CPU requests to ensure guaranteed resources without the penalty of hard throttling. However, this advice does not extend to memory. The research emphasizes that memory limits should be retained because memory management differs fundamentally from CPU management; memory limits remain necessary to protect the node from Out-of-Memory (OOM) events.
Moving forward, platform teams should monitor CFS throttling metrics to determine if their current limit configurations are causing artificial bottlenecks. The primary goal is to shift toward a model that guarantees minimums via requests while allowing applications to burst into idle capacity when available.