Kubernetes Service-to-Service Communication: ClusterIP, CoreDNS, and kube-proxy

Deep dive into the three native Kubernetes objects that support service-to-service communication: ClusterIP Service, DNS (CoreDNS), and kube-proxy.

Traditional Service-to-Service Communication

Before Kubernetes, services communicated via static IP addresses or DNS names. A client needed to know the server's IP or resolve its domain name.

Kubernetes Network Model

Kubernetes clusters consist of a control plane and worker nodes that run Pods. Each Pod receives a unique cluster‑wide IP, and every Pod can reach every other Pod without NAT, allowing direct IP visibility.

Each Pod has its own unique cluster‑wide IP address.

All Pods can communicate with every other Pod in the cluster.

Communication occurs without NAT, so source IPs are preserved and the network is trusted.

ClusterIP Service – Pod‑Level Abstraction

Pods are transient; their IPs change on recreation, making direct Pod‑to‑Pod communication unreliable. Kubernetes creates a stable virtual IP (ClusterIP) that fronts a set of Pods and provides basic load‑balancing.

The ClusterIP Service object selects Pods via labels and selectors, exposing a single IP that clients use instead of individual Pod IPs.

CoreDNS – In‑Cluster Service Discovery

CoreDNS registers each ClusterIP Service in the cluster’s DNS. Pods resolve the Service name to its IP via the cluster’s DNS server (kube‑dns).

When a ClusterIP Service is created, CoreDNS adds an entry to DNS.

CoreDNS itself is exposed as a ClusterIP (kube‑dns) and configured as the nameserver inside Pods.

Pods query DNS to obtain the Service IP, then connect using that IP and the Service port.

kube‑proxy – DNAT Between Service IP and Pod Endpoints

kube‑proxy runs on every node, watches Service objects and their Endpoints, and intercepts traffic destined for a ClusterIP. It rewrites the destination IP to the actual Pod IP (DNAT) before forwarding.

When a Pod sends a request to a ClusterIP, kube‑proxy intercepts it.

It identifies the target Service and replaces the destination with the appropriate Pod endpoint address.

How They Work Together

The interaction flow is:

The Service’s ClusterIP is registered in CoreDNS.

Pods resolve the Service name via DNS to obtain the ClusterIP.

Pods send traffic to the ClusterIP.

kube‑proxy on the node DNATs the traffic to a selected backend Pod.

Summary

These native Kubernetes objects—ClusterIP Service, CoreDNS, and kube‑proxy—enable seamless, hidden service‑to‑service communication within a cluster.