How does Kubernetes assign Guaranteed, Burstable, or BestEffort QoS to a Pod based on container requests and limits?
Select an answer to reveal the explanation.
Short Explanation
QoS is the eviction VIP line based on how carefully you filled in requests and limits. Match them for Guaranteed, leave them blank for BestEffort, and land in Burstable for the in-between cases. Probes do not pick the class.
Full Explanation
Kubernetes assigns Guaranteed, Burstable, or BestEffort QoS based on container requests and limits. Guaranteed needs equal non-zero CPU and memory requests and limits for every container; BestEffort has no requests or limits set on containers; otherwise the Pod is Burstable. This classification—not priorityClassName alone—influences eviction behavior under node memory pressure for civic workloads that must stay up longest.
Claiming QoS is chosen only from the Pod's priorityClassName and ignores resources blocks fails the QoS computation algorithm. Claiming any Pod with a liveness probe is Guaranteed because probes override resource fields fails—probes do not determine QoS. Claiming BestEffort requires requests equal to limits while Guaranteed means no resources are set inverts the real definitions and would misconfigure permitting and payment Pods.
Exam caveat: init containers also participate in QoS computation, so an init container with mismatched resources can change the whole Pod's class unexpectedly. Operational check: set matching CPU and memory requests and limits on each container for Guaranteed civic payment Pods, then verify status.qosClass is Guaranteed using kubectl get pod -o jsonpath.