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.

Workload (Pod Requests)

CPU request per pod (millicores) 1 core = 1000m. E.g. 250m = a quarter core.

Memory request per pod (Mi) 1 GiB = 1024 Mi.

Replica (pod) count

Node

CPU per node (cores)

Memory per node (GiB)

System + Kubernetes overhead (%) Capacity reserved for kube-reserved, system-reserved and the eviction threshold. Typically 10-15%.

Monthly cost per node (optional) Currency-agnostic; leave blank to hide cost.

Results

Enter your values and press "Calculate".

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 — the same node-sizing math runs a small production k3s cluster 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    263Mi

k3s v1.33.5 · 2 nodes · 194 days uptime · 4-10% CPU and 38-49% memory usage in steady state.