Cluster DNS and Service Discovery

Service discovery in Kubernetes is DNS. A component called CoreDNS runs in the cluster and resolves Service names to their virtual IPs, so a Pod can reach another service by name — orders or orders.shop.svc.cluster.local — without ever knowing an IP.

It is the glue that makes the flat network usable. Pods come and go and their IPs change; the Service name is stable, and DNS is how everything finds everything else.

CoreDNS in the Cluster

CoreDNS runs as a Deployment, fronted by a Service, and every Pod is configured to use it as its resolver. When a Pod looks up a Service name, CoreDNS answers with the Service's ClusterIP; from there kube-proxy takes over. CoreDNS watches the API server, so as Services appear and disappear its records update automatically. It is a critical-path component — when DNS is slow or down, the whole cluster feels broken.

Service DNS Names

Services follow a predictable naming scheme: <service>.<namespace>.svc.cluster.local. Within the same namespace, the short name orders resolves; from another namespace you need orders.shop or the full name. This is also why namespaces are not a network boundary — any Pod can reach any Service by its fully qualified name unless a NetworkPolicy says otherwise.

# same namespace
curl http://orders/

# another namespace (shop)
curl http://orders.shop/

# fully qualified
curl http://orders.shop.svc.cluster.local/

Headless Services and Per-Pod DNS

A normal Service resolves to one virtual IP. A headless Service (clusterIP: None) instead returns the individual Pod IPs as multiple DNS records, and, paired with a StatefulSet, gives each Pod a stable per-Pod name like db-0.db.shop.svc.cluster.local. This is how clustered systems address specific members rather than a load-balanced pool — the DNS companion to StatefulSets (Topic 14).

Resolution Gotchas

Two issues bite in practice. The ndots setting in a Pod's resolv.conf causes short names to be tried against several search domains first, so a lookup of an external host can fire several failed queries before succeeding — measurable latency at scale, often fixed by using fully qualified names (a trailing dot) for external hosts. And CoreDNS itself must be scaled and monitored: an under-provisioned CoreDNS becomes a cluster-wide bottleneck, since every connection starts with a name lookup.