Kubernetes Resource Request/Limit Calculator
Turns observed CPU and memory usage into a starting `resources` block for a pod spec, plus a rough pods-per-node estimate for capacity planning. This is a starting point based on your numbers, not a substitute for actually watching real usage after deployment — but it beats guessing, which is what a lot of resource blocks in the wild are actually based on.
Requests and limits are answering two completely different questions
Requests are what the scheduler reserves for your pod when deciding which node to place it on — set this too low and the scheduler will happily overpack a node, leading to real contention once traffic actually arrives. Limits are the hard ceiling enforced at runtime. Exceed the CPU limit and the container gets throttled, which is bad for latency but recoverable. Exceed the memory limit and the container gets OOMKilled immediately — no throttling, no warning, just a restart. That asymmetry is exactly why memory limits deserve more caution than CPU limits.
Why CPU and memory get treated differently here
CPU is compressible — a process that needs more CPU than its limit just runs slower, it doesn't crash. That's why a generous CPU burst multiplier (2–3x average usage) is common and low-risk. Memory is not compressible — there's no "running slower" version of needing more memory than you have, the process is killed. That's why the memory limit here is calculated with a smaller headroom percentage rather than a large multiplier: too little headroom risks OOMKills under normal variance, but too much just wastes cluster capacity without adding real safety, since memory can't be reclaimed the way CPU throttling can.
The debate about CPU limits specifically
Some experienced Kubernetes operators deliberately skip setting a CPU limit at all, only setting a request — the reasoning is that CPU throttling under Linux's CFS quota mechanism can introduce latency spikes even when a node has spare CPU capacity sitting idle, a known and somewhat counterintuitive gotcha. There's a real tradeoff here between protecting neighbouring pods from a runaway process (which argues for a limit) and avoiding artificial throttling (which argues against one) — this calculator gives you a reasonable starting limit, but it's worth knowing this is genuinely debated rather than a universally settled default.
Numbers only mean something once you've measured for real
These figures are only as good as the usage numbers you feed in. Watch actual CPU and memory usage under real, ideally peak, traffic for at least a few days using Prometheus, Grafana, or your cloud provider's monitoring before finalising a production resource block — a calculator can do the arithmetic, but it can't know what your application actually does under load.