Full lesson
Explore the full explanation, examples, and visuals at your own pace.
Pod A disappears. The Service address does not.
Pod A’s IP can disappear without forcing the client to change where it connects. The client uses the stable Service address; Kubernetes changes which Pod receives traffic behind it. The important question is how the Service finds that replacement.
The selector matches labels, not IP addresses.
The web Service doesn’t select Pod A by its IP. It selects the app=web label, which Pod A matches. That label-based link gives Kubernetes a way to find matching Pods as their IPs change.
Replacement Pod B gets a different IP.
Pod B takes over with a new address, 10.0.0.9 instead of Pod A’s 10.0.0.8, but keeps the app=web label. The Service can match it; Kubernetes still has to update its destination list before traffic reaches it.
EndpointSlice records the current ready destination.
When Pod B becomes ready, the controller updates the Service’s EndpointSlice with 10.0.0.9, replacing Pod A as a destination; the Service address stays stable while its ready Pod destinations change.
Pod B has app=web but is not ready yet. Should it appear as a ready destination for the Service?
Let's think this through. Pod B has app=web but is not ready yet. Should it appear as a ready destination for the Service? A: Yes, because its label matches. B: No, it must also become ready. C: Yes, if its IP differs from Pod A. Choose an answer, or just think it through. I'll explain in a moment.
- Yes, because its label matches
- No, it must also become ready
- Yes, if its IP differs from Pod A
Pod B has app=web but is not ready yet. Should it appear as a ready destination for the Service?
The answer is B: No, it must also become ready. The label makes Pod B a match, but readiness determines whether it is an eligible destination. A new IP does not prevent routing once the endpoint and forwarding rules update.
- Yes, because its label matches
- No, it must also become ready
- Yes, if its IP differs from Pod A
Node rules forward new connections to Pod B.
kube-proxy watches changes to the Service and its EndpointSlice, then updates node rules to point the stable Service IP at ready Pod B. The client’s packets follow those rules; they don’t pass through kube-proxy for each request.
What to check during replacement
During replacement, check that Pod B matches app=web and is ready. Then confirm the EndpointSlice reflects it; updates take time, so the Service address can't guarantee uninterrupted traffic.
- Does Pod B have app=web?
- Is Pod B ready?
- Has the EndpointSlice updated?
Same Service IP, updated Pod destination.
A Service selects Pods by labels, while EndpointSlices track eligible destinations and node rules forward traffic. Pod B’s matching label and readiness put it behind the unchanged Service address.