Understanding Kubernetes Service Discovery and Networking

Kubernetes service discovery often confuses newcomers; this article breaks it into two parts: the required networking background and a deep dive into how services work.

Kubernetes Network Basics – All pods run in containers within a flat, routable IP network (often a VXLAN overlay). Each pod receives a unique IP address, allowing direct pod‑to‑pod communication without NAT.

Dynamic Network – When pods are added or removed during scaling, updates, or rollbacks, their IPs appear and disappear, making manual tracking impractical.

Service Object – Kubernetes introduces a Service object that provides a stable network endpoint (name, IP, port) in front of a set of pods. The front‑end never changes, while the back‑end consists of pods selected by label selectors.

The Service creates a stable ClusterIP (virtual IP) and registers its name in the cluster DNS (CoreDNS) automatically. The DNS entry maps the Service name to this ClusterIP.

Endpoints – For each Service, Kubernetes generates an Endpoints object that stores the list of healthy pod IPs matching the Service’s selector. This list is kept up‑to‑date by the control plane.

Service Discovery Process – A pod queries the cluster DNS for a Service name, receives the ClusterIP, and sends traffic to it. Because the Service network has no direct routes, the packet is forwarded to the node’s default gateway, then to the node’s kube-proxy process.

kube-proxy watches Service and Endpoints objects and programs either iptables or IPVS rules on each node. These rules capture traffic destined for the Service’s ClusterIP and rewrite the destination to one of the healthy pod IPs, performing simple round‑robin load balancing at layer 4.

Thus, creating a Service yields a virtual IP, automatic DNS registration, an Endpoints list of matching pods, and node‑level routing rules that transparently forward traffic to the appropriate pods.

In summary, Kubernetes abstracts away the dynamic nature of pods by providing stable Service endpoints, DNS‑based registration, and kernel‑level load‑balancing, enabling reliable inter‑pod communication in a flat overlay network.