Container CPU Limit Calculator

When your Kubernetes cluster starts acting funky but doesn’t throw any errors, it’s panic time. Health checks is showing green, pods are running, but things start taking seconds instead of milliseconds. You look at the logs and there’s nothing obvious. You look at memory use and everything seems okay. Then you look at CPU metrics and you see that you’ve throttled yourself into nothingness.

That’s what happens when containers don’t perform well, and most of the time it’s because you don’t understand how CPU limits and requests actualy operate. Practical Kubernetes limits and requests is calculated by measuring millicores, replicas, node size, latency needs, sidecars, and peak demand. Use the calculator above. Convert all those measured millicores, replicas, latency needs and more into concrete recommendations. The math’s done for you, so you can start to think about tradeoffs.

How to Set CPU Limits for Kubernetes

Most engineers don’t spend much time thinking about how to configure CPUs; they slap some number on a pod and hope for the best. What they fail to realize is that limits aren’t merely caps, limits are also latency tools. If you set a very strict limit, it protects you from a noisy neighbor… except when that limit is so low, it chops off healthy demand from CFS scheduler. What do you get? The service appears to be underutilized in average metrics, but it falls over at the worst possible moment when someone hits it with a burst of traffic.

That’s what everyone gets wrong. Average doesn’t matter. Only the peaks does. Those are what determine your user experience. Scheduling is determined by requests; how things run is restricted by limits. Why? Because the scheduler doesn’t view limits: it views requests.

For example, say you’re cost-conscious and want to set your request as small as possible so you use fewer nodes. Kubernetes packs as many pods onto each node as requested. And when all those pods wake up at once, they contend for resources. They won’t exceed their limit, that’s enforced. But why do they experience latency spikes due to contention? This happens because there request wasn’t large enough.

The page makes this clear in the reference table. It shows how various types of workloads balance competing demands. For instance, a CI runner can handles high limits with aggressive bursting (since it has flexible deadlines), whereas a database pod must have low burst ratios and predictable CPU. Every workload aren’t one-size-fits-all, otherwise you’re going to pay for inefficiency or sacrifice performance.

Then there’s the unseen weight of sidecars: A pod today almost never consists only of your application container. More likely, it has a log shipper, a telemetry agent or an Envoy proxy tagalong. Those containers eats up CPU as well, and failing to take their impact into consideration when doing your sizing math means starving your app container. Eighty millicores may not sound like much overhead, but multiply by hundreds of replica and it alters the whole capacity budget of your cluster. The tool does this math for you, so that your node fit calculations is grounded in reality, not some idealized assumption.

The other metric we think you should of look out for is throttling risk: what percentage of your runnable time will be spent in a throttled state? Even with as many cores as you want, if your throttled time is more than a tiny fraction of your runnable time, your p99 latency will still be bad. The calculator computes this risk based off your desired burst duration and ratio of requests to limit. Higher ratios means you can do lots of bursting, which helps keep your costs low. But this also means there’s danger of occasional throttles if your workload spikes, which isn’t good if you’re running latency-sensitive stuff. Choose your poison: do you want to pay a bit more for headroom so you know you won’t get throttled, or take the gamble with the occasional throttle to save money?

To conclude, At the end of the day, the size of your container CPU limits isn’t so much about picking the right answer as it is being aware of what each side of the balance means to you. How does reliability play off of efficiency? And how do both balance against isolation? Making decisions based on measured data instead of a gut feeling will help you get past the fear of silent throttling and create predictable clusters that perform well under load. Begin with your metrics, include some realistic headroom, and use math to define your limits, not your fears.