1 00:00:02,040 --> 00:00:04,170 Now, that's all something you learned 2 00:00:04,170 --> 00:00:06,530 and for the moment I'm going to stick 3 00:00:06,530 --> 00:00:09,730 at concepts you learned about because as a next step, 4 00:00:09,730 --> 00:00:12,200 we will add a service, why? 5 00:00:12,200 --> 00:00:14,890 Because we wanna reach that users API 6 00:00:14,890 --> 00:00:18,450 even though authentic tasks API are not deployed yet 7 00:00:18,450 --> 00:00:22,240 but we wanna reach the users API from the outside world, 8 00:00:22,240 --> 00:00:24,460 for example with the postman tool, 9 00:00:24,460 --> 00:00:28,460 but that could also be a web application which is connected. 10 00:00:28,460 --> 00:00:30,990 We wanna be able to send such a request 11 00:00:30,990 --> 00:00:33,710 and for that we need a service. 12 00:00:33,710 --> 00:00:37,550 Because services just to really make that clear again, 13 00:00:37,550 --> 00:00:40,660 allow us to do two main things. 14 00:00:40,660 --> 00:00:42,800 They give us a stable address 15 00:00:42,800 --> 00:00:45,430 which does not change all the time. 16 00:00:45,430 --> 00:00:48,200 Pods do have IP addresses by default, 17 00:00:48,200 --> 00:00:51,510 but these IP addresses change if they are removed 18 00:00:51,510 --> 00:00:53,860 or moved to different nodes. 19 00:00:53,860 --> 00:00:56,110 But besides the stable IP addresses 20 00:00:56,110 --> 00:00:58,240 services also can be configured 21 00:00:58,240 --> 00:01:00,640 to allow outside world access 22 00:01:00,640 --> 00:01:03,960 which by default also is not possible. 23 00:01:03,960 --> 00:01:07,520 So, a stable IP addresses and outside world access, 24 00:01:07,520 --> 00:01:09,740 these are two strong arguments 25 00:01:09,740 --> 00:01:14,450 and therefore I will add a users-service.yaml file here 26 00:01:15,620 --> 00:01:17,773 and in there define my service. 27 00:01:18,680 --> 00:01:22,240 The API version is we won the kind of resource here 28 00:01:22,240 --> 00:01:26,450 is service and we can, of course also add metadata 29 00:01:26,450 --> 00:01:27,980 and give this service a name 30 00:01:27,980 --> 00:01:30,183 which could be users-service. 31 00:01:31,670 --> 00:01:35,820 Next, we set up the spec, the specification to configuration 32 00:01:35,820 --> 00:01:37,060 off that service, 33 00:01:37,060 --> 00:01:40,960 and here we wanna do three important things. 34 00:01:40,960 --> 00:01:44,143 We wanna select which parts should be part 35 00:01:44,143 --> 00:01:46,843 of that service and besides that we want to set up 36 00:01:46,843 --> 00:01:48,760 which ports should be exposed 37 00:01:48,760 --> 00:01:51,370 and which type of service it should be. 38 00:01:51,370 --> 00:01:53,920 Now, let's start with selecting ports 39 00:01:53,920 --> 00:01:57,190 and here I wanna select all the pods created 40 00:01:57,190 --> 00:01:58,763 by the users deployment. 41 00:01:59,750 --> 00:02:02,440 Hence of course, here I can select my pots 42 00:02:02,440 --> 00:02:06,370 by this app label with avail of users. 43 00:02:06,370 --> 00:02:08,729 So, here below selector in a service, 44 00:02:08,729 --> 00:02:10,893 we have app:users. 45 00:02:12,630 --> 00:02:15,330 We don't have match labels here 46 00:02:15,330 --> 00:02:17,850 because as I mentioned earlier in the course 47 00:02:17,850 --> 00:02:20,560 this service specifications simply 48 00:02:20,560 --> 00:02:24,350 is a bit simpler than the deployment specification. 49 00:02:24,350 --> 00:02:26,950 When it comes to the selector deployments 50 00:02:26,950 --> 00:02:29,160 support them more powerful selections 51 00:02:29,160 --> 00:02:31,060 syntax services stoned 52 00:02:31,060 --> 00:02:34,610 they're redirectly have labeled select doors. 53 00:02:34,610 --> 00:02:36,940 So hence here I use a label name 54 00:02:36,940 --> 00:02:39,710 and then a value for that label. 55 00:02:39,710 --> 00:02:43,170 So now, we know which pods should be part of this service 56 00:02:43,170 --> 00:02:48,170 as a next step, we need to set the type of this service. 57 00:02:48,550 --> 00:02:52,440 And there I mentioned, we have three main types. 58 00:02:52,440 --> 00:02:56,710 We have cluster IP, which is the default actually. 59 00:02:56,710 --> 00:02:59,700 So if you don't specify a type cluster IP 60 00:02:59,700 --> 00:03:03,540 will be used as a type and with cluster IP, 61 00:03:03,540 --> 00:03:06,280 the service is an internal service 62 00:03:06,280 --> 00:03:09,510 which is only reachable from inside the cluster, 63 00:03:09,510 --> 00:03:11,223 not from the outside world, 64 00:03:12,090 --> 00:03:15,280 hence it's not what we need here, of course. 65 00:03:15,280 --> 00:03:17,830 We also could set it to node port 66 00:03:17,830 --> 00:03:22,270 with node port we actually have a service 67 00:03:22,270 --> 00:03:24,610 which is reachable from the outside world 68 00:03:24,610 --> 00:03:28,950 but it's actually using the nodes IP address 69 00:03:28,950 --> 00:03:32,880 and that's therefore still isn't great necessarily 70 00:03:32,880 --> 00:03:35,660 if we have multiple nodes and ports, 71 00:03:35,660 --> 00:03:38,990 move between nodes because replica's are created 72 00:03:38,990 --> 00:03:41,560 and launched on a different node for example, 73 00:03:41,560 --> 00:03:44,190 then we have different IP addresses here, 74 00:03:44,190 --> 00:03:45,673 so this is not what we want. 75 00:03:46,650 --> 00:03:50,733 Therefore, the most useful type here is load balancer. 76 00:03:51,670 --> 00:03:55,620 This creates an outside available IP address 77 00:03:55,620 --> 00:03:59,890 and it also automatically distributes incoming requests 78 00:03:59,890 --> 00:04:04,280 across all ports no matter on which node they run, 79 00:04:04,280 --> 00:04:07,140 and IP address is also independent 80 00:04:07,140 --> 00:04:09,870 from the node on which a pod runs 81 00:04:09,870 --> 00:04:14,480 because a brand new IP address is created, so to say. 82 00:04:14,480 --> 00:04:18,570 So load balancer is a type you'll use a lot here. 83 00:04:18,570 --> 00:04:20,930 Now, one thing I wanna note here real quick though, 84 00:04:20,930 --> 00:04:22,670 is that with cluster IP, 85 00:04:22,670 --> 00:04:25,650 you would also have some load balancing kubernetes 86 00:04:25,650 --> 00:04:28,530 will then automatically distribute incoming requests 87 00:04:28,530 --> 00:04:31,410 across the different parts that belong to the service, 88 00:04:31,410 --> 00:04:35,930 but you never use a dedicated load balancing service 89 00:04:35,930 --> 00:04:38,770 by a cloud provider, for example, nor 90 00:04:38,770 --> 00:04:40,210 and that's the key thing here. 91 00:04:40,210 --> 00:04:44,630 Do you have an outside world facing IP address? 92 00:04:44,630 --> 00:04:49,510 So, cluster IP can be very useful internally in a cluster 93 00:04:49,510 --> 00:04:52,020 because then you can have internal communication 94 00:04:52,020 --> 00:04:54,440 and still have some load balancing 95 00:04:54,440 --> 00:04:56,490 but load balancer also gives you 96 00:04:56,490 --> 00:04:59,533 that outside world facing view. 97 00:05:00,470 --> 00:05:02,580 I just wanted to mention this because 98 00:05:02,580 --> 00:05:04,570 since this is named load balancer 99 00:05:04,570 --> 00:05:06,790 it sounds like it's the only type of service, 100 00:05:06,790 --> 00:05:10,470 which does distribute requests across different parts 101 00:05:10,470 --> 00:05:12,910 but that will actually not be the case. 102 00:05:12,910 --> 00:05:16,150 But it's the only type which does this distribution 103 00:05:16,150 --> 00:05:18,120 even across different notes 104 00:05:18,120 --> 00:05:21,730 and gives you that outside world IP address. 105 00:05:21,730 --> 00:05:24,070 So with that, we set up the type. 106 00:05:24,070 --> 00:05:27,190 Now, we can set up the ports for that service, 107 00:05:27,190 --> 00:05:30,720 with which we define which ports should be opened up 108 00:05:30,720 --> 00:05:32,300 and therefore reachable. 109 00:05:32,300 --> 00:05:37,270 And to which ports you wanna redirect inside of your ports. 110 00:05:37,270 --> 00:05:40,530 So, here we can list multiple ports 111 00:05:40,530 --> 00:05:42,120 by adding multiple dashes 112 00:05:42,120 --> 00:05:44,130 and every port should have a protocol 113 00:05:44,130 --> 00:05:47,790 which by default and typically is TCP. 114 00:05:47,790 --> 00:05:51,770 And then you have a port and a target port 115 00:05:51,770 --> 00:05:53,850 and the port 116 00:05:53,850 --> 00:05:57,090 is simply outside facing port. 117 00:05:57,090 --> 00:05:59,880 So, the port on this service IP address 118 00:05:59,880 --> 00:06:01,810 to which you can send the request 119 00:06:01,810 --> 00:06:05,120 and the target port is to port insight off the pod 120 00:06:05,120 --> 00:06:06,340 inside of the container, 121 00:06:06,340 --> 00:06:08,483 to which the request will be forwarded. 122 00:06:09,650 --> 00:06:13,340 And it is quite common that you use the same port here 123 00:06:13,340 --> 00:06:15,990 but you can also use different ports. 124 00:06:15,990 --> 00:06:19,960 Now, in my case this user's service actually listens 125 00:06:19,960 --> 00:06:21,570 on port 8080 126 00:06:21,570 --> 00:06:24,670 and that is the port exposed by the docker file therefore. 127 00:06:24,670 --> 00:06:26,270 So I will use this here 128 00:06:26,270 --> 00:06:28,610 obviously as a target port, 129 00:06:28,610 --> 00:06:32,031 but also as a port here 130 00:06:32,031 --> 00:06:36,470 for incoming requests though, as I just explained 131 00:06:36,470 --> 00:06:38,120 you could use a different port here. 132 00:06:38,120 --> 00:06:41,200 For the target port you need to use 8080 of course, 133 00:06:41,200 --> 00:06:43,540 because that's the container internal port 134 00:06:43,540 --> 00:06:45,913 on which it expects incoming requests. 135 00:06:47,220 --> 00:06:49,480 And with that, the services created. 136 00:06:49,480 --> 00:06:52,500 Now, we can of course apply that service 137 00:06:52,500 --> 00:06:56,810 with Kube + Ctrl applied -f users-service.yaml, 138 00:06:56,810 --> 00:06:59,203 and that will create this service. 139 00:07:00,290 --> 00:07:02,600 And now, with a created here 140 00:07:02,600 --> 00:07:06,150 in the mini cube world, in order to get access to it 141 00:07:06,150 --> 00:07:09,990 we need to run minikube service and then our service name 142 00:07:09,990 --> 00:07:13,340 which in my case is users service. 143 00:07:13,340 --> 00:07:16,360 Of course, you won't need to do that if you deploy 144 00:07:16,360 --> 00:07:17,800 to some Cloud provider 145 00:07:17,800 --> 00:07:20,790 there you will automatically get an IP address 146 00:07:20,790 --> 00:07:22,320 for the load balancer 147 00:07:22,320 --> 00:07:24,570 which is created on the Cloud provider, 148 00:07:24,570 --> 00:07:27,120 since we're in the minikube development setup though, 149 00:07:27,120 --> 00:07:29,560 that will not happen and instead minikube 150 00:07:29,560 --> 00:07:32,680 gives us a dynamically generated IP address 151 00:07:32,680 --> 00:07:34,360 by running minikube service, 152 00:07:34,360 --> 00:07:35,723 and then the service name. 153 00:07:37,070 --> 00:07:38,770 It should open up into browser 154 00:07:38,770 --> 00:07:40,520 though we don't need it there 155 00:07:40,520 --> 00:07:43,660 but make sure you grab this URL here, 156 00:07:43,660 --> 00:07:45,263 and then let's give this a try. 157 00:07:46,650 --> 00:07:48,750 You can use this instead of localized ADHT 158 00:07:50,050 --> 00:07:52,350 use the URL you just got 159 00:07:52,350 --> 00:07:55,900 and try sending a post log-in request there 160 00:07:55,900 --> 00:07:59,030 with a body's set to raw Json, 161 00:07:59,030 --> 00:08:02,290 and then some data between curly braces, 162 00:08:02,290 --> 00:08:04,980 like an email of any value of your choice 163 00:08:04,980 --> 00:08:07,763 and a password of any value of your choice. 164 00:08:09,270 --> 00:08:11,200 Make sure you wrap your keys 165 00:08:11,200 --> 00:08:13,530 and your values between double quotes 166 00:08:13,530 --> 00:08:16,590 and that you have a colon between the key value pairs, 167 00:08:16,590 --> 00:08:19,743 and a comma after the first key value pair. 168 00:08:20,630 --> 00:08:24,340 Then if you click send, you should get back a token. 169 00:08:24,340 --> 00:08:27,190 And if you, for example omits D password 170 00:08:27,190 --> 00:08:30,720 and send, you should get back an error. 171 00:08:30,720 --> 00:08:32,169 If you admit it to comma, 172 00:08:32,169 --> 00:08:34,482 you always get back a better error. 173 00:08:36,100 --> 00:08:41,100 And if I add the password again, that all works. 174 00:08:42,110 --> 00:08:46,633 Now, if we try signing up by replacing log in with sign up, 175 00:08:48,420 --> 00:08:51,270 we get back user created when we send that email 176 00:08:51,270 --> 00:08:52,173 and a password. 177 00:08:53,080 --> 00:08:54,420 So, that is working 178 00:08:54,420 --> 00:08:57,430 and that proves that our application 179 00:08:57,430 --> 00:09:00,950 or our first container here is up and running. 180 00:09:00,950 --> 00:09:03,850 Of course, they'll that was nothing new except 181 00:09:03,850 --> 00:09:06,070 for the extra information about the type 182 00:09:06,070 --> 00:09:08,590 and the load balancing I guess. 183 00:09:08,590 --> 00:09:10,310 But it is crucial to understand 184 00:09:10,310 --> 00:09:12,930 that services are a key object 185 00:09:12,930 --> 00:09:15,410 a key resource when we are talking 186 00:09:15,410 --> 00:09:20,410 about networking on kubernetes and about handling requests. 187 00:09:21,020 --> 00:09:23,910 Now however, let's move on to the next step 188 00:09:23,910 --> 00:09:25,150 and let's make sure 189 00:09:25,150 --> 00:09:28,790 that we can enable this pod internal communication 190 00:09:28,790 --> 00:09:30,710 between the users API, 191 00:09:30,710 --> 00:09:32,240 the user of this container 192 00:09:32,240 --> 00:09:36,043 and the Auth API, this auth container therefore.