Kubernetes Service Discovery: Fundamentals and Deep Dive

Kubernetes service discovery is a core topic that many find confusing; this article splits the discussion into two parts: background network knowledge and an in‑depth look at Kubernetes service discovery.

Network basics : Pods run in containers and are attached to a flat pod network (often a VXLAN overlay) where each pod receives a unique, routable IP address, enabling direct communication without NAT.

Dynamic network : As pods are added or removed during scaling, updates, or failures, their IPs change, making manual monitoring impractical. Kubernetes solves this with the Service object.

Service stability : A Service creates a stable network endpoint (name, IP, port) that remains constant for the lifetime of the Service, abstracting the dynamic pod set behind it. Clients talk to the Service, which load‑balances traffic to the pods.

Service parsing : The Service consists of a front end (stable name, IP, port) and a back end (a set of pods selected by label selectors). The front end never changes, while the back end is dynamic and load‑balanced.

Service registration : When a Service is created, the API server assigns a ClusterIP and stores the definition. The Service is automatically registered in the cluster DNS (CoreDNS), which creates an A record mapping the Service name to its ClusterIP.

Endpoints object : Kubernetes creates an Endpoints object for each Service, containing the list of pod IPs that match the Service’s label selector. This list is kept up‑to‑date so traffic is always sent to healthy pods.

Service discovery flow : Pods resolve Service names via the cluster DNS to obtain the ClusterIP, then send traffic to that IP. Because the Service network has no direct routes, traffic is first sent to the node’s default gateway, then intercepted by kube‑proxy.

kube‑proxy : Running on every node, kube‑proxy watches Service objects and creates iptables or IPVS rules that capture packets destined for a Service’s ClusterIP and rewrite their destination to a pod IP from the Endpoints list. IPVS is now the preferred implementation over iptables.

Summary : Creating a Service yields a virtual ClusterIP registered in DNS, an Endpoints object with matching pod IPs, and node‑level iptables/IPVS rules that forward traffic from the stable Service endpoint to the actual pods, enabling seamless service discovery and load balancing within a flat, routable pod network.