WEBVTT

00:00.020 --> 00:01.250
Welcome back everybody.

00:01.400 --> 00:05.930
You've seen so far just how easy it is to manage our containers in Kubernetes.

00:05.930 --> 00:07.670
All the benefits that it provides.

00:07.670 --> 00:09.290
Well I have great news.

00:09.290 --> 00:11.540
Things are about to get even easier.

00:11.540 --> 00:18.170
Let's assume you've got one pod running, one instance of your app, and one pod just simply isn't enough

00:18.170 --> 00:21.350
to handle all the traffic you're getting from your end users.

00:21.350 --> 00:29.000
Your app is just so popular, and so in this case, Kubernetes allows you to define how many replicas

00:29.000 --> 00:30.620
of your pod you want to run.

00:30.620 --> 00:36.530
Let's imagine that you decide three instances of your app is enough to handle all that traffic.

00:36.560 --> 00:44.030
What you can say is I want three pod replicas to run based on the pod template that I specify.

00:44.060 --> 00:47.900
Okay, we've been creating pods all throughout this course.

00:47.900 --> 00:54.770
The pod template would be that pod definition, and we can specify how many replicas of that pod we

00:54.770 --> 00:57.560
want deployed and ready to serve traffic.

00:57.590 --> 00:58.160
Okay.

00:58.190 --> 01:05.370
So by as a developer all you need to do is specify this very simple deployment object.

01:05.370 --> 01:12.660
And then after some Kubernetes magic, which Kubernetes does for you behind the scenes, we end up with

01:12.660 --> 01:17.430
three pod replicas, all running identical applications.

01:17.460 --> 01:19.620
Now how do we get from here to here?

01:19.650 --> 01:24.000
What actually is happening behind the scenes this deployment object.

01:24.030 --> 01:30.000
It abstracts away all the complexities, but it's good to be familiar with what actually happens and

01:30.000 --> 01:33.270
not treat Kubernetes as this magical black box.

01:34.380 --> 01:42.030
So when you create a deployment, a deployment controller will set up a replica set with three pods.

01:42.060 --> 01:49.920
A replica set is simply a specialized Kubernetes resource that ensures a certain number of pods is running

01:49.920 --> 01:50.970
at all times.

01:51.000 --> 01:59.940
Okay, so this signals to a replica set controller to create three pods based on the pod template that

01:59.940 --> 02:02.190
we specified in our deployment object.

02:02.190 --> 02:09.490
So not only do we have Kubernetes creating our three pods for us, it takes it a step further by continuously

02:09.490 --> 02:17.350
monitoring our pods to ensure that we always have three healthy pods running at all times.

02:17.350 --> 02:24.280
If one of the pods were to restart, fail, terminate, delete for whatever reason, uh, Kubernetes

02:24.280 --> 02:29.950
or the replica set controller in this case will always ensure that it will take us from whatever current

02:29.950 --> 02:39.040
state we're at to a desired state of three healthy pod replicas running our applications ready to serve

02:39.040 --> 02:40.030
traffic.

02:40.360 --> 02:47.080
So by virtue of creating this very simple deployment object, we get the benefit of automated pod deployment

02:47.080 --> 02:54.130
and continuous monitoring of our pods to make sure that we always have a certain number of healthy running

02:54.130 --> 02:54.850
pods.

02:55.240 --> 02:56.380
Enough theory.

02:56.380 --> 02:58.150
Let's go ahead and implement this.

02:58.990 --> 03:06.830
So what I'm going to do is create a new folder We'll call it section four.

03:07.310 --> 03:11.720
And in that folder I'm going to copy and paste everything we've got in section three.

03:13.610 --> 03:16.010
And let's begin.

03:16.970 --> 03:28.910
Um, we can start by cleaning up actually kubectl uh, delete pods dash dash all dash n great submission

03:29.120 --> 03:32.810
because we're not going to be deploying standalone pods anymore.

03:32.810 --> 03:38.120
We're going to create a deployment that manages these pod replicas for us.

03:38.270 --> 03:43.880
And we can go ahead and keep the services that we already have inside of great submission.

03:43.880 --> 03:46.580
The services will not change.

03:46.760 --> 03:56.150
So inside of section four I'm going to create a new file grade submission API deployment dot YAML.

03:57.380 --> 04:03.620
And by virtue of having the Kubernetes extension, we can just say deployment and it auto generates

04:03.620 --> 04:05.550
the deployment skeleton.

04:06.000 --> 04:09.150
I'm going to start by naming the deployment.

04:09.450 --> 04:16.740
Simply great submission API because it's going to be managing a certain number of great submission API

04:16.770 --> 04:17.670
pods.

