WEBVTT 00:01.260 --> 00:03.420 Hello and welcome to this lecture. 00:03.420 --> 00:11.640 My name is Mumshad Mannambeth. In this lecture we will discuss about Kubernetes Services. Kubernetes 00:11.660 --> 00:19.130 Services enable communication between various components within and outside of the application. Kubernetes 00:19.230 --> 00:26.380 services helps us connect applications together with other applications or users. 00:26.380 --> 00:33.250 For example our application has groups of pods running various sections such as a group for serving 00:33.360 --> 00:39.730 front end load to users and other group for running back end processes and a third group connecting 00:39.730 --> 00:42.250 to an external data source. 00:42.250 --> 00:49.840 It is services that enable connectivity between these groups of pods services enable the front end 00:49.900 --> 00:57.160 application to be made available to end users it helps communication between back end and front end 00:57.160 --> 01:02.710 pods and helps in establishing connectivity to an external data source. 01:02.920 --> 01:12.970 Thus services enable loose coupling between micro services in our application let's take a look at one 01:12.970 --> 01:14.890 use case of services. 01:14.890 --> 01:20.500 So far we talked about how pods communicate with each other through internal networking. 01:20.500 --> 01:23.070 Let's look at some other aspects of networking. 01:23.080 --> 01:26.890 In this lecture let's start with external communication. 01:27.550 --> 01:32.680 So we deployed our pod having a web application running on it. 01:32.680 --> 01:40.550 How do we as an external user access the web page first of all let us look at the existing setup. 01:40.690 --> 01:48.190 The Kubernetes Node has an IP address and that is 192.168.1.2. My laptop is 01:48.190 --> 01:49.830 on the same network as well. 01:49.960 --> 01:55.530 so it has an IP address 192.168.1.10. 01:55.720 --> 01:58.270 The internal POD network is in the range 01:58.310 --> 02:06.850 10.244.0.0 and the POD has an IP 10.244.0.2. 02:06.970 --> 02:16.220 Clearly, I cannot ping or access the POD at address 10.244.0.2 as its in a separate network. 02:16.780 --> 02:21.730 So what are the options to see the webpage? First, 02:21.800 --> 02:29.840 if we were to SSH into the kubernetes node at 192.168.1.2, from the node, we would 02:29.840 --> 02:37.790 be able to access the POD’s webpage by doing a curl or if the node has a GUI, we could fire up a browser 02:37.880 --> 02:47.850 and see the webpage in a browser following the address http://10.244.0.2. But this is from inside 02:47.850 --> 02:54.570 the kubernetes Node and that’s not what I really want. I want to be able to access the web server 02:54.660 --> 03:01.900 from my own laptop without having to SSH into the node and simply by accessing the IP of the kubernetes 03:01.920 --> 03:02.300 node. 03:03.180 --> 03:10.260 So we need something in the middle to help us map requests to the node from our laptop through the node 03:10.320 --> 03:13.170 to the POD running the web container. 03:14.210 --> 03:18.060 This is where the kubernetes service comes into play. 03:18.230 --> 03:25.010 The kubernetes service is an object just like PODs, Replicasetor Deployments that we worked with 03:25.010 --> 03:25.990 before. 03:26.120 --> 03:33.290 One of its use case is to listen to a port on the Node and forward requests on that port to a port 03:33.410 --> 03:36.710 on the POD running the web application. 03:36.770 --> 03:43.940 This type of service is known as a NodePortservice because the service listens to a port on the Node 03:44.030 --> 03:46.830 and forwards requests to PODs. 03:46.850 --> 03:52.820 There are other kinds of services available which we will now discuss. 03:52.850 --> 03:55.850 The first one is what we discussed already. 03:55.850 --> 04:02.730 NodePortwere the service makes an internal POD accessible on a Port on the Node. 04:02.760 --> 04:04.940 The second is cluster IP. 04:05.310 --> 04:12.300 And in this case the service creates a virtual IP inside the cluster to enable communication between 04:12.330 --> 04:18.360 different services such as a set of front end servers to a set of back end servers. 04:18.390 --> 04:25.470 The third type is a LoadBalancer, were it provisions a load balancer for our service in supported cloud 04:25.470 --> 04:26.760 providers. 04:26.760 --> 04:32.670 A good example of that would be to distribute load across the different web servers in your front end 04:32.670 --> 04:34.020 tier. 04:34.020 --> 04:38.550 We will now look at each of these in a bit more detail along with some demos. 04:38.880 --> 04:47.280 In this lecture we will discuss about the NodePortKubernetes Service.Getting back to NodePort, 04:47.310 --> 04:48.560 Few slides back. 04:48.570 --> 04:52.700 We discussed about external access to the application. 04:52.770 --> 05:02.590 We said that a Service can help us by mapping a port on the Node to a port on the POD. Let’s take a 05:02.590 --> 05:05.080 closer look at the service. 05:05.080 --> 05:08.640 If you look at it there are three ports involved. 05:08.800 --> 05:17.110 The port on the POD were the actual web server is running is 80. And it is referred to as the targetPort 05:17.110 --> 05:25.540 because that is were the service forwards the requests to. The second port is the port on the service 05:25.570 --> 05:29.850 itself it is simply referred to as the port. 05:29.880 --> 05:34.570 Remember these terms are from the viewpoint of the service. 05:34.680 --> 05:41.250 The service is in fact like a virtual server inside the node inside the cluster. 05:41.310 --> 05:48.880 It has its own IP address and that IP address is called the cluster IP of the service. 05:48.990 --> 05:56.250 And finally we have the port on the node itself which we use to access the web server externally and 05:56.250 --> 05:59.020 that is known as the node port. 05:59.130 --> 06:03.490 As you can see it is 30008. 06:03.660 --> 06:12.330 That is because NodePorts can only be in a valid range which by default is from 30000 to 06:12.330 --> 06:15.640 32767. 06:17.760 --> 06:20.450 Lets now look at how to create the service. 06:20.730 --> 06:27.270 Just like how we created a Deployment, ReplicaSet or Pod, in the past we will use a definition file 06:27.270 --> 06:33.750 to create a service the high level structure of the file remains the same as before we have the API 06:33.750 --> 06:35.340 version kind 06:35.340 --> 06:41.220 Metadata and specs sections the API version is going to be V1. 06:41.520 --> 06:48.560 The kind is of course service the metadata will have a name and that will be the name of the service. 06:48.570 --> 06:52.330 It can have labels but we don't need that for now. 06:52.350 --> 06:58.650 Next we have spec and as always this is the most crucial part of the file and that is where we will 06:58.650 --> 07:01.740 be defining the actual services. 07:01.740 --> 07:07.660 And this is the part of a definition file that differs between different objects. 07:07.680 --> 07:15.240 Next we have spec and as always this is the most crucial part of the file as this is where we will be 07:15.240 --> 07:17.420 defining the actual services. 07:17.640 --> 07:24.390 And this is the part of a definition file that differs between different objects in the spec section 07:24.390 --> 07:25.150 of a service. 07:25.170 --> 07:31.830 We have type and ports the type refers to the type of service we are creating. 07:31.830 --> 07:37.590 As discussed before it could be cluster IP node port or load balancer. 07:37.710 --> 07:42.910 In this case since we are creating a node port we will set it has nodeport. 07:43.680 --> 07:46.780 The next part of a spec is ports. 07:46.800 --> 07:51.900 This is where we input information regarding what we discussed on the left side of the screen. 07:53.250 --> 08:02.640 The first type of port is the target port which we will set to 80 the next one is simply port which 08:02.640 --> 08:09.700 is a port on the service object and we will set that to 80 as well. 08:09.700 --> 08:18.400 The third is NodePort which we will set to 30008 or any number in the valid range. 08:18.400 --> 08:27.620 Remember that out of these the only mandatory field is port if we don't provide a target port. 08:27.630 --> 08:30.870 It is assumed to be the same as port. 08:30.930 --> 08:36.990 and if you don’t provide a nodePort a free port in the valid range between 30000 and 08:36.990 --> 08:45.040 32767 is automatically allocated. Also note that ports is an array. 08:45.100 --> 08:50.110 So no the dash under the port section that indicate the first element 08:50.110 --> 08:58.100 in the array. You can have multiple such port mappings within a single service. So we have all the information 08:58.160 --> 08:58.510 in 08:58.550 --> 09:01.130 but something is really missing. 09:01.160 --> 09:07.040 There is nothing here in the definition file that connects the service to the pod. 09:07.820 --> 09:14.580 We have simply specified the target port but we didn't mention the target port on which pod. 09:14.720 --> 09:19.740 There could be 100s of other PODs with web services running on port 80. 09:19.820 --> 09:24.190 So how do we do that as we did with the replica sets previously. 09:24.230 --> 09:30.590 and a technique that you will see very often in kubernetes, we will use labels and selectors to link 09:30.620 --> 09:32.020 these together. 09:32.120 --> 09:35.530 We know that the POD was created with a label. 09:35.660 --> 09:43.420 We need to bring that label into the service definition file so we have a new property in the spec section 09:43.510 --> 09:45.640 and that is called selector. 09:45.640 --> 09:53.650 Just like in a replica set and deployment definition files under the selector provide a list of labels 09:53.650 --> 09:56.640 to identify the pod for this. 09:56.640 --> 10:00.760 Refer to the pod definition file used to create the pod. 10:01.050 --> 10:05.880 Pull the labels from the pod definition file and place it under the selector section. 10:07.050 --> 10:09.740 This links the service to the pod. 10:10.110 --> 10:16.950 Once done create the service using the kubectlcreate command and input the service-definition file 10:17.130 --> 10:23.610 and there you have the service created. To see the created service, run the kubectlget services 10:23.610 --> 10:28.210 command that list the service the cluster IP and the map port. 10:28.430 --> 10:35.790 The type is node port as we created and the port on the node is set to 30008 because 10:35.790 --> 10:39.550 that's the port that we specified in the definition file. 10:39.840 --> 10:45.450 We can now use this port to access the web service using curl or a web browser. 10:45.450 --> 10:54.180 So curl to 192.168.1.2 which is the IP of the node and then use the port 30008 10:54.360 --> 11:01.520 to access the web server so far we talked about a service mapped to a single pod. 11:01.740 --> 11:04.230 But that's not the case all the time. 11:04.230 --> 11:08.500 what do you do when you have multiple PODs? In a production environment 11:08.520 --> 11:14.430 You have multiple instances of your web application running for high availability and load balancing 11:14.430 --> 11:16.570 purposes in this case. 11:16.590 --> 11:23.830 We have multiple similar pods running our web application they all have the same labels with a key 11:23.920 --> 11:33.670 app and set to a value of my app the same label is used as a selector during the creation of the service. 11:33.790 --> 11:41.850 So when the service is created it looks for a matching pod with the label and finds three of them. 11:42.250 --> 11:49.270 The service then automatically selects all the three pods as endpoints to forward the external requests 11:49.330 --> 11:52.480 coming from the user. 11:52.500 --> 11:57.140 You don't have to do any additional configuration to make this happen. 11:57.630 --> 12:03.360 And if you're wondering what algorithm it uses to balance the load across the three different pods 12:03.960 --> 12:12.450 it uses a random algorithm does the service acts as a built in load balancer to distribute load across 12:12.450 --> 12:21.280 different pods and finally let us look at what happens when the pods are distributed across multiple 12:21.280 --> 12:22.350 nodes. 12:22.420 --> 12:28.310 In this case we have the web application on pods on separate nodes in the cluster. 12:28.420 --> 12:36.220 When we create a service without us having to do any additional configuration kubernetes automatically 12:36.220 --> 12:43.300 creates a service that spans across all the nodes in the cluster and maps the target port to the same 12:43.390 --> 12:52.050 node port on all the nodes in the cluster this way you can access your application using the IP of any 12:52.050 --> 13:00.160 node in the cluster and using the same port number which in this case is 30008 as you 13:00.160 --> 13:03.750 can see using the IP of any of these nodes. 13:03.790 --> 13:10.360 And I'm trying to curl to the same port and the same port is made available on all the nodes part of 13:10.360 --> 13:12.070 the cluster. 13:12.140 --> 13:19.670 To summarize in any case whether it be a single pod on a single node multiple pods on a single node 13:19.730 --> 13:27.080 or multiple pods on multiple nodes the service is created exactly the same without you having to do 13:27.080 --> 13:32.980 any additional steps during the service creation when pods are removed or added. 13:33.020 --> 13:40.220 The service is automatically updated making its highly flexible and adaptive once created. 13:40.260 --> 13:47.990 You won't typically have to make any additional configuration changes that's it for this lecture and 13:47.990 --> 13:49.840 I will see you in the next lecture.