Kubernetes Resource Budget Calculator
Compares your workload's CPU and memory requests against node size to show how many nodes you need, which resource is the bottleneck, and the projected monthly cost. Every calculation runs in your browser.
Last updated:
Results
Enter your values and press "Calculate".
Please enter valid numbers greater than zero in every field.
- Bottleneck resource
- CPU
- CPU utilization
- 41.7%
- Memory utilization
- 20.8%
- Pods per node (average)
- 6.0
- Estimated monthly cost
Assumes a maximum of 110 pods per node (kubelet default). DaemonSets, pod affinity and topology spread are not accounted for — this is a first-order estimate.
When this calculation actually earns its keep
Choosing an instance type
Node families differ far more in CPU-to-memory ratio than in price per core. Picking one before you know which resource your workload is bound by is how teams end up renting memory they never touch.
After an autoscaler surprise
A cluster autoscaler that keeps adding nodes is usually reporting a packing problem, not a load problem. Working out the binding resource by hand takes a minute and tells you whether to change the request or the node type. On my own cluster below the split is stark: CPU idles between 4% and 10% while memory sits at 38-49%, and a single GitLab pod holds 3.8 GiB against 61m of CPU.
Before a migration
Moving from one provider to another changes allocatable capacity even when the advertised specs match, because reserved amounts differ. Re-running the numbers against the target node shape avoids a nasty first invoice.
Worked example: paying for RAM you never use
A bursty public API: 60 replicas, 500m CPU and 384 Mi of memory requested per pod. Nodes are 8 vCPU and 32 GiB with 10% reserved for the system. Three separate limits get computed; the largest one wins.
- Allocatable per node: 7200m CPU and 29491 Mi of memory.
- CPU: 60 × 500m = 30000m. 30000 ÷ 7200 = 4.17 → 5 nodes.
- Memory: 60 × 384 Mi = 23040 Mi. 23040 ÷ 29491 = 0.78 → 1 node.
- Pod count: 60 pods against the 110-per-node ceiling. Not binding.
- Answer: 5 nodes, bound by CPU. That leaves memory sitting at roughly 16% used.
Five nodes are rented and five-sixths of the memory is dead weight. No amount of trimming memory requests helps here, which is exactly the opposite of the usual advice. The fix is the node shape: a compute-optimised family with half the RAM per core serves the same 60 replicas at a visibly lower monthly figure. Knowing which resource binds is what tells you which lever to pull.
Four mistakes worth avoiding
Treating limits as requests
The scheduler places pods on requests alone. Leaving the limit at 2 cores while the request sits at 100m means Kubernetes packs that pod as if it needed 100m. Nothing shows up on the invoice; latency shows up instead.
Confusing capacity with allocatable
A 16 GiB node will not take a 16 GiB pod. After kube-reserved, system-reserved and the eviction threshold, roughly 85-90% survives. That gap is what the overhead field above represents.
Forgetting the DaemonSets
Log shippers, metrics agents, CNI and CSI pods run one copy on every node, so their cost grows with the node count rather than the replica count. This calculator only covers your own workload; leave headroom on top.
Ignoring the 110-pod ceiling
Run enough small replicas and pod count becomes the binding limit while CPU and memory sit half empty. Buying bigger nodes does not help in that case; the kubelet max-pods setting is the thing to look at.
Tools commonly used alongside this one
- CIDR / Subnet Calculator Compute the network address, broadcast, subnet mask, usable host range and address type from CIDR notation.
- Cron Expression Parser Parse a cron expression field by field and see the next run times. For Kubernetes CronJobs and scheduled tasks.
- UUID Generator Generate cryptographically secure UUID v4 and time-ordered v7. Bulk generation and format options.
- Base64 Encoder-Decoder Encode text to Base64 or decode it back. Standard and URL-safe (base64url) variants; UTF-8 aware, in the browser.
Frequently Asked Questions
How many nodes does my Kubernetes workload need?
Node count is the largest of three limits: nodes required by CPU, by memory, and by pod count. The calculator works out each one and reports the largest as "nodes needed" — that limit is your bottleneck resource.
Why is a node's allocatable capacity lower than its total capacity?
Part of every node's capacity is reserved for the kubelet, container runtime and OS via kube-reserved and system-reserved, plus an eviction threshold. Pods are only scheduled onto the remaining "allocatable" capacity, which is why you enter an overhead percentage.
What is the default maximum pods per node?
The kubelet default is 110 pods per node. If you run many small replicas, this limit can become the bottleneck even when CPU and memory are plentiful.
Should I plan with requests or limits?
The Kubernetes scheduler makes placement decisions based on requests, not limits. This calculator uses request values for capacity planning. Limits affect throttling and OOM behaviour when a node is under pressure.
How accurate is this estimate?
It is a first-order capacity estimate. It does not account for DaemonSets, pod anti-affinity rules, topology spread constraints, vertical autoscaling or regional distribution. Use it as a baseline for production clusters, not a final figure.
Built from running real clusters
This calculator isn't theoretical: I use the same node-sizing math on the small production k3s cluster I run behind this site. Here is a current snapshot of it:
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
bilal-server Ready <none> 194d v1.33.5+k3s1
k8s-master Ready control-plane,master 194d v1.33.5+k3s1
$ kubectl top nodes
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
bilal-server 333m 4% 7828Mi 49%
k8s-master 784m 10% 12097Mi 38%
$ kubectl top pods -n default
NAME CPU MEMORY
bilal-baget-6d568d945f-4hljh 5m 142Mi
bilal-filebrowser-76c987d67b-mgwwt 1m 10Mi
bilal-gitlab-57db68cdf-4thml 61m 3843Mi
bilal-mssql-59467b7576-wrl24 34m 1450Mi
bilal-registry-5c86777897-tffxm 2m 381Mi
bilal-website-c46c6fb8f-ctnck 26m 219Mi
maya-website-58877c476c-hvj9q 74m 263Mik3s v1.33.5 · 2 nodes · 194 days uptime · 4-10% CPU and 38-49% memory usage in steady state.