Finding things by name
Cluster DNS, simply.
Inside a cluster, apps find each other by name, not by chasing IP addresses — and cluster DNS is what makes those names resolve. It is like a phone book that is always up to date: you look up a Service by its name and get its current address, so your app config can use stable names instead of brittle IPs.
Finding things by name
Kubernetes runs a DNS service in the cluster (CoreDNS) that automatically gives every Service a name, and every pod is set up to use it. So instead of hardcoding an IP, your app connects to a Service by name — and because the Service’s address is stable, the name is a reliable, permanent handle. The naming follows a simple, predictable pattern: within the same namespace you can use just the Service’s short name (db), from another namespace you add the namespace (db.data), and the fully-qualified form is service.namespace.svc.cluster.local. This is why you can write your database connection string as db (or db.data) in your config and it just works, no matter how the actual pods and IPs behind that Service change — the name resolves to the Service, and the Service routes to the live pods.
# A Service "db" in namespace "data" is reachable by name as:# db (from the same namespace)# db.data (from another namespace)# db.data.svc.cluster.local (fully-qualified)kubectl exec -it my-app -- nslookup db.data # test that a name resolves# Your app config can just say host: db.data — no IPs, ever.
Why names beat IPs
Using names instead of IPs is what makes a Kubernetes app portable and resilient. The IPs of pods (and even Services) can change, but the names do not, so your configuration written against names keeps working as the cluster reshuffles underneath. It also makes apps environment-independent: the same manifest referring to db.data works in dev, staging, and prod because the name pattern is consistent everywhere. One thing worth filing away for later: because everything relies on DNS, if cluster DNS breaks, apps suddenly cannot find each other and it can look like a widespread outage — so DNS is one of the first things experienced operators check when many things fail at once (you will see this in the troubleshooting material). But for fundamentals, the happy takeaway is that you address services by friendly, stable names and the cluster’s built-in DNS resolves them to the right place automatically. Combined with Services (stable addresses) and labels (how Services find pods), naming completes the picture of how the pieces of your app connect to each other reliably.