CoreDNS & Service Discovery

In one line

CoreDNS is what actually resolves a Service's name into its ClusterIP — every pod is automatically configured to use it, which is why service discovery in Kubernetes just works without any manual DNS configuration.

0/4 · 0%

Think of it like this

A company-wide internal phone directory that automatically updates itself the instant anyone joins, leaves, or changes desks — nobody has to manually maintain it, and everyone in the building looks things up the exact same way. CoreDNS is exactly this automatic, self-maintaining directory for every Service in the cluster.

Key ideas

01
CORE DNS is the cluster's internal DNS server, typically running as a Deployment (with its own Service) inside kube-system — it watches the API server for Services (and other objects) and automatically creates matching DNS records, with zero manual configuration required for any individual Service.
02
Every pod in the cluster is automatically configured (via its /etc/resolv.conf, set up by the kubelet at pod creation) to use CoreDNS as its DNS resolver — this is precisely why http://my-app-svc (Topic 1.2) or the fully-qualified my-app-svc.staging.svc.cluster.local (Topic 2.2) just resolves correctly from inside any pod, with no manual /etc/hosts entries or DNS setup needed anywhere.
03
The full DNS naming pattern for a Service is <service-name>.<namespace>.svc.cluster.local — within the SAME namespace, just <service-name> resolves (the resolver automatically tries the current namespace first); across namespaces, the fully-qualified form (or at minimum <service-name>.<namespace>) is required, exactly as Topic 2.2 already covered from the namespace side of this same mechanism.
04
Pods themselves can also get DNS entries — a StatefulSet's pods (Topic 1.3) specifically rely on this, getting predictable per-pod DNS names like my-db-0.my-db-headless-svc.<namespace>.svc.cluster.local, which is exactly the mechanism that lets other systems address one SPECIFIC stateful replica reliably by name.
05
kubectl exec into any pod and running nslookup <service-name> (or cat /etc/resolv.conf) is the standard way to directly verify DNS resolution is working correctly from that pod's own point of view — genuinely useful as an early, fast diagnostic step whenever a pod reports it 'can't find' a service it should be able to reach.

Code & diagrams

CoreDnsResolutiondiagram

Every pod is automatically pointed at CoreDNS — no manual configuration, anywhere, ever.

Rendering diagram…

dns-debugging.shmarkdown

Confirm DNS resolution works from a pod's own perspective — an essential first diagnostic step.

# See CoreDNS itself running as a normal Deployment
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl get svc -n kube-system kube-dns

# Confirm any pod's resolver configuration
kubectl exec -it <any-pod> -- cat /etc/resolv.conf
# nameserver <coredns-service-ip>
# search <namespace>.svc.cluster.local svc.cluster.local cluster.local

# Test resolution directly, from inside a pod
kubectl run dns-test --rm -it --image=busybox -- nslookup my-app-svc
kubectl run dns-test --rm -it --image=busybox -- nslookup my-app-svc.staging.svc.cluster.local

# A StatefulSet pod's own predictable, per-pod DNS name
kubectl run dns-test --rm -it --image=busybox -- nslookup my-db-0.my-db-headless-svc.production.svc.cluster.local

Explain it without notes

Why does a Service's name just resolve correctly from inside any pod with zero manual DNS configuration required?

You're inside a pod in the 'checkout' namespace trying to reach a Service called payments-svc that lives in the 'payments' namespace. What name should you actually use, and why won't the short name work?

Practice

From any pod, run cat /etc/resolv.conf and identify the nameserver IP and the search domains listed — compare the nameserver IP against CoreDNS's own Service IP.

Use nslookup from a temporary test pod to resolve a Service both by its short name (same namespace) and its fully-qualified name (works from any namespace) — confirm both actually work as expected.

Trade-offs

↔
CoreDNS's fully-automatic service discovery removes an enormous amount of manual DNS management compared to a traditional, non-Kubernetes environment — but it does mean DNS itself becomes a genuinely critical, load-bearing cluster component; a CoreDNS outage or misconfiguration can make services that are otherwise perfectly healthy appear completely unreachable to everything else in the cluster, which is exactly why CoreDNS's own health and resource allocation deserves real monitoring attention in any production cluster, not just the applications running on top of it.

Done when you can

I understand CoreDNS is what actually resolves Service names, and that every pod is automatically configured to use it.
I can explain the short-name-vs-fully-qualified-name distinction for cross-namespace Service resolution.
I can use nslookup from inside a pod to directly debug a DNS resolution problem.