Service
Pods die and are reborn, taking a new IP each time. A Service puts an unchanging address in front of them and picks what stands behind it by label, not by name. Matching Pods join the list as they appear and drop out as they vanish — while the address callers use never changes.
01Service
Concept at a GlancePods die and come back, and each time they get a new IP. Write a Pod's address down and it won't stay true for long.
A Service puts one address in front that never changes. Inside the cluster, callers just use this name.
Who stands behind it isn't named explicitly. Pods whose labels match the condition are picked automatically.
The two Pods carrying app=web match, and their addresses go into the endpoint list.
api-1 lives in the same cluster but carries a different label. It doesn't match, so it isn't in the list.
web-2 dies. Its address drops off the list, while the address out front doesn't change at all.
The replacement Pod has a different IP. Because its label still matches, it joins with no configuration at all.
Once the new Pod is ready the list is back to two. The caller never learns anything happened.
An incoming request goes to one of the listed addresses. Which Pod takes it is decided at that moment.
02 Understand It Simply
For EveryonePod IPs change on every restart, but a service address is fixed. The pods behind it are selected by label rather than by name, so the endpoint list updates itself.
A Service gets a cluster-internal address (ClusterIP) and a DNS name.
Its selector decides which Pods belong, and the addresses of matching Pods that have finished starting are tracked as its endpoints.
A request is forwarded to one of those endpoints by a proxy layer running on the node (kube-proxy and friends).
Pods that aren't ready never enter the list, so getting readiness right is what keeps traffic away from Pods that can't serve yet.
- –Calling by Service name instead of Pod IP
- –designing a label scheme
- –keeping traffic unbroken during rollouts via readiness
- –and scaling stateless services out
03 Frequently Asked Questions
FAQWhat is Service?+
Pods die and are reborn, taking a new IP each time. A Service puts an unchanging address in front of them and picks what stands behind it by label, not by name. Matching Pods join the list as they appear and drop out as they vanish — while the address callers use never changes.
Where is Service used?+
Calling by Service name instead of Pod IP, designing a label scheme, keeping traffic unbroken during rollouts via readiness, and scaling stateless services out.
What's a simple analogy for Service?+
Pod IPs change on every restart, but a service address is fixed. The pods behind it are selected by label rather than by name, so the endpoint list updates itself.