WEBVTT

00:00.440 --> 00:07.290
In this lab, we're going to look
at rolling updates and rollbacks.

00:07.370 --> 00:08.290
Rolling updates mainly.

00:08.370 --> 00:09.889
I'm going forward.

00:09.969 --> 00:13.469
I'm going to try
and use the alias K for kubectl.

00:13.549 --> 00:20.410
I've already set alias K for kubectl,
so I'm going to try

00:20.490 --> 00:22.910
and use that going forward.

00:22.990 --> 00:25.650
We have deployed a simple web application.

00:25.730 --> 00:27.890
Inspect the PODs and services.

00:27.970 --> 00:29.093
Let's do

00:31.900 --> 00:32.973
get POD,

00:33.053 --> 00:37.200
so there seems to be a set of frontend PODs.

00:37.280 --> 00:40.279
Most likely there is a deployment.

00:40.359 --> 00:45.520
There's a frontend deployment,
which deploys for PODs.

00:45.600 --> 00:48.400
Then wait for the application
to fully deploy and view the application

00:48.480 --> 00:50.279
using the link called Webapp Portal.

00:50.359 --> 00:54.200
There is a link here you can click
to view the application

00:54.280 --> 00:57.869
and opens it up in a new window.

00:59.320 --> 01:02.647
It just says, "Hello frontend.”

01:05.910 --> 01:09.830
A moment.

01:09.910 --> 01:12.420
Let's look at the first or second question.

01:12.500 --> 01:15.450
What is the current color
of the web application?

01:15.530 --> 01:18.880
If you look here, it is blue in color.

01:18.960 --> 01:22.040
It's blue.

01:22.120 --> 01:26.520
Now, run the script named curl-test
to send multiple requests

01:26.600 --> 01:29.990
to the web application.

01:30.070 --> 01:34.810
We have curl-test here, so I'll run that.

01:34.890 --> 01:37.900
As you can see,
all it does is it paints the application

01:37.980 --> 01:40.220
and returns to color.

01:40.300 --> 01:43.150
The color is blue,
and it just keeps running that

01:43.230 --> 01:45.760
for a few seconds.

01:45.840 --> 01:46.870
That's done.

01:46.950 --> 01:52.490
We're going to use this script
to run tests to simulate accessing

01:52.570 --> 01:56.650
the web application
by either multiple users

01:56.730 --> 02:00.840
or sending multiple requests
to the web application.

02:00.920 --> 02:07.630
We'll use that to basically just do
a small round of tests on the application.

02:07.710 --> 02:09.620
Inspect the deployment
and identify the number

02:09.700 --> 02:11.030
of PODs deployed by it.

02:11.110 --> 02:17.650
We just looked at that
and we saw that it creates four PODs.

02:17.730 --> 02:21.070
It's four, that's the answer here.

02:21.150 --> 02:27.170
Now, what container image
is used to deploy the application?

02:27.250 --> 02:31.413
Let's look at the deployment

02:31.880 --> 02:33.340
in more detail

02:39.530 --> 02:41.110
and frontend.

02:41.190 --> 02:42.360
Here we have the POD template.

02:42.440 --> 02:44.470
We have containers, image.

02:44.550 --> 02:49.320
The image is kodekloud/webapp-color:V1.

02:49.400 --> 02:50.560
It's this one right here.

02:50.640 --> 02:54.340
That's the image we've used
to deploy the application.

02:54.420 --> 02:57.473
Inspect the deployment
and identify the current strategy.

02:57.753 --> 03:04.300
If you look at this,
we have the strategy type given here,

03:04.380 --> 03:07.610
and that is rolling update.

03:07.690 --> 03:09.882
The rolling update is the current strategy.

03:12.060 --> 03:15.290
If you were to upgrade the application now

03:15.370 --> 03:21.590
one POD at
a time

03:21.670 --> 03:24.350
and brings up the new POD.

03:24.430 --> 03:28.990
It does not take all of it down
and bring the new ones up.

03:29.070 --> 03:31.540
Answer here is all PODs
are taken down before upgrading.

03:31.620 --> 03:33.290
No, that's not the correct one.

03:33.370 --> 03:40.180
PODs are upgraded a few at a time,
so that's the correct one.

03:40.260 --> 03:41.180
Let us try that.

03:41.260 --> 03:47.100
Upgrade the application
by setting the image on the deployment

03:47.180 --> 03:48.130
to kodekloud/webapp-color:v2.

03:48.210 --> 03:50.230
We're going to update the image.

03:50.310 --> 03:54.519
Now, one way to do that
is you could do kubectl edit

03:54.599 --> 03:59.153
and deployment and frontend,

04:02.807 --> 04:05.680
and then go here and change the image.

04:06.080 --> 04:10.790
Another way to do that
is just using the kubectl set command.

04:10.870 --> 04:16.770
You could do a set image,
run the help to find that out.

04:16.850 --> 04:18.980
That's kubectl set image.

04:19.060 --> 04:21.400
You can say deployment, deployment name,

