DNS for Service Discovery: Docker, Kubernetes & the Cloud

In one line

Inside platforms, DNS is how services find each other: Docker's embedded resolver, CoreDNS in Kubernetes, Route 53 private zones, and health-checked records for failover.

0/4 · 0%

Key ideas

01
DOCKER: on a user-defined network, the embedded DNS server at 127.0.0.11 resolves container and service names (postgres, shoplite) to container IPs. That's why the lab compose files in the Observability course could use http://payments:8081 (Docker course, Topic 4.3).
02
KUBERNETES: CoreDNS answers <service>.<namespace>.svc.cluster.local with the Service's ClusterIP; headless Services return the pod IPs directly (used by StatefulSets for stable per-pod names like kafka-0.kafka) (Kubernetes course, Topic 3.4).
03
CLOUD: private hosted zones give internal names inside VPCs; health-checked records (Route 53 failover and latency routing) steer traffic away from unhealthy endpoints (SRE course, Shift 2.3).
04
DNS-based discovery has limits: clients cache, answers can be stale for the TTL, and DNS doesn't know about load. Service meshes and client-side load balancers (Phase 5) add health-aware discovery on top.
05
ExternalDNS (in Kubernetes) creates DNS records automatically from Ingress and Service resources: the 'DNS as code' pattern that removes manual record edits (Platform Engineering course).

Code & diagrams

service-dns.shbash

# Docker: resolve another container by name from inside a container
docker compose exec shoplite getent hosts postgres

# Kubernetes: resolve a service and a headless StatefulSet pod
kubectl run -it --rm dns --image=busybox:1.36 --restart=Never -- nslookup shoplite.default.svc.cluster.local
kubectl run -it --rm dns --image=busybox:1.36 --restart=Never -- nslookup kafka-0.kafka.data.svc.cluster.local

Explain it without notes

Why do StatefulSets use headless Services instead of a normal ClusterIP Service?

Practice

A pod can resolve shoplite but not shoplite.other-namespace. The Service exists in other-namespace. What's the likely cause?

Trade-offs

↔
DNS discovery is universal and simple but coarse (TTLs, no load awareness); mesh-based discovery is richer and faster to react but adds sidecars or node agents and operational complexity.

Done when you can

I know how Docker and Kubernetes resolve service names.
I know when to use headless Services.
I understand DNS-based failover and its caching limits.