Set a safe CPU limit for a pod that avoids throttling while capping burst usage.
A CPU limit sets the hard ceiling the kernel's CFS bandwidth controller enforces — usage above the limit is throttled, not killed, but throttling still adds latency. This calculator derives the limit from the CPU request scaled by a headroom factor (typically 2–3×) and cross-checks it against observed peak usage, flagging throttle risk if the peak has historically exceeded that derived limit.
recommendedLimit = max(cpuRequest × headroomFactor, peakUsage)
Unlike memory, CPU is compressible — the kernel throttles the container's CPU time via cgroups rather than killing it. The pod keeps running but slows down, which can show up as latency spikes rather than crashes.
2× is a common default that allows moderate bursting. Latency-sensitive services handling unpredictable spiky traffic often use 3× or higher; steady batch workloads can use closer to 1.5×.
Not necessarily — some teams deliberately omit CPU limits (keeping only requests) to avoid artificial throttling on otherwise idle nodes, relying on requests alone for QoS and node bin-packing.