1 min lesson
Requests vs. limits
Compare two rows from "Requests vs. limits", then say when each one fits.
Step 1 of 2
Requests vs. limitsthe single most consequential knob
Requests are what the scheduler reserves; limits are the hard ceiling the kernel enforces. The gap between them decides scheduling density, eviction order and whether one noisy pod can starve its neighbors.
- Setting
- CPU request
- What it does
- Reserves schedulable CPU; affects bin-packing
- Get it wrong and…
- Too high wastes nodes; too low oversubscribes and throttles
- Setting
- CPU limit
- What it does
- Throttles the container above the ceiling
- Get it wrong and…
- Too low causes latency spikes under load (CPU throttling)
- Setting
- Memory request
- What it does
- Reserves memory for scheduling
- Get it wrong and…
- Too low lets the node oversubscribe memory
- Setting
- Memory limit
- What it does
- Hard cap; exceeding it = OOMKill
- Get it wrong and…
- Too low gets the pod killed under spikes (no throttling for memory)
| Setting | What it does | Get it wrong and… |
|---|---|---|
| CPU request | Reserves schedulable CPU; affects bin-packing | Too high wastes nodes; too low oversubscribes and throttles |
| CPU limit | Throttles the container above the ceiling | Too low causes latency spikes under load (CPU throttling) |
| Memory request | Reserves memory for scheduling | Too low lets the node oversubscribe memory |
| Memory limit | Hard cap; exceeding it = OOMKill | Too low gets the pod killed under spikes (no throttling for memory) |
Memory has no soft throttle - over the limit, the pod dies. CPU over the limit just slows down.
QoS follows from requests and limits
Set request = limit and the pod is Guaranteed and last to be evicted. Set request < limit and it's Burstable. Set neither and it's BestEffort and first to die under node pressure. For latency-critical Cursor services, Guaranteed for the hot path and Burstable for the rest is a defensible split.