Quality of service (Qos) class is a concept which determines the scheduling and eviction priority of pods. We all know that if the underlying worker node has issues, the pods running on them are moved to other nodes.This means if there is any issue with the underlying nodes, the pods are evicted. The priority of this eviction is defined by the Qos. Also this class talks about the decisions taken by the scheduler to schedule the pods on nodes.
There are 3 QoS Classes in k8s,
Guaranteed
Burstable
BestEffort
All types of kinds ( deployments, stateful sets, jobs and daemonsets ) in kubernetes accept a request and limit for 3 types of compute resources: cpu, memory and ephemeral-storage. When the pod is being scheduled on a node, it first checks for the node which has the compute resources to fulfill the “request” of that pod. During the scheduling of pods, the limits will be ignored. The limits and requests are set as in below image
Pods are scheduled as one of the Quality of Class based on following characteristics
Guaranteed Pods:
Pod is guaranteed if every container in the pod has
Explicit requests and limits for both memory and cpu
Both requests and limits defined for a container are same
[jagadishmanchala@Jagadish-theOne:k8s] cat guaranteed-pod.yml
apiVersion: v1
kind: Pod
metadata:
name: guaranteed
spec:
containers:
- name: container
image: busybox
command: [ /bin/sleep, 1d ]
resources:
limits:
cpu: 100m
memory: 10Mi
requests:
cpu: 100m
memory: 10Mi
[jagadishmanchala@Jagadish-theOne:k8s] kubectl describe pod guaranteed | grep QoS
QoS Class: Guaranteed
Guaranteed pods are scheduled only to nodes where they have enough resources to fulfil the CPU and memory requests. This is ensured by the scheduler by ensuring the sum of both memory and cpu requests for all containers is lower than the total capacity of the node
Though there are cpu and memory available, there are cases where guaranteed pods are not scheduled to nodes if that node has a DiskPressure Condition. This condition comes if the available disk space or inodes on either the root file system or image storage hit the threshold.
Burstable Pod :
Pod is Burstable when:
Pod is burstable if every container in the pod has
Explicit requests and limits for both memory and cpu
Limits are greater than the requested amount for at least one container in pod
[jagadishmanchala@Jagadish-theOne:k8s] cat burstable-pod.yml
apiVersion: v1
kind: Pod
metadata:
name: burstable
spec:
containers:
- name: container
image: busybox
command: [ /bin/sleep, 1d ]
resources:
limits:
cpu: 100m
memory: 10Mi
requests:
cpu: 100m
memory: 0
[jagadishmanchala@Jagadish-theOne:k8s] kubectl describe pod burstable | grep QoS
QoS Class: Burstable
During Scheduling , k8s will not take memory into consideration when placing this pod as there simply is no memory reservation. The k8s scheduler cannot ensure that this Class pods are deployed to nodes that have enough resources for them.
If there is no BestEffort class pod on a node, these pods are killed before Guaranteed Class pods when they reach their limit.
Best Effort Pod:
A pod is best effort if any container in that pod does not have any explicit memory or cpu requests
[jagadishmanchala@Jagadish-theOne:k8s] cat besteffort.yml
apiVersion: v1
kind: Pod
metadata:
name: besteffort
spec:
containers:
- name: container
image: busybox
command: [ /bin/sleep, 1d ]
resources:
limits:
cpu: 0
memory: 0
requests:
cpu: 0
memory: 0
[jagadishmanchala@Jagadish-theOne:k8s] kubectl describe pod besteffort | grep QoS
QoS Class: BestEffort
These Class pods are not guaranteed to be managed on to nodes that have enough resources for them. They are able to use any amount of free resources on the node. This can sometimes cause resource issues as these class pods use unlimited resources.
These classes of pods are the lowest priority and will be killed first if there are resource constraints.
Hope this helps in understanding the Kubernetes Quality of Class.
No comments :
Post a Comment