Kubernetes Resource Calculator

Turn usage numbers into requests, limits and quota YAML with the QoS class explained — entirely on this device.

RecommendationQoS class: —

	CPU	Memory
Requests	—	—
Limits	—	—

Namespace totals

Pods—
Total requests—
Total limits—

YAML

The YAML snippets appear here once the inputs parse.

Press ? for shortcuts

Do it offline:$

How to use it

Run kubectl top pods against your cluster and copy one pod's CPU and MEMORY columns into the two usage fields, suffixes included (500m, 640Mi).
Set how many replicas will run and a headroom percentage — requests become usage plus that margin, rounded up to whole millicores and whole Mi.
Pick the QoS target: Guaranteed pins every limit to its request; Burstable doubles the memory request for the limit and leaves CPU without one.
Copy the tab you need — the container resources block, LimitRange defaults for the namespace, or a ResourceQuota sized to the replica count.

Paste one pod's observed usage — CPU as 500m or 0.5, memory as 640Mi or 1G — pick a headroom margin and a QoS target, and read back requests, limits, the derived QoS class and namespace totals, with container, LimitRange and ResourceQuota YAML ready to copy. All arithmetic runs in this tab; nothing you type is transmitted.

Examples

cpu 500m · memory 512Mi · replicas 3 · headroom 20% · Guaranteed

requests    cpu 600m · memory 615Mi
limits      cpu 600m · memory 615Mi
qos         Guaranteed
namespace   pods 3 · requests 1800m / 1845Mi · limits 1800m / 1845Mi

resources:
  requests:
    cpu: 600m
    memory: 615Mi
  limits:
    cpu: 600m
    memory: 615Mi

The starter state. 512 × 1.2 is 614.4, and requests round up — never down — so memory lands on 615Mi while CPU lands exactly on 600m. Guaranteed means the limits row repeats the requests row.

cpu 0.5 · memory 640Mi · replicas 2 · headroom 25% · Burstable

cpu input   0.5 → 500m
requests    cpu 625m · memory 800Mi
limits      cpu not set · memory 1600Mi
qos         Burstable
namespace   pods 2 · requests 1250m / 1600Mi · limits not set / 3200Mi

A bare 0.5 is half a core, so the field echoes 500m before computing. Burstable sets the memory limit at twice the request and emits no CPU limit at all — the quota therefore carries no limits.cpu row either.

cpu 250m · memory 128Mi · replicas 1 · headroom 0% · Guaranteed

requests    cpu 250m · memory 128Mi
limits      cpu 250m · memory 128Mi
qos         Guaranteed
namespace   pods 1 · requests 250m / 128Mi · limits 250m / 128Mi

Zero headroom is legal and exact: requests equal the observed numbers to the millicore, limits equal the requests, and the class still derives as Guaranteed. Sensible for a batch job whose footprint you already trust.

Every example on this page is executed against the same engine that powers the tool, on every build.

Gotchas worth knowing

Mi is binary, M is decimal — and they differ by real gigabytes

128Mi is 134,217,728 bytes; 128M is 128,000,000. One suffix letter shifts a gigabyte-scale request by about 7%, which is why the memory field accepts both and echoes the byte count it parsed.

A bare memory number means bytes to Kubernetes

memory: 512 in a manifest is 512 bytes, and 400m is 0.4 of a byte — both legal, both almost never intended. This page refuses a unitless or m-suffixed memory value and asks for Mi or M explicitly.

The quota counts pods, not containers

ResourceQuota multiplies per-pod values by the replica count and pins pods to it. A two-container pod spends the sum of both against requests.cpu, so fold sidecars into the usage you paste.

Requests schedule; limits enforce

The scheduler books capacity from requests alone. At runtime, CPU past its limit is throttled, while memory past its limit draws the OOM killer — one is slowness, the other is a restart.

Headroom rounds up, never down

Requests are usage × (1 + headroom) taken to the next whole millicore and whole Mi — 512Mi at 20% is 614.4, printed as 615Mi — so a recommendation can never sit below what you actually measured.

LimitRange defaults act at admission only

The LimitRange tab fills default and defaultRequest for new containers that omit their own values; pods already running keep whatever they started with until they are recreated.

Common errors

Unknown suffix `MB` — this calculator accepts m, k, M, G, T, Ki, Mi, Gi and Ti.: Kubernetes quantities never use MB or GB; the suffix set is the resource.Quantity grammar's, and the legal list in the message is computed from the parser's own tables.
Negative quantity — CPU and memory requests and limits must be zero or positive.: The grammar technically allows a sign, but a negative request has no meaning for scheduling, so it is refused at the parser with the sign position anchored.
Headroom must be between 0% and 100% — got 250%.: Headroom is a safety margin, not a multiplier: 100% already doubles the request. Past that, pick round numbers deliberately rather than encoding them as margin.
Replicas must be a whole number from 1 to 999 — got 0.: Totals are per-pod values multiplied by the replica count, so zero pods would make them vacuous; the cap keeps the arithmetic in exact integer range.
CPU usage 10000001m is above the 10000000m cap (10000 CPUs).: Ten thousand full CPUs for one pod is beyond any node this calculator should size; the cap is named in the message and the same guard covers memory at 10000000Mi.

FAQ

Why must a Kubernetes limit be at least the request?

Because the request is a booking the limit cannot undercut: the API server rejects a container whose limit is below its request at admission. The scheduler reserves the requested amount on a node, and the limit only bounds usage above it. This calculator carries the same invariant — its Burstable memory limit is always a multiple of the request.

What does the QoS class change when a node comes under pressure?

When a node runs short of an incompressible resource, the kubelet prefers to evict pods whose usage exceeds their requests. A Guaranteed pod cannot be in that band — its usage is capped at limits, which equal its requests — so it holds the strongest protection, while BestEffort pods, with no requests at all, are reclaimed first. Exceeding a memory limit is a different event: the container is OOM-killed in any class.

Should I set CPU limits at all?

Kubernetes documents the mechanism and leaves the policy to you: a CPU limit is enforced by throttling — the container is never killed for CPU. One school therefore omits CPU limits so ready work can use idle cores, keeping requests as the fairness guarantee; another sets them where predictable multi-tenant behavior matters more than utilization. The Burstable tab takes the first position and says so on its card.

Keyboard shortcuts

⌘/Ctrl + Enter: Recalculate the recommendation immediately.
⌘/Ctrl + S: Download the active YAML tab as a .yaml file.
⌘/Ctrl + C: Copy the active YAML while nothing is selected.
⌘/Ctrl + Shift + C: Copy the active YAML even over an active selection.
t: Rotate the theme (idle while typing).
? or ⌘/Ctrl + /: Open the shortcut reference overlay.
Esc: Dismiss the topmost overlay.

Nothing you paste here leaves this tab. State only ever travels in links you explicitly create.

Kubernetes — Resource Management for Pods and Containers (requests, limits, enforcement) · Kubernetes — Configure Quality of Service for Pods (the class rules) · Kubernetes — Limit Ranges (namespace defaults and constraints) · Kubernetes — Resource Quotas (namespace hard caps, pod counts) · k8s.io/apimachinery — resource.Quantity (the suffix grammar and canonical form)

Last reviewed: 2026-08-18