Demystifying Kubernetes Service Discovery: From Pods to Stable Endpoints

K8S Service Discovery Journey

Kubernetes service discovery often confuses readers; this article is split into network fundamentals and an in‑depth look at service discovery.

Network background knowledge

Deep dive into Kubernetes service discovery

K8S Network Basics

Before exploring service discovery, understand that applications run in containers inside Pods, each Pod is attached to a flat IP network (usually a VXLAN overlay), and every Pod has a unique, routable IP address.

These three facts let application components communicate directly without NAT.

Dynamic Network

Scaling adds new Pods with new IPs; scaling down removes Pods and their IPs. Rolling updates similarly add new Pods and retire old ones, making manual tracking painful. Kubernetes solves this with the Service object.

Calling this object “Service” can be confusing because the term also describes application processes.

Service Provides Stability

A Service creates a stable network endpoint in front of a set of Pods and load‑balances traffic to them. Different groups of Pods (e.g., web front‑end, authentication) should have separate Services. Clients talk to the Service, which forwards traffic to the Pods.

The Service’s name, IP and port never change even as underlying Pods are added or removed.

K8S Service Anatomy

Service consists of a stable front‑end (name, IP, port) and a dynamic back‑end (the set of Pods selected by label selectors).

Service Registration

Kubernetes uses DNS as the service registry. Each cluster runs a DNS service (CoreDNS) in the kube‑system namespace. When a Service is created, it receives a ClusterIP, is stored in the cluster data store, and CoreDNS creates the corresponding DNS A record.

Endpoint Object

For each Service, Kubernetes automatically creates an Endpoints object that holds the current list of healthy Pods matching the Service’s label selector.

Service Discovery Process

When a Pod needs to reach another service, it queries the cluster DNS for the Service name, receives the ClusterIP, and sends traffic to that IP. The traffic reaches the Service network, is intercepted by kube‑proxy on each node, which rewrites the destination to a Pod IP from the Endpoints list using iptables or IPVS rules.

kube‑proxy does not proxy traffic; it only manages iptables/IPVS rules.

IPVS is replacing iptables as a more efficient 4‑layer load balancer.

Summary

Creating a Service allocates a virtual ClusterIP, registers the name and IP in cluster DNS, and creates an Endpoints object with the healthy Pods. All nodes install iptables/IPVS rules so that traffic to the ClusterIP is redirected to the appropriate Pod IPs, enabling reliable service discovery.