1 00:00:01,080 --> 00:00:03,900 Hello and welcome to this lecture. In this lecture 2 00:00:03,900 --> 00:00:09,150 we will discuss about DNS in the Kubernetes cluster. If you are new to DNS 3 00:00:09,150 --> 00:00:14,460 make sure you go through the prerequisite section on DNS where we discuss what DNS is, 4 00:00:14,460 --> 00:00:21,030 what are the tools used for working with DNS such as host, NS Lookup and dig utility and the different 5 00:00:21,030 --> 00:00:24,350 types of DNS records like A, CNAME etc. 6 00:00:24,560 --> 00:00:29,590 And we also saw how to setup our own DNS server using CoreDNS. 7 00:00:29,790 --> 00:00:36,140 In this lecture we will see what names are assigned to what objects, what our service DNS records, POD 8 00:00:36,160 --> 00:00:37,170 DNS records, 9 00:00:37,230 --> 00:00:41,760 What are the different ways you can reach one part from another. In the next lecture, 10 00:00:41,760 --> 00:00:48,120 we will see how Kubernetes implements DNS in the cluster. So we have a 3 node kubernetes cluster 11 00:00:48,130 --> 00:00:51,380 with some PODs and services deployed on them. 12 00:00:51,520 --> 00:00:54,930 Each node has a nodename and IP address assigned to it. 13 00:00:55,090 --> 00:01:01,280 The node names and IP addresses of the cluster are probably registered in a DNS server in your organization. 14 00:01:01,300 --> 00:01:04,540 Now how that is managed who accesses them are not of concern 15 00:01:04,540 --> 00:01:11,410 in this lecture. In this lecture we discuss about DNS resolution within the cluster between the different 16 00:01:11,410 --> 00:01:18,550 components in the cluster such as PODs and services. Kubernetes deploys a built-in DNS server by default 17 00:01:18,790 --> 00:01:24,350 when you setup a cluster. If you setup kubernetes manually, then you do it by yourself. 18 00:01:24,400 --> 00:01:28,140 We will see how that is done and how it is configured in the next lecture. 19 00:01:28,180 --> 00:01:34,300 As far as this lecture is concerned we will see how it helps pods resolve other pods and services 20 00:01:34,480 --> 00:01:38,360 within the cluster. So we don't really care about 21 00:01:38,360 --> 00:01:45,940 nodes. We focus purely on PODs and services within the cluster. As long as our cluster networking is set 22 00:01:45,940 --> 00:01:51,380 up correctly, following the best practices we learned so far in this section, and all pods and services 23 00:01:51,380 --> 00:01:54,340 can get their own IP address and can reach each other. 24 00:01:54,380 --> 00:01:55,820 We should be good. 25 00:01:55,820 --> 00:01:59,110 Let’s start with just two PODs and a service. 26 00:01:59,150 --> 00: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 27 00:02:05,060 --> 00:02:10,480 on the right, with the IP set to 10.244.2.5. Looking at their IPs, 28 00:02:10,530 --> 00:02:15,720 you can guess that they are probably hosted on two different nodes. But that doesn’t matter, as far 29 00:02:15,720 --> 00:02:17,150 as DNS is concerned. 30 00:02:17,220 --> 00:02:23,730 We assume that all PODs and services can reach other using their IP addresses. To make the web 31 00:02:23,730 --> 00:02:26,060 server accessible to the test pod, 32 00:02:26,070 --> 00:02:28,100 we create a service. We name it 33 00:02:28,110 --> 00:02:29,180 Web service. 34 00:02:29,310 --> 00:02:39,310 The service gets an IP 10.107.37.188. Whenever a service is created, the kubernetes DNS service creates 35 00:02:39,400 --> 00:02:47,950 a record for the service. It maps the service name to the IP address. So within the cluster any pod can 36 00:02:47,950 --> 00:02:51,820 now reach the service using its service name. 37 00:02:51,820 --> 00:02:57,910 Remember we talked about name spaces earlier. That everyone within the namespace address each other just 38 00:02:57,940 --> 00:03:03,130 with their first names and to address anyone in another namespace you use their full names ? 39 00:03:03,220 --> 00:03:10,090 In this case since the test pod and the web pod and its associated service are all in the same namespace. 40 00:03:10,630 --> 00:03:17,410 The default namespace. You were able to simply reach the web-service from the test pod using just the 41 00:03:17,410 --> 00:03:20,260 service name web service. 42 00:03:20,260 --> 00:03:27,670 Let's assume the web service was in a separate namespace named apps. Then to refer to it from the default 43 00:03:27,730 --> 00:03:28,660 namespace. 44 00:03:28,720 --> 00:03:36,010 you would have to say web-service.apps. The last name of the service is now the name of the namespace. 45 00:03:37,250 --> 00:03:44,210 So here web service is the name of the service and apps is the name of the namespace. For each namespace 46 00:03:44,210 --> 00:03:50,600 The DNS server creates a subdomain. All the services are grouped together into another subdomain called 47 00:03:50,710 --> 00:03:52,000 SVC. 48 00:03:52,100 --> 00:03:53,420 So what was that about? 49 00:03:53,420 --> 00:03:54,920 Let's take a closer look. 50 00:03:55,010 --> 00:04:00,620 web-service is the name of the service and apps is the name of the namespace. For each namespace 51 00:04:00,620 --> 00:04:07,370 the DNS server creates a subdomain with its name. All pods and services for a namespace are thus grouped 52 00:04:07,400 --> 00:04:11,390 together within a subdomain in the name of the namespace. 53 00:04:11,450 --> 00:04:17,530 All the services are grouped together into another subdomain called svc. 54 00:04:17,570 --> 00:04:23,140 So you can reach your application with the name web-service.apps.svc. 55 00:04:23,360 --> 00:04:29,540 Finally, all the services and PODs are grouped together into a root domain for the cluster, which is 56 00:04:29,540 --> 00:04:36,360 set to cluster.local by default. So you can access the service using the URL 57 00:04:36,410 --> 00:04:43,470 web-service.apps.svc.cluster.local. And that’s the fully qualified domain name for the service. 58 00:04:43,550 --> 00:04:47,870 So that's how services are resolved within the cluster. 59 00:04:47,890 --> 00:04:55,430 What about PODs? Records for PODs are not created by default. But we can enable that explicitly, 60 00:04:55,570 --> 00:04:59,020 We will see that in the next lecture. Once enabled, 61 00:04:59,020 --> 00:05:01,690 Records are created for pods as well. 62 00:05:01,690 --> 00:05:08,080 It does not use the POD name though. For each POD kubernetes generates a name by replacing the dots 63 00:05:08,140 --> 00:05:10,440 in the IP address with dashes. 64 00:05:10,660 --> 00:05:17,830 The namespace remains the same and type is set to pod. The root domain is always cluster.local. 65 00:05:18,550 --> 00:05:24,400 Similarly the test POD in the default namespace, gets a record in the DNS server, with its IP converted 66 00:05:24,400 --> 00:05:32,470 to a dashed hostname 10-244-1-5 and namespace set to default, type is POD 67 00:05:32,740 --> 00:05:35,610 and root is cluster.local. 68 00:05:35,710 --> 00:05:38,440 This resolve to the IP address of the POD.