WEBVTT

00:00.625 --> 00:02.429
Hello, and welcome to this lecture.

00:02.606 --> 00:04.746
In this lecture,
we will talk about updates

00:04.938 --> 00:07.063
and rollbacks in a deployment.

00:08.174 --> 00:11.036
Before we look at
how we upgrade our application,

00:11.204 --> 00:12.550
let's try to understand

00:12.718 --> 00:15.318
rollouts and versioning
in a deployment.

00:16.242 --> 00:19.890
When you first create a
deployment, it triggers a rollout.

00:20.626 --> 00:24.485
A new rollout creates
a new deployment revision.

00:24.861 --> 00:26.541
Let's call it Revision 1.

00:27.628 --> 00:30.114
In the future
when the application is upgraded,

00:30.281 --> 00:32.923
meaning when the container version
is updated

00:33.150 --> 00:35.837
to a new one,
a new rollout is triggered

00:36.005 --> 00:40.477
and a new deployment revision
is created, named Revision 2.

00:41.289 --> 00:45.513
This helps us keep track of the
changes made to our deployment,

00:45.817 --> 00:48.915
and enables us to roll back
to a previous version

00:49.083 --> 00:50.971
of deployment if necessary.

00:52.120 --> 00:55.557
You can see the status of your
rollout by running the command

00:55.838 --> 01:00.388
'kubectl rollout status', followed
by the name of the deployment.

01:01.060 --> 01:03.797
To see the revisions and history
of rollout,

01:04.175 --> 01:07.143
run the 'kubectr rollout history'
command,

01:07.386 --> 01:09.358
followed by the deployment name,

01:09.608 --> 01:11.424
and this will show you the revisions

01:11.651 --> 01:13.978
and history of our deployment.

01:16.150 --> 01:19.198
There are two types of
deployment strategies.

01:19.574 --> 01:21.970
Say for example,
you have five replicas

01:22.171 --> 01:24.637
of your web application
instance deployed.

01:25.436 --> 01:28.237
One way to upgrade
these to a newer version,

01:28.441 --> 01:30.278
is to destroy all of these

01:30.446 --> 01:34.183
and then create newer versions
of application instances.

01:35.081 --> 01:38.437
 Meaning, first destroy
the five running instances,

01:38.663 --> 01:40.820
and then deploy five new instances

01:40.992 --> 01:42.664
of the new application version.

01:43.155 --> 01:45.430
The problem with this,
as you can imagine,

01:45.597 --> 01:48.971
is that during the period
after the older versions

01:49.139 --> 01:52.147
are down and
before any newer version is up,

01:52.591 --> 01:56.121
the application is down
and inaccessible to users.

01:56.965 --> 02:00.320
This strategy is known
as the Recreate strategy

02:00.609 --> 02:04.109
and thankfully, this is not
the default deployment strategy.

02:04.925 --> 02:09.244
The second strategy is where we
do not destroy all of them at once.

02:09.682 --> 02:12.776
Instead, we take down
the older version and bring up

02:12.964 --> 02:14.966
a newer version one by one.

02:15.646 --> 02:18.143
This way,
the application never goes down

02:18.311 --> 02:20.164
and the upgrade is seamless.

02:20.923 --> 02:23.697
Remember,
if you do not specify a strategy

02:23.865 --> 02:25.377
while creating the deployment,

02:25.545 --> 02:27.936
it will assume it
to be Rolling Update.

02:28.170 --> 02:29.240
In other words,

02:29.490 --> 02:33.430
Rolling Update
is the default deployment strategy.

02:35.345 --> 02:37.294
We talked about upgrades.

02:37.654 --> 02:40.523
How exactly do you update
your deployment?

02:41.164 --> 02:43.766
When I say update,
it could be different things,

02:43.933 --> 02:46.162
such as updating
your application version

02:46.330 --> 02:48.855
by updating the version
of Docker containers used,

02:49.192 --> 02:50.551
updating their labels,

02:50.719 --> 02:53.121
or updating the number of replicas,
et cetera.

02:53.735 --> 02:56.629
Since we already have
a deployment definition file,

02:56.848 --> 02:59.125
it is easy for us
to modify this file.

02:59.609 --> 03:01.802
Once we make the necessary changes,

03:02.109 --> 03:05.751
we run the 'kubectl apply'
command to apply the changes.

03:07.399 --> 03:08.955
A new rollout is triggered,

03:09.122 --> 03:12.228
and a new revision
of the deployment is created.

03:13.041 --> 03:15.432
But there is another
way to do the same thing.

