Kubernetes uses QoS -Quality of Service - for pods, it allows it to treat pods differently depending on their priority and resource needs.
Kubernetes has three classes for pods:
Guaranteed pod - for high priority pods -
Burstable pod- for medium priority pods -
BestEffort pod- for low priority pods -
Regarding the resource needs, if for example a BestEffort pod and the Guaranteed pod live on the same node, when there is a resource shortage on that node, the BestEffort pods gets stopped first to allow the Guaranteedpod to keep running.
Resource requests means that we want at least these resources.
Limits resource means that this is the maximum resources we can get.
The QoS of pods are set in the pod's Yaml files in the resource request and resource limit section.
Below is an example of a Guaranteed pod - resources requests are equal to the resource limits -
The CPU resources are either expressed in cores or millicpu - 1000 m equals to 1 core -
We could see the resources available on a node using the below command:
Below we have an example of a Burstable pod.
A burstable pod have both limits and requests set for at least one of its containers - limits are bigger than the requests in the Yaml file -
If a Burstable pod uses more memory than its memory limit, the kubernetes scheduler will stop itand put it in an OOMKilled state as we can see below:
The scheduler tries to restart the pod:
Then the scheduler manages to restart the pod:
If the pod is still out of memory, it will be restarted, stopped then restarted and so on
For a pod to be given a QoS class of BestEffort, we don't need to set any memory or CPU limits-requests for the containers running inside the BestEffortpod.
Resource requests and limits are inherited from the namespace.
If we want a BestEffort pod - with no resource or limits settings - the default setting must not be set in the namespace. If they are set, the pod inherits them and could become burstable -.
Below is an example of the default namespace with no resource settings: