Service Discovery im Docker Swarm Modus verstehen

1. Warum Service Discovery im Swarm überhaupt nötig ist

In einem Docker Swarm Cluster ändert sich die Platzierung von Containern ständig. Ein Node fällt aus, ein Service wird skaliert, ein Rolling Update ersetzt alte Container durch neue, und jedes Mal bekommen die betroffenen Container eine neue interne IP Adresse. Ohne Service Discovery müsste jede Anwendung ständig aktualisierte IP Listen pflegen, was in der Praxis fehleranfällig und kaum wartbar wäre. Genau dieses Problem löst die eingebaute Service Discovery von Docker Swarm automatisch und transparent für die Anwendung.

Der Kerngedanke von Service Discovery im Swarm Modus ist einfach: Container sprechen einander nicht über IP Adressen an, sondern über Servicenamen. Ein Container, der den Service api erreichen will, fragt einfach den Hostnamen api an, unabhängig davon, auf welchem Node und mit welcher IP Adresse die tatsächliche Instanz gerade läuft. Diese Abstraktion ist die Grundvoraussetzung dafür, dass Skalierung, Rolling Updates und Node Ausfälle für die Anwendung selbst unsichtbar bleiben.

2. Internes DNS: Servicenamen als stabile Adresse

Jeder Docker Swarm Cluster betreibt einen eingebauten DNS Server, der innerhalb jedes Overlay Netzwerks automatisch einen Eintrag für jeden Service anlegt. Sobald ein Service mit dem Namen api in einem Netzwerk existiert, können alle anderen Container in diesem Netzwerk den Namen api auflösen, ohne dass eine externe DNS Infrastruktur wie CoreDNS oder Consul konfiguriert werden muss. Diese Service Discovery Funktion ist vollständig in die Docker Engine integriert und erfordert keine zusätzliche Komponente.

Technisch läuft die Namensauflösung über einen internen Resolver, den Docker automatisch in /etc/resolv.conf jedes Containers einträgt. Fragt eine Anwendung den Hostnamen api an, leitet dieser Resolver die Anfrage an den eingebauten DNS Server des Overlay Netzwerks weiter, der wiederum die aktuelle Liste der zum Service gehörenden IP Adressen zurückliefert. Diese Liste wird bei jeder Änderung, etwa durch Skalierung oder einen Container Neustart, sofort aktualisiert, sodass DNS Antworten niemals veraltete IP Adressen enthalten.

# Create an overlay network for a stack
docker network create --driver overlay --attachable backend

# Deploy a service — Docker registers "api" as a DNS name automatically
docker service create --name api --network backend --replicas 3 \
  registry.example.com/shop-api:1.4.0

# From another container on the same network, resolve the service name
docker exec -it $(docker ps -q -f name=worker) nslookup api

# Inspect which network aliases a service currently has
docker service inspect api --format '{{json .Endpoint.VirtualIPs}}'

3. VIP Modus gegen DNS Round Robin

Docker Swarm bietet zwei verschiedene Betriebsmodi für Service Discovery, die sich in ihrem Lastverteilungsverhalten unterscheiden. Der Standardmodus ist der VIP Modus, bei dem jeder Service eine einzige, stabile virtuelle IP Adresse erhält. Anfragen an diese virtuelle Adresse werden auf Netzwerkebene über IPVS, das Linux Kernel Modul für Layer 4 Load Balancing, auf die tatsächlichen Container Instanzen verteilt. Diese Verteilung ist für die anfragende Anwendung komplett transparent und funktioniert auch bei einer einzigen DNS Abfrage.

Alternativ kann ein Service im DNS Round Robin Modus betrieben werden, bei dem der DNS Server für jede Anfrage eine unterschiedliche IP Adresse aus der Liste der verfügbaren Container zurückgibt. Dieser Modus wird selten explizit gewählt, ist aber wichtig, wenn eine Anwendung selbst client seitiges Load Balancing implementiert oder wenn IPVS aus bestimmten Kernel Gründen nicht verfügbar ist. Der wesentliche Unterschied: VIP Modus verteilt auf Netzwerkebene, DNS Round Robin verteilt auf Namensauflösungsebene, mit entsprechend unterschiedlichem Caching Verhalten in Client Bibliotheken.

# Create a service explicitly using DNS round-robin instead of the VIP mode
docker service create --name api --network backend \
  --endpoint-mode dnsrr --replicas 3 \
  registry.example.com/shop-api:1.4.0

# Inspect the current endpoint mode of an existing service
docker service inspect api --format '{{.Spec.EndpointSpec.Mode}}'

# Switching an existing service back to VIP mode requires an update
docker service update --endpoint-mode vip api

