WEBVTT 00:00.940 --> 00:06.760 In this lecture we will discuss how Kubernetes implements DNS in 00:06.760 --> 00:07.630 the cluster. 00:07.660 --> 00:13.690 In the previous lecture we saw how you can address a service or pod from another pod. In this lecture 00:13.690 --> 00:17.020 we will see how kubernetes makes that possible. 00:17.080 --> 00:20.120 Say you were given two pods with two IP addresses. 00:20.140 --> 00:21.640 How would you do it. 00:21.790 --> 00:25.270 Based on what we learned in the prerequisite lectures on DNS, 00:25.300 --> 00:32.860 an easy way to get them to resolve each other is to add an entry into each of their /etc/hosts files. On 00:32.860 --> 00:33.850 the first pod 00:33.910 --> 00:39.330 I would say the second pod web is at 10.244.2.5 00:39.520 --> 00:45.520 and on the second pod I would say the first pod test is at 10.244.1.5. 00:45.670 --> 00:50.290 But of course, when you have 1000s of PODs in the cluster, and 100s of them being created and 00:50.290 --> 00:51.520 deleted every minute. 00:51.520 --> 00:53.890 This is not a suitable solution. 00:53.890 --> 01:00.430 So we move these entries into a central DNS server. We then point these PODs to the DNS server by 01:00.430 --> 01:07.390 adding an entry into their /etc/resolv.conf file specifying that the nameserver is at the IP address 01:07.390 --> 01:11.460 of the DNS server, which happens to be 10.96.0.10 01:11.470 --> 01:18.760 in this case. Every time a new pod is created, we add a record in the DNS server for that pod so that 01:18.880 --> 01:25.810 other pods can access the new POD, and configure the /etc/resolv.conf file in the POD to 01:25.810 --> 01:28.470 the DNS server so that the pod can resolve 01:28.570 --> 01:30.910 other pods in the cluster. 01:30.910 --> 01:37.220 This is kind of how kubernetes does it. Except that it does not create similar entries for PODs to map podname 01:37.300 --> 01:40.870 to its IP address as we have seen in the previous lecture. 01:40.870 --> 01:49.090 It does that for services. For pods it forms host names by replacing dots with dashes in the IP address 01:49.090 --> 01:56.260 of the pod. Kubernetes implements DNS in the same way. It deploys a DNS server within the cluster. 01:56.830 --> 02:04.730 Prior to version v1.12 the DNS implemented by kubernetes was known as kube-dns. With Kubernetes 02:04.840 --> 02:13.110 version 1.12 the recommended DNS server is CoreDNS. We took a brief look at a core DNS in one of 02:13.110 --> 02:15.120 the prerequisite lectures. 02:15.120 --> 02:18.120 So how is the core DNS setup in the cluster. 02:18.120 --> 02:24.330 The CoreDNS server is deployed as a POD in the kube-system namespace in the kubernetes cluster. 02:24.360 --> 02:29.200 Well they are deployed as two pods for redundancy, as part of a replicaset. 02:29.520 --> 02:35.120 they are actually a replicaset within a deployment. But it doesn’t really matter. We’ll just see 02:35.120 --> 02:38.280 CoreDNS as a POD in this lecture. 02:38.280 --> 02:45.360 This POD runs the coreDNS executable, the same executable that we ran when we deployed CoreDNS 02:45.420 --> 02:46.630 ourselves. 02:46.740 --> 02:49.880 CoreDNS requires a configuration file. In our case 02:49.920 --> 02:54.080 we used a file named Corefile. So does kubernetes. 02:54.150 --> 03:00.730 It uses a file named Corefile located at /etc/coredns. Within this file 03:00.740 --> 03:07.760 you have a number of plugins configured. The ones highlighted in orange. Plugins are configured for handling 03:07.820 --> 03:14.210 errors, reporting health, monitoring metrics, cache etc. The plugin that makes CoreDNS work with 03:14.210 --> 03:19.760 Kubernetes, is the kubernetes plugin. And this is where the top level domain name for the cluster 03:19.850 --> 03:28.340 is set. In this case cluster.local. So every record in the coredns DNS server falls under this 03:28.340 --> 03:30.800 domain. Within the kubernetes plugin 03:30.800 --> 03:32.460 there are multiple options. 03:32.620 --> 03:39.220 The pods option you see here, is what is responsible for creating a record for PODs in the cluster. 03:39.230 --> 03:44.570 Remember we talked about a record being created for each POD by converting their IPs into a dashed 03:44.570 --> 03:47.320 format that's disabled by default. 03:47.480 --> 03:50.840 But it can be enabled with this entry here. 03:50.840 --> 03:57.620 Any record that this DNS server can’t solve, for example say a POD tries to reach www.google.com 03:57.770 --> 04:04.810 it is forwarded to the nameserver specified in the coredns pods /etc/resolv.conf file. The 04:04.820 --> 04:09.290 /etc/resolv.conf file is set to use the nameserver from the kubernetes 04:09.290 --> 04:18.450 Node. Also note, that this core file is passed into the pod has a configMap object. That way if you 04:18.450 --> 04:23.240 need to modify this configuration you can edit the ConfigMap object. 04:23.310 --> 04:28.590 We now have the coredns pod up and running using the appropriate kubernetes plugin. 04:28.740 --> 04:36.180 It watches the kubernetes cluster for new PODs or services, and every time a pod or a service is created it 04:36.300 --> 04:39.510 adds a record for it in its database. 04:39.510 --> 04:43.530 Next step is for the pod to point to the coreDNS server. 04:43.830 --> 04:50.570 What address do the PODs use to reach the DNS server? When we deploy CoreDNS solution, 04:50.570 --> 04:55.550 It also creates a service to make it available to other components within a cluster. 04:55.550 --> 05:02.640 The service is named as kube-dns by default. The IP address of this service is configured as 05:02.640 --> 05:04.480 nameserver on the PODs. 05:04.500 --> 05:09.340 Now you don’t have to configure this yourself. The DNS configurations on PODs are done by kubernetes 05:09.350 --> 05:12.720 automatically when the PODs are created. 05:12.720 --> 05:17.720 Want to guess which kubernetes component is responsible for that? The kubelet. 05:17.910 --> 05:24.190 If you look at the config file of the kubelet you will see the IP of the DNS server and domain in it. 05:24.270 --> 05:30.090 Once the pods are configured with the right nameserver, you can now resolve other pods and services. 05:30.540 --> 05:36.130 You can access the web-service using just web-service, or web-service.default or web-service.default.svc or web-service.default.svc.cluster.local. 05:36.210 --> 05:41.220 You can access the web-service using just web-service, or web-service.default or web-service.default.svc or web service.default.svc.cluster.local. 05:41.460 --> 05:47.310 If you try to manually lookup the web-service using nslookup or the host command web-service command, it 05:47.310 --> 05:53.130 will return the fully qualified domain name of the web-service, which happens to be web-service.default.svc.cluster.local. 05:53.130 --> 05:55.440 will return the fully qualified domain name of the web-service, which happens to be web-service.default.svc.cluster.local. 05:55.740 --> 05:58.980 But you didn't ask for that you just set up service. 05:58.980 --> 06:01.520 So how did it look up for the full name. 06:01.530 --> 06:07.730 It so happens, the resolv.conf file also has a search entry which is set to default.svc.cluster.local 06:07.730 --> 06:13.770 as well as svc.cluster.local and cluster.local. 06:13.770 --> 06:19.590 This allows you to find the service using any name. web-service or web-service.default or web-service.default.svc. 06:19.590 --> 06:21.090 This allows you to find the service using any name. web-service or web-service.default or web-service.default.svc. 06:21.090 --> 06:27.990 However, notice that it only has search entries for service . So you won’t be able to reach a pod the same 06:27.990 --> 06:28.440 way. 06:28.500 --> 06:33.280 For that you need to specify the full FQDN of the pod. 06:33.300 --> 06:35.160 Well that's it for this lecture. 06:35.160 --> 06:41.620 Head over to the practice test and practice working with DNS on our kubernetes cluster. I will see you 06:41.860 --> 06:42.820 in the next lecture.