-In this video, we're going to walk over the practice test
on manual scheduling.
The question is a pod definition file nginx.yaml is given,
and you have to create a pod.
Let's go over this, but before that, let's just quickly explore
the environment.
If run the get nodes command, we see that it's a two node cluster,
so that's what we're working with now.
There is a file called nginx.yaml.
By the looks of it, it's just a normal pod definition file
with the name set to nginx and the image set to nginx, as well.
Let's go ahead and create this.
Okay, and let's click on check.
The goal of this exercise is just to create the pod.
You don't have to check the status for now.
Let's go to the next question.
What is the status of the created POD?
We see that it's in a pending state.
That's the answer. It's in a pending state.
Why is the POD in a pending state?
Inspect the environment for various Kubernetes control plane components.
One thing that we've learned is that it's the scheduler that schedules the pod.
If the pod's status is in pending, take a closer look at the pod.
We don't see any additional details, other than the fact
that it's in a pending state.
That basically means the scheduler has not done its job of scheduling
the pod on a node.
If you look at it here, the node field is set to none.
Let's look at the scheduler.
The scheduler runs as a pod, in the cube system namespace.
We see that we have the API server, the controller manager, the proxy,
the etcd-controlplane, but there is no scheduler running.
That could be the reason why this pod is not running,
and it's in a pending state.
We're going to say that there's no scheduler present.
Okay, so now we have to manually schedule the pod on node01.
Now, we've already created the pod, but it's not assigned to any node.
One thing that we've learned in the previous lecture is that we
can manually schedule the pod.
We're going to edit the nginx.yaml file.
We're going to add
a node name property here.
We'll set that to node01.
Okay, and then we--
Now we've got to recreate the pod, so we have to delete it and recreate it.
One way to do that is just to delete the pod and recreate it.
We can also just use the replace command
if we need to do that, just in a single command.
We're going to do a replace force.
That's going to delete the pod and then recreate it,
and then we're going to specify the file.
Yes, the pod is deleted and then it's just replaced.
Let's look at the status of the pod now.
You see that's in a container, creating state.
Now, if you don't want to run the same command multiple times,
to check the status, you could just add the watch option
and what it's going to do is it's going to continue
to monitor that part and it's going to update
the status if something changes.
It's already in a running state, so we're good.
Okay, next.
Now schedule the same pod on the controlplane node.
Again, that's pretty simple.
If you go in and make the same change, so, this is just for additional practice,
controlplane.
Then we are going to have to do the same thing.
Now, remember that we cannot move a running pod from one node to another.
Ultimately, a pod is actually a container which is basically another process running
on a system.
You cannot move a running process as-is from one system to another.
There is no way to basically move pods from systems to systems.
You can only delete pods from one system and one node
and then recreate it on another.
That was a question that I got from a student.
Let's do the replace again.
Remember to use a force.
You're sure you want to delete and recreate it?
We'll wait for it to terminate.
Now again, if you look at this it's taking a while to delete
so that's not a problem with Kubernetes or with our lab environment.
It's normal for that to happen when you terminate
or when you delete a pod,
what happens is, in the back end, it has to go in and terminate
the process that's running.
In this case, it's the Nginx process.
It basically sends a kill signal to the process and the process,
depending on what process is running and the way that it handles kill signals,
it might take some time for it to process that request
and actually kill or gracefully shut down.
That's the reason why it takes a few seconds when you delete certain pods
and that's what happened this time so it's not because there's an issue
with either Kubernetes or the node or the lab environment,
that's just how it works.
Okay, so let's now check the pod, check it's running,
if you do a wide option then you'll get to see
on which node is scheduled so you can see that it's on the controlplane node.
Okay.
All right and that's the end of this lab.