1 00:00:00,940 --> 00:00:03,840 Hello and welcome to this lecture. In this lecture 2 00:00:03,850 --> 00:00:08,380 we look at the different ways of manually scheduling a POD on a node. 3 00:00:08,380 --> 00:00:16,540 We will also look at how to view scheduler related events. We have seen how the default-scheduler works 4 00:00:16,630 --> 00:00:19,940 in a kubernetes environment in the previous lectures. 5 00:00:19,990 --> 00:00:27,220 It has an algorithm that distributes pods across nodes evenly as well as takes into consideration 6 00:00:27,580 --> 00:00:33,970 the various conditions we specify through taints & tolerations and node affinity etc. But what if none 7 00:00:33,970 --> 00:00:36,440 of these satisfies your needs? 8 00:00:36,460 --> 00:00:43,360 Say you have a specific application that requires its components to be placed on nodes after performing 9 00:00:43,360 --> 00:00:52,050 some additional checks. So you decide to have your own scheduling algorithm to place pods on nodes? So 10 00:00:52,050 --> 00:00:59,190 that you can add your own custom conditions and checks in it. Kubernetes is highly extensible. 11 00:00:59,190 --> 00:01:05,550 You can write your own kubernetes scheduler program, package it and deploy it as the default scheduler 12 00:01:05,880 --> 00:01:10,650 or as an additional scheduler in the kubernetes cluster. That way 13 00:01:10,820 --> 00:01:13,950 all of the other applications can go through the default scheduler, 14 00:01:14,050 --> 00:01:22,460 however one specific application can use your custom scheduler. Your kubernetes cluster can have multiple 15 00:01:22,460 --> 00:01:24,370 schedulers at the same time. 16 00:01:25,970 --> 00:01:31,450 When creating a POD or a Deployment you can instruct kubernetes to have the POD 17 00:01:31,460 --> 00:01:34,590 scheduled by a specific scheduler. 18 00:01:34,640 --> 00:01:37,430 Earlier we saw how to deploy the kube-scheduler. 19 00:01:37,430 --> 00:01:43,100 We download the kube-scheduler binary and run it as a service with a set of options. 20 00:01:43,100 --> 00:01:47,280 One of the option is scheduler name. If not specified 21 00:01:47,330 --> 00:01:50,970 It assumes in name of default scheduler. 22 00:01:51,050 --> 00:01:57,090 This kube-scheduler is the default scheduler. To deploy an additional scheduler, 23 00:01:57,170 --> 00:02:02,870 You can use the same kube-scheduler binary or use one that you might have built for yourself, which makes 24 00:02:02,870 --> 00:02:03,920 more sense. 25 00:02:04,070 --> 00:02:08,580 In this case we are going to use the same binary to deploy the additional scheduler. 26 00:02:08,660 --> 00:02:12,620 This time we set the scheduler name to a custom name. 27 00:02:12,620 --> 00:02:18,260 This is important to differentiate the two schedulers and this is the name that we will be specifying 28 00:02:18,350 --> 00:02:20,570 in the pod definition file later on. 29 00:02:21,410 --> 00:02:24,720 Let’s take a look at how it works with the kubeadm tool. The kubeadm 30 00:02:24,720 --> 00:02:27,340 tool deploys the scheduler as a POD. 31 00:02:27,530 --> 00:02:33,410 You can find the definition file it uses under the manifests folder. I have removed all the other details 32 00:02:33,410 --> 00:02:36,440 from the file so we can focus on the key parts. 33 00:02:36,700 --> 00:02:41,910 The command section has the command and associated options to start the scheduler. 34 00:02:41,960 --> 00:02:48,620 We can create a custom scheduler by making a copy of the same file, and by changing the name of the scheduler. 35 00:02:49,310 --> 00:02:55,520 We set the name of the pod to my-custom-scheduler and we add a new option to the scheduler command 36 00:02:55,670 --> 00:02:58,820 to set a custom name for the scheduler. 37 00:02:58,820 --> 00:03:05,360 Finally an important option to look here is the leader-elect option. The leader-elect 38 00:03:05,360 --> 00:03:11,510 option is used when you have multiple copies of the scheduler running on different master nodes, in a 39 00:03:11,510 --> 00:03:17,210 High Availability setup where you have multiple master nodes with the kube-scheduler process running 40 00:03:17,300 --> 00:03:18,650 on both of them. 41 00:03:18,830 --> 00:03:25,160 If multiple copies of the same scheduler are running on different nodes only one can be active at a 42 00:03:25,160 --> 00:03:25,990 time. 43 00:03:26,120 --> 00:03:31,100 That’s where the leader-elect option helps in choosing a leader who will lead 44 00:03:31,130 --> 00:03:37,940 scheduling activities. We will discuss more about HA setup in another section, but for now I wanted 45 00:03:37,940 --> 00:03:45,650 to point out that, to get multiple schedulers working you must either set the leader-elect option to false, 46 00:03:46,160 --> 00:03:52,550 in case where you don’t have multiple masters. In case you do have multiple masters, you can pass in an 47 00:03:52,550 --> 00:03:56,620 additional parameter to set a lock object name. 48 00:03:56,720 --> 00:04:03,230 This is to differentiate the new custom scheduler from the default during the leader election process 49 00:04:04,430 --> 00:04:11,270 Once done, create the pod using the kubectl create command. Run the get pods command in the kube-system 50 00:04:11,270 --> 00:04:14,840 namespace and look for the new custom scheduler. 51 00:04:14,840 --> 00:04:22,610 Make sure its in a running state. The next step is to configure a new POD or a deployment to use 52 00:04:22,610 --> 00:04:26,170 the new scheduler. In the Pod specification file. 53 00:04:26,210 --> 00:04:31,460 add a new field called schedulerName and specify the name of the new scheduler. 54 00:04:31,520 --> 00:04:38,600 This way when the pod is created, the right scheduler picks it up to schedule. Create the pod using 55 00:04:38,600 --> 00:04:44,420 the kubectl create command. If the scheduler was not configured correctly, then the pod will continue 56 00:04:44,420 --> 00:04:51,280 to remain in a Pending state. If everything is good, then the pod will be in a Running state. 57 00:04:51,390 --> 00:04:57,940 So how do you know which scheduler picked it up? View the events using the kubectl get events command. 58 00:04:57,990 --> 00:05:01,040 This lists all the events in the current namespace. 59 00:05:01,200 --> 00:05:07,020 Look for the Scheduled events. As you can see the source of the event is the custom scheduler we created. 60 00:05:07,500 --> 00:05:13,920 And the message says successfully assigned default/nginx image. To view the logs of the scheduler, 61 00:05:14,040 --> 00:05:19,680 view the logs of the pod using the kubectl logs command. Specify the name of the scheduler 62 00:05:19,680 --> 00:05:21,780 the correct namespace. 63 00:05:21,780 --> 00:05:23,580 Well that's it for this lecture. 64 00:05:23,580 --> 00:05:29,050 Head over to the practice exercises and practice deploying multiple schedulers. 65 00:05:29,220 --> 00:05:30,840 I will see you in the next lecture.