Kubernetes · Orchestration under pressure
How do resource requests and limits affect scheduling and runtime?
Short answer
Requests are used for scheduling and guarantee capacity. Limits are enforced at runtime: CPU is throttled and memory overuse causes OOM kills. Together they determine QoS class.
The scheduler sums requests across pods and only places a pod on a node with enough allocatable capacity. Limits are enforced by the kernel through cgroups. CPU is compressible, so exceeding a CPU limit results in throttling rather than termination. Memory is not compressible, so exceeding a memory limit triggers an OOM kill.
- No requests means the scheduler has no idea what the pod needs
- Requests equal to limits gives Guaranteed QoS for all containers
- Requests below limits gives Burstable QoS and can be evicted under pressure
- No requests or limits at all gives BestEffort, the first to be evicted
- A CPU limit that is too low causes latency spikes that look like application bugs
resources:
requests:
cpu: 250m
memory: 256Mi
limits:
cpu: 1
memory: 512MiRight-size from observed usage, not guesswork. Start with sensible requests, set memory limits above the steady-state working set, and be cautious with CPU limits for latency-sensitive services. Use metrics and vertical scaling recommendations, then review after traffic changes.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What is the difference between a request and a limit?
- 2Why does CPU throttling happen instead of an OOM kill?
- 3What are the QoS classes and why do they matter?
- 4How would you right-size a service in production?
Say it in the interview
Requests tell the scheduler what capacity to reserve, and limits cap runtime usage through cgroups. CPU overuse throttles, while memory overuse gets OOM killed, which is a crucial difference. I right-size from observed usage, set memory limits above the working set, and am careful with tight CPU limits on latency-sensitive services. QoS class follows directly from those choices and affects eviction order.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.