WEBVTT 00:00.720 --> 00:02.010 Instructor: In the last section, we finished 00:02.010 --> 00:04.110 going through both of our configuration files, 00:04.110 --> 00:05.250 and we're now ready to load these 00:05.250 --> 00:06.870 into our Kubernetes cluster 00:06.870 --> 00:09.090 and try to access our running container. 00:09.090 --> 00:10.200 So in order to do so, 00:10.200 --> 00:12.210 we're going to feed both these configuration files 00:12.210 --> 00:16.800 into our cluster through the kubectl command line tool. 00:16.800 --> 00:18.690 The command in particular that we're going to run 00:18.690 --> 00:20.940 is the apply command. 00:20.940 --> 00:21.900 So at the command line, 00:21.900 --> 00:26.070 we're going to run kubectl apply -f, 00:26.070 --> 00:28.260 and then the name of a configuration file, 00:28.260 --> 00:31.470 or I should say the path to the configuration file. 00:31.470 --> 00:33.690 Now, kubectl, again, that's a command line tool 00:33.690 --> 00:36.690 that we use to mess around with everything going on 00:36.690 --> 00:39.240 inside of our Kubernetes cluster. 00:39.240 --> 00:41.430 The apply keyword means that we want to 00:41.430 --> 00:43.620 change the configuration of our cluster. 00:43.620 --> 00:46.470 And that's actually kind of a very loaded term, 00:46.470 --> 00:48.570 like these words right here 00:48.570 --> 00:50.370 change the current configuration. 00:50.370 --> 00:52.440 That's a real loaded term right there. 00:52.440 --> 00:54.090 And it's something that we're going to expand upon 00:54.090 --> 00:56.493 at great length in just a little bit. 00:57.540 --> 01:00.030 We then specify that we want to load in a file 01:00.030 --> 01:02.220 that contains all this configuration that we care about. 01:02.220 --> 01:04.410 So we're going to add on the -f flag, 01:04.410 --> 01:07.380 and then the path to the file is the path to the file. 01:07.380 --> 01:08.640 That's pretty much it. 01:08.640 --> 01:10.500 So let's try flipping over to our command line. 01:10.500 --> 01:13.200 And we're going to run this command two times, 01:13.200 --> 01:16.410 one time for the client-pod.yaml file 01:16.410 --> 01:19.803 and one time for the client-node-port.yaml file. 01:21.510 --> 01:23.580 So back in my terminal, I'm going to first make sure 01:23.580 --> 01:26.190 that I'm inside of my simplek8s directory, 01:26.190 --> 01:29.280 which is where I have those two configuration files. 01:29.280 --> 01:32.970 I'll then run kubectl apply -f. 01:32.970 --> 01:35.550 And let's first load up the client pod. 01:35.550 --> 01:38.397 So I'll say, "client-pod.yaml." 01:40.410 --> 01:41.310 I'll hit enter, 01:41.310 --> 01:42.540 and then we'll very quickly see 01:42.540 --> 01:44.970 that the pod has been configured. 01:44.970 --> 01:46.500 Now, what does configured mean? 01:46.500 --> 01:50.040 Who knows, that seems a little bit mysterious. 01:50.040 --> 01:52.860 It doesn't really seem to say that the pod was like, 01:52.860 --> 01:55.320 or the container was successfully created. 01:55.320 --> 01:57.000 And, in fact, this message printed up 01:57.000 --> 01:58.950 a little bit too quickly for me to 01:58.950 --> 02:02.280 really feel like the container was successfully created. 02:02.280 --> 02:03.750 So we might need to do a little bit 02:03.750 --> 02:05.520 of a status check here in just a second 02:05.520 --> 02:06.930 to make sure that the pod 02:06.930 --> 02:09.303 was in fact started up successfully. 02:10.350 --> 02:13.470 But before we do, let's apply our other configuration file. 02:13.470 --> 02:16.410 So I'll do kubectl apply -f. 02:16.410 --> 02:19.860 And then the other file was called client-node-port. 02:19.860 --> 02:22.323 So client-node-port.yaml. 02:24.300 --> 02:27.090 And, again, I see configured message right here. 02:27.090 --> 02:28.530 Now, again, in both cases, 02:28.530 --> 02:30.930 seems like these messages appeared pretty quickly, 02:30.930 --> 02:32.940 so I don't really know if everything worked 02:32.940 --> 02:34.650 the way we would expect. 02:34.650 --> 02:38.190 So let's try figuring out how we can print out the status 02:38.190 --> 02:40.260 of both these different objects that we just created 02:40.260 --> 02:41.280 and just make sure that 02:41.280 --> 02:44.130 they were, in fact, successfully created. 02:44.130 --> 02:46.477 So in order to get the status 02:46.477 --> 02:48.630 of any different object that you and I create 02:48.630 --> 02:51.570 through a configuration file or any other means, 02:51.570 --> 02:55.353 we're going to be making use of the kubectl get command. 02:56.280 --> 02:58.560 The get command is going to print out the status 02:58.560 --> 03:01.860 of an entire group of object types. 03:01.860 --> 03:05.640 So, for example, we would say, "kubectl get pods." 03:05.640 --> 03:08.430 In this case, pods is the type of object 03:08.430 --> 03:10.740 that we want to get information about. 03:10.740 --> 03:13.230 Kubectl will look at our Kubernetes cluster, 03:13.230 --> 03:15.690 it'll find all the different pods that have been created, 03:15.690 --> 03:18.900 and it'll print out the status of every single one. 03:18.900 --> 03:20.610 So it's a very easy way to get a 03:20.610 --> 03:22.950 kinda high-level look at everything that's going on 03:22.950 --> 03:24.100 inside of your cluster. 03:25.590 --> 03:29.643 So I'll do kubectl get pods at my terminal. 03:31.200 --> 03:33.660 And I'll see that I have one pod created. 03:33.660 --> 03:36.090 It has a name of client-pod. 03:36.090 --> 03:37.140 One of one right here 03:37.140 --> 03:39.660 means that there is one copy of it running. 03:39.660 --> 03:42.270 And we need to have one copy running. 03:42.270 --> 03:43.440 So the first number right here 03:43.440 --> 03:45.240 is the number of pods that are running 03:45.240 --> 03:47.850 and the second number is the number of copies 03:47.850 --> 03:49.440 that we want to have. 03:49.440 --> 03:51.360 As we start to scale our application, 03:51.360 --> 03:53.130 we might want to have multiple copies 03:53.130 --> 03:54.840 of the exact same pod running. 03:54.840 --> 03:55.830 And so when that happens, 03:55.830 --> 03:57.270 you would expect to see one right here 03:57.270 --> 04:01.260 change to two, three, four, five, whatever it might be. 04:01.260 --> 04:03.060 We then see that the status is running. 04:03.060 --> 04:05.730 So it definitely looks like everything started up A-OK. 04:05.730 --> 04:07.440 There have not been any restarts. 04:07.440 --> 04:10.980 So if your pod right here crashes for any given reason, 04:10.980 --> 04:12.450 it'll be automatically restarted 04:12.450 --> 04:15.210 and you would see restarts right there increment by one. 04:15.210 --> 04:16.860 And then age of one hour means 04:16.860 --> 04:19.680 it's been running for one hour. 04:19.680 --> 04:21.300 Now in my case, the thing has not actually 04:21.300 --> 04:22.650 been running for one hour. 04:22.650 --> 04:24.480 I just started up this pod a while ago 04:24.480 --> 04:27.570 and I forgot to close it before running the apply command. 04:27.570 --> 04:28.650 But not a big deal. 04:28.650 --> 04:30.690 You're gonna see a age of like 04:30.690 --> 04:33.030 one minute or something like that. 04:33.030 --> 04:34.920 Okay, so now we're going to get the status 04:34.920 --> 04:37.980 of all the different services that we have created as well. 04:37.980 --> 04:40.590 So to get a printout of all of our different services, 04:40.590 --> 04:43.980 we're just going to slightly change the kubectl get command. 04:43.980 --> 04:45.570 We're gonna say that we want to get a printout 04:45.570 --> 04:48.903 of all the objects with type service that we have created. 04:49.950 --> 04:53.517 So I'll say, "kubectl get services." 04:55.080 --> 04:58.050 And that's gonna print out two different services. 04:58.050 --> 05:01.140 Now, chances are you have two services running as well. 05:01.140 --> 05:03.960 One might be Kubernetes with a type of ClusterIP. 05:03.960 --> 05:04.920 If you see that, 05:04.920 --> 05:07.050 that's one of the inner workings of Kubernetes 05:07.050 --> 05:09.900 and you can completely ignore that thing. 05:09.900 --> 05:10.890 Now, hopefully, you're gonna see 05:10.890 --> 05:12.750 a second service printed out in here 05:12.750 --> 05:14.490 with the name of client-node-port. 05:14.490 --> 05:16.950 Its type will be, of course, NodePort. 05:16.950 --> 05:19.800 It'll have a cluster-IP, an external-IP, 05:19.800 --> 05:23.610 and then a listing of ports and age over here as well. 05:23.610 --> 05:26.970 Now, I want you to look very closely at ports over here. 05:26.970 --> 05:30.240 You'll notice that there's both the port property 05:30.240 --> 05:33.000 and the node port property as well. 05:33.000 --> 05:35.700 And so as a quick reminder, the first number on there, 05:36.990 --> 05:37.823 where's our diagram? 05:37.823 --> 05:39.660 Here we go, so the first number on there is the port. 05:39.660 --> 05:42.690 That is the port that other pods or other objects would use 05:42.690 --> 05:47.040 to access the pod that this service points to. 05:47.040 --> 05:48.960 Second number is the node port. 05:48.960 --> 05:50.910 And so that is the port that you and I would use 05:50.910 --> 05:54.210 to access that service inside of our browser. 05:54.210 --> 05:55.650 You will notice that the one port 05:55.650 --> 05:59.430 that is not reflected inside of here is the target port. 05:59.430 --> 06:01.380 So the service does not report 06:01.380 --> 06:04.200 the port that is trying to open up inside the target pod. 06:04.200 --> 06:06.240 That's not done for any security issues. 06:06.240 --> 06:09.480 It's just done because, like, who cares? (chuckles) 06:09.480 --> 06:10.313 Who cares, right? 06:10.313 --> 06:11.146 For that print up, 06:11.146 --> 06:12.660 you probably don't care about the target port. 06:12.660 --> 06:14.790 You probably only care about the port property 06:14.790 --> 06:15.993 and the node port. 06:16.860 --> 06:17.790 All right. 06:17.790 --> 06:18.900 So that's pretty much it. 06:18.900 --> 06:21.420 We have now deployed both of these objects 06:21.420 --> 06:24.420 and they're now running on our local cluster. 06:24.420 --> 06:26.010 So now the very last thing we have to do 06:26.010 --> 06:29.700 is attempt to access our running multi-client project 06:29.700 --> 06:30.993 inside of our browser. 06:31.860 --> 06:33.600 Now, you might expect, 06:33.600 --> 06:35.820 and based on my wording right now, you'll, 06:35.820 --> 06:37.530 as you might guess, this is not the way we do it, 06:37.530 --> 06:41.460 you might expect that we would go to localhost:, 06:41.460 --> 06:44.250 and then whatever we put in as the node port over here, 06:44.250 --> 06:46.110 31515. 06:46.110 --> 06:48.390 Remember, this is the port that we use to access 06:48.390 --> 06:51.390 or test out our container inside the browser. 06:51.390 --> 06:53.070 So you might think that we go to 06:53.070 --> 06:56.550 localhost:35151 or whatever. 06:56.550 --> 06:57.927 I keep mistyping that thing. 06:57.927 --> 06:59.730 I'm just gonna do a copy paste. 06:59.730 --> 07:00.660 There we go. 07:00.660 --> 07:02.910 So, of course, when you go there, yeah, nothing works. 07:02.910 --> 07:04.410 So what's going on? 07:04.410 --> 07:06.840 Well, remember what is going on behind the scenes 07:06.840 --> 07:09.240 on your computer right now. 07:09.240 --> 07:10.860 Let's pull up a good diagram for this. 07:10.860 --> 07:12.510 This one right here, this'll do. 07:12.510 --> 07:13.560 Nah, let's do this one. 07:13.560 --> 07:14.393 Okay. 07:14.393 --> 07:16.140 So when we are inside of our browser, 07:16.140 --> 07:18.570 when we want to access some container 07:18.570 --> 07:21.600 that is running on that Kubernetes node VM 07:21.600 --> 07:23.250 created by Minikube, 07:23.250 --> 07:26.220 this is not addressed by localhost. 07:26.220 --> 07:27.930 In other words, all the ports 07:27.930 --> 07:30.090 that exist inside this node VM right here 07:30.090 --> 07:32.910 are not available on localhost. 07:32.910 --> 07:37.110 In order to access this VM, we need to actually ask Minikube 07:37.110 --> 07:39.480 for the IP address that was assigned 07:39.480 --> 07:41.130 to this virtual machine 07:41.130 --> 07:43.380 when it was created on your computer. 07:43.380 --> 07:44.610 So this virtual machine right here 07:44.610 --> 07:48.900 that was created on your machine has its own IP address, 07:48.900 --> 07:51.690 and you need to visit that IP address 07:51.690 --> 07:54.240 in order to access any of the different services, 07:54.240 --> 07:57.510 any different pods that are running inside of here. 07:57.510 --> 07:59.430 So to access that IP address, 07:59.430 --> 08:01.260 we'll flip back over to our command line, 08:01.260 --> 08:04.350 and we're going to run minicube ip. 08:04.350 --> 08:06.180 And that's gonna print out the IP address 08:06.180 --> 08:08.190 of that virtual machine. 08:08.190 --> 08:10.590 So at any point in time, 08:10.590 --> 08:13.740 forever inside this course and your own applications, 08:13.740 --> 08:15.690 anytime that you want to access 08:15.690 --> 08:18.600 some application that is running inside of Minicube 08:18.600 --> 08:20.550 or inside that virtual machine, 08:20.550 --> 08:24.240 you are not going to use localhost. 08:24.240 --> 08:27.090 Just forget it, there is no localhost, period. 08:27.090 --> 08:28.530 No localhost. 08:28.530 --> 08:31.020 Anytime that you want to access a service, 08:31.020 --> 08:32.820 or a container, or a pod, or whatever it might be, 08:32.820 --> 08:34.920 that is running on your virtual machine 08:34.920 --> 08:36.690 or inside of your Kubernetes cluster, 08:36.690 --> 08:38.790 when you're running in development mode, 08:38.790 --> 08:41.490 you're going to run minicube ip 08:41.490 --> 08:45.120 and you're going to use this IP address right here. 08:45.120 --> 08:47.400 So, hopefully, I made that memorable enough. (laughs) 08:47.400 --> 08:49.320 You're not gonna use localhost, that's pretty much it. 08:49.320 --> 08:51.660 So we're gonna copy this right here. 08:51.660 --> 08:53.430 I'm gonna go back over to my browser, 08:53.430 --> 08:55.110 I'm gonna put in that IP, 08:55.110 --> 08:58.860 and then we're going to specifically access the port, 08:58.860 --> 09:00.420 the node port that we set up on that thing. 09:00.420 --> 09:04.920 So I'll say, ":31515." 09:04.920 --> 09:06.900 And I'm going to put that over inside my command line 09:06.900 --> 09:08.220 just to make sure it's really clear. 09:08.220 --> 09:10.170 Yeah, there's a colon on there. 09:10.170 --> 09:13.890 Remember, your IP address might be very different than mine. 09:13.890 --> 09:16.440 So do not go to my IP address. 09:16.440 --> 09:19.263 Go to whatever IP you see printed out at your terminal. 09:20.100 --> 09:21.690 All right, so we're going to go there. 09:21.690 --> 09:22.770 And lo and behold, 09:22.770 --> 09:25.710 we see our application appear on the page. 09:25.710 --> 09:27.120 Now, of course, if you open up your terminal, 09:27.120 --> 09:28.650 you're gonna see a couple error messages 09:28.650 --> 09:32.100 because this thing is not able to access the Express API. 09:32.100 --> 09:32.933 That's totally fine. 09:32.933 --> 09:35.430 It's just because we have not actually set up that API 09:35.430 --> 09:37.773 inside of our Kubernetes cluster yet. 09:38.940 --> 09:40.650 Okay, so that's pretty much it. 09:40.650 --> 09:42.180 We have gone through the entire process 09:42.180 --> 09:44.640 of creating two different objects, 09:44.640 --> 09:47.190 both a pod and a service. 09:47.190 --> 09:49.200 We understand the differences between the two 09:49.200 --> 09:51.240 and we understand that we have to create a service 09:51.240 --> 09:54.960 if we want to access anything inside of our running pod. 09:54.960 --> 09:58.920 Remember, by default, Kubernetes is far more restricted, 09:58.920 --> 10:00.210 with all of its networking stuff, 10:00.210 --> 10:03.270 than anything we ever did with Docker Compose 10:03.270 --> 10:04.980 or with Elastic Beanstalk. 10:04.980 --> 10:08.370 With Kubernetes, we have to be very, very explicit 10:08.370 --> 10:10.770 about all the networking that we want to set up. 10:10.770 --> 10:12.900 And we do all the networking setup 10:12.900 --> 10:16.080 by the creation of these different service things. 10:16.080 --> 10:17.250 So that's pretty much it. 10:17.250 --> 10:18.900 That's the basics of Kubernetes. 10:18.900 --> 10:20.310 So let's take a quick pause right here, 10:20.310 --> 10:22.380 and we're gonna start looking at some more complex stuff 10:22.380 --> 10:23.380 in the next section.