WEBVTT

00:01.728 --> 00:02.627
In this video,

00:02.640 --> 00:04.000
we're going to go through

00:04.050 --> 00:05.670
the lab on init containers.

00:06.366 --> 00:08.392
First, let's identify the pod that has

00:08.392 --> 00:09.813
an initContainer configured.

00:09.813 --> 00:13.083
Let's look at the pods that are available.

00:13.350 --> 00:15.069
We see that there are three pods,

00:15.129 --> 00:16.353
red, green, and blue.

00:17.010 --> 00:18.664
We need to identify the one

00:18.664 --> 00:22.261
that has an init container available.

00:23.573 --> 00:25.733
From the looks of it from here,

00:25.733 --> 00:28.438
it looks like the green is the one

00:28.438 --> 00:29.539
that has two containers,

00:29.663 --> 00:32.092
but let's look at all of the pods

00:32.155 --> 00:32.734
in more detail.

00:32.734 --> 00:36.128
Let's do a kubectl describe pod.

00:37.202 --> 00:40.991
If you don't specify any pod name,

00:40.991 --> 00:42.596
it's going to list out

00:42.596 --> 00:43.980
the description of all the pods.

00:44.353 --> 00:47.524
If you look at red to begin with,

00:47.575 --> 00:51.311
it has containers, it has a red container,

00:51.721 --> 00:53.789
and if you look at green, 

00:53.830 --> 00:55.161
it has two containers.

00:55.161 --> 00:56.412
This is a green container one

00:56.412 --> 00:57.856
and green container two,

00:58.247 --> 01:00.608
but none of these are init containers.

01:00.608 --> 01:03.233
Init containers will be in a separate section

01:03.233 --> 01:04.206
called initContainers,

01:04.247 --> 01:06.307
but these are not init containers.

01:06.610 --> 01:07.847
If you look at blue,

01:07.966 --> 01:11.173
here we have an init container section

01:11.345 --> 01:12.499
and we have a container section.

01:13.103 --> 01:15.076
It is blue that has 

01:15.076 --> 01:18.004
an initContainer configured.

01:18.227 --> 01:19.362
If you look at the output

01:19.362 --> 01:21.173
of the get pods command,

01:21.173 --> 01:23.037
remember that it does not show up

01:23.355 --> 01:25.740
the detail of the init container here.

01:25.740 --> 01:28.070
This does not account for the init container,

01:28.070 --> 01:31.585
it only accounts for the actual

01:31.728 --> 01:33.396
containers for that pod.

01:35.510 --> 01:37.253
The answer to this is blue.

01:41.995 --> 01:44.623
What is the image used by the initContainer

01:44.623 --> 01:46.014
on the blue pod?

01:47.054 --> 01:51.801
Let us do describe

01:51.801 --> 01:54.046
and let's see the init container,

01:54.046 --> 01:57.760
it has a container probably in its service,

01:58.240 --> 02:00.339
and the image is BusyBox.

02:00.780 --> 02:02.829
BusyBox is the answer.

02:04.613 --> 02:06.950
What is the state of the initContainer

02:06.950 --> 02:08.412
on pod blue?

02:08.940 --> 02:10.033
If you look at the state,

02:10.033 --> 02:11.129
it says terminated.

02:11.129 --> 02:13.129
Terminated is the state.

02:15.898 --> 02:17.701
Why is an initContainer terminated

02:17.701 --> 02:18.783
and what is the reason?

02:19.350 --> 02:20.877
If you look at the line below,

02:20.877 --> 02:22.424
it says the reason it's completed.

02:22.613 --> 02:23.498
If you look at this,

02:23.549 --> 02:25.224
the way that the init container is set up,

02:25.224 --> 02:26.700
it has an image called BusyBox.

02:26.809 --> 02:28.002
It has a command,

02:28.513 --> 02:30.014
and it's just a command that runs

02:30.014 --> 02:31.658
a sleep in an inner shell.

02:31.658 --> 02:34.504
It just runs sleep for 5 seconds.

02:34.918 --> 02:38.104
Whenever this pod is created,

02:38.157 --> 02:39.321
when this pod was created,

02:39.803 --> 02:41.248
this init container kicks in,

02:41.248 --> 02:42.707
it just sleeps for 5 seconds,

02:42.707 --> 02:44.591
and it just terminates that container,

02:44.729 --> 02:46.654
and then the actual containers are spun up.

02:47.006 --> 02:49.202
It's a simple setup for this,

02:49.304 --> 02:51.580
and that's the reason it says this

02:51.580 --> 02:53.376
sleep command completed successfully.

02:53.653 --> 02:55.275
The exit code is 0,

02:55.369 --> 02:57.614
and that's why the reason is completed.

02:58.060 --> 02:59.539
The process did not crash,

02:59.539 --> 03:00.989
the process cannot start,

03:00.989 --> 03:02.858
now the process completed successfully.

03:03.624 --> 03:07.512
That's why it has exit code 0 here.

