[Kubernetes] Node Overcommitted

Recap on Requests and Limits

Requests

Pods are allocated to nodes based solely on the specific CPU and Memory requirements. In other words, a pod is assigned for a node if the available capacity on that node can accommodate the additional CPU and Memory requested by the pod. 

Limits

Pod Scheduling does not take limits into account, but limits play a crucial role for different purposes. They establish an upper limit on the resources a pod can acquire before facing throttling or running out of memory. This precautionary measure prevents a single pod from monopolizing all resources on a node due to any deficiencies. 

it is crucial to understand that reaching the CPU limit does not result in pod eviction; instead, it leads to throttling, potentially causing application failure. However, surpassing the Memory limit results in an out-of-memory (OOM) condition, necessitating pod eviction. 

[example of overcommit]

Now, if the node is anywhere close to reservation capacity then naturally the summation of all limits will be greater than this capacity and so you will be overcommitted.

※ If you can not have a redundant configuration you can utilize the Guaranteed Quality of Service Class by setting requests=limits to ensure that a specific workload does not risk eviction as a consequence of being overcommitted (bear in mind it could still be evicted if it is required more memory than it’s limit, it just wouldn’t be due to being overcommitted).