Kubernetes Pod Quality of Service (QoS) — DevOps Bytes
Do you specify requests & limits for your Kubernetes pods?
Here is why it’s very important.
When deploying a pod, kubernetes assigns a QoS class to pods based on the requests and limit parameters.
Let’s understand Kubernetes Pod Quality of service. (QoS).
Kubernetes pod scheduling is based on the request value to ensure the node has the resources to run the pod.
However, a node can be overcommitted if pods try to utilize all its limit ranges more than the node’s capacity.
Overcommitment = sum of resource request/limits > node capacity
When pods on the node try to utilize resources that are not available on the node, kubernetes uses the QoS class to determine which pod to kill first.
There are three Pod QoS.
Best effort
Your pod gets the best-effort class if you do not specify any CPU/Memory requests and limits. Best-effort pods are low-priority pods. The best-effort pods get killed first if the node runs out of resources.
Burstable
If you set the request lower than the limit, the pod gets burstable class. If the node runs out of resources, burstable pods get killed if no best effort pods are available.
Guaranteed
The pod gets a guaranteed class if the request and limit values are the same. It is considered the highest priority pod and gets killed if there are no best-effort or burstable pods.
Further Reading:
