Headless Services and direct Pod DNS

WHAT THIS TESTS Knowing when you want direct Pod-level addressing rather than a single load-balanced virtual IP, which is essential for stateful workloads.

A GOOD ANSWER COVERS A headless Service is defined by setting clusterIP: None. Because there is no virtual IP, kube-proxy installs no load-balancing rules for it. The difference shows up in DNS: a standard ClusterIP Service resolves to one stable virtual IP, and connections are then load-balanced across Pods. A headless Service instead resolves to multiple A records, one per ready backing Pod, so the client receives the actual Pod IPs and can connect directly or implement its own selection. When combined with a StatefulSet, each Pod also gets a stable, predictable DNS name of the form pod-name.service.namespace.svc.cluster.local.

COMMON WRONG ANSWERS Thinking a headless Service still gets a ClusterIP. Believing it load-balances. Not connecting it to StatefulSets, its canonical pairing.

LIKELY FOLLOW-UPS Why do databases need this? Replicas must address specific peers (primary versus secondaries) by stable identity. What is the StatefulSet serviceName field? It points the StatefulSet at its governing headless Service. What if no selector? Headless Services without selectors can map to manually managed endpoints.

ONE CONCRETE EXAMPLE A Cassandra cluster runs as a StatefulSet fronted by a headless Service. Resolving the Service name returns the IPs of all Cassandra Pods, and each Pod is individually addressable as cassandra-0.cassandra, cassandra-1.cassandra, and so on, so nodes can form a ring and clients can target specific replicas, which a load-balanced ClusterIP could not provide.