Kubernetes Service Discovery Clearly Explained !!!
Every Pod in Kubernetes gets its own IP. Sounds great… until it breaks your system.
In a Deployment, you don’t run just one Pod. You run multiple replicas:
pod-1 → 10.0.0.1
pod-2 → 10.0.0.2
pod-3 → 10.0.0.3
Each Pod has its own IP. So far, so good.
Now imagine another service wants to call this app. What should it use?
10.0.0.1?
10.0.0.2?
10.0.0.3?
There’s no single stable address. Already a problem.
Now it gets worse. Pods are ephemeral. If a Pod dies:
it is deleted
a new Pod is created
with a completely NEW IP
Example:
old pod → 10.0.0.2 ❌
new pod → 10.0.0.9 ✅
Your system is now pointing to a dead IP. So the real problem is:
👉 Pod IPs are dynamic
👉 Clients need a stable way to connect
Without that, service-to-service communication is unreliable. This is exactly what Kubernetes Services solve.
Instead of pointing to Pods directly, you create a Service. And here’s the key idea:
👉 You don’t connect to Pods
👉 You connect to a logical group of Pods
How does Kubernetes know which Pods belong to that group?
Using: labels & selectors
Pods are tagged with labels:
labels:
app: user-service
The Service defines a selector:
selector:
app: user-service
That’s it. This simple mapping connects them. Now Kubernetes keeps track of:
“All Pods with label app=user-service belong to this Service”
Even if Pods die or restart or scale up/down, The mapping is always updated.
And the Service gives you a stable entry point:
a fixed IP (ClusterIP)
a DNS name
So clients just call:
👉 user-service
Not individual Pods.
Behind the scenes Service finds matching Pods via labels traffic is routed to one of them, dead Pods are automatically removed, new Pods are automatically added
No manual updates.
So the transformation is:
❌ Before: Call fragile Pod IPs that keep changing
✅ After: Call a stable Service that tracks Pods dynamically
If you remember one thing:
Kubernetes doesn’t make Pods stable. It makes access to Pods stable.
That’s the real purpose of a Service. Not just load balancing. But solving the “changing IP” problem elegantly.
