Introduction to Kubernetes CoreDNS

CoreDNS is a DNS server that runs inside Kubernetes and is responsible for service discovery — i.e., translating service names (like my-service.default.svc.cluster.local) into IP addresses.

What CoreDNS Does

In a Kubernetes cluster:

• Every Pod and Service gets its own DNS name.
• CoreDNS listens for DNS queries from Pods (via /etc/resolv.conf).
• It looks up the name in the cluster’s internal DNS records and returns the correct ClusterIP or Pod IP.

So if a Pod tries to reach mysql.default.svc.cluster.local, CoreDNS will resolve it to the IP of the mysql service.

How It Works

Runs as a Deployment in the kube-system namespace.
Has a Service called kube-dns (for backward compatibility).
Uses a ConfigMap (coredns) to define how DNS queries are processed.
Listens on port 53 (UDP/TCP), the standard DNS port.

Example CoreDNS ConfigMap snippet:

apiVersion: v1

kind: ConfigMap

metadata:

  name: coredns

  namespace: kube-system

data:

  Corefile: |

    .:53 {

        errors

        health

        kubernetes cluster.local in-addr.arpa ip6.arpa {

            pods insecure

            fallthrough in-addr.arpa ip6.arpa

        }

        prometheus :9153

        forward . /etc/resolv.conf

        cache 30

        loop

        reload

        loadbalance

    }

Key Plugins

CoreDNS is modular — it uses plugins for specific functionality:

• kubernetes: handles DNS for cluster Services/Pods.
• forward: forwards queries to upstream resolvers for external domains.
• cache: caches responses for faster resolution.
• prometheus: exposes metrics for monitoring.
• health: adds a health endpoint.

Why It Matters

Without CoreDNS, Pods can’t resolve service names.

It’s essential for communication between microservices.

It’s a critical cluster component — if it breaks, DNS resolution (and often your workloads) fail.

kubectl cluster-info reports two things and one of them is that CoreDNS is running. That's how important this service is!

% kubectl cluster-info 

Kubernetes control plane is running at https://94A57AXXXXX5184.gr7.us-east-1.eks.amazonaws.com

CoreDNS is running at https://94A57AXXXXX5184.gr7.us-east-1.eks.amazonaws.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Common Commands

Check CoreDNS pods:

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

We can also get all pods in the cluster and then filter CoreDNS ones:

% kubectl get pods -A | grep coredns

kube-system     coredns-588d4c64bf-t7xkv  1/1   Running   0   314d

kube-system     coredns-588d4c64bf-tfxkz  1/1   Running   0   314d

View CoreDNS logs:

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

Edit CoreDNS config:

kubectl -n kube-system edit configmap coredns

How to prevent disruption of CoreDNS service during node group rolling updates?

Check on which nodes CoreDNS pods are running:

% kubectl get pods -A -o wide  | grep coredns

kube-system    coredns-xxx-yyy   1/1  Running   0  1d   10.1.3.51    ip-10-1-2-123.us-east-1.compute.internal

kube-system    coredns-xxx-yyy   1/1  Running   0  1d   10.1.3.98    ip-10-1-2-123.us-east-1.compute.internal

In this case both pods are on the same node. 

Check CoreDNS pod disruption budget:

% kubectl get pdb -A | grep -E "NAMESPACE|coredns"

NAMESPACE    NAME     MIN AVAILABLE  MAX UNAVAILABLE  ALLOWED DISRUPTIONS   AGE

kube-system  coredns  N/A            1                1                     1d

MAX UNAVAILABLE = 1  is perfect for high availability. As long as we have at least 2 replicas  running, the rolling update will cycle through them safely without losing DNS resolution.

Update Strategy: Check your update_config in Terraform for that node group. If max_unavailable is set to more than 1 (default value is 1), EKS might try to terminate multiple nodes at once, but your PDB will block it, potentially causing a conflict or a very slow update. In that case we can first set it to 1 before we the update.

Resource Headroom: If we are using a Managed Node Group, AWS will usually bring up a new node first (surge) before draining an old one. Ensure our AWS account limits and VPC subnets have enough free IP addresses to accommodate these extra temporary nodes.

---