BlogKubernetes

Kubernetes requests and limits: stop OOMKills, noisy pods

Set CPU and memory requests and limits that keep the scheduler honest, stop one pod from starving the node, and avoid needless OOMKills under load.

Sep 9, 2025·7 min readBeginner

Requests and limits are two different jobs. Requests tell the scheduler how much of the node to reserve — they decide where a pod lands. Limits cap what a container can actually use — they decide what happens when it misbehaves. Getting them wrong shows up as pods that will not schedule, or one workload starving a whole node.

bash — the symptomlive
kubectl get pod api-7c9 -o wide
STATUS: OOMKilled RESTARTS: 6
kubectl describe pod api-7c9 | grep -A2 Limits
Limits: memory: 128Mi
the app needs ~200Mi — the limit is killing it, not a bug

Requests vs limits

Two different jobs
Requests
reserve on the node
used for scheduling
guaranteed floor
too high -> unschedulable
Limits
hard ceiling
CPU -> throttled
memory -> OOMKilled
too low -> restarts
deploy.yaml
resources:
requests:
cpu: 100m
memory: 200Mi
limits:
memory: 256Mi # cap memory (OOM protection)
# no cpu limit -> burst freely, just throttle-free
A CPU limit throttles, a memory limit kills
Set memory requests = limits for predictable QoS. Many teams skip CPU limits deliberately so pods can burst — a CPU limit only ever slows you down, it never protects the node the way a memory limit does.

Right-size from real usage

bash — measure, do not guesslive
kubectl top pods -n shop
api-7c9 142m 198Mi
set requests near the p50, limits near the p99 — then let VPA refine
Go deeper in a courseKubernetes administrationScheduling, resources, and operating clusters end to end.View course

Related posts