The Mechanics of Headless Routing in Kubernetes (ClusterIP Only)

When you set clusterIP: None in a ClusterIP service configuration, it becomes a Headless Service. Because there is no single virtual IP address to balance the traffic, the routing behavior changes completely:

1. Direct Pod IP Discovery: When a Pod queries the internal DNS for a headless service (e.g., my-service.default.svc.cluster.local), CoreDNS does not return one Service IP. Instead, it returns an A-record list containing the direct IP addresses of all healthy backend Pods [1].
2. Client-Side Control: The calling Pod receives this list of raw Pod IPs. The application code inside the calling Pod must decide how to route the requests. It can connect to the first IP, cycle through them randomly, or implement its own round-robin logic.
3. StatefulSet Predictability: If combined with a StatefulSet, the headless service creates deterministic, individual DNS entries for each pod (e.g., pod-0.my-service, pod-1.my-service). This allows Pods to talk directly to a specific peer, which is critical for databases like PostgreSQL, Kafka, or Elasticsearch that need to manage leader/follower states.
4. Bypassing Kube-Proxy: Standard services use kube-proxy (iptables/IPVS) to randomly forward traffic. Headless routing completely bypasses this layer, establishing a direct TCP/UDP connection from container to container.