Kubernetes DNS: How Pods Find Each Other
Kubernetes DNS gives services and pods stable, human-readable names so you don't have to track ephemeral IP addresses. It's how a frontend pod finds a backend service.
WHY IT EXISTS: Pods in Kubernetes are ephemeral; they can be created, destroyed, and moved at any time. This means their IP addresses are constantly changing. Hardcoding IP addresses for communication between application components would be brittle and unmanageable. Kubernetes DNS was created to provide a stable, name-based service discovery mechanism inside the cluster.
THE MENTAL MODEL: Think of Kubernetes DNS as your cluster's internal, automatic phonebook. When you create a Service named api-server in the production namespace, K8s DNS automatically creates an entry for it. Any pod in that namespace can now simply "call" api-server by name, and K8s will route the traffic to the correct, healthy backend pods, no matter what their current IPs are.
HOW IT WORKS: Kubernetes runs a dedicated DNS service within the cluster, usually CoreDNS. When a pod starts, its DNS configuration is automatically set to query this internal DNS service. For a Service named my-svc in namespace my-ns, Kubernetes creates DNS A/AAAA records. A pod in the same namespace can resolve my-svc directly. A pod in a different namespace must use the fully qualified domain name (FQDN): my-svc.my-ns.svc.cluster.local. Pods also get a DNS name, typically in the format pod-ip-address.namespace.pod.cluster.local.
WHEN TO USE IT: This is the default and recommended way for applications inside a cluster to communicate with each other. It's the foundation for most microservice architectures on Kubernetes, used for frontend-to-backend communication, inter-service calls, and connecting applications to databases running as Services within the same cluster.
WHEN NOT TO USE IT: You wouldn't use the internal cluster DNS for external clients trying to reach your services; that's the job of an Ingress or a Service of type LoadBalancer. It's also generally an anti-pattern to try to bypass it for static IP needs within the cluster, as this fights against Kubernetes's dynamic nature.
ONE CANONICAL EXAMPLE: A webapp pod needs to talk to a database service. The database service is defined in YAML with the name db-main in the same namespace. The webapp's connection string can be configured to use the hostname db-main. Kubernetes DNS will resolve db-main to the Service's stable ClusterIP, which then load-balances traffic to the healthy database pods. If a database pod fails and is replaced, its new IP is updated automatically, but the db-main name remains the stable endpoint, requiring no changes to the webapp.
Read the original → kubernetes.io
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.