Day 31/40 — Understanding CoreDNS In Kubernetes

Overview

Video 31 of the Certified Kubernetes Administrator (CKA) 2024 series. A hands-on deep-dive into CoreDNS, the default cluster DNS server that enables service discovery and name resolution inside Kubernetes. This video is the direct application of the external DNS fundamentals covered in Day 30.

Why Cluster DNS Matters

In Kubernetes, Pod IPs are ephemeral. Every restart, reschedule, or scale event gives a Pod a new IP. Services provide stable ClusterIPs, but remembering IPs is impractical. CoreDNS solves this by maintaining an internal DNS namespace so workloads can reach each other by name — for example, database.default.svc.cluster.local — rather than by volatile IP address.

How CoreDNS Works

  1. A Pod makes a DNS query for a service name (short name or fully qualified domain name).
  2. The query is forwarded to the cluster DNS Service IP (typically the 10th IP in the Service CIDR, e.g., 10.96.0.10).
  3. CoreDNS receives the query via its Kubernetes plugin, looks up the Service in the API server, and returns the corresponding ClusterIP.
  4. For external domains (e.g., google.com), CoreDNS forwards the query upstream using the forward plugin (often to /etc/resolv.conf on the node).

CoreDNS Configuration (Corefile)

CoreDNS behavior is driven by the Corefile, stored as a ConfigMap (coredns in the kube-system namespace). A typical Corefile includes:

  • kubernetes plugin — answers .svc.cluster.local queries by talking to the API server.
  • forward plugin — sends unresolved queries to an upstream resolver.
  • cache plugin — caches responses to reduce API server load.
  • prometheus plugin — exposes metrics on :9153 for observability.
  • health plugin — provides a health endpoint for liveness/readiness probes.

DNS for Kubernetes Service Types

Service TypeDNS Behavior
ClusterIPmy-service.my-namespace.svc.cluster.local resolves to the ClusterIP
HeadlessReturns A records for each backing Pod IP directly
ExternalNameReturns a CNAME record pointing to an external domain

Cross-Namespace DNS

Services are discoverable across namespaces using the full FQDN:

<service>.<namespace>.svc.cluster.local

Within the same namespace, the short name (my-service) resolves automatically.

Troubleshooting Cluster DNS

CommandPurpose
kubectl run -it --rm debug --image=busybox:1.28 --restart=Never -- nslookup kubernetes.defaultTest if Pod DNS works
kubectl logs -n kube-system -l k8s-app=kube-dnsInspect CoreDNS logs
kubectl get configmap coredns -n kube-system -o yamlView and verify the Corefile

Key Takeaways

  1. CoreDNS is the default cluster DNS; it runs as a Deployment in kube-system.
  2. The Corefile defines plugins: kubernetes for internal names, forward for external names, cache for performance.
  3. Service DNS names follow the pattern <service>.<namespace>.svc.cluster.local.
  4. Headless Services return Pod IPs directly; ExternalName Services return a CNAME.
  5. DNS issues in the CKA exam are often caused by misconfigured Corefile, NetworkPolicy blocking UDP 53, or wrong namespace references.

See Also

Wiki Concepts

Creator / Entity