Understand Cluster DNS and Resolve Services by Name

Cluster DNS is the connective tissue of every Kubernetes workload. When a frontend Pod calls web or checkout.payments, it is not hitting hard-coded IPs - it is asking the in-cluster DNS service (CoreDNS by default) to resolve a name that the cluster issues automatically the moment a Service is created. That convention, <service>.<namespace>.svc.cluster.local, is what makes Pod-to-Pod communication portable across nodes, namespaces, and rescheduling events.

CoreDNS runs as an ordinary Deployment in the kube-system namespace, exposed by a ClusterIP Service named kube-dns. Every new Pod is wired to that Service through /etc/resolv.conf, where a carefully tuned search list and the ndots:5 option let you type short names like web and still resolve to the correct workload. In this lab, you will inspect CoreDNS, work across two pre-deployed namespaces that each expose a web Service, launch a throwaway busybox probe Pod, walk the FQDN ladder with nslookup, and then convert one Service to headless to see how DNS exposes individual Pod IPs instead of a single virtual IP.

Objectives

Upon completion of this beginner level lab, you will be able to:

• Inspect the CoreDNS Deployment and the kube-dns Service that exposes it to Pods
• Read /etc/resolv.conf from inside a running Pod and explain the search list and ndots:5 option
• Resolve a Service by short name, namespace-qualified name, and full FQDN using nslookup
• Explain why short names resolve in the local namespace but cross-namespace lookups need qualification
• Compare ClusterIP DNS (one A record) to headless Service DNS (one A record per backing Pod)

Who is this lab for?

This lab is designed for:

• Beginner Kubernetes learners who know what Pods and Services are but have not traced how names resolve
• CKAD and CKA candidates learning service discovery mechanics
• Developers and SREs debugging in-cluster connectivity