04:17.700 --> 04:25.710
The pod template we specify over here the number of pod replicas that we're going to be managing.

04:25.710 --> 04:27.630
We specify over here.

04:27.840 --> 04:28.530
Okay.

04:28.530 --> 04:35.670
So we're going to be managing three great submission API pod replicas.

04:35.940 --> 04:36.900
All right.

04:37.170 --> 04:45.000
And now we need to create a link between the great submission API deployment and whatever pods we end

04:45.030 --> 04:45.960
up creating.

04:45.960 --> 04:49.980
That link is done using a label selector.

04:49.980 --> 04:56.730
So we want the deployment to manage every single pod that has the following label.

04:56.730 --> 05:02.160
So it's going to query any pod with this label and manage its deployment.

05:02.160 --> 05:08.020
It follows that the pods we create will end up having this label.

05:08.500 --> 05:09.940
Actually, you know what?

05:09.940 --> 05:14.350
What I'm going to do is you see where it says metadata.

05:16.900 --> 05:22.870
We're going to start by copying everything from line six and downwards.

05:25.990 --> 05:32.710
And from line 12 I'm just going to select everything and paste it.

05:35.050 --> 05:37.870
Now select all this.

05:37.870 --> 05:39.250
Press tab once.

05:39.250 --> 05:41.680
Press tab twice and we're good.

05:42.400 --> 05:47.110
So this specifies how each pod will be created.

05:47.440 --> 05:54.880
And this specifies the number of pods that will be created from this pod template.

05:55.480 --> 06:01.420
And this creates a link between the deployment and the pods being created.

06:01.420 --> 06:09.080
So each pod will have the following label And the deployment is able to find and manage these pods using

06:09.080 --> 06:10.940
this label selector.

06:11.120 --> 06:11.840
Okay.

06:11.870 --> 06:12.950
That's all we need.

06:12.980 --> 06:14.960
I can go ahead and delete this.

06:18.860 --> 06:20.030
And you know what?

06:20.060 --> 06:24.740
Instead of three pod replicas, I don't want to consume too much memory and CPU.

06:24.770 --> 06:26.030
We'll leave it at two.

06:27.920 --> 06:34.820
And the great submission API service won't change, because ultimately we're going to have two pods

06:34.820 --> 06:38.420
deployed based on this template.

06:38.420 --> 06:45.650
And the service is also linked to every single pod that has this label.

06:45.650 --> 06:50.060
And it's going to be able to forward traffic to both pods.

06:50.060 --> 06:54.140
It will distribute traffic to one of the pod replicas.

06:54.170 --> 07:05.600
Okay, now we can create a great submission portal deployment, great submission portal Deployment.yaml.

07:06.440 --> 07:07.820
And we'll do the same thing.

07:08.990 --> 07:13.070
Uh, the name of the deployment will be great submission portal.

07:14.660 --> 07:23.960
Um, this great submission portal will manage the deployment of any pod labeled instance crates.

07:23.990 --> 07:24.350
Oh.

07:24.380 --> 07:25.670
What am I doing?

07:26.270 --> 07:27.050
Instance.

07:27.050 --> 07:27.320
Great.

07:27.320 --> 07:28.310
Submission portal.

07:28.310 --> 07:29.750
Fix the indentation up.

07:29.750 --> 07:30.710
All right.

07:30.710 --> 07:38.210
And, um, so here we're going to specify that we want the great submission portal to be managing just

07:38.210 --> 07:39.860
one pod replica.

07:40.040 --> 07:46.400
Uh, one pod replica should be the default, but let's explicitly specify it anyways.

07:46.490 --> 07:54.440
And the pod template we are, we've already created before, so right from here we can just copy everything.

07:57.980 --> 08:00.230
Copy and paste it.

08:03.620 --> 08:04.700
Okay

08:10.110 --> 08:10.830
That's it.

08:10.830 --> 08:14.730
So this is going to be managing the creation of one pod.

08:14.760 --> 08:20.130
This will be managing the creation of two great submission API pod replicas.

08:20.130 --> 08:25.440
We can delete the pod and we are good.

08:25.470 --> 08:25.980
Okay.

08:26.010 --> 08:34.200
Now even if this is just managing one pod, we still get the benefit that if the pod, the entire pod

08:34.230 --> 08:40.290
were to fail or terminate for whatever reason, the Great Submission Portal deployment will always ensure

08:40.290 --> 08:47.490
that that pod gets recreated in order to match the desired state that we've specified right here.

08:47.520 --> 08:54.120
Okay, so it's really important that you manage your pods through pod deployments, not through the

08:54.120 --> 08:56.160
standalone pod primitive.

