WEBVTT 00:01.080 --> 00:03.900 Hello and welcome to this lecture. In this lecture 00:03.900 --> 00:09.150 we will discuss about DNS in the Kubernetes cluster. If you are new to DNS 00:09.150 --> 00:14.460 make sure you go through the prerequisite section on DNS where we discuss what DNS is, 00:14.460 --> 00:21.030 what are the tools used for working with DNS such as host, NS Lookup and dig utility and the different 00:21.030 --> 00:24.350 types of DNS records like A, CNAME etc. 00:24.560 --> 00:29.590 And we also saw how to setup our own DNS server using CoreDNS. 00:29.790 --> 00:36.140 In this lecture we will see what names are assigned to what objects, what our service DNS records, POD 00:36.160 --> 00:37.170 DNS records, 00:37.230 --> 00:41.760 What are the different ways you can reach one part from another. In the next lecture, 00:41.760 --> 00:48.120 we will see how Kubernetes implements DNS in the cluster. So we have a 3 node kubernetes cluster 00:48.130 --> 00:51.380 with some PODs and services deployed on them. 00:51.520 --> 00:54.930 Each node has a nodename and IP address assigned to it. 00:55.090 --> 01:01.280 The node names and IP addresses of the cluster are probably registered in a DNS server in your organization. 01:01.300 --> 01:04.540 Now how that is managed who accesses them are not of concern 01:04.540 --> 01:11.410 in this lecture. In this lecture we discuss about DNS resolution within the cluster between the different 01:11.410 --> 01:18.550 components in the cluster such as PODs and services. Kubernetes deploys a built-in DNS server by default 01:18.790 --> 01:24.350 when you setup a cluster. If you setup kubernetes manually, then you do it by yourself. 01:24.400 --> 01:28.140 We will see how that is done and how it is configured in the next lecture. 01:28.180 --> 01:34.300 As far as this lecture is concerned we will see how it helps pods resolve other pods and services 01:34.480 --> 01:38.360 within the cluster. So we don't really care about 01:38.360 --> 01:45.940 nodes. We focus purely on PODs and services within the cluster. As long as our cluster networking is set 01:45.940 --> 01:51.380 up correctly, following the best practices we learned so far in this section, and all pods and services 01:51.380 --> 01:54.340 can get their own IP address and can reach each other. 01:54.380 --> 01:55.820 We should be good. 01:55.820 --> 01:59.110 Let’s start with just two PODs and a service. 01:59.150 --> 02:05.060 I have a test pod on the left with the IP set to 10.244.1.5. And I have a web pod 02:05.060 --> 02:10.480 on the right, with the IP set to 10.244.2.5. Looking at their IPs, 02:10.530 --> 02:15.720 you can guess that they are probably hosted on two different nodes. But that doesn’t matter, as far 02:15.720 --> 02:17.150 as DNS is concerned. 02:17.220 --> 02:23.730 We assume that all PODs and services can reach other using their IP addresses. To make the web 02:23.730 --> 02:26.060 server accessible to the test pod, 02:26.070 --> 02:28.100 we create a service. We name it 02:28.110 --> 02:29.180 Web service. 02:29.310 --> 02:39.310 The service gets an IP 10.107.37.188. Whenever a service is created, the kubernetes DNS service creates 02:39.400 --> 02:47.950 a record for the service. It maps the service name to the IP address. So within the cluster any pod can 02:47.950 --> 02:51.820 now reach the service using its service name. 02:51.820 --> 02:57.910 Remember we talked about name spaces earlier. That everyone within the namespace address each other just 02:57.940 --> 03:03.130 with their first names and to address anyone in another namespace you use their full names ? 03:03.220 --> 03:10.090 In this case since the test pod and the web pod and its associated service are all in the same namespace. 03:10.630 --> 03:17.410 The default namespace. You were able to simply reach the web-service from the test pod using just the 03:17.410 --> 03:20.260 service name web service. 03:20.260 --> 03:27.670 Let's assume the web service was in a separate namespace named apps. Then to refer to it from the default 03:27.730 --> 03:28.660 namespace. 03:28.720 --> 03:36.010 you would have to say web-service.apps. The last name of the service is now the name of the namespace. 03:37.250 --> 03:44.210 So here web service is the name of the service and apps is the name of the namespace. For each namespace 03:44.210 --> 03:50.600 The DNS server creates a subdomain. All the services are grouped together into another subdomain called 03:50.710 --> 03:52.000 SVC. 03:52.100 --> 03:53.420 So what was that about? 03:53.420 --> 03:54.920 Let's take a closer look. 03:55.010 --> 04:00.620 web-service is the name of the service and apps is the name of the namespace. For each namespace 04:00.620 --> 04:07.370 the DNS server creates a subdomain with its name. All pods and services for a namespace are thus grouped 04:07.400 --> 04:11.390 together within a subdomain in the name of the namespace. 04:11.450 --> 04:17.530 All the services are grouped together into another subdomain called svc. 04:17.570 --> 04:23.140 So you can reach your application with the name web-service.apps.svc. 04:23.360 --> 04:29.540 Finally, all the services and PODs are grouped together into a root domain for the cluster, which is 04:29.540 --> 04:36.360 set to cluster.local by default. So you can access the service using the URL 04:36.410 --> 04:43.470 web-service.apps.svc.cluster.local. And that’s the fully qualified domain name for the service. 04:43.550 --> 04:47.870 So that's how services are resolved within the cluster. 04:47.890 --> 04:55.430 What about PODs? Records for PODs are not created by default. But we can enable that explicitly, 04:55.570 --> 04:59.020 We will see that in the next lecture. Once enabled, 04:59.020 --> 05:01.690 Records are created for pods as well. 05:01.690 --> 05:08.080 It does not use the POD name though. For each POD kubernetes generates a name by replacing the dots 05:08.140 --> 05:10.440 in the IP address with dashes. 05:10.660 --> 05:17.830 The namespace remains the same and type is set to pod. The root domain is always cluster.local. 05:18.550 --> 05:24.400 Similarly the test POD in the default namespace, gets a record in the DNS server, with its IP converted 05:24.400 --> 05:32.470 to a dashed hostname 10-244-1-5 and namespace set to default, type is POD 05:32.740 --> 05:35.610 and root is cluster.local. 05:35.710 --> 05:38.440 This resolve to the IP address of the POD.