We are writing deployment manifests for our microservices but are confused about resource allocation. What exactly is the functional difference between setting a memory request versus a memory limit in a , and how do they impact scheduling?
3 answers
Memory requests and limits serve entirely different purposes in a . A memory request is used exclusively by the kube-scheduler during deployment to find a node that has enough unallocated capacity to host your pod; it represents the minimum guaranteed memory the pod needs to function. A memory limit, on the other hand, is enforced at runtime by the container runtime engine on the host node, acting as a strict hard ceiling that the container is never allowed to cross without being terminated.
If requests control scheduling and limits control runtime boundaries, what is the best strategy for setting the delta between them? Should our configurations keep them perfectly equal, or should we leave a wide gap for unexpected usage spikes?
Requests ensure your application secures a proper home on a node, while limits protect that node from being starved by a single rogue process.
Spot on, Evelyn. Striking the right balance between these two values is the core foundation of building an efficient and reliable cluster environment.
Keeping them equal places your pod in the "Guaranteed" QoS class, which makes it highly resilient against node eviction. Setting a wide gap creates a "Burstable" pod, which is cheaper but risks sudden eviction if the host node faces extreme resource pressure.