08:56.670 --> 09:07.680
So now if I see the out of section three CD into zero four, section four, I can go ahead Take kubectl

09:07.710 --> 09:10.300
apply dash f apply everything.

09:11.680 --> 09:17.170
Uh, the deployment gets created, the services are unchanged.

09:17.200 --> 09:19.420
Everything is working beautifully.

09:20.110 --> 09:21.970
Um, and, yeah, that's pretty much it.

09:21.970 --> 09:27.370
I can say kubectl get deployments in the namespace.

09:28.210 --> 09:30.730
Uh, I'm such a knucklehead.

09:31.540 --> 09:37.810
These were deployed in the, um, default namespace.

09:37.840 --> 09:41.800
While the services are inside of the great submission namespace.

09:41.800 --> 09:48.250
We don't want to do that kubectl delete all the deployments.

09:50.830 --> 09:53.020
And the default namespace.

09:57.250 --> 09:57.760
No.

09:57.790 --> 09:58.420
Beautiful.

09:58.420 --> 10:03.670
And while that's happening I'm going to specify a namespace of great submission.

10:07.420 --> 10:10.070
And namespace of great submission here as well.

10:12.560 --> 10:15.860
Everything is going to be deployed inside of the same namespace.

10:15.860 --> 10:20.120
They're all going to be able to seamlessly collaborate with one another.

10:20.420 --> 10:29.870
We'll reapply our deployments kubectl get deployments inside of the namespace.

10:29.870 --> 10:31.190
Great submission.

10:32.150 --> 10:34.370
So we've got two deployments.

10:34.370 --> 10:37.910
One deployment is managing two pods.

10:37.910 --> 10:41.330
One deployment is managing one pod.

10:42.320 --> 10:46.730
Then I'm going to say kubectl get pods dash n grade submission.

10:48.620 --> 10:54.890
And now we've got three pods one grade submission two grade submission API pod replicas.

10:54.920 --> 11:01.160
Notice that they both start with the name grade submission API followed by a random string.

11:01.160 --> 11:04.790
And then we've got one great submission portal pod replica.

11:04.820 --> 11:07.550
Each one is running one container.

11:08.300 --> 11:10.340
And that's pretty much it.

11:10.580 --> 11:11.970
The service.

11:12.000 --> 11:20.010
The great submission API service is going to forward traffic to any pod that has the following label.

11:20.010 --> 11:28.290
In essence, it's going to distribute traffic to these two pods, which means we get the benefit of

11:28.290 --> 11:29.790
load balancing now.

11:29.790 --> 11:36.840
So whenever we get a lot of traffic, what the cluster IP service is going to do.

11:36.870 --> 11:41.070
Cluster IP services are natural load balancers.

11:41.070 --> 11:47.280
So it's going to distribute traffic to one of the pods in a round robin fashion.

11:47.280 --> 11:50.220
It'll send one request here, one request there.

11:50.220 --> 11:57.360
And the fact that we get load balancing out of the box is amazing, because you never want one instance

11:57.360 --> 12:00.540
of your app to be getting all of the traffic right.

12:00.540 --> 12:06.930
You want to distribute that traffic, distribute the load so that your apps don't get overwhelmed and

12:06.930 --> 12:11.880
end up consuming too much memory or CPU and potentially terminating.

12:11.920 --> 12:12.520
right?

12:13.060 --> 12:18.610
So we get load balancing out of the box and everything should work beautifully.

12:18.640 --> 12:27.910
If I go ahead and say localhost 32,000, um, my request is going to be forwarded to the grade submission

12:27.910 --> 12:34.690
portal pod that is currently running that is also currently being managed by a deployment.

12:34.690 --> 12:36.370
So let's go ahead and do that.

12:38.290 --> 12:39.100
All right.

12:39.100 --> 12:45.310
So when the grade submission portal ends up making a request to this cluster IP service, there isn't

12:45.310 --> 12:46.270
just one pod.

12:46.300 --> 12:47.980
And now there are two pods.

12:47.980 --> 12:53.560
And it'll forward that request to one of the pods which will end up sending back a response.

12:53.860 --> 12:56.410
So everything should work beautifully.

12:56.440 --> 13:00.760
Harry will give him a score of 56 and charms.

13:00.790 --> 13:02.440
Actually, I think he was good at charms.

13:02.470 --> 13:03.400
We'll give him an 80.

13:03.430 --> 13:04.540
Press submit.

13:04.570 --> 13:05.650
Beautiful.

13:06.340 --> 13:07.330
All right.

13:07.330 --> 13:07.750
Uh.

13:07.750 --> 13:09.130
That's deployments.

13:09.160 --> 13:12.190
Hope you enjoyed this lesson I'll see you in the next one.