In this lecture we will discuss how Kubernetes implements DNS in
the cluster.
In the previous lecture we saw how you can address a service or pod from another pod. In this lecture
we will see how kubernetes makes that possible.
Say you were given two pods with two IP addresses.
How would you do it.
Based on what we learned in the prerequisite lectures on DNS,
an easy way to get them to resolve each other is to add an entry into each of their /etc/hosts files. On
the first pod
I would say the second pod web is at 10.244.2.5
and on the second pod I would say the first pod test is at 10.244.1.5.
But of course, when you have 1000s of PODs in the cluster, and 100s of them being created and
deleted every minute.
This is not a suitable solution.
So we move these entries into a central DNS server. We then point these PODs to the DNS server by
adding an entry into their /etc/resolv.conf file specifying that the nameserver is at the IP address
of the DNS server, which happens to be 10.96.0.10
in this case. Every time a new pod is created, we add a record in the DNS server for that pod so that
other pods can access the new POD, and configure the /etc/resolv.conf file in the POD to
the DNS server so that the pod can resolve
other pods in the cluster.
This is kind of how kubernetes does it. Except that it does not create similar entries for PODs to map podname
to its IP address as we have seen in the previous lecture.
It does that for services. For pods it forms host names by replacing dots with dashes in the IP address
of the pod. Kubernetes implements DNS in the same way. It deploys a DNS server within the cluster.
Prior to version v1.12 the DNS implemented by kubernetes was known as kube-dns. With Kubernetes
version 1.12 the recommended DNS server is CoreDNS. We took a brief look at a core DNS in one of
the prerequisite lectures.
So how is the core DNS setup in the cluster.
The CoreDNS server is deployed as a POD in the kube-system namespace in the kubernetes cluster.
Well they are deployed as two pods for redundancy, as part of a replicaset.
they are actually a replicaset within a deployment. But it doesn’t really matter. We’ll just see
CoreDNS as a POD in this lecture.
This POD runs the coreDNS executable, the same executable that we ran when we deployed CoreDNS
ourselves.
CoreDNS requires a configuration file. In our case
we used a file named Corefile. So does kubernetes.
It uses a file named Corefile located at /etc/coredns. Within this file
you have a number of plugins configured. The ones highlighted in orange. Plugins are configured for handling
errors, reporting health, monitoring metrics, cache etc. The plugin that makes CoreDNS work with
Kubernetes, is the kubernetes plugin. And this is where the top level domain name for the cluster
is set. In this case cluster.local. So every record in the coredns DNS server falls under this
domain. Within the kubernetes plugin
there are multiple options.
The pods option you see here, is what is responsible for creating a record for PODs in the cluster.
Remember we talked about a record being created for each POD by converting their IPs into a dashed
format that's disabled by default.
But it can be enabled with this entry here.
Any record that this DNS server can’t solve, for example say a POD tries to reach www.google.com
it is forwarded to the nameserver specified in the coredns pods /etc/resolv.conf file. The
/etc/resolv.conf file is set to use the nameserver from the kubernetes
Node. Also note, that this core file is passed into the pod has a configMap object. That way if you
need to modify this configuration you can edit the ConfigMap object.
We now have the coredns pod up and running using the appropriate kubernetes plugin.
It watches the kubernetes cluster for new PODs or services, and every time a pod or a service is created it
adds a record for it in its database.
Next step is for the pod to point to the coreDNS server.
What address do the PODs use to reach the DNS server? When we deploy CoreDNS solution,
It also creates a service to make it available to other components within a cluster.
The service is named as kube-dns by default. The IP address of this service is configured as
nameserver on the PODs.
Now you don’t have to configure this yourself. The DNS configurations on PODs are done by kubernetes
automatically when the PODs are created.
Want to guess which kubernetes component is responsible for that? The kubelet.
If you look at the config file of the kubelet you will see the IP of the DNS server and domain in it.
Once the pods are configured with the right nameserver, you can now resolve other pods and services.
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.
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.
If you try to manually lookup the web-service using nslookup or the host command web-service command, it
will return the fully qualified domain name of the web-service, which happens to be web-service.default.svc.cluster.local.
But you didn't ask for that you just set up service.
So how did it look up for the full name.
It so happens, the resolv.conf file also has a search entry which is set to default.svc.cluster.local
as well as svc.cluster.local and cluster.local.
This allows you to find the service using any name. web-service or web-service.default or web-service.default.svc.
However, notice that it only has search entries for service . So you won’t be able to reach a pod the same
way.
For that you need to specify the full FQDN of the pod.
Well that's it for this lecture.
Head over to the practice test and practice working with DNS on our kubernetes cluster. I will see you
in the next lecture.