1 00:00:01,260 --> 00:00:03,420 Hello and welcome to this lecture. 2 00:00:03,420 --> 00:00:11,640 My name is Mumshad Mannambeth. In this lecture we will discuss about Kubernetes Services. Kubernetes 3 00:00:11,660 --> 00:00:19,130 Services enable communication between various components within and outside of the application. Kubernetes 4 00:00:19,230 --> 00:00:26,380 services helps us connect applications together with other applications or users. 5 00:00:26,380 --> 00:00:33,250 For example our application has groups of pods running various sections such as a group for serving 6 00:00:33,360 --> 00:00:39,730 front end load to users and other group for running back end processes and a third group connecting 7 00:00:39,730 --> 00:00:42,250 to an external data source. 8 00:00:42,250 --> 00:00:49,840 It is services that enable connectivity between these groups of pods services enable the front end 9 00:00:49,900 --> 00:00:57,160 application to be made available to end users it helps communication between back end and front end 10 00:00:57,160 --> 00:01:02,710 pods and helps in establishing connectivity to an external data source. 11 00:01:02,920 --> 00:01:12,970 Thus services enable loose coupling between micro services in our application let's take a look at one 12 00:01:12,970 --> 00:01:14,890 use case of services. 13 00:01:14,890 --> 00:01:20,500 So far we talked about how pods communicate with each other through internal networking. 14 00:01:20,500 --> 00:01:23,070 Let's look at some other aspects of networking. 15 00:01:23,080 --> 00:01:26,890 In this lecture let's start with external communication. 16 00:01:27,550 --> 00:01:32,680 So we deployed our pod having a web application running on it. 17 00:01:32,680 --> 00:01:40,550 How do we as an external user access the web page first of all let us look at the existing setup. 18 00:01:40,690 --> 00:01:48,190 The Kubernetes Node has an IP address and that is 192.168.1.2. My laptop is 19 00:01:48,190 --> 00:01:49,830 on the same network as well. 20 00:01:49,960 --> 00:01:55,530 so it has an IP address 192.168.1.10. 21 00:01:55,720 --> 00:01:58,270 The internal POD network is in the range 22 00:01:58,310 --> 00:02:06,850 10.244.0.0 and the POD has an IP 10.244.0.2. 23 00:02:06,970 --> 00:02:16,220 Clearly, I cannot ping or access the POD at address 10.244.0.2 as its in a separate network. 24 00:02:16,780 --> 00:02:21,730 So what are the options to see the webpage? First, 25 00:02:21,800 --> 00:02:29,840 if we were to SSH into the kubernetes node at 192.168.1.2, from the node, we would 26 00:02:29,840 --> 00: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 27 00:02:37,880 --> 00:02:47,850 and see the webpage in a browser following the address http://10.244.0.2. But this is from inside 28 00:02:47,850 --> 00:02:54,570 the kubernetes Node and that’s not what I really want. I want to be able to access the web server 29 00:02:54,660 --> 00:03:01,900 from my own laptop without having to SSH into the node and simply by accessing the IP of the kubernetes 30 00:03:01,920 --> 00:03:02,300 node. 31 00:03:03,180 --> 00:03:10,260 So we need something in the middle to help us map requests to the node from our laptop through the node 32 00:03:10,320 --> 00:03:13,170 to the POD running the web container. 33 00:03:14,210 --> 00:03:18,060 This is where the kubernetes service comes into play. 34 00:03:18,230 --> 00:03:25,010 The kubernetes service is an object just like PODs, Replicasetor Deployments that we worked with 35 00:03:25,010 --> 00:03:25,990 before. 36 00:03:26,120 --> 00: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 37 00:03:33,410 --> 00:03:36,710 on the POD running the web application. 38 00:03:36,770 --> 00:03:43,940 This type of service is known as a NodePortservice because the service listens to a port on the Node 39 00:03:44,030 --> 00:03:46,830 and forwards requests to PODs. 40 00:03:46,850 --> 00:03:52,820 There are other kinds of services available which we will now discuss. 41 00:03:52,850 --> 00:03:55,850 The first one is what we discussed already. 42 00:03:55,850 --> 00:04:02,730 NodePortwere the service makes an internal POD accessible on a Port on the Node. 43 00:04:02,760 --> 00:04:04,940 The second is cluster IP. 44 00:04:05,310 --> 00:04:12,300 And in this case the service creates a virtual IP inside the cluster to enable communication between 45 00:04:12,330 --> 00:04:18,360 different services such as a set of front end servers to a set of back end servers. 46 00:04:18,390 --> 00:04:25,470 The third type is a LoadBalancer, were it provisions a load balancer for our service in supported cloud 47 00:04:25,470 --> 00:04:26,760 providers. 48 00:04:26,760 --> 00:04:32,670 A good example of that would be to distribute load across the different web servers in your front end 49 00:04:32,670 --> 00:04:34,020 tier. 50 00:04:34,020 --> 00:04:38,550 We will now look at each of these in a bit more detail along with some demos. 51 00:04:38,880 --> 00:04:47,280 In this lecture we will discuss about the NodePortKubernetes Service.Getting back to NodePort, 52 00:04:47,310 --> 00:04:48,560 Few slides back. 53 00:04:48,570 --> 00:04:52,700 We discussed about external access to the application. 54 00:04:52,770 --> 00: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 55 00:05:02,590 --> 00:05:05,080 closer look at the service. 56 00:05:05,080 --> 00:05:08,640 If you look at it there are three ports involved. 57 00:05:08,800 --> 00: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 58 00:05:17,110 --> 00:05:25,540 because that is were the service forwards the requests to. The second port is the port on the service 59 00:05:25,570 --> 00:05:29,850 itself it is simply referred to as the port. 60 00:05:29,880 --> 00:05:34,570 Remember these terms are from the viewpoint of the service. 61 00:05:34,680 --> 00:05:41,250 The service is in fact like a virtual server inside the node inside the cluster. 62 00:05:41,310 --> 00:05:48,880 It has its own IP address and that IP address is called the cluster IP of the service. 63 00:05:48,990 --> 00:05:56,250 And finally we have the port on the node itself which we use to access the web server externally and 64 00:05:56,250 --> 00:05:59,020 that is known as the node port. 65 00:05:59,130 --> 00:06:03,490 As you can see it is 30008. 66 00:06:03,660 --> 00:06:12,330 That is because NodePorts can only be in a valid range which by default is from 30000 to 67 00:06:12,330 --> 00:06:15,640 32767. 68 00:06:17,760 --> 00:06:20,450 Lets now look at how to create the service. 69 00:06:20,730 --> 00:06:27,270 Just like how we created a Deployment, ReplicaSet or Pod, in the past we will use a definition file 70 00:06:27,270 --> 00:06:33,750 to create a service the high level structure of the file remains the same as before we have the API 71 00:06:33,750 --> 00:06:35,340 version kind 72 00:06:35,340 --> 00:06:41,220 Metadata and specs sections the API version is going to be V1. 73 00:06:41,520 --> 00:06:48,560 The kind is of course service the metadata will have a name and that will be the name of the service. 74 00:06:48,570 --> 00:06:52,330 It can have labels but we don't need that for now. 75 00:06:52,350 --> 00: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 76 00:06:58,650 --> 00:07:01,740 be defining the actual services. 77 00:07:01,740 --> 00:07:07,660 And this is the part of a definition file that differs between different objects. 78 00:07:07,680 --> 00: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 79 00:07:15,240 --> 00:07:17,420 defining the actual services. 80 00:07:17,640 --> 00:07:24,390 And this is the part of a definition file that differs between different objects in the spec section 81 00:07:24,390 --> 00:07:25,150 of a service. 82 00:07:25,170 --> 00:07:31,830 We have type and ports the type refers to the type of service we are creating. 83 00:07:31,830 --> 00:07:37,590 As discussed before it could be cluster IP node port or load balancer. 84 00:07:37,710 --> 00:07:42,910 In this case since we are creating a node port we will set it has nodeport. 85 00:07:43,680 --> 00:07:46,780 The next part of a spec is ports. 86 00:07:46,800 --> 00:07:51,900 This is where we input information regarding what we discussed on the left side of the screen. 87 00:07:53,250 --> 00: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 88 00:08:02,640 --> 00:08:09,700 is a port on the service object and we will set that to 80 as well. 89 00:08:09,700 --> 00:08:18,400 The third is NodePort which we will set to 30008 or any number in the valid range. 90 00:08:18,400 --> 00:08:27,620 Remember that out of these the only mandatory field is port if we don't provide a target port. 91 00:08:27,630 --> 00:08:30,870 It is assumed to be the same as port. 92 00:08:30,930 --> 00:08:36,990 and if you don’t provide a nodePort a free port in the valid range between 30000 and 93 00:08:36,990 --> 00:08:45,040 32767 is automatically allocated. Also note that ports is an array. 94 00:08:45,100 --> 00:08:50,110 So no the dash under the port section that indicate the first element 95 00:08:50,110 --> 00:08:58,100 in the array. You can have multiple such port mappings within a single service. So we have all the information 96 00:08:58,160 --> 00:08:58,510 in 97 00:08:58,550 --> 00:09:01,130 but something is really missing. 98 00:09:01,160 --> 00:09:07,040 There is nothing here in the definition file that connects the service to the pod. 99 00:09:07,820 --> 00:09:14,580 We have simply specified the target port but we didn't mention the target port on which pod. 100 00:09:14,720 --> 00:09:19,740 There could be 100s of other PODs with web services running on port 80. 101 00:09:19,820 --> 00:09:24,190 So how do we do that as we did with the replica sets previously. 102 00:09:24,230 --> 00:09:30,590 and a technique that you will see very often in kubernetes, we will use labels and selectors to link 103 00:09:30,620 --> 00:09:32,020 these together. 104 00:09:32,120 --> 00:09:35,530 We know that the POD was created with a label. 105 00:09:35,660 --> 00:09:43,420 We need to bring that label into the service definition file so we have a new property in the spec section 106 00:09:43,510 --> 00:09:45,640 and that is called selector. 107 00:09:45,640 --> 00:09:53,650 Just like in a replica set and deployment definition files under the selector provide a list of labels 108 00:09:53,650 --> 00:09:56,640 to identify the pod for this. 109 00:09:56,640 --> 00:10:00,760 Refer to the pod definition file used to create the pod. 110 00:10:01,050 --> 00:10:05,880 Pull the labels from the pod definition file and place it under the selector section. 111 00:10:07,050 --> 00:10:09,740 This links the service to the pod. 112 00:10:10,110 --> 00:10:16,950 Once done create the service using the kubectlcreate command and input the service-definition file 113 00:10:17,130 --> 00:10:23,610 and there you have the service created. To see the created service, run the kubectlget services 114 00:10:23,610 --> 00:10:28,210 command that list the service the cluster IP and the map port. 115 00:10:28,430 --> 00:10:35,790 The type is node port as we created and the port on the node is set to 30008 because 116 00:10:35,790 --> 00:10:39,550 that's the port that we specified in the definition file. 117 00:10:39,840 --> 00:10:45,450 We can now use this port to access the web service using curl or a web browser. 118 00:10:45,450 --> 00:10:54,180 So curl to 192.168.1.2 which is the IP of the node and then use the port 30008 119 00:10:54,360 --> 00:11:01,520 to access the web server so far we talked about a service mapped to a single pod. 120 00:11:01,740 --> 00:11:04,230 But that's not the case all the time. 121 00:11:04,230 --> 00:11:08,500 what do you do when you have multiple PODs? In a production environment 122 00:11:08,520 --> 00:11:14,430 You have multiple instances of your web application running for high availability and load balancing 123 00:11:14,430 --> 00:11:16,570 purposes in this case. 124 00:11:16,590 --> 00:11:23,830 We have multiple similar pods running our web application they all have the same labels with a key 125 00:11:23,920 --> 00: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. 126 00:11:33,790 --> 00:11:41,850 So when the service is created it looks for a matching pod with the label and finds three of them. 127 00:11:42,250 --> 00:11:49,270 The service then automatically selects all the three pods as endpoints to forward the external requests 128 00:11:49,330 --> 00:11:52,480 coming from the user. 129 00:11:52,500 --> 00:11:57,140 You don't have to do any additional configuration to make this happen. 130 00:11:57,630 --> 00:12:03,360 And if you're wondering what algorithm it uses to balance the load across the three different pods 131 00:12:03,960 --> 00:12:12,450 it uses a random algorithm does the service acts as a built in load balancer to distribute load across 132 00:12:12,450 --> 00:12:21,280 different pods and finally let us look at what happens when the pods are distributed across multiple 133 00:12:21,280 --> 00:12:22,350 nodes. 134 00:12:22,420 --> 00:12:28,310 In this case we have the web application on pods on separate nodes in the cluster. 135 00:12:28,420 --> 00:12:36,220 When we create a service without us having to do any additional configuration kubernetes automatically 136 00:12:36,220 --> 00:12:43,300 creates a service that spans across all the nodes in the cluster and maps the target port to the same 137 00:12:43,390 --> 00:12:52,050 node port on all the nodes in the cluster this way you can access your application using the IP of any 138 00:12:52,050 --> 00:13:00,160 node in the cluster and using the same port number which in this case is 30008 as you 139 00:13:00,160 --> 00:13:03,750 can see using the IP of any of these nodes. 140 00:13:03,790 --> 00: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 141 00:13:10,360 --> 00:13:12,070 the cluster. 142 00:13:12,140 --> 00:13:19,670 To summarize in any case whether it be a single pod on a single node multiple pods on a single node 143 00:13:19,730 --> 00:13:27,080 or multiple pods on multiple nodes the service is created exactly the same without you having to do 144 00:13:27,080 --> 00:13:32,980 any additional steps during the service creation when pods are removed or added. 145 00:13:33,020 --> 00:13:40,220 The service is automatically updated making its highly flexible and adaptive once created. 146 00:13:40,260 --> 00:13:47,990 You won't typically have to make any additional configuration changes that's it for this lecture and 147 00:13:47,990 --> 00:13:49,840 I will see you in the next lecture.