What is a headless service, what does it do/accomplish, and what are some legitimate use cases for it?

Well, I think you need some theory. There are many explanations (including the official docs) across the whole internet, but I think Marco Luksa did it the best:

Each connection to the service is forwarded to one randomly selected
backing pod. But what if the client needs to connect to all of those
pods? What if the backing pods themselves need to each connect to all
the other backing pods. Connecting through the service clearly isn’t
the way to do this. What is?

For a client to connect to all pods, it needs to figure out the the IP
of each individual pod. One option is to have the client call the
Kubernetes API server and get the list of pods and their IP addresses
through an API call, but because you should always strive to keep your
apps Kubernetes-agnostic, using the API server isn’t ideal

Luckily, Kubernetes allows clients to discover pod IPs through DNS
lookups. Usually, when you perform a DNS lookup for a service, the DNS
server returns a single IP — the service’s cluster IP. But if you tell
Kubernetes you don’t need a cluster IP for your service (you do this
by setting the clusterIP field to None in the service specification ),
the DNS server will return the pod IPs instead of the single service
IP. Instead of returning a single DNS A record, the DNS server will
return multiple A records for the service, each pointing to the IP of
an individual pod backing the service at that moment. Clients can
therefore do a simple DNS A record lookup and get the IPs of all the
pods that are part of the service. The client can then use that
information to connect to one, many, or all of them.

Setting the clusterIP field in a service spec to None makes the
service headless, as Kubernetes won’t assign it a cluster IP through
which clients could connect to the pods backing it.

“Kubernetes in Action” by Marco Luksa

Leave a Comment