Power of PriorityClass in Kubernetes

A MicroBlog to understand how priority classes can be used in Kubernetes to prioritize important workloads over the least-critical ones.

What is a PriorityClass?

Pods can have priorities with help of PriorityClass which is a non-namespaced object that contains a numeric integer value that is equal to or lower than 1,000,000,000 which determines the priority of a pod over other pods. PriorityClass ensures that production or mission-critical workloads are allocated resources/nodes on priority over other non-critical resources. PriorityClass is used to order the scheduling queue in Kubernetes or also evict the least priority pods in order to make high priority pods run. We can assign a pod a PriorityClass by specifying the name of the PriorityClass in the podspec of a Pod priorityClassName attribute.

By default, Kubernetes ships with two PriorityClasses

1. system-cluster-critical
2. system-node-critical

By default, all pods have priority equal to 0 if no priority class is assigned to a pod.

Creating PriorityClass & Explaining why all pods are not equal :(

In order to test PriorityClass, let's use minikube.

Minikube is available on major operating systems (Installation Guide Link)

Once we are done installing minikube, lets spawn a simple cluster.

minikube start --memory 1800 --cpus 2

As minikube by default creates a single node, we would limit the memory to it by 1800MB as there are other components that would also consume the memory, the total usual memory for the pods would only be around ~1Gi this is purposefully done in order to simulate a resource crunch & cause PriorityClass to provide more priority to high priority pods over other pods.

Create a Priority Class

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
  namespace: default
value: 1000000
globalDefault: false
description: "Used for High Priority Pods"

In this case, we have created a priority class which will be tagged as high-priority-pods.

Now let's create three pods in which ~1Gi is memory available in total.

1. no-priority-pod (memory: 500Mi) (1Gi~ — 500Mi) — 500Mi~ remaining
2. high-priority-1 (memory: 500Mi) (524Mi ~— 500Mi) — 24Mi~remaining
3. high-priority-2 (memory: 500Mi) — will cause preemption as no resource is available.

Creating the First Pod: No-Priority-Pod

apiVersion: v1
kind: Pod
metadata:
  name: no-priority-pod
  namespace: default
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: 500m
        memory: 500Mi
      limits:
        cpu: 500m
        memory: 500Mi

In this case, this is a pod that has no PriorityClass assigned which means its default priority value is 0 which makes it have less priority over the class which we do have a PriorityClass.

In this case, after creating the pod the pod now allocates 500Mi out of 1024~Mi.

Creating the Second Pod: High-Priority-Pod-1

kind: Pod
metadata:
  name: high-priority-pod-1
  namespace: default
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: 500m
        memory: 500Mi
      limits:
        cpu: 500m
        memory: 500Mi
  priorityClassName: high-priority

In this case, we create another pod that has PriorityClass assigned and has allocated memory around 500Mi in which the total memory of the node is closed to being exhausted now let's try to create another high-priority-2

Creating Third Pod: High-Priority-Pod-2 (Magic Happens!)

apiVersion: v1
kind: Pod
metadata:
  name: high-priority-pod-2
  namespace: default
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: 500m
        memory: 500Mi
      limits:
        cpu: 500m
        memory: 500Mi
  priorityClassName: high-priority

In this case, the moment we try to create the new pod (high-priority-pod-2) there is a resource crunch as we need 500Mi memory for the pod to run, but since its high-priority-pod, the pod which doesn't have priority or lower priority gets terminated and the high-priority-pod2 gets the memory for it to run.

Summary:

PriorityClass can be of great use when we have specific production workloads that require high availability even if there is a resource crunch situation that might arise, we should also take into account how we can have a tiered approach of having different types of PriorityClass for various class of workloads. PriorityClass does prove something at the end

“no pod is born equal :( “

“If you found this article useful, feel free to 👏 clap many times or share it with your friends. If you have any doubts regarding the same or anything around the DevOps Space, get in touch with me on Linkedin, Twitter, Instagram.”