03:15.785 --> 03:18.765
You could use
the 'kubectl set image' command,

03:18.933 --> 03:21.231
to update the image
of your application.

03:21.775 --> 03:25.433
Remember, doing it this way
will result in the deployment

03:25.608 --> 03:28.880
definition file having
a different configuration,

03:29.216 --> 03:30.896
so you must be careful

03:31.110 --> 03:35.270
when using the same definition file
to make changes in the future.

03:37.391 --> 03:41.651
The difference between the Recreate
and RollingUpdate strategies can also

03:41.827 --> 03:44.835
be seen when you view
the deployments in detail.

03:45.230 --> 03:48.777
Run the 'kubectl describe deployment'
command to see

03:48.952 --> 03:51.644
the detailed information
regarding the deployments.

03:52.255 --> 03:55.381
You will notice
when the Recreate strategy was used,

03:55.614 --> 03:57.406
the events indicate that

03:57.599 --> 04:01.439
the old replica set was scaled down
to zero first,

04:01.659 --> 04:04.854
and then the new replica set scaled
up to five.

04:05.487 --> 04:08.591
However, when the RollingUpdate
strategy was used,

04:08.787 --> 04:12.169
the old replica set was
scaled down one at a time,

04:12.490 --> 04:16.833
simultaneously scaling up
the new replica set one at a time.

04:18.011 --> 04:22.171
Let's look at how a deployment
performs an upgrade under the hood.

04:22.887 --> 04:24.785
When a new deployment is created,

04:24.953 --> 04:27.356
say to deploy five replicas,

04:27.630 --> 04:31.082
it first creates
a Replica Set automatically,

04:31.371 --> 04:34.179
which in turn creates the number
of pods required

04:34.347 --> 04:35.960
to meet the number of replicas.

04:36.655 --> 04:38.692
When you upgrade your application,

04:38.859 --> 04:40.693
as we saw in the previous slide,

04:41.076 --> 04:45.185
the Kubernetes deployment object
creates a new Replica Set

04:45.357 --> 04:48.860
under the hood and starts deploying
the containers there,

04:49.449 --> 04:51.316
at the same time taking down

04:51.485 --> 04:55.837
the pods in the old Replica Set,
following a rolling update strategy.

04:56.556 --> 05:00.167
This can be seen when you try to list
the Replica Sets using

05:00.335 --> 05:02.976
the 'kubectl get replicasets'
command.

05:03.326 --> 05:05.508
Here, we see the old Replica Set

05:05.698 --> 05:08.236
with zero pods,
and the new Replica Set

05:08.526 --> 05:09.726
with five pods.

05:10.744 --> 05:13.480
Say, for instance,
once you upgrade your application,

05:13.653 --> 05:15.684
you realize
something isn't very right.

05:15.926 --> 05:18.555
Something's wrong
with the new version of 'build'

05:18.868 --> 05:20.271
you used to upgrade,

05:20.616 --> 05:22.833
so you would like to
roll back your update.

05:23.344 --> 05:27.696
Kubernetes deployments allow you
to roll back to a previous revision.

05:28.254 --> 05:32.606
To undo a change, run the 'kubectl
rollout undo' command,

05:32.805 --> 05:34.935
followed by the name
of the deployment.

05:35.537 --> 05:39.555
The deployment will then destroy
the pods in the new Replica Set,

05:39.781 --> 05:42.944
and bring the older ones up
in the old Replica Set,

05:43.163 --> 05:46.734
and your application is back
to its older format.

05:47.201 --> 05:48.734
When you compare the output

05:48.902 --> 05:51.603
of the 'kubectl get replicasets'
command,

05:51.882 --> 05:53.860
before and after the rollback,

05:54.212 --> 05:56.446
you will be able to
notice this difference.

05:56.842 --> 05:58.065
Before the rollback,

05:58.505 --> 06:01.628
the first Replica Set had zero pods,

06:02.058 --> 06:04.586
and new Replica Set had five pods,

06:04.938 --> 06:08.406
and this is reversed
after the rollback is finished.

06:08.727 --> 06:10.621
To summarize the commands real quick,

06:10.789 --> 06:14.410
use the 'kubectl create' command
to create the deployment,

06:14.797 --> 06:16.193
'get deployments' command

06:16.482 --> 06:18.199
to list the deployments,

06:18.675 --> 06:22.799
'apply' and 'set image' commands
to update the deployments,

06:23.259 --> 06:27.803
and 'rollout status' command to see
the status of rollouts,

06:28.239 --> 06:33.184
and 'rollout undo' command
to roll back a deployment operation.