Kubernetes Requests vs Limits: The Mental Model Most Teams Get Wrong

If your Kubernetes cluster has ever shown:

• Pods stuck in Pending
• Containers getting OOMKilled
• APIs slowing down without errors

There is a very high chance your resource requests and limits are wrong.

This post explains how requests and limits actually work in production, not how they are usually explained.

---

Requests vs Limits Are NOT a Min/Max Pair

Most engineers think:

Request = minimum
Limit = maximum

This mental model is dangerously incomplete.

In reality:

• Requests are used only by the scheduler
• Limits are enforced at runtime by the Linux kernel

They operate at different layers of the system.

---

1. What Requests Really Do (Scheduling Only)

A request tells Kubernetes:

“Do not place this pod unless this much CPU/memory is available.”

If no node can satisfy the request, the pod never starts.

kubectl describe pod <pod-name>
kubectl get events --sort-by=.lastTimestamp

If you see:

• Insufficient cpu
• Insufficient memory

The pod is blocked before runtime.

✅ Requests affect placement, not performance.

---

2. What Limits Really Do (Runtime Enforcement)

A limit tells the kernel:

“This container must not exceed this amount.”

What happens next depends on the resource.

---

CPU Limits → Throttling (Silent Performance Kill)

CPU is compressible.

If a container exceeds its CPU limit:

• It is throttled
• It keeps running
• Latency increases
• No crash
• No error logs

This is why CPU‑limited APIs can feel “slow” without obvious failures.

---

Memory Limits → OOMKill (Hard Kill)

Memory is not compressible.

If a container exceeds its memory limit:

• Kernel kills the process
• Pod restarts
• Status shows OOMKilled
• Exit code is usually 137

kubectl describe pod <pod-name>
kubectl top pod <pod-name>

If you see Reason: OOMKilled, your memory limit is below real usage.

---

3. Why Pods Stay Pending After “Small Changes”

This happens often in production:

• Someone increases memory request “to be safe”
• Requests now exceed node allocatable memory
• Autoscaler cannot add larger nodes
• Pod stays Pending forever

kubectl describe pod <pod-name>
kubectl describe nodes

Kubernetes is not broken — it is protecting the cluster.

---

4. Requests ≠ Reserved Resources

A critical misunderstanding:

• Requests are accounting values
• They are not exclusive reservations
• Nodes can still be under pressure even if requests fit

This explains why:

• Pods are scheduled successfully
• But runtime performance is unstable

---

5. Production‑Safe Resource Strategy

For latency‑sensitive services

• Set realistic CPU requests
• Avoid very tight CPU limits
• Monitor throttling

For memory‑heavy workloads

• Measure baseline usage
• Set memory limits above working set
• Avoid guessing

kubectl top pod
kubectl top nodes

Always measure before setting limits.

---

The One‑Line Rule That Saves Incidents

• Requests decide WHERE a pod runs
• Limits decide HOW it fails

Once you internalize this, Kubernetes behavior becomes predictable.

---

InfraDecode Takeaway

Most Kubernetes outages are not caused by bugs —
they are caused by incorrect mental models.

Fix the model, and the system makes sense.

— InfraDecode