Cloud-Native Microservices With Kubernetes - 2nd Edition

CPU vs. Memory Is Time vs. Space

Regardless of Kubernetes, memory and CPU exhibit two distinct behaviors in resource management. Consider the following example:

• CPU—the computing power—is like time, regenerated every cycle. If you don't use it, you lose it. It's also referred to as a compressible resource. A compressible resource implies that if its usage reaches the limit, any process needing to use it will first need to wait for the CPU to become available. This is like having a waiting line with processes queuing up for CPU time slices. When a process (container) ends its cycles, the next process in line gets its turn. When the cycle ends, the CPU is available again for other processes, even if the first process hasn't used a slice of the CPU time allocated to it.

• Memory is akin to space in that it's a non-cyclical and incompressible resource. This means that if memory usage reaches its limit, any process requiring it will not be able to run. Think of memory as your room's storage capacity. Once it's full, you can't fit anything more in until you free up some space.

ℹ️ CPU is cyclical and shareable over time; memory is finite and must be freed before reuse.

When a container requests a specific amount of memory, it doesn’t necessarily consume all of it — it’s simply guaranteed access to that much memory when resources are shared among multiple containers on the same node. The container may use less, but Kubernetes guarantees that memory up to the requested amount is available if needed.

In practice, the container runtime translates this request into cgroup settings. Under cgroups v2, the memory request influences parameters like memory.min (guaranteed) and memory.low (best-effort), which define the minimum memory that should be protected from reclamation pressure. Meanwhile, the limit maps to memory.max, which sets the absolute ceiling that the container cannot exceed.