Millicores
- Input
- 500m
- Result
- 0.5 cores
1000m is one core. A request of 100m means the scheduler reserves a tenth of a core.
Kubernetes Resource Calculator
Convert millicores and memory suffixes, multiply them across replicas, and see the QoS class the kubelet will assign. The suffix table makes the Mi versus M gap concrete, which is where quiet overspend and surprise OOMKills come from.
Example workloads
QoS class: BurstableCPU limit is 5.0× the requestMemory limit is 2.0× the request
| Per pod | × 3 replicas | |
|---|---|---|
| CPU request | 0.1 | 0.3 |
| CPU limit | 0.5 | 1.5 |
| Memory request | 128Mi | 384Mi |
| Memory limit | 256Mi | 768Mi |
Manifest snippet
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 256Mi
# 3 replicas require
# cpu 0.3 cores requested, 1.5 at the limit
# memory 384Mi requested, 768Mi at the limitMi is not M
Kubernetes accepts both binary and decimal suffixes, and they are not the same size.
| Suffix | Bytes | Suffix | Bytes | Difference |
|---|---|---|---|---|
| 1Ki | 1,024 | 1k | 1,000 | +2.4% |
| 1Mi | 1,048,576 | 1M | 1,000,000 | +4.9% |
| 1Gi | 1,073,741,824 | 1G | 1,000,000,000 | +7.4% |
So 1G is 1G while 1Gi is 1Gi — about 7% more.
Runs entirely in your browser. This page is a static file. Whatever you type stays in the tab, is never sent to a server, and is gone when you close it — so pasting a real token or config is safe.
When you reach for this
- Sizing a Deployment and needing to know how much cluster capacity the replica count will claim.
- Working out why a pod is Burstable when you meant it to be Guaranteed.
- Translating a docker-compose memory limit into the units a manifest expects.
Worked examples
The suffix that costs money
- Input
- 1000M vs 1Gi
- Result
- 1,000,000,000 vs 1,073,741,824 bytes
Writing M where you meant Mi gives the container about 7% less memory than intended.
Guaranteed QoS
- Input
- requests == limits
- Result
- Guaranteed
Only when both CPU and memory requests exactly equal their limits. Anything else is Burstable and gets evicted sooner under pressure.
Where people get this wrong
Writing M when you mean Mi
512M is 512,000,000 bytes; 512Mi is 536,870,912. The manifest is valid either way, so nothing warns you — the pod just gets less memory than the number suggests.
Setting a CPU limit far above the request
A limit many times the request lets the pod burst, then get throttled hard the moment the node is busy. Latency spikes that look like application bugs often trace back to CFS throttling.
Omitting requests entirely
A pod with no requests is BestEffort and is the first thing evicted when a node runs short. It also gives the scheduler nothing to plan with, so nodes fill unevenly.
Frequently asked questions
What is the difference between a request and a limit?
The request is what the scheduler reserves when placing the pod; the limit is the ceiling the kernel enforces at runtime. Requests decide where a pod lands, limits decide when it gets throttled or OOMKilled.
How is the QoS class decided?
Guaranteed means every container has CPU and memory requests equal to its limits. BestEffort means no requests or limits at all. Everything in between is Burstable, which matters because eviction happens in that order.
Should I set a CPU limit at all?
Many teams set memory limits but leave CPU unlimited, because exceeding a memory limit kills the container while exceeding a CPU limit merely throttles it — often at a worse cost to latency than letting the pod use idle capacity.