WEBVTT 00:00.710 --> 00:03.350 Hello and welcome to this lecture. In this lecture 00:03.350 --> 00:07.850 we will discuss about service networking. In the previous lectures 00:07.850 --> 00:14.330 we talked about POD networking. How bridge networks are created within each node and how PODs get a 00:14.330 --> 00:20.060 namespace created for them and how interfaces are attached to those name spaces and how parts get an 00:20.120 --> 00:24.230 IP address assigned to them within the subnet assigned for that note. 00:24.350 --> 00:30.950 And we also saw through routes or other overlay techniques, we can get the PODs in different nodes to talk 00:30.950 --> 00:36.500 to each other forming a large virtual network where all pods can reach each other. 00:36.510 --> 00:41.390 Now you would rarely configure your pods to communicate directly with each other. 00:41.480 --> 00:48.320 If you want a pod to access services hosted on another pod you would always use a service. 00:48.320 --> 00:54.910 Let's quickly recap the different kinds of services. To make the orange pod accessible to the blue pod, 00:54.950 --> 01:01.010 we create an orange service. The orange service gets an IP address and a name assigned to it. 01:01.010 --> 01:07.420 The blue pod can now access the orange pod through the orange services IP or its name. 01:07.430 --> 01:10.500 We'll talk about name resolution in the upcoming lectures. 01:10.520 --> 01:18.150 For now let's just focus on IP addresses. The blue and orange pod around the same node. 01:18.200 --> 01:20.360 What about access from the other PODs 01:20.390 --> 01:27.650 on other nodes? when a service is created it is accessible from all parts of the cluster, irrespective 01:27.740 --> 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. 01:35.630 --> 01:43.160 It is not bound to a specific node. But remember, the service is only accessible from within the cluster. 01:43.160 --> 01:46.440 This type of service is known as ClusterIP. 01:46.460 --> 01:52.430 If the orange POD was hosting a database application that is to be only accessed from within the cluster, 01:52.820 --> 01:55.430 then this type of service works just fine. 01:56.420 --> 02:02.810 Say for instance the purple pod was hosting a web application. To make the application on the pod accessible 02:02.870 --> 02:04.240 outside the cluster. 02:04.310 --> 02:07.790 we create another service of type NodePort. 02:07.790 --> 02:14.270 This service also gets an IP address assigned to it and works just like ClusterIP. As in all the other 02:14.270 --> 02:17.300 PODs can access this service using it’s IP. 02:17.390 --> 02:25.460 But, in addition it also exposes the application on a port on all nodes in the cluster. That way external 02:25.460 --> 02:28.820 users or applications have access to the service. 02:29.450 --> 02:32.850 So that's the topic of our discussion for this lecture. 02:32.960 --> 02:38.380 Our focus is more on services and less on PODs. 02:38.420 --> 02:44.300 How are the services getting these IP addresses and how are they made available across all the nodes 02:44.300 --> 02:45.440 in the cluster. 02:45.440 --> 02:50.440 How is the service made available to external users through a port on each node. 02:50.510 --> 02:53.540 Who is doing that and how and where do we see it. 02:53.540 --> 02:54.640 So let's get started. 02:55.160 --> 02:56.900 Let's start on a clean slate. 02:56.930 --> 03:01.310 We have a three node cluster, no pods or services yet. 03:01.370 --> 03:08.420 We know that every kubernetes node runs a kubelet process, which is responsible for creating PODs. Each 03:08.470 --> 03:10.690 kubelet service on each node 03:10.700 --> 03:14.360 watches the changes in the cluster through the kube-api server, 03:14.570 --> 03:19.930 and every time a new POD is to be created, it creates the POD on the nodes. 03:20.330 --> 03:24.850 It then invokes the CNI plugin to configure networking for that POD. 03:24.860 --> 03:30.560 Similarly, each node runs another component known as kube-proxy. Kube 03:30.570 --> 03:38.270 proxy watches the changes in the cluster through kube-api server, and every time a new service is to be created, 03:38.510 --> 03:46.480 kube-proxy gets into action. Unlike PODs, services are not created on each node or assigned to each node. 03:46.520 --> 03:48.970 Services are a cluster wide concept. 03:49.040 --> 03:52.310 They exist across all the nodes in the cluster. 03:52.310 --> 03:55.460 As a matter of fact they don't exist at all. 03:55.520 --> 04:01.860 There is no server or service really listening on the IP of the service. We have seen that 04:01.860 --> 04:09.030 PODs have containers and containers have namespaces with interfaces and Ips assigned to those interfaces. 04:09.270 --> 04:10.440 With services 04:10.440 --> 04:12.080 Nothing like that exists. 04:12.120 --> 04:16.010 There are no processes or name spaces or interfaces for a service. 04:16.500 --> 04:18.870 It's just a virtual object. 04:18.870 --> 04:20.640 Then how do they get an IP address 04:20.670 --> 04:26.010 and how were we able to access the application on the pod through service? 04:26.010 --> 04:32.730 When we create a service object in kubernetes, it is assigned an IP address from a pre-defined range. 04:33.240 --> 04:39.450 The kube-proxy components running on each node, get’s that IP address and creates forwarding rules on 04:39.450 --> 04:46.710 each node in the cluster, saying any traffic coming to this IP, the IP of the service, should go to the 04:46.710 --> 04:48.660 IP of the POD. 04:48.690 --> 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 04:55.770 --> 05:00.240 IP address which is accessible from any node in the cluster. 05:00.240 --> 05:05.310 Now remember it's not just the IP it's an IP and port combination. 05:05.310 --> 05:11.940 Whenever services are created or deleted the kube-proxy component creates or deletes these rules. 05:11.940 --> 05:18.750 So how are these rules created? kube-proxy supports different ways, such as userspace where kube-proxy 05:18.750 --> 05:25.550 listens on a port for each service and proxies connections to the pods. By creating ipvs rules or 05:25.560 --> 05:32.640 the third and the default option and the one familiar to us is using IP tables. The proxy mode can be 05:32.640 --> 05:37.520 set using the proxy mode option while configuring the kube-proxy service 05:37.560 --> 05:45.000 If this is not set, it defaults to iptables. So we’ll see how iptables are configured by kube-proxy and 05:45.000 --> 05:47.610 how you can view them on the nodes. 05:47.640 --> 05:50.590 We have a pod named db deployed on node-1. 05:50.640 --> 05:57.870 it has IP address 10.244.1.2. We create a service of type ClusterIP to make this pod 05:57.870 --> 06:00.030 available within the cluster. 06:00.030 --> 06:04.890 When the service is created kubernetes assigns an IP address to it. 06:05.100 --> 06:10.210 It is set to 10.103.132.104 06:10.260 --> 06:13.330 This range is specified in the kube-apiservers 06:13.380 --> 06:22.050 option called service-cluster-ip-range. Which is by default set to 10.0.0.0/24. 06:22.050 --> 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. 06:31.230 --> 06:42.380 That gives my services IP any where from 10.96.0.0 to 10.111.255.255. A relative 06:42.390 --> 06:44.010 point to mention here. 06:44.010 --> 06:51.960 when I setup my POD networking, I provided a POD network CIDR range of 10.244.0.0/16 06:52.140 --> 07:00.720 which gives my pods IP addresses from 10.244.0.0 to 10.244.255.255. 07:00.720 --> 07:06.030 The reason I brought this up here is because whatever range is specified for each of these networks 07:06.480 --> 07:09.390 it shouldn't overlap which it doesn't 07:09.390 --> 07:16.900 in this case. Both of these should have its own dedicated range of IPs to work with. There shouldn't 07:16.900 --> 07:21.850 be a case where a POD and a service are assigned the same IP address. 07:21.850 --> 07:23.740 So getting back to services. 07:23.740 --> 07:30.480 that’s how my service got an IP address of 10.103.132.104. 07:30.490 --> 07:34.110 You can see the rules created by kube-proxy in the iptables 07:34.120 --> 07:35.650 nat table output. 07:35.650 --> 07:39.740 Search for the name of the service as all rules created by kube-proxy 07:39.760 --> 07:43.050 have a comment with the name of the service on it. 07:43.060 --> 07:51.310 These rules mean, any traffic going to IP address 10.103.132.104 on port 3306 07:51.490 --> 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. 07:57.700 --> 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. 08:02.500 --> 08:06.760 This is done by adding a DNAT rule to IP tables. 08:06.760 --> 08:13.240 Similarly, when you create services of type NodePort, kube-proxy creates IPTable rules to forward all 08:13.240 --> 08:18.620 traffic coming on a port on all nodes to the respective backend PODs. 08:18.850 --> 08:25.030 You can also see kube-proxy create these entries in the kube-proxy logs itself. In the logs 08:25.120 --> 08:32.080 you will find what proxier it uses, in this case its IP tables and the Add an entry when it added 08:32.110 --> 08:34.840 a new service for the database. 08:34.840 --> 08:38.950 Note that the location of this file might vary depending on your installation. 08:39.010 --> 08:44.830 If you don't see these entries you must also check the verbosity level of the process as well. 08:45.830 --> 08:48.890 Well that's it about service networking. 08:48.890 --> 08:50.540 I will see you in the next lecture.