Services and DNS inside the cluster

Pods get IPs when they start, and those IPs change whenever a pod is rescheduled. A Service solves this. It selects a set of pods by label and gives them one stable name and virtual IP. Clients use the name, and Kubernetes decides which pod answers.

The big idea

Think of a Service as a receptionist with a list of who is free today. Callers ask for the receptionist's number, which never changes. The receptionist passes each call to someone on the current list. Someone who is busy or away gets taken off the list.

Service types

Walking through a request

Here is a client pod calling checkout on port 8080.

1. The client asks cluster DNS (CoreDNS) for checkout.payments.
2. DNS returns the Service's virtual IP, here 10.96.4.20.
3. The client sends traffic to that IP.
4. Node-level rules pick a ready pod from the EndpointSlice and forward the packet to its IP.

From inside any pod, you can check the name with getent hosts checkout.payments.svc.cluster.local. It should return the Service IP, not a pod IP.

Readiness decides membership

The EndpointSlice lists the ready pod IPs behind a Service. A pod that fails readiness is dropped from that list, so no new connection goes to it. When it passes again, it returns. This is why readiness checks should reflect whether the pod can serve traffic right now.

The network model

Every pod gets its own IP, and any pod can reach any other pod IP without NAT. A CNI plugin makes this work. NetworkPolicy objects are the firewall rules on top, selected by pod label. A default-deny policy plus explicit allows is the usual production setup. This only works if your CNI supports NetworkPolicy. Verify that before you rely on it.

Common mistakes

• Hard-coding pod IPs. They change on every reschedule. Use the Service name.
• Assuming NetworkPolicy is enforced. Check your CNI first.
• Using NodePort as the production edge. Put a load balancer or Ingress in front of it instead.
• Forgetting that a headless Service is needed for StatefulSet peers. Without it, peers cannot find each other by stable name.

Check yourself

1. A pod fails its readiness probe. Does it still get traffic? No. It is removed from the Service's endpoints until it passes again.
2. Why do StatefulSets need a headless Service? It makes DNS return each pod's IP directly, so peers can find each other by stable name.

Key takeaways

• A Service gives a set of pods one stable name and virtual IP.
• DNS resolves the name. Node rules forward the traffic to a ready pod.
• Readiness controls who receives traffic.
• NetworkPolicy only works if your CNI enforces it.

Further learning

Next, look at the settings, storage and names pods depend on in config, storage and labels. For traffic that enters from outside the cluster, see edge and traffic.