DNS in Kubernetes
In this tutorial, we are going to discuss about DNS in the Kubernetes cluster. If you are new to DNS make sure you go through the prerequisite section on DNS where we discuss what DNS is, what are the tools used for working with DNS such as host, NS Lookup and dig utility and the different types of DNS records like A, CNAME etc.
We also discussed how to setup our own DNS server using CoreDNS. In this tutorial we will see what names are assigned to what objects, what our service DNS records, POD DNS records, What are the different ways you can reach one part from another.
In the next tutorial, we will see how Kubernetes implements DNS in the cluster.
So we have a 3 node Kubernetes cluster with some PODs and services deployed on them. Each node has a node name and IP address assigned to it.
The node names and IP addresses of the cluster are probably registered in a DNS server in your organization. Now how that is managed who accesses them are not of concern in this tutorial.
In this tutorial, we discuss about DNS resolution within the cluster between the different components in the cluster such as PODs and services.
Kubernetes deploys a built-in DNS server by default when you setup a cluster. If you setup Kubernetes manually, then you do it by yourself.
We will see how that is done and how it is configured in the next tutorial. As far as this tutorial is concerned we will see how it helps pods resolve other pods and services within the cluster.
So we don’t really care about nodes. We focus purely on PODs and services within the cluster. As long as our cluster networking is set up correctly, following the best practices we discussed so far in this section, and all pods and services can get their own IP address and can reach each other.
Let’s start with just two PODs and a service. I have a test POD with the IP set to 10.244.1.5. And I have a web POD with the IP set to 10.244.2.5.
Looking at their IPs, you can guess that they are probably hosted on two different nodes. But that doesn’t matter, as far as DNS is concerned.
We assume that all PODs and services can reach other using their IP addresses. To make the web server accessible to the test POD, we create a service. We name it web service.
The service gets an IP 10.107.37.188. Whenever a service is created, the Kubernetes DNS service creates a record for the service. It maps the service name to the IP address.
So within the cluster any POD can now reach the service using its service name.
$ curl http://web-service
Welcome to NGINX!Remember we discussed about name spaces earlier. That everyone within the namespace address each other just with their first names and to address anyone in another namespace you use their full names.
In this case since the test POD and the web POD and its associated service are all in the same namespace, the default namespace.
You were able to simply reach the web-service from the test pod using just the service name web service.
Let’s assume the web service was in a separate namespace named apps. Then to refer to it from the default namespace. You would have to say web-service.apps. The last name of the service is now the name of the namespace.
So here web service is the name of the service and apps is the name of the namespace.
$ curl http://web-service.apps
Welcome to NGINX!For each namespace, The DNS server creates a subdomain. All the services are grouped together into another subdomain called SVC. So what was that about?
Let’s take a closer look. web-service is the name of the service and apps is the name of the namespace. For each namespace the DNS server creates a subdomain with its name.
All pods and services for a namespace are thus grouped together within a subdomain in the name of the namespace.
All the services are grouped together into another subdomain called svc. So you can reach your application with the name web-service.apps.svc.
Finally, all the services and PODs are grouped together into a root domain for the cluster, which is set to cluster.local by default. So you can access the service using the URL web-service.apps.svc.cluster.local.
So that’s how services are resolved within the cluster. What about PODs? Records for PODs are not created by default. But we can enable that explicitly, We will see that in the next tutorial. Once enabled, Records are created for pods as well.
It does not use the POD name though. For each POD Kubernetes generates a name by replacing the dots in the IP address with dashes. The namespace remains the same and type is set to pod. The root domain is always cluster.local.
$ curl http://10-244-2-5.apps.pod.cluster.local
Welcome to NGINX!Similarly the test POD in the default namespace, gets a record in the DNS server, with its IP converted to a dashed hostname 10-244-1-5 and namespace set to default, type is POD and root is cluster.local. This resolve to the IP address of the POD.