WEBVTT 00:00.050 --> 00:01.250 Welcome back everybody. 00:01.460 --> 00:04.580 We need to change the way that we're accessing our entry point. 00:04.610 --> 00:05.750 Our great submission portal. 00:05.750 --> 00:06.230 Front end. 00:06.260 --> 00:10.160 We can't be using the node port service anymore. 00:11.030 --> 00:13.850 Zooming in on just the great submission portal pod. 00:13.850 --> 00:19.610 Currently, we're using a node port service to expose a static port on our nodes as IP address. 00:19.640 --> 00:24.620 Now, because we're prototyping and we're doing everything locally, the IP address in this case is 00:24.620 --> 00:32.690 very obvious and we can just very easily say localhost 32,000 and direct our external request to the 00:32.690 --> 00:33.980 internal pod. 00:33.980 --> 00:39.260 But in a realistic scenario in production, when we've got a Kubernetes cluster on AWS with many, many 00:39.260 --> 00:45.620 nodes, with each node with a different IP address, and only some of the nodes could be running our 00:45.650 --> 00:52.400 app, keeping track of all the correct IP addresses would be very, very hard, especially in this day 00:52.400 --> 00:54.680 and age where environments are very dynamic. 00:54.710 --> 01:01.850 IP addresses are being changed very frequently, so relying on an IP address on a static IP address 01:01.850 --> 01:04.670 to access our apps just doesn't make any sense. 01:04.700 --> 01:05.000 All right. 01:05.030 --> 01:08.900 So node port we're going to officially retire it in this section. 01:08.900 --> 01:14.690 So we're going to replace it with a solution that can actually scale to when we deploy our cluster on 01:14.690 --> 01:15.500 the cloud. 01:16.130 --> 01:19.850 So when we do deploy our cluster on the cloud it's going to look something like this. 01:19.850 --> 01:21.230 We're not going to have one node. 01:21.230 --> 01:25.370 We're going to have many worker nodes running our container workloads. 01:25.370 --> 01:32.270 And we can make an assumption in this case that each worker node is running an nginx ingress controller 01:32.270 --> 01:32.840 pod. 01:32.840 --> 01:39.050 So let's assume you bought a domain from a registrar like GoDaddy and you bought the domain. 01:39.050 --> 01:47.480 Great submission portal.com, and you made that domain point to a load balancer that is provided by 01:47.960 --> 01:48.770 AWS. 01:48.800 --> 01:57.860 When you deploy your cluster on AWS, you get access to a load balancer, which is a server whose sole 01:57.860 --> 02:02.960 purpose is to load balance traffic across your worker nodes. 02:02.990 --> 02:08.430 Load balancing is important because you never want to put too much burden on one node. 02:08.430 --> 02:15.120 The load balancer ensures that traffic is load balanced appropriately, so it's going to choose one 02:15.120 --> 02:17.940 of the worker nodes to forward that request to. 02:17.970 --> 02:23.400 But ultimately the recipient of that request is the nginx ingress controller. 02:23.430 --> 02:27.330 The nginx ingress controller acts as a reverse proxy. 02:27.360 --> 02:29.160 What do I mean by this? 02:29.220 --> 02:36.810 Let's imagine a traditional forward proxy, which acts on behalf of the client to send a request to 02:36.840 --> 02:38.460 a particular server. 02:38.820 --> 02:47.430 A reverse proxy in this case acts on behalf of the server to decide where a request is going to go, 02:47.550 --> 02:56.370 and it relies on ingress rules that we're going to write ourselves to direct the request to a certain 02:56.370 --> 02:58.110 cluster IP service. 02:58.140 --> 03:05.190 Once the nginx ingress controller determines which cluster IP service it needs to forward the traffic 03:05.190 --> 03:10.410 to the cluster IP service, as you've seen in this course, or as we've talked about in this course, 03:10.440 --> 03:12.690 is a natural load balancer itself. 03:12.690 --> 03:17.850 If we assume that we had four pod replicas of the Great submission portal, the cluster IP service will 03:17.850 --> 03:20.250 naturally load balance traffic to them. 03:20.250 --> 03:24.630 So the cluster IP service is a natural load balancer at the pod level. 03:24.630 --> 03:30.900 And by deploying our cluster on AWS, we get a load balancer at the node level. 03:30.990 --> 03:31.590 Okay. 03:31.590 --> 03:33.690 So we've got load balancers everywhere. 03:33.690 --> 03:35.040 That's pretty cool. 03:35.640 --> 03:39.120 But we haven't deployed our cluster on AWS just yet. 03:39.120 --> 03:41.760 We're not going to buy a domain from GoDaddy. 03:41.790 --> 03:44.730 We don't have a fancy schmancy load balancer just yet. 03:44.760 --> 03:52.200 We're still doing things on our local machine, which means we still need to say localhost, and it 03:52.200 --> 03:56.160 follows that an ingress service is going to expose a static port 80. 03:56.160 --> 03:58.740 So we can say localhost 80. 03:58.740 --> 04:07.050 Invoke our ingress controller, which will rely on ingress rules to determine which cluster IP service 04:07.050 --> 04:15.010 it needs to send that traffic to, and then the cluster IP service will send that traffic to the appropriate 04:15.010 --> 04:16.600 grade submission portal pod. 04:16.600 --> 04:20.560 So technically we've still got this going on. 04:20.590 --> 04:21.370 Okay. 04:21.370 --> 04:29.380 Except that instead of having an AWS Elastic Load Balancer, we're still using localhost 80. 04:29.410 --> 04:36.220 But the ingress controller solution will ultimately scale when we do deploy our cluster, our Kubernetes, 04:36.250 --> 04:38.440 our Kubernetes cluster on AWS. 04:38.470 --> 04:39.610 So enough talk. 04:39.610 --> 04:41.680 Let's go ahead and do this right now. 04:43.330 --> 04:47.230 Um copy and paste section nine. 04:47.860 --> 04:50.680 Call it section ten. 04:52.090 --> 04:53.980 All right. 04:55.450 --> 04:58.210 And before we start what do I want to do? 04:58.750 --> 05:05.440 So the horizontal pod autoscaler I'm not going to carry it over to the remaining sections. 05:05.500 --> 05:11.860 So let's delete it was a very fun section to create however. 05:12.070 --> 05:22.630 And let's delete the Horizontal Pod autoscaler from our grade submission namespace. 05:24.100 --> 05:30.520 We'll keep the metric server because it is nice to say kubectl top pods, and be able to see the CPU 05:30.520 --> 05:34.990 and memory usage of our apps, so we'll keep it in section nine. 05:34.990 --> 05:40.510 That way you have reference to what a horizontal pod autoscaler is, but I don't intend on giving the 05:40.510 --> 05:48.190 Great Submission API or the portal or our Mongo apps scaling auto scaling capabilities. 05:48.190 --> 05:50.200 We're just prototyping. 05:50.410 --> 05:56.230 Um, I don't imagine we're ever going to be flooded with requests, but in a production environment, 05:56.230 --> 05:58.150 do consider the need of an autoscaler. 05:58.180 --> 06:01.840 Okay, let's clear the output CD out of section nine. 06:02.530 --> 06:05.170 Um, I'll CD into section ten. 06:07.180 --> 06:08.230 All right. 06:08.230 --> 06:16.610 And here, our great submission portal relies on a node port service to expose a static node port 32,000. 06:16.730 --> 06:18.230 Ah, let's not do that. 06:18.230 --> 06:23.360 We're going to make this a cluster IP service in accordance. 06:23.660 --> 06:24.050 Nope. 06:24.080 --> 06:24.920 Wrong thing. 06:24.920 --> 06:29.000 In accordance to the diagram that we have right over here. 06:29.030 --> 06:29.720 Okay. 06:29.720 --> 06:34.010 So the cluster IP service is going to send traffic to the great submission portal pod. 06:34.010 --> 06:40.700 But it relies on the ingress controller in order to receive traffic from the outside. 06:40.700 --> 06:45.770 The ingress is ultimately the entry point into our Kubernetes cluster. 06:45.920 --> 06:46.940 All right. 06:46.970 --> 06:50.660 Now, before we do anything, let me grab a command. 06:53.030 --> 07:00.860 Um, what I want you to do is say kubectl delete namespace ingress engine x. 07:00.920 --> 07:06.680 So you probably don't have this namespace, but I don't want to take any chances, just in case you 07:06.680 --> 07:08.600 decided to play around throughout this course. 07:08.600 --> 07:10.370 So I don't have it yet. 07:10.370 --> 07:17.900 You shouldn't either Um, and after you've made sure that you don't have that namespace because we want 07:17.930 --> 07:19.940 to start off from a fresh installation. 07:19.940 --> 07:25.100 I left you this command inside of your resources folder. 07:25.130 --> 07:26.090 Okay. 07:26.540 --> 07:28.700 Um, it's inside of a text file. 07:28.700 --> 07:36.830 So copy and paste this command and we can use it to install and the nginx ingress controller. 07:37.400 --> 07:50.060 So if I say kubectl get pods dash n nginx ingress or ingress nginx we can see that it's currently starting 07:50.060 --> 07:50.450 up. 07:50.480 --> 07:50.930 Okay. 07:50.930 --> 07:52.130 We'll give it time. 07:53.810 --> 07:54.500 All right. 07:54.500 --> 08:00.740 So inside of section ten I'm going to say great submission portal ingress. 08:05.150 --> 08:06.530 Dot YAML. 08:08.150 --> 08:12.290 And now I'm just going to write ingress. 08:12.320 --> 08:20.190 And it sets up an ingress resource I'm going to call the ingress resource great submission Mission portal 08:20.190 --> 08:21.300 ingress. 08:22.020 --> 08:23.670 Deploy it in the namespace. 08:23.670 --> 08:25.590 I'm not going to forget the namespace this time. 08:25.590 --> 08:26.910 Great submission. 08:28.290 --> 08:30.750 Don't really need any labels for this one. 08:30.750 --> 08:32.970 Here we specify the rules okay. 08:33.000 --> 08:36.870 The host is the fully qualified domain name. 08:36.900 --> 08:37.410 All right. 08:37.410 --> 08:41.430 So we're not actually going to buy a domain. 08:41.520 --> 08:42.840 Uh great submission portal. 08:42.840 --> 08:44.280 Com or anything. 08:44.820 --> 08:47.910 Uh so we can just remove host. 08:48.960 --> 08:57.120 Basically this rule it accepts traffic from any host and will forward it to our cluster IP service, 08:57.150 --> 08:58.950 which I'll define in a second. 08:58.980 --> 09:05.520 Now path type prefix means it will match any path that starts with slash. 09:05.520 --> 09:14.220 So basically we're allowing requests from any hosts with any path that starts with slash and forwarding 09:14.220 --> 09:16.350 that to our cluster IP service. 09:16.350 --> 09:23.850 So the host could be example.com uh great submission portal Com or in this case just localhost. 09:23.850 --> 09:27.090 So this host is going to be accepted by our rule. 09:27.090 --> 09:37.170 And prefix means it will match any path that starts with slash and forward it to the cluster IP service. 09:37.170 --> 09:45.060 The service name I'm pretty sure is great submission portal and the port number is 5001. 09:45.060 --> 09:46.320 Let me just make sure. 09:46.350 --> 09:48.540 Great submission portal 5001. 09:48.540 --> 09:50.100 We are golden. 09:50.130 --> 09:50.550 All right. 09:50.550 --> 09:51.390 And that's pretty much it. 09:51.420 --> 09:53.910 We've got our ingress controller. 09:53.910 --> 10:01.080 We've got ingress rules that will forward any external traffic to our cluster IP service. 10:01.890 --> 10:03.420 All right I think we're done. 10:03.600 --> 10:10.350 Um I'll go ahead and say kubectl apply dash f. 10:10.350 --> 10:15.390 Great submission portal ingress or we'll just. 10:15.420 --> 10:15.630 Yeah. 10:15.660 --> 10:16.920 Great submission portal slash. 10:16.920 --> 10:20.730 Great submission portal ingress dot YAML. 10:22.260 --> 10:25.190 Uh, there's something I forgot to specify. 10:25.730 --> 10:30.710 That is the ingress class name. 10:30.740 --> 10:37.520 We need to associate this ingress rule with the engine X ingress controller. 10:37.670 --> 10:39.200 How did I get this class name? 10:39.200 --> 10:44.300 You can just say cube CTL get ingress class engine x. 10:44.330 --> 10:49.400 Okay, now let's reapply the ingress. 10:49.970 --> 10:50.930 Okay. 10:50.960 --> 10:52.520 Clear the output. 10:55.040 --> 10:58.040 Um, everything should be fine. 10:58.280 --> 11:06.290 I'm going to say cube ctl get services dash n great submission. 11:08.810 --> 11:09.590 All right. 11:09.590 --> 11:12.050 We still have a great submission portal node port. 11:12.050 --> 11:13.400 That's no good. 11:13.820 --> 11:16.310 Cube CTL delete. 11:16.910 --> 11:19.850 Great submission portal service 11:25.400 --> 11:27.790 And so I need to actually apply. 11:29.260 --> 11:37.420 Um, I need to actually apply the great submission Portal cluster IP service, because ultimately that 11:37.420 --> 11:40.390 is what's going to receive the traffic from our ingress controller. 11:40.390 --> 11:47.440 So kubectl apply dash f great submission portal slash great submission portal service. 11:48.250 --> 11:50.740 I should have just deployed everything in the folder. 11:51.220 --> 11:56.830 Uh whatever okay let's check on that again. 11:57.580 --> 11:59.170 All cluster IP services. 11:59.170 --> 11:59.710 Beautiful. 11:59.710 --> 12:00.970 No more node ports. 12:00.970 --> 12:06.910 The last service we want to check on is the one that exposes a port 80 on our local host machine. 12:06.910 --> 12:26.920 So kubectl get services dash n uh ingress engine x beautiful All right. 12:32.780 --> 12:33.740 Beautiful. 12:33.770 --> 12:41.240 Okay, so all that's happening is the ingress controller is using the ingress rules to determine where 12:41.270 --> 12:43.160 to forward the external request. 12:43.160 --> 12:44.780 The ingress rules. 12:44.780 --> 12:52.490 We programmed to accept requests from any host and any request that starts with the path. 12:52.520 --> 12:59.060 Slash forward that to the great Submission Portal cluster IP service, which is exactly what happened. 12:59.060 --> 13:07.100 This same ingress rule should scale when we deploy things on AWS, because ultimately, whether the 13:07.100 --> 13:16.190 request comes from great submission portal com example.com mangos com it accepts requests from any host. 13:16.190 --> 13:22.850 And if the path begins with slash it'll forward it to the great Submission Portal cluster IP service, 13:22.850 --> 13:26.420 which will forward the request to one of the pods. 13:26.450 --> 13:27.530 All right. 13:27.530 --> 13:28.910 And that's pretty much it. 13:28.910 --> 13:30.800 I hope you enjoyed this lesson.