03:08.547 --> 03:11.808
Now, we just created a new app named Purple.

03:13.360 --> 03:17.650
Let's look at this.

03:20.831 --> 03:23.316
How many initContainers does it have?

03:23.767 --> 03:28.962
Let's look at this pod in a bit more detail.

03:31.236 --> 03:33.289
Here you see that you have

03:33.289 --> 03:34.547
the init container section.

03:34.906 --> 03:36.458
You have one container here

03:36.458 --> 03:37.643
and you have another one here.

03:37.728 --> 03:40.346
There are two, it's 1 and warm-up-2.

03:42.627 --> 03:44.361
That's two, two is the answer

03:44.361 --> 03:45.287
to the question.

03:47.624 --> 03:49.730
Now, what is the state of the pod?

03:50.327 --> 03:53.461
If you look at the state of the pod here,

03:53.633 --> 03:55.401
under get pod under the output

03:55.401 --> 03:58.254
of get pods init 02.

03:58.664 --> 04:00.271
Now over here, under status,

04:00.271 --> 04:01.740
you can see that it's in a pending state.

04:02.504 --> 04:03.905
The state is pending.

04:08.041 --> 04:09.769
How long after the creation of the pod

04:09.769 --> 04:10.904
will the application come up

04:10.904 --> 04:12.334
and be available to users?

04:12.480 --> 04:15.270
Let's take a look at how this pod is set up.

04:15.561 --> 04:17.212
This pod has a purple container,

04:17.425 --> 04:19.175
which is the app right here,

04:19.551 --> 04:21.471
but it has two init containers.

04:21.534 --> 04:22.671
You have the warm-up 1

04:22.671 --> 04:24.499
and warm-up 2 init containers.

04:24.807 --> 04:26.753
The first one has a command

04:27.144 --> 04:29.280
set to sleep for 600 seconds,

04:29.658 --> 04:31.389
and the second init container

04:31.389 --> 04:35.345
has a command set to sleep for 1,200 seconds.

04:35.987 --> 04:37.052
This is going to run first

04:37.185 --> 04:39.818
and then this is going to run after.

04:39.849 --> 04:41.534
You can have multiple init containers

04:41.750 --> 04:43.680
chained like this if required.

04:44.688 --> 04:48.489
This is going to be 10 minutes

04:48.972 --> 04:50.150
and this is 20 minutes.

04:50.797 --> 04:53.486
In total, before this actually comes up,

04:54.841 --> 04:57.270
the init containers are going to just sleep

04:57.294 --> 04:59.197
for 30 minutes.

04:59.277 --> 05:00.943
Only after 30 minutes will this come up.

05:01.607 --> 05:03.001
It's a silly use case,

05:03.015 --> 05:05.309
but it's just a very simple example

05:05.374 --> 05:06.441
to help you understand

05:06.923 --> 05:08.635
how the init containers work.

05:08.724 --> 05:09.983
That's 30 minutes.

05:10.804 --> 05:14.332
Now this could be anything in real life.

05:14.783 --> 05:18.705
This could be things that prepare a database

05:19.139 --> 05:21.646
or prepare some startup scripts,

05:21.806 --> 05:22.843
stuff like that.

05:24.162 --> 05:26.654
That has to be run before the actual

05:26.901 --> 05:28.084
application comes up.

05:28.974 --> 05:33.146
The next question is to update

05:33.146 --> 05:35.294
the pod red, to use an initContainer.

05:35.922 --> 05:38.295
There is a pod red,

05:39.381 --> 05:40.596
it has one container

05:40.596 --> 05:41.798
and it's in a running state

05:42.104 --> 05:43.786
and we need to update it to use

05:43.840 --> 05:44.981
an initContainer that uses

05:44.981 --> 05:46.041
the busybox image

05:46.290 --> 05:47.796
and sleeps for 20 seconds.

05:47.866 --> 05:51.243
Let's do an edit pod red,

05:52.838 --> 05:54.993
and we have the container section here

05:55.345 --> 05:56.368
so we're going to add

05:56.623 --> 06:00.610
a section called initContainers.

06:02.174 --> 06:07.035
Then here we have the image.

06:07.381 --> 06:09.665
The image is busybox

06:11.270 --> 06:16.598
and then we have the name

06:16.598 --> 06:17.990
so this could be any name,

06:19.127 --> 06:20.567
we just say busybox 

06:23.410 --> 06:25.495
and as a command.

06:26.880 --> 06:36.036
The command is to sleep for 20 seconds.

06:39.597 --> 06:42.448
That's it let's save that.

06:44.477 --> 06:46.807
Of course it didn't allow us to save,

06:46.807 --> 06:48.070
so we're just going to quit

06:48.237 --> 06:49.183
and we're going to do

06:49.246 --> 06:56.496
a kubectl replace force and this,

06:58.804 --> 07:01.013
and let's just wait for the pod

07:02.421 --> 07:04.676
to terminate and recreate.

07:06.880 --> 07:08.152
That's done.

