Why Services

You have 3 Pods running your web application. Another Pod inside the cluster needs to call them. Which IP does it use?

Pod A has IP 10.244.0.5. Pod B has 10.244.0.6. Pod C has 10.244.0.7. You pick Pod A and hardcode 10.244.0.5 into your client configuration. Everything works. Then Pod A crashes. The ReplicaSet creates a replacement with IP 10.244.0.8. Your client still points to 10.244.0.5, which no longer exists. The connection fails silently.

This is not a bug in your code. It is a structural problem: Pod IPs are ephemeral.

Pod IPs Are Not Stable

Every time a Pod is created, Kubernetes assigns it a new IP address from the cluster network range. There is no guarantee this IP will be the same as the previous Pod’s. A Pod that crashes, gets evicted from a node, or is replaced during a rolling update receives a brand new IP. Any client that holds the old IP has no automatic way to discover the replacement.

This affects every communication pattern inside a cluster. A frontend Pod calling a backend, a worker calling a queue, a sidecar calling the main application. All of them break the moment a Pod is replaced, unless something provides a stable address.

Start by creating the Deployment you will expose through a Service. Run this in the simulator:

nano web-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.28
          ports:
            - containerPort: 80

kubectl apply -f web-deployment.yaml
kubectl get pods -l app=web -o wide

Look at the IP column in the output. Note those addresses. They are real inside the simulated cluster, but they will change the next time those Pods are replaced.

The Service Abstraction

A Service gives a group of Pods a single stable virtual IP, called the ClusterIP, and a DNS name that never changes. Clients call the Service. The Service finds the right Pods using a label selector. When a Pod is replaced, the Service updates its routing automatically. The ClusterIP stays the same.

Think of it like a company phone directory. Employees move desks constantly, but their extension number is always listed under their name. You call the directory number, not the desk. The phone system routes the call to whoever is sitting there now. Pods are the employees; the Service is the directory entry.

The label selector is the bridge between the Service and the Pods. The Service says: “route traffic to any Pod that has the label app: web.” Kubernetes keeps that list up to date automatically. When Pod A dies and Pod C appears with the same label, Pod C enters the routing pool. The client never changes its target.

Confirming Ephemeral IPs

You can observe the problem directly. Trigger a rollout to replace the existing Pods:

kubectl rollout restart deployment/web
kubectl get pods -l app=web -o wide

Compare the IPs in the output to the ones you noted earlier. They are different. Any client that cached the old IPs is now broken. This is exactly the problem a Service prevents.

What Comes Next

You have a Deployment with 2 Pods ready to serve traffic. The next step is creating a Service that exposes them and understanding exactly how the Service tracks which Pods to route to. That tracking mechanism is the Endpoints object, and it is the topic of the next lesson.