Why Kubernetes Services exist

WHAT THIS TESTS The foundational reason the Service abstraction exists: Pods are cattle, not pets, and their IPs are unstable.

A GOOD ANSWER COVERS Every Pod gets its own IP, but that IP is tied to that specific Pod instance. When a Pod crashes, is rescheduled to another node, is replaced during a rolling update, or scales up and down, it gets a new IP. Any client that hard-coded the old IP breaks. A Service solves this by providing a stable, long-lived virtual IP (the ClusterIP) and a DNS name that do not change as the backing Pods churn. The Service uses a label selector to dynamically discover the current set of matching, healthy Pods and load-balances incoming connections across them.

COMMON WRONG ANSWERS Asserting Pod IPs are stable; they are not across restarts or rescheduling. Treating Services as only for external exposure, when the most common type, ClusterIP, is for internal traffic. Ignoring load balancing as a benefit.

LIKELY FOLLOW-UPS How does the Service know which Pods to route to? Through the selector, which the endpoints controller turns into an EndpointSlice of ready Pod IPs. What provides the stable DNS name? CoreDNS resolving the Service name. How is traffic actually routed? kube-proxy programs iptables or IPVS rules.

ONE CONCRETE EXAMPLE A frontend talks to a backend Deployment of three Pods. Instead of tracking three ever-changing Pod IPs, the frontend connects to the backend Service by name. When a backend Pod is replaced and gets a new IP, the Service automatically updates its endpoints, and the frontend keeps working with no config change.