WEBVTT

00:00.090 --> 00:03.920
[music]

00:04.970 --> 00:06.460
-Hello, and welcome to this lecture.

00:06.620 --> 00:08.570
My name is Mumshad Mannambeth.

00:08.780 --> 00:12.400
In this lecture, we will discuss
about Kubernetes deployments.

00:14.130 --> 00:18.050
For a minute, let us forget
about pods and replica sets

00:18.220 --> 00:20.220
and other Kubernetes concepts

00:20.670 --> 00:24.020
and talk about how you might
want to deploy your application

00:24.180 --> 00:25.730
in a production environment.

00:26.330 --> 00:30.270
Say, for example, you have a web
server that needs to be deployed

00:30.440 --> 00:31.920
in a production environment,

00:32.380 --> 00:35.030
you need not one
but many such instances

00:35.200 --> 00:38.260
of the web server running
for obvious reasons.

00:39.070 --> 00:43.140
Secondly, whenever newer versions
of application builds become

00:43.310 --> 00:45.330
available on the Docker registry,

00:45.770 --> 00:49.540
you would like to upgrade
your Docker instances seamlessly.

00:49.890 --> 00:52.870
However, when you upgrade
your instances,

00:53.100 --> 00:56.800
you do not want to upgrade
all of them at once as we just did.

00:57.220 --> 01:00.010
This may impact users
accessing our applications.

01:00.180 --> 01:03.430
So you might want to upgrade them
one after the other.

01:04.150 --> 01:07.220
That kind of upgrade
is known as rolling updates.

01:08.240 --> 01:10.570
Suppose one of the upgrades
you performed resulted

01:10.740 --> 01:12.770
in an unexpected error

01:12.940 --> 01:15.440
and you're asked
to undo the recent change.

01:15.950 --> 01:18.480
You would like to be able
to roll back the changes

01:18.650 --> 01:20.280
that were recently carried out.

01:21.160 --> 01:23.920
Finally, say, for example,
you would like to make

01:24.090 --> 01:27.330
multiple changes to your environment
such as upgrading

01:27.490 --> 01:29.640
the underlying web server versions,

01:29.880 --> 01:32.470
as well as scaling your environment
and also modifying

01:32.640 --> 01:34.980
the resource allocations, et cetera,

01:35.270 --> 01:38.450
you do not want
to apply each change immediately

01:38.620 --> 01:39.410
after the command is run.

01:39.580 --> 01:43.330
Instead, you would like to apply
a pause to your environment,

01:43.520 --> 01:46.590
make the changes, and then resume,
so that all the changes

01:46.760 --> 01:48.410
are rolled out together.

01:49.230 --> 01:51.220
All of these capabilities
are available

01:51.390 --> 01:53.280
with the Kubernetes deployments.

01:53.750 --> 01:56.780
So far in this course,
we discussed about pods,

01:56.950 --> 02:00.430
which deploy single instances
of our application

02:00.600 --> 02:02.870
such as the web application
in this case.

02:03.710 --> 02:06.370
Each container is
encapsulated in pods.

02:07.050 --> 02:10.870
Multiple sites pods are deployed
using replication controllers

02:11.040 --> 02:12.180
or replica sets.

02:13.040 --> 02:16.490
Then comes deployment,
which is a Kubernetes object

02:16.670 --> 02:18.720
that comes higher in the hierarchy.

02:19.610 --> 02:22.440
The deployment provides us
with the capability

02:22.730 --> 02:25.430
to upgrade the underlying
instances seamlessly

02:25.600 --> 02:27.290
using rolling updates,

02:27.600 --> 02:31.480
undo changes, and pause
and resume changes as required.

02:32.790 --> 02:34.500
How do we create a deployment?

02:35.290 --> 02:37.760
As with the previous components,
we first create

02:37.930 --> 02:39.940
a deployment definition file.

02:40.380 --> 02:43.680
The contents of the deployment
definition file are exactly similar

02:43.840 --> 02:47.800
to the replica set definition file,
except for the kind

02:47.970 --> 02:50.210
which is now going to be deployment.

02:50.850 --> 02:54.190
If we walk through the contents
of the file, it has an API version

02:54.360 --> 02:56.860
which is apps/v1,

02:57.260 --> 03:01.230
metadata which has name and labels,
and a spec that has template,

03:01.400 --> 03:02.990
replicas, and selector.

03:03.740 --> 03:06.770
The template has
a pod definition inside it.

03:07.930 --> 03:11.150
Once the file is ready,
run the kubectl create command

03:11.310 --> 03:13.750
and specify
the deployment definition file.

03:14.760 --> 03:17.910
Then run the kubectl
get deployments command

03:18.080 --> 03:20.140
to see the newly created deployment.

03:20.590 --> 03:23.620
The deployment automatically
creates a replica set.

03:23.960 --> 03:26.800
So if you run the kubectl
get replica set command,

03:26.990 --> 03:31.400
you will be able to see a new replica
set in the name of the deployment.

03:32.220 --> 03:34.720
The replica sets ultimately
create pods.

03:34.880 --> 03:37.720
If you run the kubectl
get pods command,

03:38.100 --> 03:40.250
you will be able
to see the pods with the name

03:40.420 --> 03:42.480
of the deployment
and the replica set.

03:43.500 --> 03:47.450
So far, there hasn't been much
of a difference between replica set

03:47.620 --> 03:51.010
and deployments,
except for the fact that deployment

03:51.180 --> 03:54.660
created a new Kubernetes object
called deployments.

03:55.680 --> 03:58.460
We will see how to take advantage
of the deployment using

03:58.620 --> 04:01.330
the use cases we discussed
in the previous slide

04:01.490 --> 04:02.940
in the upcoming lectures.

04:04.430 --> 04:07.320
One more note
before we end this lecture.

04:07.490 --> 04:11.680
To see all the created objects
at once, run the kubectl

04:11.840 --> 04:13.170
get all command.

04:14.060 --> 04:17.780
In this case, we can see
that the deployment was created,

04:17.950 --> 04:19.910
and then we have the replica set,

04:20.070 --> 04:22.200
followed by three pods
that we created

04:22.370 --> 04:24.110
as part of the deployment.

04:24.540 --> 04:25.890
That's it for this lecture.