Your web app runs in the namespace web and needs to reach a Service named db that lives in the namespace data. What host should its config use?

db.data. From another namespace you add the namespace on the end, so db.data resolves to the db Service over in the data namespace, and it keeps working as Pods and IPs change.

The lesson says seasoned operators check cluster DNS first when a pile of unrelated apps break at the same time. Why?

Almost everything finds its dependencies by name through DNS, so one broken CoreDNS makes many apps fail together and looks like a huge mysterious outage. Because name lookups are the shared dependency, a single DNS fault surfaces as widespread, unrelated-looking failures.

You apply the db Service in namespace data but create no Pods carrying the label app: db. From another Pod in namespace data you run nslookup db. What comes back?

The Service's ClusterIP, such as 10.96.45.12, because a Service gets a name and address the moment it exists, though a real connection would then have no Pod to land on. DNS resolves a Service as soon as it is created, independent of whether any Pods back it yet.

Courses Kubernetes fundamentalsFinding things by name

Finding things by name

Cluster DNS, simply.

Beginner8 min · lesson 18 of 24

In plain terms

CoreDNS resolves service / service.namespace to the Service IP.

Cluster DNS lets apps find each other by name instead of memorizing IPs. DNS (Domain Name System) turns a name into the address a computer dials. A cluster is the group of machines Kubernetes runs your apps on.

Pods get replaced, and each replacement gets a new IP (for example 10.96.45.12). If the frontend hard-coded a pod IP, it would break on the next swap. Point apps at a Service: a stable name and address in front of those Pods. CoreDNS, the cluster DNS server, resolves that name to the Service IP.

The names follow a pattern. Say a Service named db lives in namespace data. A namespace is a named slice of the cluster that keeps one team's objects apart from another's. From the same namespace, the short name is db. From another namespace, use db.data. The full name is db.data.svc.cluster.local. All three point at the same Service; you will type the short one most days.

Set up a Service to find

Let's make this real instead of theoretical. The namespace called data doesn't exist yet, and you can't drop a Service into a namespace that isn't there, so you make it first. A namespace, remember, is that named area that keeps one team's things apart from another's.

terminal

kubectl create namespace data

output

namespace/data created

Now you need a Service worth looking up. Below is a complete file you can save and apply exactly as it is. It creates a Service named db in the data namespace that sends traffic to any Pod wearing the label app: db. A label is just a small key-value tag you stick on Pods so a Service knows which ones belong to it. You won't create any Pods with that label here, and that's fine. A Service gets its name and address the moment it exists, so DNS can answer for it even before a single Pod shows up.

db-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: db
  namespace: data
spec:
  selector:
    app: db
  ports:
    - port: 5432
      targetPort: 5432

terminal

kubectl apply -f db-service.yaml

output

service/db created

Now ask the cluster for that Service's current address. kubectl is the command-line tool you use to talk to the cluster, and the -n flag tells it which namespace to look in.

terminal

kubectl get svc db -n data

output

NAME   TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
db     ClusterIP   10.96.45.12    <none>        5432/TCP   12s

That CLUSTER-IP, 10.96.45.12, is the number a caller would otherwise have to know. You won't type it anywhere. The name db carries it for you, and the number is free to change without you ever noticing.

Look the name up

You can watch DNS do its job with one command. This spins up a tiny throwaway Pod, runs a name lookup inside the cluster, and deletes itself the moment it finishes. Because you don't pass -n, the Pod lands in the default namespace, so you'll reach db by its cross-namespace name, db.data.

terminal

kubectl run dnstest --rm -it --image=busybox:1.36 --restart=Never -- nslookup db.data

output

Server:    10.96.0.10
Address:   10.96.0.10:53
 
Name:      db.data.svc.cluster.local
Address:   10.96.45.12
 
pod "dnstest" deleted

The lookup came back with the full name db.data.svc.cluster.local and the address 10.96.45.12, the exact number you saw a moment ago. That Server line, 10.96.0.10, is CoreDNS itself answering. In your app's config, the database host is simply db.data. No IP addresses live in your files, and there is nothing to edit when Pods come and go underneath.

