DNS and CoreDNS in Kubernetes
- date
- category
- Containers
- also in
- Networking
- reading
- 2 min / 337 words
The Kubernetes network makes communication over IP addresses possible.
The problem is that addresses are not a good interface for applications.
Pods are dynamic:
- they can be deleted,
- they can be created again,
- they can get a different IP address,
- they can be moved to another node.
That is why applications need a stable way to find services.
DNS plays that role.
CoreDNS
The standard DNS server used in Kubernetes is CoreDNS.
Its job is to serve names related to cluster resources.
Example:
backend.default.svc.cluster.local
Such a name can point to a Service named backend in the default namespace.
The application doesn't need to know a specific IP.
Why DNS matters
Imagine two applications:
frontend
backend
The frontend wants to connect to the backend.
Without DNS it would have to know a specific address:
10.96.32.15
With DNS it can use:
backend
That is much more resilient to infrastructure changes.
What the flow looks like
In simplified form:
frontend Pod
|
v
DNS query
|
v
CoreDNS
|
v
Service IP
Only then does the actual network communication begin:
Service IP
|
v
kube-proxy / eBPF
|
v
backend Pod
This is an important distinction.
DNS doesn't carry application traffic.
DNS only answers:
at what address is the thing you are looking for?
CoreDNS and Service
CoreDNS and Service are related, but responsible for different things.
A Service provides a stable logical address.
CoreDNS provides a stable name.
You can write it down like this:
name
|
v
CoreDNS
|
v
Service IP
|
v
network datapath
|
v
Pod
CoreDNS and kube-proxy
The simplest distinction:
CoreDNS
-> turns a name into an address
kube-proxy / eBPF
-> directs traffic to an endpoint
If DNS works but the datapath is broken, the application can resolve the name correctly, but the connection still won't work.
If the datapath works but DNS doesn't, communication over IP may work, but communication over names won't.
Is CoreDNS part of the control plane?
Not in the same sense as:
- kube-apiserver,
- scheduler,
- controller-manager,
- etcd.
CoreDNS usually runs as a workload in the cluster.
Even so, it is such a basic part of most Kubernetes installations that it almost always comes up when discussing the architecture.
What to remember
CoreDNS is responsible for service discovery by name.
It is not responsible for routing packets or starting applications.
In short:
CoreDNS
-> "where?"
network datapath
-> "how do I get there?"