07:08.278 --> 07:09.127
Let's check.

07:11.107 --> 07:11.934
Let's go next.

07:14.981 --> 07:16.938
Now a new application orange is deployed.

07:16.938 --> 07:18.155
There is something wrong with it.

07:18.196 --> 07:19.711
Identify and fix the issue.

07:20.063 --> 07:21.573
Once fixed wait for the application

07:21.573 --> 07:23.362
to run before checking the solution.

07:23.726 --> 07:27.883
Let's check the application called pod

07:29.755 --> 07:33.340
and it has one container and in it,

07:33.481 --> 07:34.572
CrashLoopBackOff.

07:34.836 --> 07:38.601
Let's take a closer look at why it's failing.

07:42.465 --> 07:45.512
If you look at this pod,

07:46.409 --> 07:47.978
we see that it has initContainers.

07:48.458 --> 07:49.553
There's one initContainer 

07:49.553 --> 07:50.819
called init-myservice.

07:51.073 --> 07:53.803
There's the container called

07:53.803 --> 07:54.787
orange container

07:55.120 --> 07:57.299
and it's just a simple app.

07:59.129 --> 08:00.281
Here, if you look at this,

08:00.761 --> 08:04.385
it says back-off restarting failed container.

08:05.699 --> 08:08.007
One of the containers seems

08:08.021 --> 08:10.254
to be failing and restarting.

08:10.438 --> 08:11.430
If you look at it here,

08:11.430 --> 08:13.646
it says init CrashLoopBackOff indicates

08:13.667 --> 08:16.244
that it is an initContainer that's failing

08:16.244 --> 08:18.421
and that's what is being restarted.

08:18.644 --> 08:20.181
One of the things that we could look at

08:20.181 --> 08:22.135
when that happens is the logs.

08:22.984 --> 08:26.460
You could look at the logs of a pod

08:26.460 --> 08:29.100
using the kubectl logs command

08:29.367 --> 08:31.311
and we're going to specify orange

08:31.311 --> 08:32.053
as the pod,

08:32.433 --> 08:36.048
but just running logs is just always

08:36.048 --> 08:37.047
going to fetch logs

08:37.047 --> 08:37.978
from the orange container,

08:37.978 --> 08:39.146
but the orange container

08:39.560 --> 08:44.572
in the orange pod is just waiting to start

08:44.601 --> 08:46.038
because it's actually

08:46.189 --> 08:47.689
in an initializing state.

08:49.250 --> 08:56.715
Let's look at the logs of the container,

08:56.715 --> 08:57.978
which is the image container.

08:58.201 --> 09:00.867
For that, you specify dash C

09:01.369 --> 09:02.904
and then give the container name,

09:02.904 --> 09:06.455
which is init-myservice.

09:07.927 --> 09:11.910
Here you see that it says sleep not found.

09:13.107 --> 09:15.478
It seems to be a typo in the sleep command.

09:16.247 --> 09:19.020
If you look at how that init container

09:19.020 --> 09:19.854
is configured,

09:20.167 --> 09:21.730
you see that there's a command section

09:21.730 --> 09:23.406
and you have sleep command,

09:23.406 --> 09:24.863
but it has a typo in it,

09:25.095 --> 09:26.991
and that's basically the reason it's failing

09:26.991 --> 09:28.630
and you see that the state is terminated,

09:28.865 --> 09:30.511
but this time the reason is error

09:30.620 --> 09:33.301
as opposed to completed as it is before.

09:33.524 --> 09:36.281
Then the exit code is 127.

09:36.734 --> 09:41.832
It just keeps restarting until it's fixed.

09:42.329 --> 09:43.978
Let's go ahead and fix that.

09:44.242 --> 09:50.310
Let's do a kubectl edit for orange

09:52.264 --> 09:54.829
and go to init containers.

09:56.395 --> 09:59.837
We're going to fix this just fix the typo

10:00.378 --> 10:04.637
and we'll save that and surprise, surprise,

10:05.507 --> 10:06.608
save that.

10:06.775 --> 10:10.261
We're going to just do a kubectl replace

10:10.593 --> 10:13.064
force dash F 

10:17.733 --> 10:18.669
put this file.

10:19.437 --> 10:20.753
Okay, so that's replaced.

10:21.272 --> 10:24.310
Let's check the status now.

10:28.821 --> 10:32.722
We see that the init container has a command,

10:33.103 --> 10:34.266
which is now correct

10:34.819 --> 10:36.014
and it's already terminated

10:36.014 --> 10:37.973
and it's completed.

10:38.673 --> 10:40.610
Exit code is now 0.

10:42.254 --> 10:44.792
Check the status of the pod

10:45.939 --> 10:47.452
and it's now in a running state.

10:48.901 --> 10:50.630
Let's check it now.

10:50.664 --> 10:51.779
That's done.

10:52.812 --> 10:54.038
Well, that's the end of this lab

10:54.162 --> 10:56.012
 and I'll see you in the next one.