4. Overlay Netzwerke als technisches Fundament

Ohne Overlay Netzwerke gäbe es keine clusterweite Service Discovery. Ein Overlay Netzwerk kapselt Container Traffic in VXLAN Tunneln, die über die physischen Node zu Node Verbindungen laufen, und schafft damit ein logisches Netzwerk, das sich über alle Nodes im Cluster erstreckt, unabhängig von deren tatsächlicher physischer Netzwerktopologie. Container in demselben Overlay Netzwerk erreichen einander direkt über ihre Servicenamen, egal auf welchem physischen Node sie tatsächlich laufen.

Jeder Swarm Stack bekommt standardmäßig ein eigenes Overlay Netzwerk, das nur die zum Stack gehörenden Services verbindet. Diese Isolation ist ein wichtiger Sicherheitsaspekt: Ein Service in Stack A kann standardmäßig keinen Service in Stack B über Service Discovery erreichen, solange kein explizit gemeinsames Netzwerk definiert wurde. Für Szenarien, in denen mehrere Stacks kommunizieren müssen, etwa ein zentraler Reverse Proxy, der mehrere unabhängige Anwendungs Stacks bedient, wird ein zusätzliches, geteiltes Overlay Netzwerk mit attachable: true angelegt.

5. Routing Mesh: externe Erreichbarkeit über jeden Node

Der Routing Mesh ergänzt die interne Service Discovery um externe Erreichbarkeit. Wird ein Service Port veröffentlicht, etwa mit --publish 8080:8080, öffnet Docker diesen Port auf jedem einzelnen Node im Cluster, unabhängig davon, ob auf diesem Node tatsächlich eine Instanz des Services läuft. Eine eingehende Anfrage an einen beliebigen Node wird intern über den Routing Mesh an einen Node weitergeleitet, auf dem tatsächlich ein gesunder Container läuft.

Diese Eigenschaft vereinfacht externe Load Balancer Konfigurationen erheblich, weil jeder Node im Cluster als gültiger Zielpunkt für eingehenden Traffic dient. Ein externer Load Balancer muss lediglich alle Node IP Adressen kennen, die interne Verteilung auf gesunde Container übernimmt der Swarm Routing Mesh selbstständig. Für Anwendungsfälle, in denen die Quell IP Adresse des Clients wichtig ist, etwa bei IP basierter Zugriffskontrolle, muss der host Modus statt des Standard ingress Modus verwendet werden, da der Routing Mesh sonst die Quelladresse durch NAT verändert.

6. Netzwerk Aliase und mehrere Netzwerke pro Service

Neben dem automatisch registrierten Servicenamen unterstützt Service Discovery im Swarm Modus zusätzliche Netzwerk Aliase, über die derselbe Service unter mehreren Namen erreichbar gemacht werden kann. Das ist praktisch, wenn eine Migration schrittweise erfolgt und ein alter Servicename parallel zum neuen Namen weiter funktionieren soll, oder wenn mehrere logische Rollen auf denselben physischen Service zeigen sollen.

Ein Service kann außerdem an mehrere Overlay Netzwerke gleichzeitig angeschlossen werden. Das ist relevant, wenn ein Service sowohl mit einem internen Backend Netzwerk als auch mit einem geteilten Proxy Netzwerk kommunizieren muss, ohne dass Backend Services direkt für den Proxy sichtbar werden. Jedes zusätzliche Netzwerk fügt der Service Discovery eine weitere DNS Zone hinzu, in der der Servicename aufgelöst werden kann, was die Netzwerksegmentierung deutlich flexibler macht als ein einziges, flaches Netzwerk für den gesamten Cluster.

# Attach a service to an additional network with a custom alias
docker service update \
  --network-add name=proxy-net,alias=shop-api-legacy \
  api

# List all networks a service is currently attached to
docker service inspect api --format '{{json .Spec.TaskTemplate.Networks}}'

7. Diagnose: Service Discovery Probleme finden

Wenn ein Container einen anderen Service nicht über Service Discovery erreichen kann, ist die erste Frage immer, ob beide Container im selben Overlay Netzwerk angeschlossen sind. Ein häufiger Fehler ist ein Service, der versehentlich in einem anderen Stack Netzwerk läuft, ohne dass ein gemeinsames Netzwerk existiert. docker network inspect zeigt alle aktuell angeschlossenen Container und deren zugewiesene IP Adressen im jeweiligen Netzwerk.

