Welcome back everybody.
You've seen so far just how easy it is to manage our containers in Kubernetes.
All the benefits that it provides.
Well I have great news.
Things are about to get even easier.
Let's assume you've got one pod running, one instance of your app, and one pod just simply isn't enough
to handle all the traffic you're getting from your end users.
Your app is just so popular, and so in this case, Kubernetes allows you to define how many replicas
of your pod you want to run.
Let's imagine that you decide three instances of your app is enough to handle all that traffic.
What you can say is I want three pod replicas to run based on the pod template that I specify.
Okay, we've been creating pods all throughout this course.
The pod template would be that pod definition, and we can specify how many replicas of that pod we
want deployed and ready to serve traffic.
Okay.
So by as a developer all you need to do is specify this very simple deployment object.
And then after some Kubernetes magic, which Kubernetes does for you behind the scenes, we end up with
three pod replicas, all running identical applications.
Now how do we get from here to here?
What actually is happening behind the scenes this deployment object.
It abstracts away all the complexities, but it's good to be familiar with what actually happens and
not treat Kubernetes as this magical black box.
So when you create a deployment, a deployment controller will set up a replica set with three pods.
A replica set is simply a specialized Kubernetes resource that ensures a certain number of pods is running
at all times.
Okay, so this signals to a replica set controller to create three pods based on the pod template that
we specified in our deployment object.
So not only do we have Kubernetes creating our three pods for us, it takes it a step further by continuously
monitoring our pods to ensure that we always have three healthy pods running at all times.
If one of the pods were to restart, fail, terminate, delete for whatever reason, uh, Kubernetes
or the replica set controller in this case will always ensure that it will take us from whatever current
state we're at to a desired state of three healthy pod replicas running our applications ready to serve
traffic.
So by virtue of creating this very simple deployment object, we get the benefit of automated pod deployment
and continuous monitoring of our pods to make sure that we always have a certain number of healthy running
pods.
Enough theory.
Let's go ahead and implement this.
So what I'm going to do is create a new folder We'll call it section four.
And in that folder I'm going to copy and paste everything we've got in section three.
And let's begin.
Um, we can start by cleaning up actually kubectl uh, delete pods dash dash all dash n great submission
because we're not going to be deploying standalone pods anymore.
We're going to create a deployment that manages these pod replicas for us.
And we can go ahead and keep the services that we already have inside of great submission.
The services will not change.
So inside of section four I'm going to create a new file grade submission API deployment dot YAML.
And by virtue of having the Kubernetes extension, we can just say deployment and it auto generates
the deployment skeleton.
I'm going to start by naming the deployment.
Simply great submission API because it's going to be managing a certain number of great submission API
pods.
The pod template we specify over here the number of pod replicas that we're going to be managing.
We specify over here.
Okay.
So we're going to be managing three great submission API pod replicas.
All right.
And now we need to create a link between the great submission API deployment and whatever pods we end
up creating.
That link is done using a label selector.
So we want the deployment to manage every single pod that has the following label.
So it's going to query any pod with this label and manage its deployment.
It follows that the pods we create will end up having this label.
Actually, you know what?
What I'm going to do is you see where it says metadata.
We're going to start by copying everything from line six and downwards.
And from line 12 I'm just going to select everything and paste it.
Now select all this.
Press tab once.
Press tab twice and we're good.
So this specifies how each pod will be created.
And this specifies the number of pods that will be created from this pod template.
And this creates a link between the deployment and the pods being created.
So each pod will have the following label And the deployment is able to find and manage these pods using
this label selector.
Okay.
That's all we need.
I can go ahead and delete this.
And you know what?
Instead of three pod replicas, I don't want to consume too much memory and CPU.
We'll leave it at two.
And the great submission API service won't change, because ultimately we're going to have two pods
deployed based on this template.
And the service is also linked to every single pod that has this label.
And it's going to be able to forward traffic to both pods.
It will distribute traffic to one of the pod replicas.
Okay, now we can create a great submission portal deployment, great submission portal Deployment.yaml.
And we'll do the same thing.
Uh, the name of the deployment will be great submission portal.
Um, this great submission portal will manage the deployment of any pod labeled instance crates.
Oh.
What am I doing?
Instance.
Great.
Submission portal.
Fix the indentation up.
All right.
And, um, so here we're going to specify that we want the great submission portal to be managing just
one pod replica.
Uh, one pod replica should be the default, but let's explicitly specify it anyways.
And the pod template we are, we've already created before, so right from here we can just copy everything.
Copy and paste it.
Okay
That's it.
So this is going to be managing the creation of one pod.
This will be managing the creation of two great submission API pod replicas.
We can delete the pod and we are good.
Okay.
Now even if this is just managing one pod, we still get the benefit that if the pod, the entire pod
were to fail or terminate for whatever reason, the Great Submission Portal deployment will always ensure
that that pod gets recreated in order to match the desired state that we've specified right here.
Okay, so it's really important that you manage your pods through pod deployments, not through the
standalone pod primitive.
So now if I see the out of section three CD into zero four, section four, I can go ahead Take kubectl
apply dash f apply everything.
Uh, the deployment gets created, the services are unchanged.
Everything is working beautifully.
Um, and, yeah, that's pretty much it.
I can say kubectl get deployments in the namespace.
Uh, I'm such a knucklehead.
These were deployed in the, um, default namespace.
While the services are inside of the great submission namespace.
We don't want to do that kubectl delete all the deployments.
And the default namespace.
No.
Beautiful.
And while that's happening I'm going to specify a namespace of great submission.
And namespace of great submission here as well.
Everything is going to be deployed inside of the same namespace.
They're all going to be able to seamlessly collaborate with one another.
We'll reapply our deployments kubectl get deployments inside of the namespace.
Great submission.
So we've got two deployments.
One deployment is managing two pods.
One deployment is managing one pod.
Then I'm going to say kubectl get pods dash n grade submission.
And now we've got three pods one grade submission two grade submission API pod replicas.
Notice that they both start with the name grade submission API followed by a random string.
And then we've got one great submission portal pod replica.
Each one is running one container.
And that's pretty much it.
The service.
The great submission API service is going to forward traffic to any pod that has the following label.
In essence, it's going to distribute traffic to these two pods, which means we get the benefit of
load balancing now.
So whenever we get a lot of traffic, what the cluster IP service is going to do.
Cluster IP services are natural load balancers.
So it's going to distribute traffic to one of the pods in a round robin fashion.
It'll send one request here, one request there.
And the fact that we get load balancing out of the box is amazing, because you never want one instance
of your app to be getting all of the traffic right.
You want to distribute that traffic, distribute the load so that your apps don't get overwhelmed and
end up consuming too much memory or CPU and potentially terminating.
right?
So we get load balancing out of the box and everything should work beautifully.
If I go ahead and say localhost 32,000, um, my request is going to be forwarded to the grade submission
portal pod that is currently running that is also currently being managed by a deployment.
So let's go ahead and do that.
All right.
So when the grade submission portal ends up making a request to this cluster IP service, there isn't
just one pod.
And now there are two pods.
And it'll forward that request to one of the pods which will end up sending back a response.
So everything should work beautifully.
Harry will give him a score of 56 and charms.
Actually, I think he was good at charms.
We'll give him an 80.
Press submit.
Beautiful.
All right.
Uh.
That's deployments.
Hope you enjoyed this lesson I'll see you in the next one.