Now watch it fail

Beginners hit this one constantly, so it's worth seeing on purpose. The throwaway Pod is in the default namespace, not data. Ask it for the bare short name db, and there is nothing for CoreDNS to match, because a short name only means something inside the Service's own namespace.

terminal

kubectl run dnstest --rm -it --image=busybox:1.36 --restart=Never -- nslookup db

output

Server:    10.96.0.10
Address:   10.96.0.10:53
 
*** Can't find db: No answer
 
pod "dnstest" deleted
pod default/dnstest terminated (Error)

Read what it's telling you. CoreDNS answered on the first two lines, so DNS is healthy; it simply had no record for db from where you asked. The last line, terminated (Error), is just nslookup exiting non-zero because the lookup came up empty, not a cluster fault. The fix is the one you already ran: add the namespace and ask for db.data (or the full db.data.svc.cluster.local), and the answer comes straight back. This single mistake, a short name used from the wrong namespace, is behind a large share of 'my app can't reach the database' tickets.

How a name becomes a real address

You only ever write the name. Everything to the right of it can change freely, and your config never has to.

Writing your config against names instead of numbers is what makes an app easy to move and hard to break. Pod addresses shift constantly, and even a Service's address can change if it gets recreated, but the names stay put. Your config keeps working while the cluster reshuffles beneath it. The same file that says db.data runs unchanged in your test setup, in staging, and in production, because the naming pattern is identical in every cluster. And because almost everything finds its dependencies through DNS, a broken cluster DNS makes many apps fail at once and can look like a giant mysterious outage when it's really one thing. Seasoned operators check DNS first whenever a pile of unrelated things breaks together, and you'll practice that in the troubleshooting lessons.

Cluster DNS (CoreDNS) lets pods find Services by name: short names inside a namespace, FQDNs across namespaces. Prefer DNS names in config maps over IPs. When DNS breaks, everything looks like an app outage.

Debug with nslookup from a busybox pod toward service.namespace.svc.cluster.local. If DNS fails but ClusterIP curl works, you have a DNS/path problem instead of a Service selector problem.

In production, watch CoreDNS replicas and latency. A starved CoreDNS is a cluster-wide incident waiting to happen.

Try this

From a debug pod, resolve a Service short name and FQDN, then wget the Service to prove name → VIP → pod.

terminal

$ kubectl create deployment svcname --image=nginx:1.27 --replicas=1
deployment.apps/svcname created
$ kubectl expose deployment svcname --port=80
service/svcname exposed
 
$ kubectl run dnsbox --image=busybox:1.36 --restart=Never --command -- sleep 300
pod/dnsbox created
 
$ kubectl exec dnsbox -- nslookup svcname
Server:    10.96.0.10
Name:      svcname.default.svc.cluster.local
Address:   10.96.88.21
 
$ kubectl exec dnsbox -- nslookup svcname.default.svc.cluster.local
Name:      svcname.default.svc.cluster.local
Address:   10.96.88.21
 
$ kubectl exec dnsbox -- wget -qO- http://svcname | Select-String nginx | Select-Object -First 1
Welcome to nginx!
 
$ kubectl delete pod dnsbox; kubectl delete svc svcname; kubectl delete deployment svcname
pod "dnsbox" deleted
service "svcname" deleted
deployment.apps "svcname" deleted

Takeaway

Use Service DNS names, not pod IPs. Verify with nslookup from a debug pod, and treat CoreDNS health as tier-0 infrastructure for the whole cluster.

The short name only works in its own namespace

Calling a Service by its bare name, like db, only resolves from inside the same namespace. If your app runs in the web namespace and the database Service lives in data, plain db won't be found and you'll get a 'not found' error like the one above. Add the namespace and use db.data instead. When a connection works within a namespace but fails across one, this is almost always the reason.

The kinds of ServiceIngress: one front door

Cluster architectureKubernetes administration Security domains & threat modelKubernetes security & hardening The cluster attack surfaceKubernetes attack & defense Kubernetes interview questionsInterview prep

Finding things by name

Set up a Service to find

Look the name up

Now watch it fail

Try this

Takeaway

Related