In Kubernetes, **Quality of Service (QoS) classes** define how resources (CPU and memory) are allocated to pods, especially during times of resource contention. The three QoS classes are: * **Guaranteed** * **Burstable** * **BestEffort** Here’s a breakdown of the **difference between Burstable and Guaranteed QoS** classes: --- ### ✅ **Guaranteed QoS** * **Requirements:** * Pod must have **equal `requests` and `limits`** for **both CPU and memory** for **all containers**. * **Behavior:** * Kubernetes treats these pods with the **highest priority**. * Guaranteed resources are **reserved** for the pod. * Least likely to be **evicted** when a node runs out of memory. * **Use Case:** Critical workloads that must not be interrupted, such as databases or key backend services. --- ### ⚡ **Burstable QoS** * **Requirements:** * Pod has **both `requests` and `limits` set**, but they are **not equal**, or **only set for some containers**. * **Behavior:** * Resources are **guaranteed up to the request**, but can **burst** up to the limit if resources are available. * Lower priority than Guaranteed but higher than BestEffort. * Can be **evicted** under memory pressure if higher priority pods need resources. * **Use Case:** Non-critical apps that can scale up temporarily or tolerate being restarted. --- ### Comparison Summary: | Feature | **Guaranteed** | **Burstable** | | -------------------- | ------------------------ | ------------------------------------------- | | `requests == limits` | Yes (for all containers) | Not always (or partial containers) | | Resource Priority | Highest | Medium | | Eviction Risk | Lowest | Medium | | Resource Usage | Reserved fully | Bursts above requests if resources are free | | Ideal for | Critical apps | Apps with variable demand | ---