Hello and welcome to this lecture. In this lecture
we look at the different ways of manually scheduling a POD on a node.
We will also look at how to view scheduler related events. We have seen how the default-scheduler works
in a kubernetes environment in the previous lectures.
It has an algorithm that distributes pods across nodes evenly as well as takes into consideration
the various conditions we specify through taints & tolerations and node affinity etc. But what if none
of these satisfies your needs?
Say you have a specific application that requires its components to be placed on nodes after performing
some additional checks. So you decide to have your own scheduling algorithm to place pods on nodes? So
that you can add your own custom conditions and checks in it. Kubernetes is highly extensible.
You can write your own kubernetes scheduler program, package it and deploy it as the default scheduler
or as an additional scheduler in the kubernetes cluster. That way
all of the other applications can go through the default scheduler,
however one specific application can use your custom scheduler. Your kubernetes cluster can have multiple
schedulers at the same time.
When creating a POD or a Deployment you can instruct kubernetes to have the POD
scheduled by a specific scheduler.
Earlier we saw how to deploy the kube-scheduler.
We download the kube-scheduler binary and run it as a service with a set of options.
One of the option is scheduler name. If not specified
It assumes in name of default scheduler.
This kube-scheduler is the default scheduler. To deploy an additional scheduler,
You can use the same kube-scheduler binary or use one that you might have built for yourself, which makes
more sense.
In this case we are going to use the same binary to deploy the additional scheduler.
This time we set the scheduler name to a custom name.
This is important to differentiate the two schedulers and this is the name that we will be specifying
in the pod definition file later on.
Let’s take a look at how it works with the kubeadm tool. The kubeadm
tool deploys the scheduler as a POD.
You can find the definition file it uses under the manifests folder. I have removed all the other details
from the file so we can focus on the key parts.
The command section has the command and associated options to start the scheduler.
We can create a custom scheduler by making a copy of the same file, and by changing the name of the scheduler.
We set the name of the pod to my-custom-scheduler and we add a new option to the scheduler command
to set a custom name for the scheduler.
Finally an important option to look here is the leader-elect option. The leader-elect
option is used when you have multiple copies of the scheduler running on different master nodes, in a
High Availability setup where you have multiple master nodes with the kube-scheduler process running
on both of them.
If multiple copies of the same scheduler are running on different nodes only one can be active at a
time.
That’s where the leader-elect option helps in choosing a leader who will lead
scheduling activities. We will discuss more about HA setup in another section, but for now I wanted
to point out that, to get multiple schedulers working you must either set the leader-elect option to false,
in case where you don’t have multiple masters. In case you do have multiple masters, you can pass in an
additional parameter to set a lock object name.
This is to differentiate the new custom scheduler from the default during the leader election process
Once done, create the pod using the kubectl create command. Run the get pods command in the kube-system
namespace and look for the new custom scheduler.
Make sure its in a running state. The next step is to configure a new POD or a deployment to use
the new scheduler. In the Pod specification file.
add a new field called schedulerName and specify the name of the new scheduler.
This way when the pod is created, the right scheduler picks it up to schedule. Create the pod using
the kubectl create command. If the scheduler was not configured correctly, then the pod will continue
to remain in a Pending state. If everything is good, then the pod will be in a Running state.
So how do you know which scheduler picked it up? View the events using the kubectl get events command.
This lists all the events in the current namespace.
Look for the Scheduled events. As you can see the source of the event is the custom scheduler we created.
And the message says successfully assigned default/nginx image. To view the logs of the scheduler,
view the logs of the pod using the kubectl logs command. Specify the name of the scheduler
the correct namespace.
Well that's it for this lecture.
Head over to the practice exercises and practice deploying multiple schedulers.
I will see you in the next lecture.