In this video,
we're going to go through
the lab on init containers.
First, let's identify the pod that has
an initContainer configured.
Let's look at the pods that are available.
We see that there are three pods,
red, green, and blue.
We need to identify the one
that has an init container available.
From the looks of it from here,
it looks like the green is the one
that has two containers,
but let's look at all of the pods
in more detail.
Let's do a kubectl describe pod.
If you don't specify any pod name,
it's going to list out
the description of all the pods.
If you look at red to begin with,
it has containers, it has a red container,
and if you look at green,
it has two containers.
This is a green container one
and green container two,
but none of these are init containers.
Init containers will be in a separate section
called initContainers,
but these are not init containers.
If you look at blue,
here we have an init container section
and we have a container section.
It is blue that has
an initContainer configured.
If you look at the output
of the get pods command,
remember that it does not show up
the detail of the init container here.
This does not account for the init container,
it only accounts for the actual
containers for that pod.
The answer to this is blue.
What is the image used by the initContainer
on the blue pod?
Let us do describe
and let's see the init container,
it has a container probably in its service,
and the image is BusyBox.
BusyBox is the answer.
What is the state of the initContainer
on pod blue?
If you look at the state,
it says terminated.
Terminated is the state.
Why is an initContainer terminated
and what is the reason?
If you look at the line below,
it says the reason it's completed.
If you look at this,
the way that the init container is set up,
it has an image called BusyBox.
It has a command,
and it's just a command that runs
a sleep in an inner shell.
It just runs sleep for 5 seconds.
Whenever this pod is created,
when this pod was created,
this init container kicks in,
it just sleeps for 5 seconds,
and it just terminates that container,
and then the actual containers are spun up.
It's a simple setup for this,
and that's the reason it says this
sleep command completed successfully.
The exit code is 0,
and that's why the reason is completed.
The process did not crash,
the process cannot start,
now the process completed successfully.
That's why it has exit code 0 here.
Now, we just created a new app named Purple.
Let's look at this.
How many initContainers does it have?
Let's look at this pod in a bit more detail.
Here you see that you have
the init container section.
You have one container here
and you have another one here.
There are two, it's 1 and warm-up-2.
That's two, two is the answer
to the question.
Now, what is the state of the pod?
If you look at the state of the pod here,
under get pod under the output
of get pods init 02.
Now over here, under status,
you can see that it's in a pending state.
The state is pending.
How long after the creation of the pod
will the application come up
and be available to users?
Let's take a look at how this pod is set up.
This pod has a purple container,
which is the app right here,
but it has two init containers.
You have the warm-up 1
and warm-up 2 init containers.
The first one has a command
set to sleep for 600 seconds,
and the second init container
has a command set to sleep for 1,200 seconds.
This is going to run first
and then this is going to run after.
You can have multiple init containers
chained like this if required.
This is going to be 10 minutes
and this is 20 minutes.
In total, before this actually comes up,
the init containers are going to just sleep
for 30 minutes.
Only after 30 minutes will this come up.
It's a silly use case,
but it's just a very simple example
to help you understand
how the init containers work.
That's 30 minutes.
Now this could be anything in real life.
This could be things that prepare a database
or prepare some startup scripts,
stuff like that.
That has to be run before the actual
application comes up.
The next question is to update
the pod red, to use an initContainer.
There is a pod red,
it has one container
and it's in a running state
and we need to update it to use
an initContainer that uses
the busybox image
and sleeps for 20 seconds.
Let's do an edit pod red,
and we have the container section here
so we're going to add
a section called initContainers.
Then here we have the image.
The image is busybox
and then we have the name
so this could be any name,
we just say busybox
and as a command.
The command is to sleep for 20 seconds.
That's it let's save that.
Of course it didn't allow us to save,
so we're just going to quit
and we're going to do
a kubectl replace force and this,
and let's just wait for the pod
to terminate and recreate.
That's done.
Let's check.
Let's go next.
Now a new application orange is deployed.
There is something wrong with it.
Identify and fix the issue.
Once fixed wait for the application
to run before checking the solution.
Let's check the application called pod
and it has one container and in it,
CrashLoopBackOff.
Let's take a closer look at why it's failing.
If you look at this pod,
we see that it has initContainers.
There's one initContainer
called init-myservice.
There's the container called
orange container
and it's just a simple app.
Here, if you look at this,
it says back-off restarting failed container.
One of the containers seems
to be failing and restarting.
If you look at it here,
it says init CrashLoopBackOff indicates
that it is an initContainer that's failing
and that's what is being restarted.
One of the things that we could look at
when that happens is the logs.
You could look at the logs of a pod
using the kubectl logs command
and we're going to specify orange
as the pod,
but just running logs is just always
going to fetch logs
from the orange container,
but the orange container
in the orange pod is just waiting to start
because it's actually
in an initializing state.
Let's look at the logs of the container,
which is the image container.
For that, you specify dash C
and then give the container name,
which is init-myservice.
Here you see that it says sleep not found.
It seems to be a typo in the sleep command.
If you look at how that init container
is configured,
you see that there's a command section
and you have sleep command,
but it has a typo in it,
and that's basically the reason it's failing
and you see that the state is terminated,
but this time the reason is error
as opposed to completed as it is before.
Then the exit code is 127.
It just keeps restarting until it's fixed.
Let's go ahead and fix that.
Let's do a kubectl edit for orange
and go to init containers.
We're going to fix this just fix the typo
and we'll save that and surprise, surprise,
save that.
We're going to just do a kubectl replace
force dash F
put this file.
Okay, so that's replaced.
Let's check the status now.
We see that the init container has a command,
which is now correct
and it's already terminated
and it's completed.
Exit code is now 0.
Check the status of the pod
and it's now in a running state.
Let's check it now.
That's done.
Well, that's the end of this lab
and I'll see you in the next one.