04:21.480 --> 04:24.920
and then the container name, and the image.

04:27.130 --> 04:28.050
Let's try that.

04:28.130 --> 04:32.750
That's kubectl set image or the deployment.

04:32.830 --> 04:38.770
The deployment name is frontend
and the container name,

04:38.850 --> 04:41.580
we need to find out the container name.

04:41.660 --> 04:47.720
Let's do deploy frontend.

04:47.800 --> 04:50.420
The container name is simple-webapp.

04:50.500 --> 04:53.520
Let's do that again.

04:53.600 --> 04:59.493
Kubectl set image, deploy, frontend,

05:01.307 --> 05:02.350
container name

05:02.430 --> 05:05.073
is simple-webapp

05:07.153 --> 05:08.244
equals

05:11.947 --> 05:17.010
test image, and that's updated.

05:17.090 --> 05:18.809
Let's make sure it's updated.

05:18.889 --> 05:24.980
I'm going to describe command again
when we see that the image is set to v2.

05:25.060 --> 05:26.839
Success.

05:26.919 --> 05:31.790
Let's run the curl test again
and see what we're seeing.

05:31.870 --> 05:36.520
We're still seeing blue
but we see green occasionally.

05:36.600 --> 05:39.089
There's a lot of blue
and there's some green.

05:39.169 --> 05:41.710
Green is the new version
that we have deployed

05:41.790 --> 05:46.670
and blue is the older version
and now we have a lot of green.

05:46.750 --> 05:49.130
If you look at this,
there was a lot of blue at first

05:49.210 --> 05:53.500
and then there's some green,
and then there's green and blue

05:53.580 --> 05:55.570
at one point of time.

05:55.650 --> 05:56.920
Then we just have green.

05:57.000 --> 06:00.320
That's how it's updated,
the application deployment.

06:00.400 --> 06:03.630
That's the rolling update.

06:03.710 --> 06:08.890
Up to how many PODs can be down
for upgrade at a time?

06:08.970 --> 06:12.150
Consider the current strategy settings.

06:12.230 --> 06:15.011
If you look at this,
the strategy type is rolling update

06:15.091 --> 06:16.700
which we've already seen.

06:16.780 --> 06:20.839
There's rolling update strategy,
the additional details here.

06:20.919 --> 06:23.020
25% max unavailable.

06:23.100 --> 06:25.313
That means it's going to take down

06:25.393 --> 06:31.947
only 25% of the PODs at a time
before bringing the new ones up.

06:32.027 --> 06:34.820
You have four replicas,

06:34.900 --> 06:38.589
and 25% of that is just one.

06:38.669 --> 06:41.470
Let's select one.

06:41.550 --> 06:46.230
Change the deployment strategy to Recreate.

06:46.310 --> 06:50.720
Delete and re-create the deployment
if necessary.

06:50.800 --> 06:54.890
Let's go ahead and try
and change the deployment strategy.

06:54.970 --> 06:56.473
Let's do a kubectl edit,

06:58.640 --> 07:02.500
deployment, frontend.

07:03.340 --> 07:08.559
We'll just go here
and we'll just change

07:08.639 --> 07:13.967
this strategy type to Recreate.

07:17.980 --> 07:20.199
The Recreate does not require
the rolling update parameter,

07:20.280 --> 07:23.213
so we're just going to get rid of this.

07:31.010 --> 07:35.850
Let's verify.

07:35.930 --> 07:39.950
We see the strategy
is changed to Recreate.

07:43.240 --> 07:46.527
The next one is to upgrade the application
by setting the image

07:46.607 --> 07:48.714
on the deployment to v3.

07:48.794 --> 07:51.059
Currently, we have v2

07:51.139 --> 07:54.020
and we have got to change it to v3.

07:54.100 --> 07:59.850
Let's use the same command,
the kubectl set image deploy command,

07:59.930 --> 08:03.020
and we'll now change this to 3.

08:03.100 --> 08:06.630
Okay, so that's updated.

08:08.227 --> 08:10.880
Next, let's run the curl-test again.

08:10.960 --> 08:14.480
When we run this this time,
unlike the previous time,

08:14.560 --> 08:16.830
we see a lot of failures.

08:16.910 --> 08:18.647
Some of the requests are failing

08:18.727 --> 08:20.807
and this is because it took down

08:24.050 --> 08:29.027
some of the PODs as part of the upgrade

08:29.407 --> 08:31.167
because we're doing a recreate.

08:32.570 --> 08:35.630
Let's just give it some time.

08:35.710 --> 08:38.633
If you look at the application here,

08:39.107 --> 08:42.167
it says, "Bad gateway.”

08:46.770 --> 08:49.690
Now we can see it started to respond.

08:49.770 --> 08:55.210
We have the red color is coming up
and when we refresh this,

08:55.290 --> 09:00.870
you see that we have application v3
and the red color is coming up.

09:00.950 --> 09:03.209
Okay, so that's the end of this lab.