WEBVTT 00:05.870 --> 00:12.650 Hello and welcome to this lecture, in this lecture, we will discuss about coordinative services. 00:14.540 --> 00:21.020 Added services enable communication between various components within and outside of the application 00:21.680 --> 00:28.820 covid-19 services helps us connect applications together with other applications or users. 00:29.390 --> 00:36.320 For example, our application has groups of parties running various sections, such as a group for serving 00:36.590 --> 00:42.830 front end load to users and other groups for running back and processes, and a third group connecting 00:42.830 --> 00:44.480 to an external data source. 00:45.230 --> 00:50.240 It is services that enable connectivity between these groups of parts. 00:50.960 --> 00:56.400 Services enabled the front end application to be made available to end users. 00:56.840 --> 01:03.680 It helps communication between backend and front end parts and helps in establishing connectivity to 01:03.680 --> 01:05.270 an external data source. 01:05.900 --> 01:12.110 Thus, services enable loose coupling between micro services in our application. 01:14.460 --> 01:21.360 Let's take a look at one use case of services so far, we talked about how pilots communicate with each 01:21.360 --> 01:23.130 other through internal networking. 01:23.490 --> 01:26.940 Let's look at some other aspects of networking in this lecture. 01:27.720 --> 01:29.990 Let's start with external communication. 01:30.570 --> 01:35.160 So we deployed our pod, having a Web application running on it. 01:35.700 --> 01:39.810 How do we as an external user access the Web page? 01:40.620 --> 01:44.280 First of all, let's look at the existing set up, the Khubani. 01:44.280 --> 01:52.850 This node has an IP address and that is 192 DOT 168 to my laptop is on the same network as well. 01:52.950 --> 01:57.810 So it has an IP address, 190 to 168 dot one or 10. 01:58.680 --> 02:07.830 The internal pod network is in the range 10 to 4.0 dot zero and the part has an IP tendered 240 for 02:07.900 --> 02:09.100 the two. 02:10.020 --> 02:19.200 Clearly I cannot ping or access the pod at address 10 to 40, 4.0 to as it's in a separate network. 02:19.770 --> 02:22.200 So what are the options to see the Web page? 02:23.940 --> 02:31.890 First, if we were to SSX into the Covenant, it now at 192, that was sixty eight to one or two from 02:31.890 --> 02:37.260 the node, we would be able to access the parts web page by doing a call. 02:37.290 --> 02:43.860 Or if the node has a DUI, we would fire up a browser and see the web page in a browser following the 02:43.860 --> 02:44.370 address. 02:44.370 --> 02:48.060 ETP Tanda 240 4.0 dot to. 02:49.100 --> 02:53.600 But this is from inside the cabin is no, and that's not what I really want. 02:54.550 --> 03:02.260 I want to be able to access the Web server from my own laptop without having to SSX into the node and 03:02.260 --> 03:05.360 simply by accessing the IP of the Cuban editor's note. 03:06.160 --> 03:13.330 So we need something in the middle to help us map requests to the node from our laptop through the node 03:13.360 --> 03:16.030 to the port running the web container. 03:17.230 --> 03:25.300 This is where the coroner's service comes into play, the coroner's service is an object just like part 03:25.300 --> 03:28.600 replica set or deployments that we worked with before. 03:29.110 --> 03:36.370 One of its use case is to listen to a report on the note and forward request on that port to a port 03:36.400 --> 03:38.890 on the port running the Web application. 03:39.770 --> 03:47.050 This type of service is known as a known port service because the service listens to a port on the node 03:47.050 --> 03:48.550 and forward request to the. 03:49.840 --> 03:53.680 There are other kinds of services available which we will now discuss. 03:55.830 --> 04:03.090 The first one is what we discussed already know port, where the service makes an internal port accessible 04:03.090 --> 04:04.680 on a port on the node. 04:05.730 --> 04:14.130 The second is close IP, and in this case, the service creates a virtual IP inside the cluster to enable 04:14.130 --> 04:20.430 communication between different services, such as a set of front end servers to a set of backend servers. 04:21.400 --> 04:28.110 The third type is a load balancer where it positions a load balancer for our application in supported 04:28.120 --> 04:29.230 cloud providers. 04:29.740 --> 04:35.730 A good example of that would be to distribute load across the different Web servers in your front and 04:35.740 --> 04:36.160 tier. 04:36.970 --> 04:41.020 We will now look at each of these in a bit more detail, along with some demos. 04:41.830 --> 04:46.300 In this lecture, we will discuss about the node, Port Khubani, the service. 04:48.050 --> 04:55.070 Getting back to Northport, few slides back, we discussed about external access to the application. 04:55.790 --> 05:02.630 We said that a service can help us by mapping a port on the node to a port on the part. 05:05.100 --> 05:11.160 Let's take a closer look at the service, if you look at it, there are three ports involved. 05:11.790 --> 05:20.190 The port on the part where the actual Web server is running is 18 and it is referred to as the target 05:20.190 --> 05:26.910 port because that is where the service forwards the request to the second port. 05:26.910 --> 05:29.240 Is the port on the service itself. 05:30.120 --> 05:36.880 It is simply referred to as the port, remember, these terms are from the viewpoint of the service. 05:37.680 --> 05:44.010 The service is, in fact like a virtual server, inside the node, inside the cluster. 05:44.250 --> 05:46.290 It has its own IP address. 05:46.290 --> 05:51.070 And that IP address is called the cluster IP of the service. 05:51.930 --> 05:58.740 And finally, we have the port on the node itself, which we use to access the Web server externally, 05:59.010 --> 06:01.530 and that is known as the node port. 06:02.070 --> 06:05.810 As you can see, it is said thirty thousand eight. 06:06.660 --> 06:15.390 That is because node ports can only be in a valid range, which by default is from thirty thousand to 06:15.390 --> 06:18.540 thirty two thousand seven hundred and sixty seven. 06:20.740 --> 06:27.220 Let's now look at how to create the service, just like how we created a deployment replica set or pod 06:27.220 --> 06:27.970 in the past. 06:28.350 --> 06:31.420 We will use a definition file to create a service. 06:32.330 --> 06:35.820 The high level structure of the file remains the same as before. 06:35.830 --> 06:40.540 We have the API version, kind metadata and spec sections. 06:41.260 --> 06:43.780 The API version is going to be the one. 06:44.560 --> 06:46.840 The kind is, of course, service. 06:47.560 --> 06:51.540 The metadata will have a name and that will be the name of the service. 06:51.550 --> 06:54.490 It can have labels, but we don't need that for now. 06:55.390 --> 06:57.070 Next we have spek. 06:57.070 --> 07:04.240 And as always, this is the most crucial part of the file as this is where we will be defining the actual 07:04.240 --> 07:04.980 services. 07:05.290 --> 07:10.390 And this is the part of a definition file that differs between different objects. 07:11.080 --> 07:12.930 In the spec section of a service. 07:12.940 --> 07:15.250 We have type and ports. 07:15.940 --> 07:19.270 The type refers to the type of service we are creating. 07:19.480 --> 07:24.850 As discussed before, it could be cluster IP node port or load balancer. 07:25.390 --> 07:30.640 In this case, since we are creating a node port, we will sell it as node port. 07:31.390 --> 07:33.920 The next part of espec is ports. 07:34.520 --> 07:39.700 This is where we input information regarding what we discussed on the left side of the screen. 07:40.970 --> 07:45.230 The first type of port is the target port, which we will set to 80. 07:46.590 --> 07:54.990 The next one is simply port, which is a port on the service object, and we will set that to 80 as 07:54.990 --> 07:55.310 well. 07:57.420 --> 08:06.810 The third is North Port, which we will send to 30000 aid or any number in the valid range, remember 08:06.810 --> 08:11.100 that out of this, the only mandatory field is port. 08:12.320 --> 08:19.880 If you don't provide a target port, it is assumed to be the same as port, and if you don't provide 08:19.880 --> 08:27.170 a known port, every port in the valid range between thirty thousand and thirty two thousand 767 is 08:27.170 --> 08:28.790 automatically allocated. 08:29.880 --> 08:37.890 Also note that sports is an array, so not a dash under the sports section that indicate the first element 08:37.890 --> 08:38.530 in the area. 08:38.940 --> 08:43.170 You can have multiple such sport mappings within a single service. 08:44.190 --> 08:51.360 So we have all the information in, but something is really missing, there is nothing here in the definition 08:51.360 --> 08:54.750 filed that connects the service to the pod. 08:55.530 --> 09:02.700 We have simply specified the target board, but we didn't mention the target board on which pod there 09:02.700 --> 09:07.390 could be hundreds of other pods with Web services running on Port 80. 09:07.500 --> 09:13.500 So how do we do that, as we did with the replica sets previously and a technique that you will see 09:13.500 --> 09:15.300 very often in communities? 09:15.780 --> 09:19.210 We will use labels and selectors to link these together. 09:19.830 --> 09:22.730 We know that the pod was created with a label. 09:23.370 --> 09:27.240 We need to bring that label into the service definition file. 09:28.790 --> 09:34.970 So we have a new property in the specs section, and that is called Selecter, just like in a replica 09:34.970 --> 09:42.890 set and deployment definition filed under The Selecter, provide a list of labels to identify the part. 09:43.790 --> 09:51.050 For this referred to the pod definition file used to create the pod, pull the labels from the pod definition 09:51.050 --> 09:53.660 file and place it under the selector section. 09:54.760 --> 10:01.570 This links the service to the past, once done, create the service using the cube control, create 10:01.570 --> 10:04.790 command and input the service definition file. 10:04.810 --> 10:11.410 And there you have the service created to see the created service, run the cube control, get services, 10:11.410 --> 10:15.520 command that list the service, the cluster IP and the map ports. 10:16.120 --> 10:23.590 The type is node port as we created and the port on the node is set to three thousand eight because 10:23.590 --> 10:26.850 that's the port that we specified in the definition file. 10:27.550 --> 10:35.680 We can now use this port to access the Web service using Kerl or a Web browser so called to 190 to 168 10:35.680 --> 10:38.830 Wando to, which is the IP of the node. 10:39.190 --> 10:43.600 And then I use the port thirty thousand eight to access the web server. 10:44.710 --> 10:51.490 So far, we talked about a service mapped to a single pod, but that's not the case all the time. 10:51.940 --> 10:56.280 What do you do when you have multiple pods in a production environment? 10:56.290 --> 11:02.230 You have multiple instances of your Web application running for high availability and load balancing 11:02.230 --> 11:02.860 purposes. 11:03.520 --> 11:08.170 In this case, we have multiple similar pods running our Web application. 11:09.150 --> 11:17.460 They all have the same labels with a key app and said to a value of my app, the same label is used 11:17.460 --> 11:20.650 as a selector during the creation of the service. 11:21.510 --> 11:29.040 So when the service is created, it looks for a matching pod with the label and finds three of them. 11:29.940 --> 11:37.080 The service then automatically selects all the three parts as endpoints to forward the external request 11:37.080 --> 11:38.310 coming from the user. 11:40.180 --> 11:46.600 You don't have to do any additional configuration to make this happen, and if you're wondering what 11:46.600 --> 11:53.860 algorithm it uses to balance the load across the three different parts, it uses a random algorithm. 11:54.790 --> 12:01.240 Does the service acts as a built in load balancer to distribute load across different parts? 12:03.770 --> 12:10.520 And finally, let's look at what happens when the polls are distributed across multiple nodes in this 12:10.520 --> 12:15.610 case, we have the Web application on Pardes, on separate nodes in the cluster. 12:16.130 --> 12:23.990 When we create a service without us having to do any additional configuration, Cuban errors automatically 12:23.990 --> 12:31.130 creates a service that spans across all the nodes in the cluster and maps the target port to the same 12:31.130 --> 12:34.070 node port on all the nodes in the cluster. 12:35.080 --> 12:42.400 This way, you can access your application using the IP of any node in the cluster and using the same 12:42.400 --> 12:46.360 port number, which in this case is thirty thousand eight. 12:47.590 --> 12:54.580 As you can see, using the IP of any of these nodes, and I'm trying to call to the same port and the 12:54.580 --> 12:58.810 same port is made available on all the nodes, part of the cluster. 12:59.880 --> 13:07.110 To summarize, in any case, whether it be a single pot on a single node, multiple parts on a single 13:07.110 --> 13:14.490 node or multiple paths on multiple nodes, the service is created exactly the same without you having 13:14.490 --> 13:17.700 to do any additional steps during the service creation. 13:18.390 --> 13:25.380 When parts are removed or added, the service is automatically updated, making it highly flexible and 13:25.380 --> 13:26.010 adaptive. 13:26.840 --> 13:32.540 Once created, you won't typically have to make any additional configuration changes. 13:34.200 --> 13:35.550 That's it for this lecture. 13:35.820 --> 13:39.090 Head over to the demo and I will see you in the next lecture.