In Kubernetes, memory 500m asks for half a byte. The developer set cpu to 500m, which correctly means half a core. Then they copied that same style into the memory lines, for both requests and limits. The suffix m means one thousandth, so memory gets a nearly empty budget.

When the developer runs apply, the API server only checks that 500m is a valid quantity. It is, so the pod is created and nothing complains. Later, the kubelet, the agent on each node, asks the runtime, the software that actually starts containers, to launch it. With a limit near zero, the container fails or gets killed, and the kubelet reports that back.

Here's a quick reference. The suffix m means milli, one thousandth. Mi and Gi are binary, powers of 1024, so one Mi is 1,048,576 bytes. M and G are decimal, powers of 1000. These suffixes scale the number the same way for any resource.

Look at the two sides. For CPU, 500m means 0.5, half a core, which is a sensible request. For memory, the very same 500m means 0.5 bytes, a tiny fraction of one byte. The suffix is just a scale. It doesn't know which resource it's describing.

Here are three memory values on one chart. The 500m bar is invisible, because it's half a byte. 500M is 500 million bytes, so 500 megabytes. 500Mi is about 524 million bytes, a bit larger. Changing one letter changes the scale enormously.

There's a smaller gotcha too. 500Mi is about 4.9 percent larger than 500M. Say an app peaks at 510 megabytes, as an illustrative number. A 500M limit sits below that peak, so the container gets killed. A 500Mi limit, about 524 megabytes, sits above it, so the app survives.

What you actually see depends on your runtime and environment. Some reject the tiny limit when creating the container. Others start it, then it's OOMKilled, meaning out of memory. As kubelet keeps restarting it, the pod ends up in CrashLoopBackOff.

Start with kubectl describe pod web. It shows the container's current state, why it last terminated, and recent events. Here, that's CrashLoopBackOff after OOMKilled. Then the Limits section shows memory: 500m. That's the clue. This output is illustrative, and the exact reasons may differ on your cluster.

To confirm, run kubectl get pod web with dash o yaml. That prints exactly what the cluster stored, and under limits you'll see memory: 500m, kept as written. Kubernetes never corrected it. The fix lives in your manifest: change it to 512Mi, then apply it again.

You can stop this before it reaches the cluster. Standardize on Mi or Gi for memory. Then add a CI lint step that flags milli units on memory, or an admission policy tool that rejects suspicious values before apply. No specific tool is required.

The suffix sets the scale; m means thousandth for everything. So write memory in Mi or Gi, and when a pod dies instantly, read back its resources.