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.
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.
kubectl get pod api-7c9 -o wideSTATUS: OOMKilled RESTARTS: 6kubectl describe pod api-7c9 | grep -A2 LimitsLimits: memory: 128Mithe app needs ~200Mi — the limit is killing it, not a bugRequests vs limits
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: 100mmemory: 200Milimits: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
kubectl top pods -n shopapi-7c9 142m 198Miset requests near the p50, limits near the p99 — then let VPA refine