Scheduling in Kubernetes ☸☸

How does the process of Scheduling works in Kubernetes ??

Introduction 🚩🚩

Hi fellow Readers 👋 :))
I have been writing about the basics of Kubernetes and it’s objects for a while now. I feel the basics are covered well and it is time to move to the more advanced Kubernetes topics now.
One of such topic is regarding the process of Scheduling in Kubernetes.

So In this article, we will try to learn about :

• What is a Scheduler ??
• How to manually schedule pods in Kubernetes ??
• Concept of Taints and Tolerations in Kubernetes.
• Concept of Node Affinity in Kubernetes.

So without any further delay, lets get started with it :))

What is a Scheduler ?? 🤔🤔

Kubernetes Cluster Architecture

In general terms, a scheduler is a component which helps to basically schedules different things.
In the world of Kubernetes, a scheduler is basically a component which is present in the master node of the cluster and is called kube-scheduler.

A kube-scheduler is a control plane component which assigns Pods to Nodes. The scheduler determines which Nodes are valid placements for each Pod present in the scheduling queue according to constraints and available resources. The scheduler then ranks each valid Node and binds the Pod to a suitable Node.

In simple terms scheduler in Kubernetes decides which pod will run on which node. (Only decides, does not put the pod on that node)
For this process, it considers the resource needs of a pod such as CPU or memory requirements, along with the health of the nodes before deciding where the pod will be scheduled.

**Note: Multiple different schedulers can also be used within a same cluster

We just studied “What is kube-scheduler in Kubernetes ??”
But the question arises that can’t we bypass this kube-scheduler thing and schedule the pods our own way manually on whichever nodes we want to ??

Yes, we can manually schedule them. Let us find out how in the next section :))

How to manually schedule Pods in Kubernetes ?? 🤔🤔

We can manually schedule our pods on the whichever node we want. Let us have a look at all how it really happens.

Every POD has a field called nodeName that by default is not set and kube-scheduler sets it on its own. So if one needs to manually schedule a pod, then they just need to set the nodeName property in the pod definition file under the spec section.

**Note: Above method only works when pod is still not created. If the pod is created and already running, then this method won’t work.

Below is the example of a Pod configuration file, in a scenario where the Pod needs to be manually scheduled on node named “node02”

Have a look at the nodeName: node02 property in the file below.

apiVersion: v1
kind: Pod
metadata:
 name: nginx
 labels:
  name: nginx
spec:
 containers:
 - name: nginx
   image: nginx
   ports:
   - containerPort: 8080
 nodeName: node02

Whenever the user specify the nodeName property in the Pod’s configuration file. The kube-scheduler detects it and instead of on its own scheduling the Pod, it takes the user choice and schedules the Pod in that specified node. Simple :))

We just learned about Manual Scheduling in Kubernetes.
But one question which arises is that when we are using kube-scheduler, then can we not make the whole process according to our needs like not according to the kube-scheduler ??

Yes we can specify our rules even while using kube-scheduler for scheduling Pods. Let us find out how in the next section :))

Taints and Tolerations in Kubernetes

Taints and Tolerations in Kubernetes

Imagine you’re the administrator of a Kubernetes cluster. Now it is you job to make sure sometimes that on a particular node only a particular kind of Pod should gets scheduled. How can we achieve this ??
Here comes the concept of Taints and Tolerations in Kubernetes.

Let us try to understand the whole concept by using some real world entities :

• There are three nodes “production-node”, “development-node” & “testing-node”
• Now it is the duty of administrator to make sure that only “Production-pods” should get scheduled on “production-node” nothing else.
• So to make sure above thing gets right, the administrator can spray a taint on the “production-node”.
• After spraying the node with a taint, administrator can next spray toleration for that taint on the “production-pods”.

In simple terms, Taints are like a Repellant spray. If we spray a taint on any node it will not allow any Pod to get scheduled on it.
Unless the Pod has the Toleration for that Taint being sprayed on itself.

Taint on the “production-node” can be specified using the below command :

kubectl taint nodes production-node app=red:NoSchedule

There are 3 taint effects

• NoSchedule : It means Pod without the toleration of the taint can’t be scheduled on the tainted node.
• PreferNoSchedule : It means Pod without the toleration of the taint should not be scheduled on the tainted node. But if there is no other choice then it can be scheduled on the tainted node.
• NoExecute : It means if a node is tainted while some Pods are running on it. The running pods which does not have toleration for that taint will get evicted from the node.

Toleration on the “production-pod” can be specified using the below configuration file :

apiVersion: v1
kind: Pod
metadata:
 name: production-pod
spec:
 containers:
 - name: nginx-container
   image: nginx
 tolerations:
 - key: "app"
   operator: "Equal"
   value: "red"
   effect: "NoSchedule"

We just learned about Taints and Tolerations in Kubernetes.
Using the above concept only makes sure which type of Pods can’t be scheduled on Nodes.

It doesn’t make sure that a Pod will be only be scheduled on a certain node.
For example : There are two nodes “Red-Tainted” and “Normal” . A Pod with “Red-toleration” can be scheduled on both.
How can we tackle this situation ?? Let us find out :))

Node Affinity in Kubernetes

Imagine you’re the administrator of a Kubernetes cluster. Now it is you job to make sure that your Pod only gets scheduled on a certain type of Node.
How can we achieve this ?? Here comes the concept of Node Affinity in Kubernetes.

Let us try to understand what happens when we use Node Affinity in Kubernetes.

• Administrator can makes sure to label all the Nodes. Example of labels can be “Large”, “Medium”, “Small” and many more.
• Then while creating Pods, they can specify the Node affinity rule to specify the choice where they want to schedule that Pod.

Node Affinity Rules on a Pod which has to be scheduled on a Medium Labeled Node would look something like below :

apiVersion: v1
kind: Pod
metadata:
 name: medium-pod
spec:
 containers:
 - name: data-processor
   image: data-processor
 affinity:
   nodeAffinity:
     requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: size
            operator: In
            values: 
            - Large
            - Medium

There are four different types of Node Affinity types

Available

• requiredDuringSchedulingIgnoredDuringExecution
• preferredDuringSchedulingIgnoredDuringExecution

Planned

• requiredDuringSchedulingRequriedDuringExecution
• preferredDuringSchedulingRequiredDuringExecution

In this way, by using Node affinity rules. We can actually make the Pods get scheduled only on certain type of Nodes. Simple :))

What next ? 👀 👀

Thanks a lot for reaching till here! This is the end of this article.
But we have only scratched the surface of the K8s ecosystem :))
Much more to go, it will be a fun journey where we will learn a lot of cool stuff together.

Do clap and follow me 🙈 if you like my writings and want to read more from me in the future :))

In case of any doubts around this article or for some general chit chat, feel free to reach out to me on my social media handles

Twitter — https://twitter.com/ChindaVibhor

LinkedIn — https://www.linkedin.com/in/vibhor-chinda-465927169/

Related Articles

Deploying a Local Kubernetes Cluster using Minikube 🚢 🚢

Kubectl Commands 101 📝📝

I will still keep on coming with new articles covering a bunch of topics I am exploring.

That’s All folks !! Doodles :))