The Domain Name System (DNS) is a system for associating various types of information – such as IP addresses – with easy-to-remember names. By default most Kubernetes clusters automatically configure an internal DNS service to provide a lightweight mechanism for service discovery. Built-in service discovery makes it easier for applications to find and communicate with each other on Kubernetes clusters, even when pods and services are being created, deleted, and shifted between nodes.
The implementation details of the Kubernetes DNS service have changed in recent versions of Kubernetes. In this article we will take a look at both the kube-dns and CoreDNS versions of the Kubernetes DNS service. We will review how they operate and the DNS records that Kubernetes generates.
To gain a more thorough understanding of DNS before you begin, please read An Introduction to DNS Terminology, Components, and Concepts. For any Kubernetes topics you may be unfamiliar with, you could read What is Kubernetes?.
If you’re looking for a managed Kubernetes hosting service, check out our simple, managed Kubernetes service built for growth.
Before Kubernetes version 1.11, the Kubernetes DNS service was based on kube-dns. Version 1.11 introduced CoreDNS to address some security and stability concerns with kube-dns.
Regardless of the software handling the actual DNS records, both implementations work in a similar manner:
A service named
kube-dns and one or more pods are created.
kube-dns service listens for service and endpoint events from the Kubernetes API and updates its DNS records as needed. These events are triggered when you create, update or delete Kubernetes services and their associated pods.
kubelet sets each new pod’s
nameserver option to the cluster IP of the
kube-dns service, with appropriate
search options to allow for shorter hostnames to be used:
nameserver 10.32.0.10 search namespace.svc.cluster.local svc.cluster.local cluster.local options ndots:5
Applications running in containers can then resolve hostnames such as
example-service.namespace into the correct cluster IP addresses.
The full DNS
A record of a Kubernetes service will look like the following example:
A pod would have a record in this format, reflecting the actual IP address of the pod:
SRV records are created for a Kubernetes service’s named ports:
The result of all this is a built-in, DNS-based service discovery mechanism, where your application or microservice can target a simple and consistent hostname to access other services or pods on the cluster.
Because of the search domain suffixes listed in the
resolv.conf file, you often won’t need to use the full hostname to contact another service. If you’re addressing a service in the same namespace, you can use just the service name to contact it:
If the service is in a different namespace, add it to the query:
If you’re targeting a pod, you’ll need to use at least the following:
As we saw in the default
resolv.conf file, only
.svc suffixes are automatically completed, so make sure you specify everything up to
Now that we know the practical uses of the Kubernetes DNS service, let’s run through some details on the two different implementations.
As noted in the previous section, Kubernetes version 1.11 introduced new software to handle the
kube-dns service. The motivation for the change was to increase the performance and security of the service. Let’s take a look at the original
kube-dns implementation first.
kube-dns service prior to Kubernetes 1.11 is made up of three containers running in a
kube-dns pod in the
kube-system namespace. The three containers are:
Security vulnerabilities in Dnsmasq, and scaling performance issues with SkyDNS led to the creation of a replacement system, CoreDNS.
As of Kubernetes 1.11 a new Kubernetes DNS service, CoreDNS has been promoted to General Availability. This means that it’s ready for production use and will be the default cluster DNS service for many installation tools and managed Kubernetes providers.
CoreDNS is a single process, written in Go, that covers all of the functionality of the previous system. A single container resolves and caches DNS queries, responds to health checks, and provides metrics.
In addition to addressing performance- and security-related issues, CoreDNS fixes some other minor bugs and adds some new features:
autopathcan improve DNS response times when resolving external hostnames, by being smarter about iterating through each of the search domain suffixes listed in
10.32.0.125.namespace.pod.cluster.localwould always resolve to
10.32.0.125, even if the pod doesn’t actually exist. CoreDNS has a “pods verified” mode that will only resolve successfully if a pod exists with the right IP and in the right namespace.
For more information on CoreDNS and how it differs from kube-dns, you can read the Kubernetes CoreDNS GA announcement.
Kubernetes operators often want to customize how their pods and containers resolve certain custom domains, or need to adjust the upstream nameservers or search domain suffixes configured in
resolv.conf. You can do this with the
dnsConfig option of your pod’s spec:
apiVersion: v1 kind: Pod metadata: namespace: example name: custom-dns spec: containers: - name: example image: nginx dnsPolicy: "None" dnsConfig: nameservers: - 203.0.113.44 searches: - custom.dns.local
Updating this config will rewrite a pod’s
resolv.conf to enable the changes. The configuration maps directly to the standard
resolv.conf options, so the above config would create a file with
nameserver 203.0.113.44 and
search custom.dns.local lines.
In this article we covered the basics of what the Kubernetes DNS service provides to developers, showed some example DNS records for services and pods, discussed how the system is implemented on different Kubernetes versions, and highlighted some additional configuration options available to customize how your pods resolve DNS queries.
For more information on the Kubernetes DNS service, please refer to the official Kubernetes DNS for Services and Pods documentation.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.