Kubernetes DNS Service

Photo of author

By admin

With Kubernetes, an individual can create container groups and align various services for efficient functioning. It utilizes a virtual static IP address, and connections reaching these IP addresses will be routed automatically to one container of the same group.

Using services helps administrators to utilize the benefits of the containers without identifying them. In addition, Kubernetes generates DNS entries to further simplify things. Let’s learn about DNS and its benefits in detail along with its configuration and built-in servers.

What is DNS?

The Domain Name System or DNS successfully connects various information, such as IP addresses with names through which they can be searched easily. Kubernetes clusters run automatic configurations for internal DNS services for providing a lightweight process for service discovery by default.

This pre-configured service discovery allows easy searching for various applications and bridges them to communicate successfully with one another within a cluster. In addition, it also offers easy creation, removal, and sharing of pods and services between the nodes.

Moreover, it schedules a DNS Pod and Service on clusters and configures the kubelets of every container to utilize the IP of the DNS Services to resolve DNS names. Every time a service gets added to the cluster, it will be aligned with a dedicated DNS name.

Since the recent release of Kubernetes, the implementation of DNS has been changed a bit. Let’s learn about the same in the next section.

Working of Kubernetes DNS Service

All the Kubernetes versions prior to 1.14 were based on kube-dns. Version 1.14 comes with the usage of CoreDNS for addressing a few safety and security concerns. However, apart from the way they handle the records of DNS, their implementation process works similarly:

  • A service, namely kube-dns will be generated.
  • This service will take care of the endpoints of any event through APIs and will update the DNS record accordingly. These events occur when an individual creates, updates or deletes any Kubernetes service or associated pod.
  • Kubelet aligns every /etc/resolv.conf nameserver for cluster IP of the kube-dns service along with apt search option for allowing the usage of shorter hostnames.
  • Further, applications can also modify their hostnames, for example, example-service.namespace with valid cluster IP address.

Configuring and Implementing Kubernetes DNS servers

As mentioned above, every cluster created on Kubernetes will be assigned with a DNS server automatically. Right after this, the process continues when the kubelet situated on every worker node forwards the container to the DNS server for changing those DNS names with IP addresses.

The whole Kubernetes DNS server (for version 1.14 and above) is based on CoreDNS, which is modular and pluggable. Its behavior is managed by configuration files that are named “Corefile”.

Therefore, Corefile is a Kubernetes ConfigMap that defines CoreDNS behavior and cannot be modified directly. Also, keep in mind that modification of CoreDNS default behavior is mandatory because it deletes all the other customizations during every internal update of clusters.

If you’ll update your Kubernetes from the older version to version 1.14 or above, the kube-dns will automatically be replaced by the CoreDNS server. However, the customizations will not be implemented into CoreDNS ConfigMap if you’ll customize kube-dns with the help of kube-dns ConfigMap.

Therefore, an individual will have to apply a new ConfigMap composed of the customizations of her choice into CoreDNS Corefile. Have a look at some of the implementation details regarding Kubernetes DNS servers:

1. kube-dns

Its service gets to build on 3 containers that run on the kube-dns pod in the kube-system namespace. Following is the list of all 3 containers:

  • kube-dns: Responsible for performing DNS query resolutions.
  • dnsmasq: Resolves issues in DNS caches all the responses received from SkyDNS.
  • sidecar: Manages metrics reporting and replies to all the health checks.

Various security concerns in Dnsmasq and scaling issues result in its replacement with CoreDNS.

2. CoreDNS

CoreDNS is now used for production and is promoted as the default DNS service for Kubernetes. It is a simplified single process that retains all the good functionalities of kube-dns. CoreDNS is based on only 1 container that performs all the functions, such as caching DNS queries, replying to the health checks accordingly, and offering metrics.

Along with improved performance and security, CoreDNS also comes with a lot of bug fixes and the following features:

  • Eliminates all the compatibility issues along stubDomains and external services.
  • CoreDNS comes with an improved load balancing feature.
  • Offers a feature known as autopath that improves DNS response time when resolving external hostnames.

Debugging DNS Server

Before starting out, ensure to have a Kubernetes cluster along with the configured kubectl command-line tool for communicating with your clusters. Also, configure your clusters to use the CoreDNS addon or kube-dns. Last but not the least, make sure to have Kubernetes version v1.6 or above. Here’s how to debug the DNS Server:

1. Verify DNS configuration

Peep into resolv.conf file by running the following command in the command-line:

kubectl exec -ti dnsutils -- cat /etc/resolv.conf

Check the faults in the search path and the server are set up. If everything is ok, proceed further.

2. Ensure the DNS pod is working

Run the following command to check whether or not the DNS pod is working:

kubectl get pods --namespace=kube-system -l k8s-app=kube-dns

In case of discovering any stopped or failed CoreDNS Pod, ensure that your DNS addon is deployed correctly by default. Therefore, if not, you have to deploy it manually.

3. Check for errors

Check the logs for DNS containers by running the below-mentioned command and look for any suspicious or unexpected messages:

kubectl logs --namespace=kube-system -l k8s-app=kube-dns

4. Verify DNS service to be ‘up’

Use the following kubectl get service command to check if the DNS service is “up” or not:

kubectl get svc --namespace=kube-system

5. Check for endpoints

Check if the endpoints of your DNS are exposed with the help of the kubectl get endpoints command. If you didn’t find any endpoints, then check for the endpoints in debugging Services documentation:

kubectl get endpoints kube-dns --namespace=kube-system

6. Receiving and processing of queries

Ensure that all your DNS queries are getting received by CoreDNS. Add the log plugin into the Corefile that will be situated in ConfigMap named as “coredns”. Use the following command to edit this file:

kubectl -n kube-system edit configmap coredns

Save changes, and wait for a minute or two to let the changes come into effect into the CoreDNS pods. Further, you can also check the implementation by processing queries. If the CoreDNS receives the queries, it will successfully reflect on the logs.

DNS Policies for pods

An individual can set DNS policies on various pods that may differ for each other. Setting up the policies will help pods to function in a structured way. Following are some pod-specific policies for DNS that users can implement:

  • “Default”: This policy will set the pods to pick up the name configuration from nodes onto which it is running.
  • “ClusterFirst”: DNS queries not matching the configured cluster domain suffix will be forwarded to the upstream nameserver picked up from the node. Admins may have extra stubDomain and upstream DNS servers configured.
  • “ClusterFirstWithHostNet”: Set this policy for all the Pods running with hostNetwork.
  • “None”: Setting this policy will remove all of the other policies and the DNS settings will provide results using the dnsConfig field in the Pod Spec.

Conclusion

Clusters created with the help of Kubernetes will include a DNS server because it is a built-in feature that configures automatically. It is an extremely useful service that assigns a name to all the information to make it easily discoverable.

Kubernetes versions prior to 1.14 are based on kube-dns that is replaced by CoreDNS for recent versions because of few security reasons and bug fixes. Detailed information regarding their configuration and implementation is mentioned in the blog along with updated features that CoreDNS brings to the table.

Moreover, steps to debug the Kubernetes server are also mentioned that includes verification of configurations, verifying the functioning of pods, and errors along with checking the endpoints. This information is also tailored with dedicated Kubectl codes that one can run for successful configurations.

In addition, the DNS policies for pods will help you learn about how you can make the service run with certain manipulations.

Leave a Comment