WEBVTT 00:02.090 --> 00:06.850 Okay, in this video, we'll go over the lab on multi-container pods. 00:07.160 --> 00:08.780 The first question is to identify 00:08.860 --> 00:12.690 the number of containers created in the red pod. 00:12.970 --> 00:15.190 Let's first see the pod. 00:15.270 --> 00:19.360 There seems to be multiple pods, and there is indeed a red pod. 00:19.440 --> 00:23.000 They are in a container-creating state. 00:23.410 --> 00:26.470 To identify the number of containers, 00:26.950 --> 00:29.710 we've learned that we could just look at this. 00:29.790 --> 00:33.080 When you look at the ready column for a pod, 00:33.160 --> 00:36.610 this is the total number of pods and these are the ones that are ready. 00:36.690 --> 00:38.510 From here, we can figure out that there are three. 00:38.590 --> 00:45.850 The other way to find that out is to look at it with the describe command. 00:46.500 --> 00:50.490 We see that under containers, you have one, two, and three. 00:50.570 --> 00:53.800 There are three containers for this pod. 00:56.410 --> 00:59.170 The next question is to identify the name 00:59.250 --> 01:01.900 of the containers running in the blue pod. 01:02.280 --> 01:07.440 Let's look into the blue pod, 01:09.060 --> 01:14.450 and we see that under containers, there are two and it's teal and navy. 01:19.570 --> 01:21.920 Okay, the next task is to create a multi-container pod 01:22.000 --> 01:25.230 with two containers, and use the spec given below 01:25.310 --> 01:29.870 if the pod goes into a crashloopbackoff, then add sleep 1000. 01:29.950 --> 01:31.830 That's because this one is busybox. 01:32.180 --> 01:34.470 We have to create a pod with the name yellow. 01:34.850 --> 01:37.910 The first container's name should be lemon, 01:37.990 --> 01:40.310 and then using the busybox image, 01:40.390 --> 01:42.410 the second container's name should be called 01:42.490 --> 01:44.310 using the Redis image. 01:44.390 --> 01:48.750 Let's create a pod, so kubectl run 01:50.530 --> 01:51.790 and then the name of the pod, 01:51.870 --> 01:54.520 it is yellow and image. 01:55.900 --> 02:01.200 First image is busybox, then we have to use the dry-run 02:01.280 --> 02:03.830 because we don't want to create this yet, 02:04.150 --> 02:07.070 we need to add in the second thing as well. 02:07.150 --> 02:10.070 Let's output it into a yaml form. 02:10.150 --> 02:12.210 We have the pod definition file. 02:12.290 --> 02:14.880 Let's move that to yelow.yaml. 02:16.690 --> 02:22.150 Okay, and then, to edit the file, add the additional container in. 02:22.230 --> 02:23.750 The first container 02:26.770 --> 02:28.760 has the image busybox. 02:29.070 --> 02:31.790 The name though, the name for the first container has to be lemon. 02:31.870 --> 02:34.160 You have to go in and modify that. 02:34.240 --> 02:37.230 By default, it automatically takes the name of the pod 02:37.310 --> 02:38.870 as the name of the first container. 02:38.950 --> 02:42.700 Let's change that to lemon 02:42.780 --> 02:44.440 and 02:47.060 --> 02:51.050 let's add a new container to it. 02:51.130 --> 02:57.990 The next one's name is called-- And image is redis. 03:00.470 --> 03:02.420 Okay, let's save that. 03:02.500 --> 03:05.190 We also said, although this is optional 03:05.270 --> 03:09.460 to add the command sleep 1000 for the lemon. 03:09.540 --> 03:13.900 That's the busybox container. 03:13.980 --> 03:15.740 Let's add command. 03:16.790 --> 03:20.640 We've learned that we got to give it an array, that's sleep. 03:21.160 --> 03:26.780 Always when you type a command, the first element has to be 03:26.860 --> 03:30.520 just the command below the option 1000 03:30.600 --> 03:33.460 or anything else needs to go as an argument 03:33.540 --> 03:35.590 and as an extra item in the array. 03:36.370 --> 03:40.030 Let's create that pod. 03:41.440 --> 03:42.930 Let's look at the pod 03:47.020 --> 03:48.940 and it's created, it has two containers. 03:49.020 --> 03:50.340 The first one lemon 03:51.250 --> 03:55.280 as busybox with the command and gold has redis. 04:01.030 --> 04:03.790 Next we're going to look at a simple application setup. 04:04.070 --> 04:06.020 Here we have deployed an application 04:06.100 --> 04:09.290 and a logging stack in the elastic stack namespace. 04:09.370 --> 04:11.160 There's a namespace called elastic stack 04:11.240 --> 04:15.330 and there is an application and multiple pods. 04:15.410 --> 04:16.970 Before proceeding with the next set of questions, 04:17.050 --> 04:19.970 please wait for all the pods in the elastic namespace to be ready. 04:21.650 --> 04:24.010 Let's first explore that namespace. 04:25.120 --> 04:28.010 Let's do a ctl, get pods, 04:30.090 --> 04:33.850 elastic stack and we see that there is the app pod, 04:33.930 --> 04:36.450 and then you have the elastic search pod 04:36.530 --> 04:41.390 and then you have the kibana pod. 04:41.470 --> 04:43.230 All of them are now in a running state. 04:44.010 --> 04:48.430 Let's go ahead, and once the body is in a ready state, 04:48.510 --> 04:51.830 inspect the Kibana UI using the link above your terminal. 04:51.910 --> 04:53.600 Now, if you're not familiar with this stack, 04:53.680 --> 04:58.340 so basically elastic search is where the data is collected 04:58.420 --> 05:01.310 and this could be in metrics, logs. 05:01.390 --> 05:05.210 These are logs that are collected from applications, and then it's-- 05:05.290 --> 05:07.520 The Kibana is the dashboard that users 05:07.600 --> 05:12.820 or administrators use if you, and in a filter the logs. 05:13.840 --> 05:16.160 You can view that here. Clicking on Kibana 05:16.240 --> 05:19.860 opens up the UI to the Kibana dashboard. 05:19.940 --> 05:22.800 Let's wait for it to load. 05:23.110 --> 05:24.870 This is the dashboard. 05:25.580 --> 05:28.540 The goal here is to transfer 05:28.620 --> 05:32.370 the logs of this application to elastic search. 05:32.450 --> 05:38.580 Then elastic search is that log so then viewed on the Kibana dashboard. 05:38.660 --> 05:40.720 That's the ultimate goal. 05:41.460 --> 05:44.090 This is ready. 05:45.070 --> 05:48.390 Now, inspect the app pod and identify the number of containers in it. 05:49.240 --> 05:50.660 The app pod 05:54.980 --> 05:59.670 has containers and there's a single container. 06:01.280 --> 06:04.010 No, that was not the app pod. 06:04.090 --> 06:07.680 These are all the pods because we didn't specify a pod name. 06:08.090 --> 06:10.350 Let's give the name of the pod. 06:11.760 --> 06:13.880 We have containers and app 06:13.960 --> 06:16.690 and that's there's just one container in it. 06:17.000 --> 06:19.290 Let's select that. 06:20.200 --> 06:23.860 The container basically has this image called kodekloud event simulator. 06:23.940 --> 06:27.100 The event simulator is just a simple program 06:27.180 --> 06:30.570 that just throws out some events for logs. 06:31.110 --> 06:36.000 The application outputs logs to the file /log/app.log. 06:36.080 --> 06:40.680 /log/app.log within this pod. 06:41.760 --> 06:48.220 Now view the logs and try to identify the user having issues with login, 06:48.300 --> 06:53.050 inspect the log file inside the pod. 06:53.130 --> 07:02.660 One way to do that is, let's do a kubectl logs, app, namespace elastic, 07:03.040 --> 07:05.970 and we see that these are the logs of the app. 07:06.050 --> 07:13.010 The goal here is to identify 07:13.720 --> 07:16.580 the user having issues with login. 07:17.060 --> 07:20.950 If you look through this, we'll see that it's User 5 07:21.030 --> 07:23.150 that was having issues with login. 07:23.530 --> 07:24.790 The answer is User 5, 07:26.470 --> 07:29.290 but let me also show that these are the logs 07:29.370 --> 07:31.760 that we are viewing from here, 07:31.840 --> 07:33.760 but these logs are also stored within the pod. 07:33.840 --> 07:39.770 If you do a kubectl exec into it, into the pod, 07:39.850 --> 07:43.740 we're going to do elastic-stack exec. 07:44.650 --> 07:50.980 Take IT app, and then we just want to execute the command 07:51.060 --> 07:57.820 to view the log at app.log 07:57.900 --> 08:01.360 and you'll see the same contents, whatever we just saw. 08:01.700 --> 08:05.230 This app is continuously throwing logs, 08:05.310 --> 08:09.630 information through the logs but the point to note 08:09.710 --> 08:11.900 is that it's storing these logs 08:11.980 --> 08:16.600 at /log/app.log location 08:16.680 --> 08:19.740 within that particular container. 08:23.930 --> 08:27.780 The answer, as we said is User 5 so let's proceed. 08:29.330 --> 08:31.690 Now, edit the pod to add a sidecar container 08:31.770 --> 08:34.460 to send logs to elastic search. 08:36.400 --> 08:37.790 If you look at this image here, 08:37.870 --> 08:39.260 we know that on this pod, 08:39.340 --> 08:42.360 the logs are stored under the location/log. 08:42.640 --> 08:46.430 Now, what we want to do is the way that you connect a pod 08:46.510 --> 08:50.270 or you configure a pod to send logs to a central location. 08:50.520 --> 08:52.640 Let's say there are hundreds of similar pods, 08:52.720 --> 08:55.940 and you want them to send logs to a central location, 08:56.020 --> 09:00.920 which is elastic search, then you add a sidecar container to it. 09:02.160 --> 09:03.720 That's what we're going to do here. 09:03.800 --> 09:08.190 We know that the app pod already has a container called app, 09:08.270 --> 09:11.830 and that's the existing container which has this particular image. 09:12.970 --> 09:14.330 That's actually the application. 09:14.410 --> 09:17.230 Then what we want to do is add an additional container as a sidecar, 09:17.310 --> 09:19.300 so the name has to be sidecar. 09:19.380 --> 09:21.770 The image has to be the filebeat image. 09:21.850 --> 09:23.970 This is basically a custom image 09:24.050 --> 09:28.280 we created off of the default filebeat [?] 09:28.360 --> 09:31.250 where we've configured it to automatically send 09:31.330 --> 09:33.680 the data to elastic search. 09:33.760 --> 09:36.750 This is just something that's created just for this lab, 09:36.830 --> 09:39.690 purpose of this lab to demonstrate this. 09:39.770 --> 09:43.590 Then you have-- You must configure the volumeMount. 09:43.670 --> 09:45.730 Basically these two, 09:45.810 --> 09:47.460 sorry, these two containers. 09:47.540 --> 09:50.000 The app container and the filebeat container 09:50.080 --> 09:54.670 are going to share this particular path. 09:54.750 --> 09:59.970 The path to the log, where the logs are stored. 10:00.050 --> 10:01.440 Let's do that. 10:02.290 --> 10:06.110 We have to edit the existing pod. 10:06.190 --> 10:09.150 Kubectl edit pod app 10:09.230 --> 10:14.290 in the elastic namespace 10:16.040 --> 10:19.130 and the goal is to add an additional container. 10:21.310 --> 10:22.630 It's going to add a container here 10:26.780 --> 10:30.040 and the image for that container 10:30.120 --> 10:35.240 is filebeat-configured. 10:36.660 --> 10:46.920 Name is sidecar and in volumeMounts. 10:51.370 --> 10:55.400 The volumeMount path is-- 10:55.940 --> 10:58.470 We can just copy this from here. 11:04.820 --> 11:07.880 The mountPath is /var/log/event-simulator 11:14.300 --> 11:17.020 and then the volumeMount name is log volume. 11:18.630 --> 11:22.660 This is the sidecar filebeat container 11:22.740 --> 11:26.660 and what's happening here is the pod now is going to have two containers. 11:27.240 --> 11:29.000 This is our actual application, 11:29.080 --> 11:32.170 and it stores logs in this particular path, 11:32.250 --> 11:35.800 or in this particular volume, the volume named log-volume. 11:36.750 --> 11:40.340 That log-volume is mounted at the path/log 11:40.420 --> 11:41.710 within this application. 11:41.790 --> 11:43.850 This could be anything but the important thing 11:43.930 --> 11:46.250 is this log volume that's specified here. 11:46.930 --> 11:49.320 We're adding an additional container which-- 11:49.400 --> 11:51.750 All it does is going to take-- 11:51.830 --> 11:53.690 It's going to read the logs 11:53.770 --> 11:56.260 and pass it through to the elastic search, 11:56.640 --> 12:00.290 central elastic search kind of database. 12:00.370 --> 12:02.600 What you have is you also have the volumeMount here, 12:02.680 --> 12:04.000 and it's the same name. 12:04.080 --> 12:07.670 These are going to be the same volume. 12:07.750 --> 12:10.300 Think of a volume being here. 12:10.380 --> 12:13.370 That's going to be mounted on both of the containers. 12:13.960 --> 12:18.880 Then this, the path to this is at /var/log/event-simulator. 12:18.960 --> 12:22.020 Basically, the app.log is all going to be stored 12:22.100 --> 12:24.450 inside this on this container, 12:24.530 --> 12:26.890 as well as inside this on this container 12:26.970 --> 12:31.460 and this filebeat is configured to read the logs 12:31.540 --> 12:35.100 from this particular directory and send it to elastic search. 12:36.340 --> 12:39.700 From the point of this exercise, 12:39.780 --> 12:43.300 all we need to do is add this additional sidecar container. 12:43.380 --> 12:45.670 Let me save that, 12:47.690 --> 12:48.940 but it's not going to allow us to see that 12:49.020 --> 12:53.180 because pod updates may not add or remove containers but that's fine. 12:53.260 --> 12:55.520 We're going to quit from this 12:55.600 --> 12:58.250 and now we have our file with the edits, 12:58.330 --> 13:04.290 and we'll just do a kubectl replace, force. 13:12.080 --> 13:16.600 We'll just wait for that to finish. 13:21.320 --> 13:24.950 Okay, let's check our work. 13:26.090 --> 13:27.780 Okay, that's successful. 13:28.130 --> 13:29.320 Let's go next. 13:29.400 --> 13:32.620 Now, inspect the Kibana UI and you should now see the logs 13:32.700 --> 13:34.760 appearing in the discover section. 13:34.840 --> 13:38.460 Let's go to the Kibana UI. 13:39.470 --> 13:41.830 We go here. 13:45.810 --> 13:48.570 What this says is that you have to create an index pattern 13:48.650 --> 13:53.040 and Kibana uses index patterns to retrieve data from elastic search. 13:53.120 --> 13:57.010 You have to give something like a pattern that it can look for. 13:57.090 --> 13:58.450 Well, basically, we're just going to get everything, 13:58.530 --> 14:00.980 so we'll just say star 14:02.300 --> 14:04.120 and Time Filter field name. 14:04.200 --> 14:09.160 I don't want to use Time Filter, and let's just create the index pattern. 14:12.470 --> 14:14.930 Okay, now let's go to discover 14:17.610 --> 14:20.300 and we should now be able to see the logs coming through. 14:20.680 --> 14:22.770 These are the logs that are coming through. 14:22.850 --> 14:26.010 Here you have the user-related details. 14:26.090 --> 14:29.480 User 2 is viewing page 1. 14:30.560 --> 14:35.220 You have User 3 is logged in, 14:35.500 --> 14:39.420 User 4 is viewing page 1. 14:41.440 --> 14:43.290 User 7's order's failed. 14:44.310 --> 14:46.960 These are the details that we saw earlier 14:47.040 --> 14:48.430 when we just reviewed the logs directly. 14:48.510 --> 14:52.630 Now we have the logs coming in through to this Kibana dashboard, 14:52.710 --> 14:54.170 and we can have as many-- 14:54.250 --> 14:57.270 We can do the same configuration to as many pods 14:57.350 --> 14:59.570 or deployments or any application that we've deployed 14:59.650 --> 15:02.810 on kubernetes to be configured too. 15:02.890 --> 15:05.010 Okay, that's about it for now 15:06.490 --> 15:08.380 and I'll see you in the next one.