CoreDNS is a modern, flexible, extensible DNS server with a modular architecture. You can easily extend it with plugins, and it has no scalability concerns. The Kubernetes cluster configured with Kubeadm runs CoreDNS as a Deployment<\/a> with two replicas and exposes it with a kube-dns service in the kube-system<\/em> namespace. The service name kube-dns<\/em> is intended to offer backward compatibility with the legacy DNS server.<\/p>\n<\/p>\n kubectl get svc -n kube-system<\/p> <\/pre>\n<\/p>\n View CoreDNS deployment and service in the cluster<\/p>\n<\/div>\n The above hyperlink takes the reader to a screenshot showing the Deployment and service objects. The second command also indicates the Cluster-IP of the kube-dns service. The following commands will help you view the service endpoints and the IP address of the Pods.<\/p>\n<\/p>\n kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide<\/p> <\/pre>\n<\/p>\n View kube dns service endpoints and the IP addresses of the CoreDNS Pods<\/p>\n<\/div>\n The first command displays the IP address of the CoreDNS service, while the second command reveals the IP addresses of the Pods acting as service endpoints. The primary nameserver for the Kubernetes cluster is represented by the CoreDNS service IP address, which in our case is 10.96.0.10<\/em>.<\/p>\n<\/p>\n The DNS server’s behaviour is defined by a configuration file used by CoreDNS called the Corefile. This file enables you to configure DNS zones, plugins, the rules for forwarding, and other settings that manage DNS requests. In a Kubernetes cluster, the Corefile is saved in a ConfigMap<\/a> resource named coredns<\/em>. The following command can be utilized to view it:<\/p>\n<\/p>\n Let’s break down the Corefile for better understanding. The Corefile begins with a DNS zone name. The .:53 indicates that the CoreDNS server should handle all possible queries and listen on the default Port 53. All the keywords in the Corefile (e.g., errors, log, health, ready, kubernetes, and forward) are plugins that perform a particular task. The plugins are configured using directives, and the options for each directive vary with the plugin. Some plugins have no directives; some have one or more (required and optional). Let’s discuss some of the most common plugins.<\/p>\n<\/p>\n The plugin’s syntax follows the pattern kubernetes [zones]{}<\/em>, where zones<\/em> specify the DNS zones for which the kubernetes plugin is authoritative. As per the screenshot, the cluster.local <\/em>zone is for the default cluster domain, while in-addr.arpa <\/em>and ip6.arpa<\/em> are the reverse DNS zones for the IPv4 and IPv6 addresses, respectively. The curly braces include various directives for adjusting the plugin’s behavior.<\/p>\n disabled\u2014Setting this mode means that the kubernetes<\/em> plugin does not process Pod requests and returns an NXDOMAIN as a response when you try to query a Pod name. This is the default mode.<\/p>\n<\/li>\n insecure\u2014Setting this mode means the kubernetes<\/em> plugin will process Pod requests and return the Pod’s IP address without verifying that the IP address belongs to a Pod in the specified namespace. This mode is not secure because it can expose Pods in other namespaces. It is only there for backward compatibility with the legacy kube-dns.- The fallthrough<\/em> directive helps pass the unhandled queries to the next plugin in the chain (e.g., forward). It allows the kubernetes<\/em> plugin to delegate the reverse DNS queries to another plugin so it can focus on handling the DNS queries for the cluster domain (e.g., cluster.local<\/em>) itself.<\/p>\n<\/li>\n Please note that covering all plugins and their options is beyond the scope of this post. To learn more about CoreDNS plugins, check out the official docs<\/a>.<\/p>\n<\/p>\n As stated earlier, the CoreDNS runs as a Deployment object in the Kubernetes cluster, which runs two Pods for redundancy. The Corefile is passed to these Pods as a ConfigMap, making it easier to edit the Corefile when needed.<\/p>\n<\/p>\n # Run this command to view all CoreDNS Pods <\/p> kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide<\/p> # Run this command to describe a CoreDNS Pod<\/p> kubectl describe pod coredns-5d78c9869d-7hhb5 -n kube-system<\/p> <\/pre>\n<\/p>\n Understanding how the Corefile is passed to the CoreDNS Pods in Kubernetes<\/a><\/p>\n The first command lists all the Pods managed by the CoreDNS Deployment, and the second command describes a CoreDNS Pod. Don’t forget to specify your actual Pod name with the second command. The paragraph describes that the coredns<\/em> ConfigMap is defined as a volume in the Pod. The volume is then mounted in the \/etc\/coredns<\/em> container path as read-only, and finally, the \/etc\/coredns\/Corefile<\/em> is passed as an argument to the coredns<\/em> container that runs in the Pod.<\/p>\n<\/p>\n To make any changes to the Corefile, you can edit the ConfigMap with this command:<\/p>\n<\/p>\n <\/pre>\n<\/p>\n Changing the CoreDNS configuration file Corefile<\/a><\/p>\n The above command opens the ConfigMap object for in-place editing. For the demo, I changed the pods<\/em> mode from insecure<\/em> to disabled<\/em>. The reload plugin periodically (30 seconds, by default) checks the Corefile by calculating the SHA512 checksum. When the file is changed, the plugin gracefully reloads it without causing any service disruption.<\/p>\n<\/p>\n If you make significant changes to the Corefile, the Pods might not automatically detect the changes. In this case, you can kill the Pods manually with this command, and ReplicaSet will create new Pods with an updated configuration file for you.<\/p>\n<\/p>\n kubectl get pods -n kube-system -l k8s-app=kube-dns<\/p> <\/pre>\n<\/p>\n Forcing the recreation of CoreDNS Pods after changing the Corefile<\/a><\/p>\n<\/p>\n The screenshot reveals that new Pods are automatically generated.<\/p>\n<\/p>\n Understanding the notions of CoreDNS and the Corefile may leave you pondering about how each Pod in the cluster utilizes CoreDNS. What configures them for CoreDNS usage?<\/p>\n<\/p>\n It’s probably known to you that kubelet is the one in charge of executing Pods on Kubernetes nodes. The exposition of the CoreDNS Deployment through a kube-dns service was also discussed. The kubeadm tool is configured to make use of the kube-dns service IP address as the cluster DNS server on each node. Here is the command to view the kubelet configuration:<\/p>\n<\/p>\n <\/a><\/p>\n Viewing the cluster DNS IP address in the kubelet configuration<\/p>\n<\/p>\n The screenshot shows the clusterDNS<\/em> and clusterDomain<\/em> set in the kubelet configuration file. When the kubelet creates a Pod, it adds the clusterDNS IP address to the \/etc\/resolv.conf<\/em> file of the Pod to help resolve internal service names within the cluster. The external names are resolved by the forward<\/em> plugin specified in the Corefile. Remember the forward . \/etc\/resolv.conf<\/em> line of the Corefile?<\/p>\n<\/p>\n Let’s quickly run a temporary Pod and view its \/etc\/resolv.conf<\/em> file.<\/p>\n<\/p>\n <\/pre>\n<\/p>\nkubectl get deploy -n kube-system<\/p>
Kubectl describe svc kube-dns -n kube-system<\/p>
Corefile\u2014the CoreDNS configuration file<\/h2>\n<\/p>\n
kubectl get configmap coredns -n kube-system -o yaml<\/pre>\n<\/p>\n
\n
\n
Changing the Corefile<\/h2>\n<\/p>\n
<\/p>
kubectl edit configmap coredns -n kube-system<\/p>
kubectl delete pods -n kube-system -l k8s-app=kube-dns<\/p>
How are Pods utilizing CoreDNS?<\/h2>\n<\/p>\n
cat \/var\/lib\/kubelet\/config.yaml<\/pre>\n<\/p>\n
kubectl run test-pod -it --rm --restart=Never --image=tutum\/dnsutils -- \/bin\/bash<\/p>