How Kubernetes Enables Service‑to‑Service Communication: ClusterIP, CoreDNS, and Kube‑Proxy Explained

Overview

The article introduces three native Kubernetes objects that make inter‑service communication possible: ClusterIP Service , CoreDNS , and kube‑proxy . It compares these mechanisms with traditional IP‑based service communication.

Traditional Service‑to‑Service Communication

Before Kubernetes, services communicated directly via static IP addresses or DNS‑registered domain names. This works only for a few services because each client must know the exact IP or domain of the target.

Kubernetes Network Model

In a Kubernetes cluster, each pod receives a unique cluster‑wide IP address. All pods can reach every other pod without NAT, and the source IP is preserved, assuming the network is trusted.

Every pod has its own IP address.

All pods can communicate with any other pod in the cluster.

Communication occurs without NAT, so the destination pod sees the real source IP.

ClusterIP Service – Pod‑Level Abstraction

Because pods are transient and receive new IPs on each recreation, direct pod‑to‑pod communication is unreliable. Kubernetes introduces a ClusterIP Service that provides a stable virtual IP address for a group of pods and performs basic load‑balancing.

The service object uses label selectors to match pods and creates Endpoints that map the virtual IP to the actual pod IPs. This allows multiple pod versions to coexist behind a single service.

CoreDNS – In‑Cluster Service Discovery

Clients need to resolve the ClusterIP service name to an IP address. Kubernetes runs CoreDNS (exposed as the kube-dns service) to provide DNS resolution for services.

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

CoreDNS itself is exposed via a ClusterIP Service, and pods use its IP as their nameserver.

Pods query DNS to obtain the service’s virtual IP, then connect using that IP and the service port.

kube‑proxy – DNAT Between Service and Pods

The actual forwarding from the virtual IP to the pod IPs is performed by kube‑proxy , which runs on every node and watches Service and Endpoint objects.

When a pod sends traffic to a ClusterIP, kube‑proxy intercepts the request.

kube‑proxy rewrites the destination IP and port to one of the backend pod endpoints (DNAT).

Interaction Flow

The complete interaction proceeds as follows:

The target ClusterIP Service is registered in CoreDNS.

Pods resolve the service name via DNS to obtain the virtual IP.

The client pod contacts the service IP and port.

kube‑proxy on the node rewrites the destination to a concrete pod IP.

Summary

The native Kubernetes objects—ClusterIP Service, CoreDNS, and kube‑proxy—together hide the complexity of service‑to‑service communication from application code, providing stable service endpoints, automatic DNS discovery, and transparent load‑balancing within the cluster.