1 00:00:00,710 --> 00:00:03,350 Hello and welcome to this lecture. In this lecture 2 00:00:03,350 --> 00:00:07,850 we will discuss about service networking. In the previous lectures 3 00:00:07,850 --> 00:00:14,330 we talked about POD networking. How bridge networks are created within each node and how PODs get a 4 00:00:14,330 --> 00:00:20,060 namespace created for them and how interfaces are attached to those name spaces and how parts get an 5 00:00:20,120 --> 00:00:24,230 IP address assigned to them within the subnet assigned for that note. 6 00:00:24,350 --> 00:00:30,950 And we also saw through routes or other overlay techniques, we can get the PODs in different nodes to talk 7 00:00:30,950 --> 00:00:36,500 to each other forming a large virtual network where all pods can reach each other. 8 00:00:36,510 --> 00:00:41,390 Now you would rarely configure your pods to communicate directly with each other. 9 00:00:41,480 --> 00:00:48,320 If you want a pod to access services hosted on another pod you would always use a service. 10 00:00:48,320 --> 00:00:54,910 Let's quickly recap the different kinds of services. To make the orange pod accessible to the blue pod, 11 00:00:54,950 --> 00:01:01,010 we create an orange service. The orange service gets an IP address and a name assigned to it. 12 00:01:01,010 --> 00:01:07,420 The blue pod can now access the orange pod through the orange services IP or its name. 13 00:01:07,430 --> 00:01:10,500 We'll talk about name resolution in the upcoming lectures. 14 00:01:10,520 --> 00:01:18,150 For now let's just focus on IP addresses. The blue and orange pod around the same node. 15 00:01:18,200 --> 00:01:20,360 What about access from the other PODs 16 00:01:20,390 --> 00:01:27,650 on other nodes? when a service is created it is accessible from all parts of the cluster, irrespective 17 00:01:27,740 --> 00:01:35,560 of what nodes the pods are on. While a pod is hosted on a node, a service is hosted across the cluster. 18 00:01:35,630 --> 00:01:43,160 It is not bound to a specific node. But remember, the service is only accessible from within the cluster. 19 00:01:43,160 --> 00:01:46,440 This type of service is known as ClusterIP. 20 00:01:46,460 --> 00:01:52,430 If the orange POD was hosting a database application that is to be only accessed from within the cluster, 21 00:01:52,820 --> 00:01:55,430 then this type of service works just fine. 22 00:01:56,420 --> 00:02:02,810 Say for instance the purple pod was hosting a web application. To make the application on the pod accessible 23 00:02:02,870 --> 00:02:04,240 outside the cluster. 24 00:02:04,310 --> 00:02:07,790 we create another service of type NodePort. 25 00:02:07,790 --> 00:02:14,270 This service also gets an IP address assigned to it and works just like ClusterIP. As in all the other 26 00:02:14,270 --> 00:02:17,300 PODs can access this service using it’s IP. 27 00:02:17,390 --> 00:02:25,460 But, in addition it also exposes the application on a port on all nodes in the cluster. That way external 28 00:02:25,460 --> 00:02:28,820 users or applications have access to the service. 29 00:02:29,450 --> 00:02:32,850 So that's the topic of our discussion for this lecture. 30 00:02:32,960 --> 00:02:38,380 Our focus is more on services and less on PODs. 31 00:02:38,420 --> 00:02:44,300 How are the services getting these IP addresses and how are they made available across all the nodes 32 00:02:44,300 --> 00:02:45,440 in the cluster. 33 00:02:45,440 --> 00:02:50,440 How is the service made available to external users through a port on each node. 34 00:02:50,510 --> 00:02:53,540 Who is doing that and how and where do we see it. 35 00:02:53,540 --> 00:02:54,640 So let's get started. 36 00:02:55,160 --> 00:02:56,900 Let's start on a clean slate. 37 00:02:56,930 --> 00:03:01,310 We have a three node cluster, no pods or services yet. 38 00:03:01,370 --> 00:03:08,420 We know that every kubernetes node runs a kubelet process, which is responsible for creating PODs. Each 39 00:03:08,470 --> 00:03:10,690 kubelet service on each node 40 00:03:10,700 --> 00:03:14,360 watches the changes in the cluster through the kube-api server, 41 00:03:14,570 --> 00:03:19,930 and every time a new POD is to be created, it creates the POD on the nodes. 42 00:03:20,330 --> 00:03:24,850 It then invokes the CNI plugin to configure networking for that POD. 43 00:03:24,860 --> 00:03:30,560 Similarly, each node runs another component known as kube-proxy. Kube 44 00:03:30,570 --> 00:03:38,270 proxy watches the changes in the cluster through kube-api server, and every time a new service is to be created, 45 00:03:38,510 --> 00:03:46,480 kube-proxy gets into action. Unlike PODs, services are not created on each node or assigned to each node. 46 00:03:46,520 --> 00:03:48,970 Services are a cluster wide concept. 47 00:03:49,040 --> 00:03:52,310 They exist across all the nodes in the cluster. 48 00:03:52,310 --> 00:03:55,460 As a matter of fact they don't exist at all. 49 00:03:55,520 --> 00:04:01,860 There is no server or service really listening on the IP of the service. We have seen that 50 00:04:01,860 --> 00:04:09,030 PODs have containers and containers have namespaces with interfaces and Ips assigned to those interfaces. 51 00:04:09,270 --> 00:04:10,440 With services 52 00:04:10,440 --> 00:04:12,080 Nothing like that exists. 53 00:04:12,120 --> 00:04:16,010 There are no processes or name spaces or interfaces for a service. 54 00:04:16,500 --> 00:04:18,870 It's just a virtual object. 55 00:04:18,870 --> 00:04:20,640 Then how do they get an IP address 56 00:04:20,670 --> 00:04:26,010 and how were we able to access the application on the pod through service? 57 00:04:26,010 --> 00:04:32,730 When we create a service object in kubernetes, it is assigned an IP address from a pre-defined range. 58 00:04:33,240 --> 00:04:39,450 The kube-proxy components running on each node, get’s that IP address and creates forwarding rules on 59 00:04:39,450 --> 00:04:46,710 each node in the cluster, saying any traffic coming to this IP, the IP of the service, should go to the 60 00:04:46,710 --> 00:04:48,660 IP of the POD. 61 00:04:48,690 --> 00:04:55,680 Once that is in place, whenever a POD tries to reach the IP of the service, it is forwarded to the PODs 62 00:04:55,770 --> 00:05:00,240 IP address which is accessible from any node in the cluster. 63 00:05:00,240 --> 00:05:05,310 Now remember it's not just the IP it's an IP and port combination. 64 00:05:05,310 --> 00:05:11,940 Whenever services are created or deleted the kube-proxy component creates or deletes these rules. 65 00:05:11,940 --> 00:05:18,750 So how are these rules created? kube-proxy supports different ways, such as userspace where kube-proxy 66 00:05:18,750 --> 00:05:25,550 listens on a port for each service and proxies connections to the pods. By creating ipvs rules or 67 00:05:25,560 --> 00:05:32,640 the third and the default option and the one familiar to us is using IP tables. The proxy mode can be 68 00:05:32,640 --> 00:05:37,520 set using the proxy mode option while configuring the kube-proxy service 69 00:05:37,560 --> 00:05:45,000 If this is not set, it defaults to iptables. So we’ll see how iptables are configured by kube-proxy and 70 00:05:45,000 --> 00:05:47,610 how you can view them on the nodes. 71 00:05:47,640 --> 00:05:50,590 We have a pod named db deployed on node-1. 72 00:05:50,640 --> 00:05:57,870 it has IP address 10.244.1.2. We create a service of type ClusterIP to make this pod 73 00:05:57,870 --> 00:06:00,030 available within the cluster. 74 00:06:00,030 --> 00:06:04,890 When the service is created kubernetes assigns an IP address to it. 75 00:06:05,100 --> 00:06:10,210 It is set to 10.103.132.104 76 00:06:10,260 --> 00:06:13,330 This range is specified in the kube-apiservers 77 00:06:13,380 --> 00:06:22,050 option called service-cluster-ip-range. Which is by default set to 10.0.0.0/24. 78 00:06:22,050 --> 00:06:31,020 In my case, if I look at my kube-api-server option. I see it is set to 10.96.0.0/12. 79 00:06:31,230 --> 00:06:42,380 That gives my services IP any where from 10.96.0.0 to 10.111.255.255. A relative 80 00:06:42,390 --> 00:06:44,010 point to mention here. 81 00:06:44,010 --> 00:06:51,960 when I setup my POD networking, I provided a POD network CIDR range of 10.244.0.0/16 82 00:06:52,140 --> 00:07:00,720 which gives my pods IP addresses from 10.244.0.0 to 10.244.255.255. 83 00:07:00,720 --> 00:07:06,030 The reason I brought this up here is because whatever range is specified for each of these networks 84 00:07:06,480 --> 00:07:09,390 it shouldn't overlap which it doesn't 85 00:07:09,390 --> 00:07:16,900 in this case. Both of these should have its own dedicated range of IPs to work with. There shouldn't 86 00:07:16,900 --> 00:07:21,850 be a case where a POD and a service are assigned the same IP address. 87 00:07:21,850 --> 00:07:23,740 So getting back to services. 88 00:07:23,740 --> 00:07:30,480 that’s how my service got an IP address of 10.103.132.104. 89 00:07:30,490 --> 00:07:34,110 You can see the rules created by kube-proxy in the iptables 90 00:07:34,120 --> 00:07:35,650 nat table output. 91 00:07:35,650 --> 00:07:39,740 Search for the name of the service as all rules created by kube-proxy 92 00:07:39,760 --> 00:07:43,050 have a comment with the name of the service on it. 93 00:07:43,060 --> 00:07:51,310 These rules mean, any traffic going to IP address 10.103.132.104 on port 3306 94 00:07:51,490 --> 00:07:57,700 which is the IP of the service, should have its destination address changed to 10.244.1.2 and port 3306 which is the IP of the POD. 95 00:07:57,700 --> 00:08:02,480 which is the IP of the service, should have its destination address changed to 10.244.1.2 and port 3306 which is the IP of the POD. 96 00:08:02,500 --> 00:08:06,760 This is done by adding a DNAT rule to IP tables. 97 00:08:06,760 --> 00:08:13,240 Similarly, when you create services of type NodePort, kube-proxy creates IPTable rules to forward all 98 00:08:13,240 --> 00:08:18,620 traffic coming on a port on all nodes to the respective backend PODs. 99 00:08:18,850 --> 00:08:25,030 You can also see kube-proxy create these entries in the kube-proxy logs itself. In the logs 100 00:08:25,120 --> 00:08:32,080 you will find what proxier it uses, in this case its IP tables and the Add an entry when it added 101 00:08:32,110 --> 00:08:34,840 a new service for the database. 102 00:08:34,840 --> 00:08:38,950 Note that the location of this file might vary depending on your installation. 103 00:08:39,010 --> 00:08:44,830 If you don't see these entries you must also check the verbosity level of the process as well. 104 00:08:45,830 --> 00:08:48,890 Well that's it about service networking. 105 00:08:48,890 --> 00:08:50,540 I will see you in the next lecture.