DNS and Service Discovery
Understand how Pods find each other using Kubernetes built-in DNS, and how Service discovery works under the hood.
DNS and Service Discovery is a free DevOps Bootcamp lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the DevOps Bootcamp learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
The Service Discovery Problem
Pods come and go, and their IPs change constantly. Hardcoding IPs would break instantly. Kubernetes solves this with DNS-based service discovery.
Instead of an IP, you talk to a stable name.
Cluster DNS
Every cluster runs a DNS service (usually CoreDNS). It automatically creates DNS records for Services and Pods, so names resolve to the right ClusterIP.
Service DNS Names
A Service gets a DNS name following a predictable pattern:
service-name.namespace.svc.cluster.local
Within the same namespace you can just use the short service-name.
# from a Pod in the same namespace
curl http://payment-service:8080
# fully qualified, from any namespace
curl http://payment-service.shop.svc.cluster.local:8080Namespaces and Naming
The namespace is part of the name. To reach a Service in another namespace, include it: service.namespace.
# Pod in 'frontend' namespace calling 'backend' namespace
curl http://api.backend.svc.cluster.localTesting DNS from a Pod
You can launch a throwaway Pod to test name resolution.
kubectl run dnstest --image=busybox:1.36 --rm -it --restart=Never -- nslookup payment-serviceHow CoreDNS Resolves Names
When a Pod queries a name, the request goes to CoreDNS. It looks up the matching Service and returns its ClusterIP. For headless Services it returns the Pod IPs directly.
Headless Services
A headless Service (clusterIP: None) skips the single virtual IP. DNS instead returns the individual Pod IPs, which is essential for stateful apps that address Pods directly.
apiVersion: v1
kind: Service
metadata:
name: db
spec:
clusterIP: None
selector:
app: db
ports:
- port: 5432Pod DNS Records
With a headless Service, each backing Pod can also get its own DNS record, useful for StatefulSets where Pods have stable identities like db-0, db-1.
# stable per-Pod name in a StatefulSet
curl http://db-0.db.default.svc.cluster.local:5432Inspecting Pod resolv.conf
Kubernetes injects DNS config into each Pod. The search domains let short names resolve correctly.
kubectl exec -it mypod -- cat /etc/resolv.conf
# nameserver 10.96.0.10
# search default.svc.cluster.local svc.cluster.local cluster.localEnvironment Variables vs DNS
Kubernetes also injects Service connection info as environment variables, but only for Services that existed when the Pod started. DNS is preferred because it always reflects the current state.
Common DNS Pitfalls
- Forgetting the namespace when calling across namespaces
- Expecting DNS for a Service with no matching Pods (no endpoints)
- Caching stale IPs in the app instead of re-resolving the name
Quick Check
Choose the correct DNS name format.
Recap
You learned that Kubernetes uses CoreDNS to give Services stable DNS names following service.namespace.svc.cluster.local. Short names work within a namespace, headless Services expose individual Pod IPs, and DNS always reflects the current cluster state.
Frequently asked questions
Is the “DNS and Service Discovery” lesson free?
Yes — the full text of “DNS and Service Discovery” is free to read here on the web, and the DevOps Bootcamp course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the DevOps Bootcamp course, upgrade to CoddyKit PRO.
What will I learn in “DNS and Service Discovery”?
Understand how Pods find each other using Kubernetes built-in DNS, and how Service discovery works under the hood. You practise DevOps Bootcamp with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start DevOps Bootcamp?
No prior experience is required. DevOps Bootcamp on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “DNS and Service Discovery” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this DevOps Bootcamp lesson?
Yes. Every DevOps Bootcamp lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.