A headless Service lets clients find the pods behind a Kubernetes Service instead of connecting through one Service IP address. It is useful when a client must choose a particular pod, discover every pod, or let peer pods contact one another. DNS returns the matching pod IP addresses, so clients can use DNS without querying the Kubernetes API. section 11.4.2
Listing 11.7 A headless service
apiVersion: v1
kind: Service
metadata:
name: quote-headless
spec:
clusterIP: None #1
selector:
app: quote
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP
In this Service manifest, `clusterIP: None` makes the Service headless. The `app: quote` selector determines which pods its DNS name exposes. section 11.4.2
Check what DNS returns
After applying the manifest with `kubectl apply`, run `kubectl get svc quote-headless -o wide` to confirm its cluster IP is `None`. Compare the pod IPs from `kubectl get po -l app=quote -o wide` with `nslookup quote-headless` inside a pod: the lookup returns an address for each matching pod. By contrast, `nslookup quote` for a regular Service returns one Service IP. A client connecting to the headless name connects to a pod IP, not a Service IP. section 11.4.2
The distinction matters for stateful applications. A StatefulSet uses an associated headless Service to give each pod an individual DNS name. That name continues to identify the same StatefulSet replica even if the pod moves to another node and gets a new IP address. A headless Service on its own exposes the group's pod addresses; the individual pod records described here arise from its association with a StatefulSet. section 16.1.3 section 16.5
Discover database replicas
For a MongoDB replica set, a client needs the replicas' addresses to find the primary for writes. With a StatefulSet and a headless Service named `quiz-pods`, it can address a replica such as `quiz-0.quiz-pods.kiada.svc.cluster.local`. Naming the Service port `mongodb` also provides the expected SRV record, allowing a `mongodb+srv://quiz-pods.kiada.svc.cluster.local` connection string instead of listing every replica. Set `publishNotReadyAddresses: true` if these pod DNS records must exist before the pods are ready. section 16.1.3 section 16.1.5
The same pattern supports pods in an Indexed Job that need to reach specific peers. Create a headless Service selecting the Job's pods, set the Job's `completionMode` to `Indexed`, and set its pod template's `subdomain` to the Service name. A peer can then reach an indexed pod by its DNS name. section 18.1.6
