Kubernetes Quantity Parser

Paste one quantity per line, or a whole resources block straight out of a manifest. Every value is converted exactly, and the ones the API server would refuse are named with the reason. Nothing is uploaded.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Convert. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

The m suffix on memory

memory: 100m is 0.1 BYTES, not 100 megabytes, and Kubernetes accepts it

memory: 100m

M against Mi

512M is 512,000,000 bytes and 512Mi is 536,870,912

512M
512Mi

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Writing memory: 100m

    The m suffix means milli, so this requests one tenth of a BYTE. Kubernetes accepts it, the pod schedules anywhere, and it is then OOM killed immediately.

    Instead:Use Mi or Gi for memory. The m suffix is only meaningful for CPU.

  2. Using M where Mi was meant

    M is 1,000,000 and Mi is 1,048,576. Across a large deployment the difference is real capacity.

    Instead:Use the binary suffixes for memory, matching how every monitoring tool reports it.

  3. Setting a CPU limit expecting a guarantee

    A CPU limit is a throttle, not a reservation. The request is what the scheduler guarantees; the limit only caps the ceiling and causes throttling under load.

    Instead:Set requests to what the workload needs. Be cautious with CPU limits, which cause throttling even when the node is idle.

What it catches

A quantity is four characters long and there is no schema to check it against, which is why these mistakes reach production rather than review.

memory: 500m, which is half a byte

In Kubernetes m is milli. In Docker, in free -m, and in most of the tooling anyone used that week, m is mega. A memory value written with it is accepted by the API server, the pod is scheduled, and it is OOMKilled on the first allocation with nothing anywhere naming the cause. This is reported as a critical finding with the value it actually resolves to.

The suffixes that are refused outright

MB, GB and B are not Kubernetes suffixes and neither is uppercase K, which is a trap because it is the only suffix in the set that is lowercase. None of these round down to something workable: the API server rejects the object, and rejecting one field rejects the whole apply.

Exact arithmetic, not floating point

1Ei is 1152921504606846976 bytes, which is past the point where a double stops holding integers exactly. Values here are carried as an integer of digits with a decimal scale, and every conversion is a multiply by a power of two or ten, so the byte count for a Pi or Ei value is the real one rather than the nearest representable one.

The gap between Mi and M, as a number

1G is 6.9% less memory than 1Gi, and 1T is 9.1% less than 1Ti. Neither is wrong, but a limit set in decimal units next to a JVM flag set in binary ones is a container that gets killed at what looks like well under its limit. The difference is stated rather than left as folklore.

How Kubernetes reads a quantity

Every resource number in Kubernetes goes through one parser, which is why the same rules apply to CPU, memory, ephemeral storage and any extended resource a device plugin adds. It accepts three families of suffix, and the trouble comes from the two that look alike.

Three families, and only one of them is a power of two

Binary suffixes end in i and are powers of 1024. Decimal suffixes have no i and are powers of 1000. A scientific exponent is a third form that people rarely write by hand but templating tools emit constantly. Note that the kilo suffix is the only lowercase one, and that there is no suffix at all for bytes.

binary    Ki  Mi  Gi  Ti  Pi  Ei      1Ki = 1024
decimal   k   M   G   T   P   E       1k  = 1000
tiny      n   u   m                   1m  = 0.001
exponent  1e3 1.5e6 2E-3               1e3 = 1000

no suffix at all means bytes:  memory: 134217728

m is milli, and this is the one that costs money

For CPU it is what everyone expects: 100m is a tenth of a core, and it is the normal way to write CPU. For memory the same suffix means the same thing, one thousandth, and it is almost never what was meant. The manifest is valid, so nothing warns you.

cpu: 100m      0.1 of a core          correct and idiomatic
memory: 500m   0.5 of a BYTE          valid, accepted, fatal
memory: 500Mi  524288000 bytes        what was meant
memory: 500M   500000000 bytes        also plausible, 4.6% less

docker run -m 512m   ->  512 mebibytes
kubernetes 512m      ->  0.512 bytes

CPU is quantised to 1m, and finer values are refused

One millicore is the smallest unit of CPU that exists. A value with more precision than that is not rounded to the nearest millicore, it is rejected. This catches anyone converting from a percentage or dividing a core count in a template.

cpu: 0.5      -> 500m    fine
cpu: 0.001    -> 1m      fine, and the floor
cpu: 0.0005   -> rejected: more precise than 1m

and in practice, anything under about 10m starts so
slowly under CFS throttling that the pod looks hung

What the API server stores is not always what you wrote

Quantities are canonicalised on the way in. A fractional byte count is rounded up to a whole byte, and the value is re-serialised in the suffix family it was written in. This is why a value you set can come back out of kubectl get -o yaml looking different, which reads like something changed it.

written        stored
1024Mi         1Gi
1000000        1M
0.5            500m
1.5            1500m
1e3            1k