Ein weiterer häufiger Fehler betrifft die Groß und Kleinschreibung oder abweichende Servicenamen zwischen Compose Datei und tatsächlichem Aufruf im Code. Da Docker DNS Namen grundsätzlich case insensitive aber sonst exakt matched, führt ein Tippfehler im Servicenamen zu einem klassischen Name or service not known Fehler. Mit docker exec -it getent hosts lässt sich direkt aus einem laufenden Container heraus prüfen, ob die Namensauflösung tatsächlich funktioniert, bevor tiefer in der Anwendung selbst nach dem Fehler gesucht wird.

# Step-by-step diagnostic sequence for service discovery failures

# 1. Confirm both containers share the same overlay network
docker network inspect backend --format '{{range .Containers}}{{.Name}} {{end}}'

# 2. Confirm the target service actually has running, healthy tasks
docker service ps api --filter "desired-state=running"

# 3. Resolve the service name from inside the calling container
docker exec -it $(docker ps -q -f name=worker) getent hosts api

# 4. Check whether the service uses VIP or DNS round-robin mode
docker service inspect api --format '{{.Spec.EndpointSpec.Mode}}'

# 5. If DNS resolves but connections still fail, check firewall
# rules on the host and confirm the overlay network's VXLAN
# traffic (UDP 4789) is not blocked between nodes

8. Grenzen der eingebauten Service Discovery

Die eingebaute Service Discovery von Docker Swarm deckt die meisten Standardfälle ab, hat aber Grenzen, die bei komplexeren Anforderungen relevant werden. Sie bietet kein natives Circuit Breaking, keine erweiterten Routing Regeln auf Basis von HTTP Headern und keine automatische Retry Logik bei fehlgeschlagenen Verbindungen, Funktionen, die ein Service Mesh wie Linkerd oder Istio zusätzlich mitbringen würde. Für die meisten Anwendungen mit einer überschaubaren Anzahl an Services ist dieser zusätzliche Funktionsumfang jedoch nicht notwendig.

Eine weitere Grenze betrifft Multi Cluster Szenarien: Service Discovery im Swarm Modus funktioniert ausschließlich innerhalb eines einzigen Clusters. Müssen Services über mehrere unabhängige Swarm Cluster hinweg kommunizieren, etwa zwischen verschiedenen Rechenzentren, ist eine externe Lösung wie ein globaler DNS Dienst oder ein dediziertes Service Mesh mit Multi Cluster Unterstützung erforderlich. Für die überwiegende Mehrheit produktiver Setups mit einem einzigen Cluster reicht die eingebaute Lösung aber vollständig aus.

Eine dritte, oft übersehene Grenze betrifft die Geschwindigkeit der Konvergenz bei sehr schnellen Änderungen. Wird ein Service in kurzer Folge mehrfach skaliert oder neu gestartet, kann es einen kurzen Moment geben, in dem DNS Antworten noch veraltete Einträge enthalten, bis der Cluster Zustand vollständig propagiert ist. Für die überwiegende Mehrheit der Anwendungen ist diese Verzögerung im Millisekundenbereich irrelevant, für sehr latenzsensitive Systeme lohnt sich aber ein Blick auf das Retry Verhalten der eigenen Client Bibliotheken.

9. Service Discovery im Vergleich: Swarm gegen externe Lösungen

Die folgende Tabelle vergleicht die eingebaute Swarm Service Discovery mit externen Alternativen, die in größeren oder heterogeneren Umgebungen zum Einsatz kommen.

Für die überwiegende Mehrheit der Docker Swarm Cluster mit einer überschaubaren Anzahl an Services ist die eingebaute Service Discovery vollkommen ausreichend und deutlich einfacher zu betreiben als ein zusätzliches Service Mesh mit eigenem Sidecar Overhead.

10. Zusammenfassung

Service Discovery im Docker Swarm Modus basiert auf drei zusammenspielenden Mechanismen: internem DNS für die Namensauflösung, dem VIP Modus für transparente Lastverteilung, und dem Routing Mesh für externe Erreichbarkeit über jeden Node. Container erreichen einander über stabile Servicenamen, unabhängig von der tatsächlichen, sich ständig ändernden Platzierung im Cluster. Diese Abstraktion ist die Grundlage dafür, dass Skalierung, Rolling Updates und Node Ausfälle für die Anwendung selbst transparent bleiben.

Für die überwiegende Mehrheit produktiver Setups reicht die eingebaute Service Discovery vollständig aus, ohne dass ein zusätzliches Service Mesh mit eigenem Sidecar Overhead nötig wäre. Wer die Grundlagen aus DNS Auflösung, Overlay Netzwerken und Routing Mesh versteht, kann die häufigsten Netzwerkprobleme im Swarm Cluster selbstständig diagnostizieren, statt bei jedem Verbindungsfehler in Ratlosigkeit zu verfallen.

11. FAQ: Service Discovery im Docker Swarm Modus