DevOps & Kubernetes (50 Qs)•Part 3: Production K8s Scaling, Reliability & SRE (26 - 35)
Resource Requests, Limits, and Quality of Service (QoS) Classes: Guaranteed vs. Burstable vs. BestEffort.
Scheduling vs. Runtime Enforcement
Kubernetes manages CPU and Memory using two parameters: Requests (guaranteed reservation used by Scheduler) and Limits (enforced ceiling at runtime).
ini
+-----------------------------------------------+
| MEMORY |
| Request = 512Mi Limit = 1024Mi |
+-----------------------------------------------+
[ Guaranteed Memory ] [ Burstable Room ] | Exceed Limit -> OOMKilled!
+-----------------------------------------------+
| CPU |
| Request = 500m (0.5 core) Limit = 1000m (1 core)
+-----------------------------------------------+
[ Guaranteed Cycles ] [ Burstable Cycles] | Exceed Limit -> CFS Throttled!
QoS Classes Comparison
Kubernetes assigns a Quality of Service (QoS) class based on how requests and limits are defined:
| QoS Class | Condition | Eviction Priority Under Node Memory Pressure |
|---|---|---|
| Guaranteed | Every container has requests == limits for both CPU and Memory. | Lowest eviction priority (last to be killed). Reserved for critical databases and core services. |
| Burstable | requests < limits, or only requests are specified. | Medium eviction priority. Most common for web APIs and microservices. |
| BestEffort | No requests or limits specified at all. | Highest eviction priority (first to be killed instantly when node memory tightens). |
CPU Throttling vs. Memory OOM
- CPU is a compressible resource: If a container exceeds its CPU limit, Linux does not kill it. Instead, the kernel Completely Fair Scheduler (CFS) restricts CPU cycles (CPU throttling), resulting in increased latency.
- Memory is an incompressible resource: If a container exceeds its memory limit, the Linux kernel terminates the process immediately with an out-of-memory error (
OOMKilled/ exit code 137).