Why pods need a Service

Pods move; a Service stays put.

You have a Deployment running several pods — but how does anything reach them, when pods come and go and each has a different, temporary IP address? The answer is a Service, and understanding why it exists is the key that makes Kubernetes networking click. Pods move; a Service stays put.

Pods move; a Service stays put

Recall that pods are ephemeral: they are replaced (not moved), each getting a new IP address, so you can never rely on a pod’s address staying valid. That makes talking to your app directly by pod IP hopeless — the address you used a minute ago may belong to a pod that no longer exists. A Service solves this by providing one stable address and name that never changes, sitting in front of your pods. It finds the current pods by label (there are those stickers again) and load-balances incoming traffic across them. So other apps — and users — connect to the Service’s steady name, and the Service takes care of delivering that traffic to whichever pods are alive right now. The pods churn behind the scenes; the Service is the constant, reliable front they hide behind.

apiVersion: v1
kind: Service
metadata: { name: hello }
spec:
  selector: { app: hello }        # find pods wearing this label
  ports: [{ port: 80, targetPort: 8080 }]
# Now anything can reach the app at the STABLE name "hello" (and a stable IP),
# and the Service load-balances to whichever app=hello pods are alive right now.
 
kubectl get endpoints hello       # the current pods the Service is sending to

What the Service gives you

A Service delivers three things at once, all flowing from that stable front. Stable identity: a fixed name and IP that other things can rely on, no matter how the pods behind it change. Load balancing: traffic is spread across all the healthy, ready pods, so scaling up genuinely increases capacity and one pod is never overwhelmed while others idle. And automatic membership: as pods are created, become ready, die, or scale, the Service’s set of targets updates on its own — new pods that match the label join, gone ones drop out, and only ready pods (remember readiness probes) receive traffic. This is why the earlier pieces fit together so neatly: Deployments keep the right pods running, labels connect them, readiness decides which are fit for traffic, and the Service turns that ever-changing set into one dependable endpoint. The next lessons cover the kinds of Service (for internal versus external access) and how names resolve — but the core insight is this one: pods are disposable, and the Service is the stable address that makes them usable.