Mobile, Cloud & DevOps Tools

Kubernetes Resource Calculator

Add up CPU and memory requests and limits across deployments and replicas, see each pod's QoS class, and check how many pods fit on a node after system reservations, with quantities parsed exactly as Kubernetes does.

  • Totals and QoS per pod
  • Pods per node
  • Overcommit warnings
Runs in your browser

Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics.

K8s resources workspace

1 Workloads

Examples:
Add a workload without writing YAML

2 Node size

Reservations (kubelet)

Managed services reserve their own amounts - check your provider's allocatable figures and enter them here.

3 Totals and fit

Paste workloads or load an example, then choose Calculate.

What the Kubernetes Resource Calculator does

This calculator adds up the CPU and memory requests and limits of your Kubernetes workloads, across every replica, and works out each pod's quality-of-service class, how many pods fit on a node after the kubelet's reservations, and the fewest nodes that can hold everything you request. Quantities such as 250m, 0.5, 512Mi and 1G are read exactly as Kubernetes reads them.

Paste the YAML you already have, or add workloads with the small form. It is arithmetic in your browser: nothing is applied to a cluster or sent anywhere.

How to use it

  1. Paste Deployments, StatefulSets, DaemonSets, Jobs, CronJobs or Pods - several documents separated by ---, or a JSON list. Services and other objects are skipped and listed.
  2. Or open "Add a workload" and enter a name, replicas, and the requests and limits; it writes the Deployment YAML for you.
  3. Enter the node size and count, and adjust the kubelet reservations to match your platform.
  4. Choose Calculate. Read the totals, the share of the cluster requested, the per-workload table and the warnings.

Reading the results

Requests are what the scheduler reserves; limits are what a container may use. A container with only limits gets requests equal to its limits, which is why a limits-only pod is Guaranteed.

The pod's effective request is the larger of its app containers plus sidecars, or its biggest init container plus the sidecars started before it - the rule from the Kubernetes documentation. RuntimeClass overhead is added on top.

Nodes needed is a lower bound: total requests divided by what one node can allocate after DaemonSets take their share. Real clusters need more for bin-packing, affinity, zone spreading and rolling-update surge.

Worked example: a web shop on three 4-CPU nodes

The example runs six web pods (500m CPU, 512Mi requested), one Postgres pod (2 CPU, 4Gi, requests equal to limits), a log agent DaemonSet (100m, 128Mi per node) and a nightly report CronJob with no resources.

Each node has 4 CPU and 16Gi. After 100m + 100m CPU and 1Gi + 500Mi + 100Mi memory for the kubelet, system and eviction threshold, 3,800m CPU and 14,760Mi are allocatable. Requests total 3,000m + 2,000m + 3 x 100m = 5,300m CPU - 46% of the 11,400m the three nodes offer.

After the log agent takes 100m on each node, 3,700m is free per node, and 5,000m of other requests need at least two nodes. Postgres is Guaranteed; the web pods are Burstable; the report job is BestEffort and is flagged because it requests nothing.

Formulas and scoring rules

Quantities
m = 1/1000; k M G T P E = 10^3..10^18; Ki Mi Gi Ti Pi Ei = 2^10..2^60CPU is rounded up to whole millicores, as the API server does.
Pod request
max(sum(app) + sum(sidecars), max over init i of (init_i + sidecars started before i)) + overhead
Allocatable
capacity - kube-reserved - system-reserved - eviction threshold (memory)
Pods per node
min(floor(alloc CPU / pod CPU request), floor(alloc memory / pod memory request), max pods)
Nodes needed (lower bound)
ceil(max(CPU requests / free CPU, memory requests / free memory, pods / free slots)), free = allocatable - DaemonSet requests

The three QoS classes, briefly

Guaranteed pods set CPU and memory limits on every container, with requests equal to limits. BestEffort pods set no requests or limits at all. Everything else is Burstable. When a node runs short of memory, the kubelet evicts BestEffort pods first and Guaranteed pods last.

CPU and memory behave differently at their limits: a container over its CPU limit is throttled, while one over its memory limit is killed. That is why the calculator treats overcommitted CPU limits as a note and overcommitted memory limits as a warning.

Limitations: what the result does not prove

  • It reads the manifests you paste. LimitRange defaults, ResourceQuota, admission webhooks and Vertical Pod Autoscaler changes applied in the cluster are not known.
  • Node figures are what you enter. Managed services such as EKS, GKE and AKS reserve their own amounts, which vary by node size - use your provider's allocatable figures for accuracy.
  • Only CPU and memory are summed. GPUs, ephemeral storage and extended resources are not.

Privacy: where your data goes

Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.

Standards and sources

Frequently asked questions

What does 500m CPU mean in Kubernetes?

m means thousandths, so 500m is half a CPU core - 0.5 and 500m are the same. Kubernetes rounds CPU to whole millicores, so 0.0005 becomes 1m.

What is the difference between Mi and M?

Mi is a mebibyte, 1,048,576 bytes; M is a megabyte, 1,000,000 bytes. 128Mi is about 134.2M. Mixing them up changes memory requests by about 5% at Mi and 7% at Gi.

What happens if I set a limit but no request?

Kubernetes sets the request equal to the limit. That can make a pod much larger to the scheduler than you intended, and if CPU and memory are both set that way on every container, the pod becomes Guaranteed.

How is the request of a pod with init containers calculated?

Init containers run one at a time before the app, so the pod needs the larger of the biggest init container and the sum of the app containers. Sidecars - init containers with restartPolicy Always - keep running, so they add to both.

Why are fewer pods fitting on my nodes than this says?

The figure here uses requests only. The scheduler also respects taints, affinity, topology spread, pods already running such as system add-ons, and volume or port limits. Compare with kubectl describe node for real allocatable and allocated values.

Should I set CPU limits?

Opinions differ. Limits stop a noisy container using spare CPU, but also throttle it when the node is idle. Many teams set memory limits always and CPU limits only where predictability matters. The calculator shows totals either way and never enforces a policy.

Last reviewed by the A2Z.Tools team against the sources listed above.

Rate this tool

Was this tool useful? Your feedback helps us improve it.

No ratings yet — be the first to rate this tool.
Your rating (required)
0 / 2000

Please do not include passwords, payment details or other sensitive information.

Your feedback is sent privately to the A2Z.Tools team and will not be posted publicly.