I have the following use case:

• Suppose node1 has 4GB RAM and node2 has 4GB RAM.

• pod1 has requested "resources.requests" of 2GB.

• pod2 has requested "resources.requests" of 2GB.

• suppose "scheduler" sends both the pods on node1.

• pod1 occupies 250MB and pod2 occupies 250MB on node1.

• Now, pod3 comes in and it doesn't have resources declaration.

• suppose "scheduler" also sends the pod3 also on node1.

Here, if pod3 starts occupying space and gets 2GB space leaving only 1.5GB available on node1.

What would happen?

Will it evict pod1 and pod2 from node1 and move them to node2?

CodePudding user response：

To address your query, the answer is no, pod 1 and pod 2 won't be kicked off of node 1 and relocated to node 2. Since node 1 can still accommodate the 2GB resource required by pod 3 in the use case you specified, pod 3 will continue to occupy node 1 after both pod 1 and pod 2 have occupied 500mb each, leaving node 1 with 3.5GB.

According to my understanding of Kubernetes, pod that have been first deployed to a node will be prioritized, use the necessary resources, and not be relocated or transferred to other nodes. If a new pod were generated and a node does not have enough memory, the scheduler will assign the new pod to the node that has enough memory. Assuming there is no other node created, then the pod will be tagged as unschedulable.

This means that pod 1 and pod 2 will remain on node 1, and pod 3 will be deployed there as well, unless node 1 is unable to provide the required memory, in which case pod 3 will be relocated to node 2.

Note: All figures here are all used as examples in this topic, in real life this is not the case, as other services running that also consumes resources.

CodePudding user response：

In the situation you describe, where the actual memory usage is

Since there is free memory, nothing gets evicted. Since the third pod didn't request any memory, it "fits" on that node given only the resource requests.

But now let's say both pods 1 and 2 start doing real work, and the situation changes to

and the Kubernetes eviction algorithm gets triggered. By the normal rules, the first two pods are within their resource requests, but the third one is substantially over. That means that pod 3 will get evicted in this scenario.