1 00:00:00,740 --> 00:00:05,550 In last video I told you that we needed a load balancer service to somehow get traffic into all of our 2 00:00:05,550 --> 00:00:06,710 different pods. 3 00:00:06,720 --> 00:00:11,640 Now it turns out that this entire idea of a load balancer service is a little bit more intricate than 4 00:00:11,700 --> 00:00:13,110 at first glance. 5 00:00:13,140 --> 00:00:17,550 So this video I want to clarify some terminology that you're going to see online and as a matter of 6 00:00:17,550 --> 00:00:21,480 fact we're gonna see very quickly around this load balancer service thing. 7 00:00:21,540 --> 00:00:25,860 So when we talk about a load balancer service or as I've been mentioning it in the previous videos I'm 8 00:00:25,860 --> 00:00:29,300 really talking about two distinct things in the world the Cuban eddies. 9 00:00:29,370 --> 00:00:33,760 So first off there is something in Cuba that is called a load balancer service. 10 00:00:33,900 --> 00:00:40,680 There is something that is also very closely related that is referred to as ingress or in ingress controller. 11 00:00:40,680 --> 00:00:45,480 Now technically an ingress and egress controller are two different things but for the purposes of this 12 00:00:45,480 --> 00:00:48,900 course we're going to kind of refer to them with interchangeable terms. 13 00:00:49,050 --> 00:00:53,370 A lot of the stuff I'm about to show you is kind of a very high level overview and so I'm simplifying 14 00:00:53,370 --> 00:00:58,530 some very specific parts of it to just make some parts a lot easier to understand because having a deep 15 00:00:58,530 --> 00:01:02,050 understanding of the behind the scenes stuff is super not critical right now. 16 00:01:02,070 --> 00:01:04,580 You really just need a taste of what is going on. 17 00:01:04,620 --> 00:01:08,910 It doesn't make a lot of sense to dive into the deep end at the very start because it it's just way 18 00:01:08,910 --> 00:01:09,600 too confusing. 19 00:01:10,820 --> 00:01:10,990 All right. 20 00:01:11,000 --> 00:01:16,820 So what is this stuff a load balancer service is going to be something that tells Cuban cities or specifically 21 00:01:16,820 --> 00:01:20,050 are cluster to reach out to its provider. 22 00:01:20,060 --> 00:01:24,500 We'll talk about what that isn't just a moment and provision a load balancer. 23 00:01:24,500 --> 00:01:30,310 The goal of a load balancer service is to get traffic into a single pod. 24 00:01:30,450 --> 00:01:33,050 On the other hand an ingress or ingress controller. 25 00:01:33,060 --> 00:01:37,800 Again technically different things but we're going to use these terms interchangeably is a pod that 26 00:01:37,800 --> 00:01:42,900 has a set of routing rules in it that are going to distribute traffic to other services inside of our 27 00:01:42,900 --> 00:01:44,850 cluster now. 28 00:01:44,870 --> 00:01:46,910 Just look at these definitions not super useful. 29 00:01:47,060 --> 00:01:48,770 So let's take a look at a diagram or two. 30 00:01:48,890 --> 00:01:52,270 We're going to first focus on what a load balancer service really is. 31 00:01:53,130 --> 00:01:53,420 All right. 32 00:01:53,430 --> 00:01:57,570 So in this diagram we've got our cluster here in the blue box. 33 00:01:57,570 --> 00:02:03,000 We're going to imagine that we are running one singular pod right here called some pod our cluster at 34 00:02:03,000 --> 00:02:03,940 some point in time. 35 00:02:03,990 --> 00:02:08,790 Not right now on our local machine but at some point on the future is going to be running on some cloud 36 00:02:08,790 --> 00:02:09,570 provider. 37 00:02:09,690 --> 00:02:13,740 So maybe eight of us Google Cloud ASR or something similar. 38 00:02:13,740 --> 00:02:19,260 We are going to want to somehow get traffic or network requests from the outside world to some pod inside 39 00:02:19,260 --> 00:02:20,430 of our cluster. 40 00:02:20,430 --> 00:02:23,690 So how do we do that using a load balancer. 41 00:02:23,700 --> 00:02:27,960 Well we would create a config file for a load balancer service. 42 00:02:27,960 --> 00:02:34,620 We would then be that thing into our cluster using that same QCT cell apply command now a load balancer 43 00:02:34,620 --> 00:02:40,590 service is a very special little thing just about all the objects we've been discussing throughout this 44 00:02:40,590 --> 00:02:45,450 last section on Cuba daddy so far has been all about stuff that gets created directly inside of our 45 00:02:45,450 --> 00:02:46,170 cluster. 46 00:02:46,170 --> 00:02:51,540 So we have created services inside the cluster ODS inside the cluster deployments inside the cluster 47 00:02:52,080 --> 00:02:57,630 a load balancer service is a little bit different a load balancer service is going to tell our cluster 48 00:02:57,810 --> 00:03:05,640 to reach out to the its cloud provider so reach out directly to a WSU cloud or Asa and provision something 49 00:03:05,640 --> 00:03:13,470 called a load balancer this load balancer exists completely outside of our cluster it is a part of Google 50 00:03:13,470 --> 00:03:19,710 cloud or a W us or asa this load balancer is going to be used to take traffic from the outside world 51 00:03:20,190 --> 00:03:27,970 and direct it in to some pod inside of our cluster the goal of a load balancer or that really I should 52 00:03:27,970 --> 00:03:33,630 say the goal of a load balancer service is to tell our cluster to reach out to its provider provisional 53 00:03:33,630 --> 00:03:40,390 load balancer with the goal of getting some traffic into a pod on our cluster a load balancer by itself 54 00:03:40,450 --> 00:03:43,380 is not super useful for you and I right now. 55 00:03:43,390 --> 00:03:47,490 Instead what you and I really want to do is what we saw back in this diagram over here. 56 00:03:47,620 --> 00:03:53,110 We want to get traffic distributed to a set of different pods and we want to have some routing rules 57 00:03:53,170 --> 00:03:59,310 inside of something to decide where to send this traffic to one thing on a mention really quickly is 58 00:03:59,310 --> 00:04:04,350 that our ReACT application doesn't really want to have to understand the difference between say the 59 00:04:04,350 --> 00:04:07,070 query pod and the comments pod in the post pod. 60 00:04:07,110 --> 00:04:11,610 We don't want to have to encode that information inside the react app instead of what would be great 61 00:04:11,610 --> 00:04:17,580 is if we can just say make a request to this route and if there is something over here around our cluster 62 00:04:17,580 --> 00:04:23,910 to figure out what pod that request should be forwarded to the load balancer just by itself is not really 63 00:04:23,910 --> 00:04:25,430 doing the full thing for us. 64 00:04:25,440 --> 00:04:30,060 That's not doing everything we need and that is where this idea of an ingress or ingress controller 65 00:04:30,150 --> 00:04:36,110 is going to come into play so the ingress or ingress controller is a pod that has a set of routing rules 66 00:04:36,140 --> 00:04:37,310 inside of it. 67 00:04:37,310 --> 00:04:41,080 It's going to work alongside this load balancer service thing. 68 00:04:41,120 --> 00:04:44,110 Let's take a look at a diagram to understand what this Ingress is really doing. 69 00:04:45,660 --> 00:04:47,680 OK then this diagram very similar. 70 00:04:47,680 --> 00:04:50,340 We've got our cluster right here in the blue box. 71 00:04:50,410 --> 00:04:56,330 It's being hosted with some cloud provider and we want to get some outside traffic into these set of 72 00:04:56,330 --> 00:04:57,650 different pods. 73 00:04:57,660 --> 00:05:02,870 These are different pods so it might be say to post comments query whatever else. 74 00:05:03,170 --> 00:05:08,390 So we are going to have a request coming in still to a load balancer that has been provisioned with 75 00:05:08,390 --> 00:05:14,540 our cloud provider but now this load balancer is going to send that request on to this ingress controller 76 00:05:14,540 --> 00:05:19,880 thing and it's ingress controllers going to have a set of routing rules inside of it. 77 00:05:19,940 --> 00:05:24,170 This route when I use the term routing rules by the way I'm really just saying this ingress controller 78 00:05:24,170 --> 00:05:30,140 is going to look at the path of the incoming request and then decide based upon that path whether to 79 00:05:30,140 --> 00:05:35,380 send the request on to that pod or that pod or that pod or whatever else. 80 00:05:35,520 --> 00:05:41,360 And naturally when I say send the request onto some pod I'm really meaning to say send it to some cluster 81 00:05:41,390 --> 00:05:44,420 IP service that is sending request on to the pod. 82 00:05:44,430 --> 00:05:46,640 So I'm not showing the cluster IP services in here. 83 00:05:46,640 --> 00:05:50,750 They technically do exist but for the purposes of this diagram I'm just saying we're going to send traffic 84 00:05:50,750 --> 00:05:56,500 on to the pod so that is the relationship between this load balancer thing and this ingress controller 85 00:05:56,500 --> 00:05:56,940 thing. 86 00:05:57,090 --> 00:06:00,990 The load balancer is just about getting traffic into our cluster. 87 00:06:01,060 --> 00:06:06,340 This ingress thing is about routing rules or having some routing configuration that's going to send 88 00:06:06,340 --> 00:06:08,760 requests off to the appropriate pod. 89 00:06:08,770 --> 00:06:13,450 Now once you repeat once again that I am simplifying some aspects of this just to make this a little 90 00:06:13,450 --> 00:06:15,800 bit easier to understand in the first go round. 91 00:06:15,940 --> 00:06:20,680 If we went at full depth tried to really understand all the behind the scenes stuff it would take a 92 00:06:20,680 --> 00:06:25,270 lot of time and just not be a very efficient use of time so effectively this is good enough for what 93 00:06:25,270 --> 00:06:25,870 we need to do. 94 00:06:26,790 --> 00:06:27,030 All right. 95 00:06:27,040 --> 00:06:28,450 So we can take a quick pause right here. 96 00:06:28,450 --> 00:06:32,710 When we come back the next video we're going to take a look at a very specific implementation of an 97 00:06:32,740 --> 00:06:37,030 ingress controller that we're going to use inside of our app and we'll start to implement this thing 98 00:06:37,120 --> 00:06:37,960 inside of our cluster.