A seasonal licensing API should run with Burstable QoS so it can use spare capacity above its baseline. How should requests and limits be set?
Select an answer to reveal the explanation.
Short Explanation
Burstable is a soft reservation with room to stretch—request the baseline, limit the ceiling higher. When requests sit below limits, QoS lands on Burstable. Equal requests and limits is Guaranteed; nothing reserved is BestEffort.
Full Explanation
A seasonal licensing API that should run with Burstable QoS so it can use spare capacity above its baseline should set CPU and memory requests lower than their corresponding limits on the containers. Requests establish the baseline reservation for scheduling; higher limits allow bursting into spare capacity when the node has room. That configuration matches municipal seasonal traffic patterns.
Omitting both requests and limits entirely makes the Pod BestEffort, not Guaranteed by default, and not Burstable with a defined baseline. Setting requests equal to limits for every resource classifies the Pod as Guaranteed rather than Burstable. Setting only limits and leaving requests unset tends toward defaults or BestEffort-like outcomes depending on LimitRange and does not cleanly express Burstable with an explicit baseline request.
Exam caveat: if LimitRange injects defaults that equalize requests and limits, you may accidentally become Guaranteed—always inspect the admitted Pod. Operational check: set requests below limits for CPU and memory, verify qosClass is Burstable, load-test seasonal peaks, and confirm bursting works until the limit without surprise QoS changes. In CKAD scenarios involving q209, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.