The m suffix on memory
memory: 100m is 0.1 BYTES, not 100 megabytes, and Kubernetes accepts it
memory: 100m
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.
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.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
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.
memory: 100m is 0.1 BYTES, not 100 megabytes, and Kubernetes accepts it
memory: 100m
512M is 512,000,000 bytes and 512Mi is 536,870,912
512M 512Mi
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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 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 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