How Kubernetes DNS Works: Service Discovery Explained
Exploring and building innovative tech solutions for the future while documenting the insights and knowledge gained along the way.
Kubernetes is built to run distributed applications where hundreds or even thousands of containers communicate with each other.
But there is a challenge.
Pods in Kubernetes are ephemeral — they can be created, destroyed, and recreated at any time. Their IP addresses constantly change.
So how do services in a Kubernetes cluster find and communicate with each other reliably?
The answer is Kubernetes DNS.
In this article, we will understand how Kubernetes DNS works, how service discovery happens, and how CoreDNS enables internal communication inside the cluster.
Why Kubernetes Needs DNS
In a traditional system, applications communicate using static IP addresses or hostnames.
But in Kubernetes:
Pods are temporary
Pod IPs change frequently
Pods can be rescheduled to different nodes
Because of this, applications cannot rely on fixed IPs.
Instead, Kubernetes provides service discovery using DNS names.
Applications communicate like this:
http://frontend-service
http://payment-service
http://user-service
Instead of using IP addresses.
Kubernetes automatically resolves these names to the correct service.
What is Kubernetes DNS?
Kubernetes DNS is a built-in DNS system inside the cluster that allows Pods and services to discover each other using DNS names.
It works similarly to the internet DNS system:
Example:
google.com → resolves to an IP
Inside Kubernetes:
frontend-service.default.svc.cluster.local → resolves to a Service IP
So instead of remembering IPs, applications simply use service names.
CoreDNS: The DNS Engine of Kubernetes
Kubernetes uses CoreDNS as its DNS server.
CoreDNS runs as a pod inside the Kubernetes cluster and handles all DNS queries from other Pods.
CoreDNS is responsible for:
Resolving service names
Resolving pod names
Managing DNS records inside the cluster
Enabling service discovery
You can see CoreDNS running using:
kubectl get pods -n kube-system
Example output:
coredns-558bd4d5db-abc12
coredns-558bd4d5db-def34
These pods listen for DNS queries from all other pods.
How Service Discovery Works
Service discovery means automatically finding services without knowing their IP addresses.
In Kubernetes, services are given DNS names.
For example, if you create a service:
frontend-service
Other pods can call it using:
http://frontend-service
Behind the scenes:
DNS → resolves name → Service IP → load balances to Pods
This makes microservices communication simple.
Kubernetes DNS Naming Structure
Kubernetes follows a structured DNS naming format.
The full DNS name of a service looks like this:
<service-name>.<namespace>.svc.cluster.local
Example:
frontend-service.default.svc.cluster.local
Breakdown:
| Part | Meaning |
|---|---|
| frontend-service | Service name |
| default | Namespace |
| svc | Indicates service |
| cluster.local | Cluster domain |
Usually, applications only use:
frontend-service
or
frontend-service.default
Kubernetes automatically resolves the full DNS name.
DNS Records in Kubernetes
Kubernetes automatically creates DNS records for services.
ClusterIP Service
For a standard service:
frontend-service
DNS record:
frontend-service.default.svc.cluster.local → ClusterIP
Example:
frontend-service → 10.96.32.10
Traffic then goes to the backend pods.
Headless Service
If a service is headless, DNS returns individual pod IPs instead of a service IP.
Example DNS result:
pod1 → 10.244.1.5
pod2 → 10.244.2.8
pod3 → 10.244.3.4
This is commonly used in:
Databases
StatefulSets
Kafka clusters
How Kubernetes DNS Resolution Works
Let’s say a pod wants to call a service.
Example request:
http://frontend-service
The process works like this.
Step 1: Pod sends DNS query
The Pod sends a request to resolve:
frontend-service
Step 2: Request goes to CoreDNS
The query is forwarded to the CoreDNS pod running in the cluster.
Step 3: CoreDNS checks Kubernetes API
CoreDNS checks the Kubernetes API server for a service named:
frontend-service
Step 4: CoreDNS returns Service IP
CoreDNS returns the ClusterIP:
frontend-service → 10.96.32.10
Step 5: Service routes traffic to Pods
The service forwards traffic to the backend pods.
Example:
Pod A → frontend-service → Pod B
Complete Communication Flow
The entire flow looks like this:
Pod A
|
| DNS Query
v
CoreDNS
|
| returns Service IP
v
Service (ClusterIP)
|
| load balances
v
Backend Pods
Or simply:
Pod → DNS → Service → Pod
This mechanism enables dynamic microservice communication inside Kubernetes clusters.
Example: Real Kubernetes DNS Name
Suppose we deploy a service called:
frontend-service
in the default namespace.
Full DNS name:
frontend-service.default.svc.cluster.local
A backend pod can call it like:
curl http://frontend-service
or
curl http://frontend-service.default
Both will resolve correctly.
Why Kubernetes DNS is Important
Kubernetes DNS provides several benefits.
1. Service Discovery
Pods can find services without knowing IP addresses.
2. Loose Coupling
Applications communicate using names instead of fixed infrastructure.
3. Scalability
Services can scale without changing application configuration.
4. Fault Tolerance
If pods restart or move nodes, DNS still resolves correctly.
Kubernetes DNS in DevOps Interviews This topic is frequently asked in DevOps and Kubernetes interviews. Common questions include:
1. What is CoreDNS?
CoreDNS is the DNS server used inside a Kubernetes cluster.
It is responsible for resolving service names into IP addresses.
When a pod tries to connect to a service using its name, the request goes to CoreDNS, which returns the correct IP address.
Example:
frontend-service.default.svc.cluster.local
CoreDNS resolves this name to the ClusterIP of the service.
2. How does Kubernetes Service Discovery work?
Kubernetes uses DNS-based service discovery.
Instead of using IP addresses, applications communicate using service names.
Flow:
Pod → DNS Query → CoreDNS → Service IP → Pod
Example:
Backend Pod calls:
http://user-service
CoreDNS resolves user-service to its ClusterIP, and the request is routed to one of the backend pods.
3. What is the DNS format of a Kubernetes Service?
Kubernetes services follow a structured DNS naming convention:
<service-name>.<namespace>.svc.cluster.local
Example:
payment-service.default.svc.cluster.local
Where:
| Part | Meaning |
|---|---|
| service-name | Name of the service |
| namespace | Kubernetes namespace |
| svc | Indicates a service |
| cluster.local | Default cluster domain |
Most of the time you only need to use:
payment-service
if both pods are in the same namespace.
4. What is a Headless Service?
A Headless Service is a service that does not assign a ClusterIP.
Instead of returning one service IP, DNS returns the IP addresses of all pods behind the service.
Example:
database.default.svc.cluster.local
DNS might return:
10.244.1.5
10.244.1.6
10.244.1.7
Headless services are commonly used with:
Stateful applications
Databases
StatefulSets
5. How does Pod-to-Service communication work?
Step-by-step flow:
A pod sends a request to a service name.
The request goes to CoreDNS.
CoreDNS returns the ClusterIP of the service.
Kubernetes kube-proxy routes the request to one of the backend pods.
Flow diagram:
Pod A
│
▼
DNS Query
│
▼
CoreDNS
│
▼
Service (ClusterIP)
│
▼
Pod B / Pod C / Pod D
This enables dynamic service discovery without hardcoding IP addresses.
Final Thoughts
Kubernetes DNS plays a crucial role in enabling automatic service discovery inside a cluster. Instead of relying on fixed IP addresses, applications communicate using service names, making deployments more scalable and resilient.
Understanding how CoreDNS, services, and DNS records work together is essential.
