WEBVTT 00:00.906 --> 00:04.890 -In this video, we're going to walk over the practice test 00:04.920 --> 00:06.681 on manual scheduling. 00:08.700 --> 00:12.990 The question is a pod definition file nginx.yaml is given, 00:13.080 --> 00:14.699 and you have to create a pod. 00:14.700 --> 00:17.819 Let's go over this, but before that, let's just quickly explore 00:17.820 --> 00:18.820 the environment. 00:19.920 --> 00:24.330 If run the get nodes command, we see that it's a two node cluster, 00:24.450 --> 00:26.046 so that's what we're working with now. 00:27.180 --> 00:29.950 There is a file called nginx.yaml. 00:32.400 --> 00:36.060 By the looks of it, it's just a normal pod definition file 00:36.420 --> 00:40.111 with the name set to nginx and the image set to nginx, as well. 00:41.160 --> 00:43.530 Let's go ahead and create this. 00:49.920 --> 00:52.441 Okay, and let's click on check. 00:55.702 --> 01:00.461 The goal of this exercise is just to create the pod. 01:01.351 --> 01:03.420 You don't have to check the status for now. 01:04.320 --> 01:05.520 Let's go to the next question. 01:06.120 --> 01:08.010 What is the status of the created POD? 01:08.171 --> 01:10.063 We see that it's in a pending state. 01:11.070 --> 01:12.850 That's the answer. It's in a pending state. 01:18.492 --> 01:22.303 Why is the POD in a pending state? 01:22.383 --> 01:26.742 Inspect the environment for various Kubernetes control plane components. 01:27.570 --> 01:32.640 One thing that we've learned is that it's the scheduler that schedules the pod. 01:33.270 --> 01:38.134 If the pod's status is in pending, take a closer look at the pod. 01:44.850 --> 01:49.527 We don't see any additional details, other than the fact 01:49.597 --> 01:51.299 that it's in a pending state. 01:51.300 --> 01:56.361 That basically means the scheduler has not done its job of scheduling 01:56.411 --> 01:57.930 the pod on a node. 01:58.680 --> 02:02.536 If you look at it here, the node field is set to none. 02:03.570 --> 02:06.750 Let's look at the scheduler. 02:08.261 --> 02:14.051 The scheduler runs as a pod, in the cube system namespace. 02:16.260 --> 02:21.870 We see that we have the API server, the controller manager, the proxy, 02:21.960 --> 02:24.271 the etcd-controlplane, but there is no scheduler running. 02:25.170 --> 02:32.519 That could be the reason why this pod is not running, 02:32.520 --> 02:33.641 and it's in a pending state. 02:33.850 --> 02:37.620 We're going to say that there's no scheduler present. 02:41.924 --> 02:45.395 Okay, so now we have to manually schedule the pod on node01. 02:45.865 --> 02:49.862 Now, we've already created the pod, but it's not assigned to any node. 02:50.730 --> 02:53.369 One thing that we've learned in the previous lecture is that we 02:53.370 --> 02:54.931 can manually schedule the pod. 02:55.431 --> 02:58.641 We're going to edit the nginx.yaml file. 03:00.311 --> 03:01.488 We're going to add 03:02.978 --> 03:05.489 a node name property here. 03:06.319 --> 03:08.674 We'll set that to node01. 03:11.129 --> 03:13.220 Okay, and then we-- 03:14.313 --> 03:17.734 Now we've got to recreate the pod, so we have to delete it and recreate it. 03:18.813 --> 03:21.914 One way to do that is just to delete the pod and recreate it. 03:22.590 --> 03:24.367 We can also just use the replace command 03:24.867 --> 03:27.740 if we need to do that, just in a single command. 03:27.800 --> 03:30.120 We're going to do a replace force. 03:30.200 --> 03:32.683 That's going to delete the pod and then recreate it, 03:32.780 --> 03:35.470 and then we're going to specify the file. 03:35.551 --> 03:39.841 Yes, the pod is deleted and then it's just replaced. 03:40.527 --> 03:44.070 Let's look at the status of the pod now. 03:44.589 --> 03:47.130 You see that's in a container, creating state. 03:48.270 --> 03:50.710 Now, if you don't want to run the same command multiple times, 03:51.040 --> 03:54.300 to check the status, you could just add the watch option 03:54.390 --> 03:56.900 and what it's going to do is it's going to continue 03:56.970 --> 04:00.490 to monitor that part and it's going to update 04:00.550 --> 04:02.070 the status if something changes. 04:02.760 --> 04:07.320 It's already in a running state, so we're good. 04:09.771 --> 04:11.001 Okay, next. 04:12.780 --> 04:16.701 Now schedule the same pod on the controlplane node. 04:17.641 --> 04:21.061 Again, that's pretty simple. 04:22.497 --> 04:27.717 If you go in and make the same change, so, this is just for additional practice, 04:28.557 --> 04:30.337 controlplane. 04:31.814 --> 04:35.310 Then we are going to have to do the same thing. 04:35.670 --> 04:43.082 Now, remember that we cannot move a running pod from one node to another. 04:43.992 --> 04:50.639 Ultimately, a pod is actually a container which is basically another process running 04:50.640 --> 04:51.960 on a system. 04:52.560 --> 04:57.370 You cannot move a running process as-is from one system to another. 04:57.760 --> 05:04.060 There is no way to basically move pods from systems to systems. 05:04.370 --> 05:07.278 You can only delete pods from one system and one node 05:07.279 --> 05:09.410 and then recreate it on another. 05:09.750 --> 05:14.031 That was a question that I got from a student. 05:16.781 --> 05:19.653 Let's do the replace again. 05:21.449 --> 05:23.040 Remember to use a force. 05:24.870 --> 05:27.060 You're sure you want to delete and recreate it? 05:29.322 --> 05:30.941 We'll wait for it to terminate. 05:31.201 --> 05:35.011 Now again, if you look at this it's taking a while to delete 05:35.481 --> 05:41.700 so that's not a problem with Kubernetes or with our lab environment. 05:42.180 --> 05:45.900 It's normal for that to happen when you terminate 05:45.960 --> 05:46.960 or when you delete a pod, 05:47.417 --> 05:50.609 what happens is, in the back end, it has to go in and terminate 05:50.610 --> 05:51.900 the process that's running. 05:52.020 --> 05:53.850 In this case, it's the Nginx process. 05:54.080 --> 05:56.954 It basically sends a kill signal to the process and the process, 05:58.084 --> 06:03.360 depending on what process is running and the way that it handles kill signals, 06:03.690 --> 06:07.350 it might take some time for it to process that request 06:07.400 --> 06:10.200 and actually kill or gracefully shut down. 06:10.777 --> 06:15.360 That's the reason why it takes a few seconds when you delete certain pods 06:15.870 --> 06:20.040 and that's what happened this time so it's not because there's an issue 06:20.597 --> 06:24.093 with either Kubernetes or the node or the lab environment, 06:24.094 --> 06:27.000 that's just how it works. 06:28.770 --> 06:35.310 Okay, so let's now check the pod, check it's running, 06:35.430 --> 06:38.440 if you do a wide option then you'll get to see 06:38.460 --> 06:42.240 on which node is scheduled so you can see that it's on the controlplane node. 06:46.958 --> 06:47.958 Okay. 06:50.100 --> 06:52.440 All right and that's the end of this lab.