Okay, in this video, we'll go over the lab on multi-container pods.
The first question is to identify
the number of containers created in the red pod.
Let's first see the pod.
There seems to be multiple pods, and there is indeed a red pod.
They are in a container-creating state.
To identify the number of containers,
we've learned that we could just look at this.
When you look at the ready column for a pod,
this is the total number of pods and these are the ones that are ready.
From here, we can figure out that there are three.
The other way to find that out is to look at it with the describe command.
We see that under containers, you have one, two, and three.
There are three containers for this pod.
The next question is to identify the name
of the containers running in the blue pod.
Let's look into the blue pod,
and we see that under containers, there are two and it's teal and navy.
Okay, the next task is to create a multi-container pod
with two containers, and use the spec given below
if the pod goes into a crashloopbackoff, then add sleep 1000.
That's because this one is busybox.
We have to create a pod with the name yellow.
The first container's name should be lemon,
and then using the busybox image,
the second container's name should be called
using the Redis image.
Let's create a pod, so kubectl run
and then the name of the pod,
it is yellow and image.
First image is busybox, then we have to use the dry-run
because we don't want to create this yet,
we need to add in the second thing as well.
Let's output it into a yaml form.
We have the pod definition file.
Let's move that to yelow.yaml.
Okay, and then, to edit the file, add the additional container in.
The first container
has the image busybox.
The name though, the name for the first container has to be lemon.
You have to go in and modify that.
By default, it automatically takes the name of the pod
as the name of the first container.
Let's change that to lemon
and
let's add a new container to it.
The next one's name is called-- And image is redis.
Okay, let's save that.
We also said, although this is optional
to add the command sleep 1000 for the lemon.
That's the busybox container.
Let's add command.
We've learned that we got to give it an array, that's sleep.
Always when you type a command, the first element has to be
just the command below the option 1000
or anything else needs to go as an argument
and as an extra item in the array.
Let's create that pod.
Let's look at the pod
and it's created, it has two containers.
The first one lemon
as busybox with the command and gold has redis.
Next we're going to look at a simple application setup.
Here we have deployed an application
and a logging stack in the elastic stack namespace.
There's a namespace called elastic stack
and there is an application and multiple pods.
Before proceeding with the next set of questions,
please wait for all the pods in the elastic namespace to be ready.
Let's first explore that namespace.
Let's do a ctl, get pods,
elastic stack and we see that there is the app pod,
and then you have the elastic search pod
and then you have the kibana pod.
All of them are now in a running state.
Let's go ahead, and once the body is in a ready state,
inspect the Kibana UI using the link above your terminal.
Now, if you're not familiar with this stack,
so basically elastic search is where the data is collected
and this could be in metrics, logs.
These are logs that are collected from applications, and then it's--
The Kibana is the dashboard that users
or administrators use if you, and in a filter the logs.
You can view that here. Clicking on Kibana
opens up the UI to the Kibana dashboard.
Let's wait for it to load.
This is the dashboard.
The goal here is to transfer
the logs of this application to elastic search.
Then elastic search is that log so then viewed on the Kibana dashboard.
That's the ultimate goal.
This is ready.
Now, inspect the app pod and identify the number of containers in it.
The app pod
has containers and there's a single container.
No, that was not the app pod.
These are all the pods because we didn't specify a pod name.
Let's give the name of the pod.
We have containers and app
and that's there's just one container in it.
Let's select that.
The container basically has this image called kodekloud event simulator.
The event simulator is just a simple program
that just throws out some events for logs.
The application outputs logs to the file /log/app.log.
/log/app.log within this pod.
Now view the logs and try to identify the user having issues with login,
inspect the log file inside the pod.
One way to do that is, let's do a kubectl logs, app, namespace elastic,
and we see that these are the logs of the app.
The goal here is to identify
the user having issues with login.
If you look through this, we'll see that it's User 5
that was having issues with login.
The answer is User 5,
but let me also show that these are the logs
that we are viewing from here,
but these logs are also stored within the pod.
If you do a kubectl exec into it, into the pod,
we're going to do elastic-stack exec.
Take IT app, and then we just want to execute the command
to view the log at app.log
and you'll see the same contents, whatever we just saw.
This app is continuously throwing logs,
information through the logs but the point to note
is that it's storing these logs
at /log/app.log location
within that particular container.
The answer, as we said is User 5 so let's proceed.
Now, edit the pod to add a sidecar container
to send logs to elastic search.
If you look at this image here,
we know that on this pod,
the logs are stored under the location/log.
Now, what we want to do is the way that you connect a pod
or you configure a pod to send logs to a central location.
Let's say there are hundreds of similar pods,
and you want them to send logs to a central location,
which is elastic search, then you add a sidecar container to it.
That's what we're going to do here.
We know that the app pod already has a container called app,
and that's the existing container which has this particular image.
That's actually the application.
Then what we want to do is add an additional container as a sidecar,
so the name has to be sidecar.
The image has to be the filebeat image.
This is basically a custom image
we created off of the default filebeat [?]
where we've configured it to automatically send
the data to elastic search.
This is just something that's created just for this lab,
purpose of this lab to demonstrate this.
Then you have-- You must configure the volumeMount.
Basically these two,
sorry, these two containers.
The app container and the filebeat container
are going to share this particular path.
The path to the log, where the logs are stored.
Let's do that.
We have to edit the existing pod.
Kubectl edit pod app
in the elastic namespace
and the goal is to add an additional container.
It's going to add a container here
and the image for that container
is filebeat-configured.
Name is sidecar and in volumeMounts.
The volumeMount path is--
We can just copy this from here.
The mountPath is /var/log/event-simulator
and then the volumeMount name is log volume.
This is the sidecar filebeat container
and what's happening here is the pod now is going to have two containers.
This is our actual application,
and it stores logs in this particular path,
or in this particular volume, the volume named log-volume.
That log-volume is mounted at the path/log
within this application.
This could be anything but the important thing
is this log volume that's specified here.
We're adding an additional container which--
All it does is going to take--
It's going to read the logs
and pass it through to the elastic search,
central elastic search kind of database.
What you have is you also have the volumeMount here,
and it's the same name.
These are going to be the same volume.
Think of a volume being here.
That's going to be mounted on both of the containers.
Then this, the path to this is at /var/log/event-simulator.
Basically, the app.log is all going to be stored
inside this on this container,
as well as inside this on this container
and this filebeat is configured to read the logs
from this particular directory and send it to elastic search.
From the point of this exercise,
all we need to do is add this additional sidecar container.
Let me save that,
but it's not going to allow us to see that
because pod updates may not add or remove containers but that's fine.
We're going to quit from this
and now we have our file with the edits,
and we'll just do a kubectl replace, force.
We'll just wait for that to finish.
Okay, let's check our work.
Okay, that's successful.
Let's go next.
Now, inspect the Kibana UI and you should now see the logs
appearing in the discover section.
Let's go to the Kibana UI.
We go here.
What this says is that you have to create an index pattern
and Kibana uses index patterns to retrieve data from elastic search.
You have to give something like a pattern that it can look for.
Well, basically, we're just going to get everything,
so we'll just say star
and Time Filter field name.
I don't want to use Time Filter, and let's just create the index pattern.
Okay, now let's go to discover
and we should now be able to see the logs coming through.
These are the logs that are coming through.
Here you have the user-related details.
User 2 is viewing page 1.
You have User 3 is logged in,
User 4 is viewing page 1.
User 7's order's failed.
These are the details that we saw earlier
when we just reviewed the logs directly.
Now we have the logs coming in through to this Kibana dashboard,
and we can have as many--
We can do the same configuration to as many pods
or deployments or any application that we've deployed
on kubernetes to be configured too.
Okay, that's about it for now
and I'll see you in the next one.