Ein Kubernetes Headless Service ist ein Service ohne virtuelle Cluster-IP. Statt Anfragen über eine feste IP lastzuverteilen, löst sein DNS-Name direkt in die Adressen der dahinterliegenden Pods auf. Anwendungen, die selbst entscheiden wollen, welchen Pod sie kontaktieren, nutzen diese Variante.
So funktioniert er
Ein normaler Service bekommt vom Cluster eine virtuelle IP und der kube-proxy verteilt Anfragen auf die Pods. Ein Headless Service setzt dagegen clusterIP: None: Der Cluster vergibt keine virtuelle IP und baut keine Lastverteilungsregeln. Der DNS-Server liefert für den Dienstnamen mehrere A-Records – einen pro bereitem Pod, der zum Selector passt. Mit publishNotReadyAddresses: true erscheinen auch noch nicht bereite Pods im DNS.
Einsatz mit StatefulSets
Für StatefulSets ist der Headless Service der Standard: Jeder Pod trägt einen festen Namen wie db-0 oder db-1. Der Headless Service macht diese Namen per DNS erreichbar – db-0.mein-dienst.default.svc.cluster.local zeigt direkt auf den jeweiligen Pod. So erhalten Datenbank-Cluster (MySQL, Cassandra, Kafka) eine stabile Netzwerk-Identität für die Kommunikation untereinander.
Ein Pod in einem solchen Cluster kennt seinen eigenen Namen über die Downward API (Feld metadata.name) – der Name entspricht genau dem DNS-Eintrag des Headless Service.
Weitere Anwendungsfälle
- Client-seitiges Load-Balancing: Die Anwendung holt alle Pod-Adressen per DNS und verteilt selbst.
- Service-Discovery direkt auf Pod-Ebene statt über einen Vermittler.
- Ohne Selector erzeugt der Headless Service DNS-Einträge für manuell gepflegte Endpoints, etwa eine externe Datenbank außerhalb des Clusters.
- Benannte Ports liefert der DNS zusätzlich als SRV-Records.
Auch der Admission-Prozess kennt Services: Ein Admission Webhook kann Service-Objekte – darunter Headless Services – vor dem Speichern prüfen und verändern.