Pods CPU behavior for Guaranteed QOS pods with noisy neighbor

Question

Struggling to understand if Guaranteed Qos class (by same limits and requests) behavior for CPU, would actually Guarantee my pods get the requested CPU when they ask for it , even if a noisy neighbour with Burstable Qos is using more CPU then available for both Guaranteed and Burstable pods.

Consider the following (simplfied) scenario:

Node has 2 CPU and 2 scheduled pods:

• 1 pod with Burstable requests 1 CPU limit 2 CPU

• 1 pod with Guaranteed requests 1 CPU Limit 1 CPU

Now consider that the Guaranteed pod is currently using 0.6 cpu (by the language runtime inside the container) and the burstable pod bursts to use 1.4 CPU.

What happens when the guaranteed pod needs more CPU? Would it get the extra CPU while the burstable one be throttled?

1. Or would it be throttled?
2. It won't be allowed to the to 1.4 because the "requested" cpu is reserved even if not in actual use?
3. the Guaranteed pod won't get the CPU it needs now?

Answer 1

There are 3 classes in Kubernetes:

• Guaranteed - if you set only limits OR if you set limits and requests to the same value. (Highest priority).
• Burstable - if you set only requests OR if you set requests lower than limits. (Medium priority).
• Best-effort - if you don’t set those at all. (Lower priority).

In the case of a CPU, its excess power will be distributed proportionally to the request.cpu value assigned to the containers running on the node. If two processes are fighting for CPU, the one with higher request gets more. However, if 2 processes fight for the CPU, the one from the Guaranteed class will get more. The other will only get what's left (in fact, the kernel will not let him starve, but it will be much slower).

You can also find more information about QoS classes and their behaviour here and here. This last site is pretty good. Guy explains very well what happens when resources are used too much. This breaks down into memroy and CPU.