<p>I've read a couple of passages from some books written on Kubernetes as well as the <a href="https://kubernetes.io/docs/concepts/services-networking/service/#headless-services" rel="noreferrer">page on headless services in the docs</a>. But I'm still unsure what it really actually does and why someone would use it. Does anyone have a good understanding of it, what it accomplishes, and why someone would use it?</p>

<p>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:</p>

<blockquote>
  <p>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? </p>
  
  <p>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</p>
  
  <p>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.</p>
  
  <p>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.</p>
</blockquote>

<p>"Kubernetes in Action" by Marco Luksa</p>
