In a Kubernetes manifest, what is the difference between `512M` and `512Mi` for a memory request or limit?
Quick Answer
`512M` is decimal (SI): 512 × 1,000,000 = 512,000,000 bytes. `512Mi` is binary (IEC): 512 × 1,048,576 = 536,870,912 bytes — about 24 MB more. Kubernetes, the Linux kernel, and container runtimes all count memory in binary, so you should almost always use the `Mi`/`Gi` suffixes.
Detailed Answer
Kubernetes accepts two families of memory suffixes. The plain SI suffixes k, M, G, T are powers of 1000 (decimal), while the IEC suffixes Ki, Mi, Gi, Ti are powers of 1024 (binary). So 512M = 512 × 10^6 = 512,000,000 bytes, but 512Mi = 512 × 2^20 = 536,870,912 bytes.
The gap looks small per pod (~24 MB here) but it compounds with size: 4G is only ~93% of 4Gi (a ~280–295 MB shortfall). Because the kubelet converts your quantity to an exact byte count and writes it into the container's cgroup memory limit, and the kernel OOM killer enforces that exact byte count, an app sized for '4 GiB' but given a 4G limit can be OOMKilled.
Rule of thumb: use Mi/Gi for memory so your intent matches how the kernel and runtimes actually account for it.
Code Example
resources:
requests:
memory: "512Mi" # 536,870,912 bytes (binary — recommended)
limits:
memory: "512Mi"
# Avoid:
# memory: "512M" # 512,000,000 bytes (decimal — ~24MB less than you think)Interview Tip
State the exact byte math for both, then say the kernel/cgroups count binary — that shows you understand *why* Mi/Gi is the safe default, not just that it is.