Container CPU Request Calculator for Home Labs

Your new service deploys to your home lab without any problems. It works great for a few hours, but then there’s a traffic spike or a nightly backup job and things slows down on your node. 9 times out of 10, it’s not the hardware. It’s typically the way scheduler gave you not enough CPU for your pod.

For most people, Kubernetes CPU requests is treated as static hardware slots. They’ll give each of their containers a flat value and cross their fingers. That breaks down in two scenarios: when services gets throttled or resources go to waste. What you’ve mixed up is that the process doesn’t do what scheduler sees. A Kubernetes request isn’t a guarantee of dedicated CPU time. It’s a request for scheduling capacity. By setting a request, you’re asking cluster to reserve capacity for you; even while you sit idle. Limits are an actualy measure of consumption and is a hard ceiling. The kernel will throttle your pod when it exceed this limit.

How to Set CPU Requests and Limits in Kubernetes

What you need to know is what it’s measuring. Do you set a request so high as to starve other workload? Do you set a limit too low such that your API gets sluggish during small spikes? What about comparing a Java app to a static website? Running a simple Nginx container that serves cached images take two milliseconds of CPU for each request. The same operation on a JVM-based service would of took seventy milliseconds. It also uses a lot of resources while idling because background threads and garbage collection processes is running. Sizing them the same way will either mean you’re over-provisioning your static site or under-provisioning your Java app.

You can let the calculator do the math (you just have to give it the data). First, measure how much CPU it use per request, not just what its average load is. Say your API gets 50 requests a second and spends 20ms doing some compute per request. That’s about a thousand millicores. Add some extra for latency tolerance or sidecar buffers, that will support your load. Lots of admins do neither; they’ll estimate based off solely the kind of container. This results in instability.

Second, consider quiet hours. Your process will consume CPU even when there aren’t requests. Telemetry exporters, health checks, and event loops all still draw power. If you don’t consider your idle baseline, your actual minimum workload will be higher than your requests.

What are millicores? And then there’s Node capacity. Each Raspberry Pi 5 core can do something, but you still need some of it for the operating system and kubelet. Even though that is a four-core Raspberry Pi, the raw specs does not matter much. It will usually only have about three thousand four hundred millicores available for pods. The “usable scheduling units” section on the page translates various hardware profiles into those terms.

Why does this matter? Oversubscribing makes it impossible for the system to cope. If you set up pods requesting three thousand eight hundred millicores when you only have three thousand four hundred free on your node, you create a physical impossibility.

Lastly, think about how the work bursts. Some workloads aren’t even smooth. Maybe a background worker processes a queue, sitting idly for minutes at a time before spiking to full capacity. Or perhaps you have a web API that must react quickly and be both smooth and predictable. The difference should show in how you size things. Size the worker conservatively so that it doesn’t flatten your node. Give the API more head room so it can absorbs unexpected traffic spikes without throttling.

More than anything, it’s not so much getting the precise number right as it is establishing the bounds of what is an acceptable performance. Get your requests right and your scheduler does its thing for you. Get your limits wrong and now you’re fighting your infrastructure.