Overlay-Netzwerke über mehrere Docker-Hosts

1. Warum Bridge-Netzwerke an der Host-Grenze enden

Ein Bridge-Netzwerk existiert ausschließlich innerhalb des Linux-Kernels eines einzelnen Docker-Hosts. Container auf zwei unterschiedlichen Maschinen können sich in einem Bridge-Netzwerk niemals per Containername erreichen, selbst wenn beide Netzwerke identisch benannt sind, weil es sich technisch um zwei völlig getrennte virtuelle Switches handelt. Sobald ein Setup mehr als einen Host umfasst, etwa für Hochverfügbarkeit oder horizontale Skalierung, braucht es eine andere Lösung als ein gewöhnliches Bridge-Netzwerk.

Genau hier setzt ein Overlay-Netzwerk an. Es kapselt den Container-Traffic in zusätzliche Netzwerkpakete, die über das reguläre Netzwerk zwischen den Hosts transportiert werden, und entkapselt sie am Zielhost wieder. Für die Anwendung innerhalb des Containers ist davon nichts sichtbar, sie kommuniziert weiterhin über gewöhnliche IP-Adressen und Servicenamen, unabhängig davon, auf welchem physischen Host der Zielcontainer tatsächlich läuft. Ein Overlay-Netzwerk macht die Host-Grenze für die Container-Kommunikation transparent.

2. Grundlagen von Docker Swarm und Overlay-Netzwerken

Docker liefert seine Multi-Host-Orchestrierung im sogenannten Swarm Mode, der ohne zusätzliche Software direkt in der Docker Engine enthalten ist. Ein Swarm besteht aus Manager-Knoten, die den Cluster-Zustand verwalten, und Worker-Knoten, die Container ausführen. Ein Overlay-Netzwerk wird auf einem Manager-Knoten definiert und automatisch an jeden Knoten repliziert, der tatsächlich Container in diesem Netzwerk ausführt, statt es global auf alle Knoten des Clusters zu verteilen.

Der Kontrollplan für ein Overlay-Netzwerk läuft über den Gossip-Protokoll-basierten Cluster-Store von Swarm, der Informationen über Container-IPs und -Namen zwischen allen beteiligten Knoten synchron hält. Das unterscheidet ein Overlay-Netzwerk fundamental von einem Bridge-Netzwerk, bei dem der eingebettete DNS-Server nur lokale Informationen kennt. Ohne aktiven Swarm Mode lässt sich kein reguläres Overlay-Netzwerk erstellen, ein einzelner Docker-Host im Standalone-Betrieb bleibt auf Bridge, Host und Macvlan beschränkt.

Für die Hochverfügbarkeit des Clusters selbst nutzen die Manager-Knoten einen Raft-Konsensalgorithmus, der auch bei Ausfall einzelner Manager weiterhin eine konsistente Sicht auf den Cluster-Zustand und damit auf jedes Overlay-Netzwerk garantiert. Empfohlen werden ungerade Manager-Anzahlen, meist drei oder fünf, damit bei einem Netzwerksplit stets eine Mehrheit für gültige Entscheidungen zustande kommt. Diese Konsensschicht ist der Grund, warum ein Overlay-Netzwerk auch nach dem Ausfall eines einzelnen Managers weiterhin korrekt funktioniert, solange die Mehrheit der Manager erreichbar bleibt.

# List all nodes in the cluster with their role and availability
docker node ls

# Example output:
# ID       HOSTNAME   STATUS   AVAILABILITY   MANAGER STATUS
# abc123   node-1     Ready    Active         Leader
# def456   node-2     Ready    Active         Reachable
# ghi789   node-3     Ready    Active         Reachable

3. Swarm initialisieren und Overlay-Netzwerk anlegen

Der erste Schritt zu einem Overlay-Netzwerk ist die Initialisierung eines Swarm-Clusters auf einem ersten Knoten, der dabei automatisch zum Manager wird. Weitere Knoten treten dem Cluster über einen Join-Token bei, den der Manager beim Initialisieren ausgibt, getrennt nach Manager- und Worker-Rolle. Erst nach erfolgreichem Beitritt mehrerer Knoten ergibt ein Overlay-Netzwerk praktischen Sinn, weil es genau die Kommunikation zwischen diesen Knoten ermöglicht.

Ein Overlay-Netzwerk wird anschließend mit dem Treiber overlay angelegt und einem Service über docker service create zugewiesen. Docker Swarm platziert die Container des Services automatisch auf den verfügbaren Worker-Knoten und sorgt dafür, dass jeder Container, unabhängig vom tatsächlichen physischen Host, im selben logischen Netzwerk erscheint und über den Servicenamen erreichbar ist.

# Initialize the swarm on the first node (becomes the manager)
docker swarm init --advertise-addr 10.0.1.10

# Retrieve the join token to add worker nodes
docker swarm join-token worker

# On a second machine, join the swarm as a worker
docker swarm join --token SWMTKN-1-xxxxx 10.0.1.10:2377

# Create an overlay network for cross-host communication
docker network create -d overlay --attachable shop-overlay

# Deploy a service using the overlay network, replicated across nodes
docker service create --name shop-app \
  --network shop-overlay \
  --replicas 3 \
  shop-app:latest

4. VXLAN-Kapselung: die Technik dahinter

Technisch basiert ein Overlay-Netzwerk in Docker auf VXLAN, Virtual Extensible LAN, einem Kapselungsprotokoll, das Ethernet-Frames in UDP-Pakete verpackt. Jedes Paket, das ein Container in ein anderes physisches Netzwerksegment senden will, wird am Quellhost mit einem VXLAN-Header versehen, über das physische Netzwerk zum Zielhost transportiert und dort wieder entpackt, bevor es an den Zielcontainer weitergeleitet wird. Diese Kapselung läuft vollständig im Kernel und ist für Anwendungen im Container unsichtbar.

Der entscheidende Vorteil von VXLAN gegenüber klassischem VLAN-Tagging: ein Overlay-Netzwerk ist nicht auf 4094 mögliche Segmente begrenzt wie bei 802.1Q, sondern nutzt einen 24-Bit-Identifier, der über 16 Millionen unterschiedliche logische Netzwerke erlaubt. Für den Betrieb reicht es, dass die beteiligten Hosts über das physische Netzwerk UDP-Pakete auf dem VXLAN-Standardport austauschen können, eine tiefere Konfiguration des physischen Netzwerks ist normalerweise nicht nötig.

5. Service Discovery und Load Balancing

Innerhalb eines Overlay-Netzwerks funktioniert Namensauflösung genauso wie in einem lokalen Bridge-Netzwerk: jeder Service ist über seinen Namen erreichbar, unabhängig davon, auf welchem Knoten die einzelnen Replica-Container tatsächlich laufen. Zusätzlich integriert Docker Swarm einen virtuellen IP-basierten Load Balancer, der Anfragen an einen Servicenamen automatisch über alle laufenden Replicas verteilt, ohne dass ein externer Load Balancer konfiguriert werden muss.

Dieser eingebaute Load Balancer arbeitet auf Layer 4 und nutzt IPVS im Linux-Kernel für die Verteilung, was bei der Kommunikation innerhalb eines Overlay-Netzwerks deutlich weniger Overhead erzeugt als ein separater Reverse Proxy pro Service. Für den ankommenden Traffic von außerhalb des Clusters kommt zusätzlich ein Ingress-Netzwerk zum Einsatz, ein spezielles, automatisch erstelltes Overlay-Netzwerk, das veröffentlichte Ports auf jedem Knoten des Clusters annimmt und an den richtigen Container weiterleitet.

Welcher Knoten welche Replica eines Services tatsächlich ausführt, lässt sich jederzeit über docker service ps nachvollziehen. Das ist besonders beim Debugging hilfreich, wenn eine bestimmte Replica auffällig langsam reagiert und geprüft werden soll, ob diese Replica zufällig auf einem überlasteten Knoten des Overlay-Netzwerks läuft, während andere Replicas auf ruhigeren Knoten problemlos funktionieren.

# Show which node each replica of a service actually runs on
docker service ps shop-app

# Example output:
# NAME          NODE     CURRENT STATE
# shop-app.1    node-2   Running 2 hours ago
# shop-app.2    node-3   Running 2 hours ago
# shop-app.3    node-1   Running 2 hours ago

6. Overlay-Traffic mit --opt encrypted verschlüsseln

Standardmäßig ist der Traffic in einem Overlay-Netzwerk unverschlüsselt, sobald er das physische Netzwerk zwischen den Hosts durchquert. Für Umgebungen, in denen dieses physische Netzwerk nicht vollständig vertrauenswürdig ist, etwa bei Hosts in unterschiedlichen Rechenzentren oder Cloud-Regionen, lässt sich Verschlüsselung mit der Option --opt encrypted beim Anlegen des Netzwerks aktivieren. Docker nutzt dafür IPsec mit automatisch generierten und rotierten Schlüsseln über den internen Swarm-Zertifikatsspeicher.

Die Verschlüsselung eines Overlay-Netzwerks hat einen messbaren, aber meist moderaten Performance-Overhead durch die zusätzliche Ver- und Entschlüsselung jedes Pakets. Für sensible Daten, etwa Verbindungen zwischen Anwendungscontainern und Datenbanken über mehrere Rechenzentren hinweg, überwiegt der Sicherheitsgewinn diesen Overhead in fast allen Fällen. Für rein interne Cluster in einem einzigen, physisch abgesicherten Rechenzentrum ist die Verschlüsselung dagegen oft verzichtbar.

# Create an encrypted overlay network for sensitive cross-host traffic
docker network create -d overlay \
  --opt encrypted \
  --attachable \
  secure-overlay

# Verify encryption is active by inspecting the network options
docker network inspect secure-overlay --format '{{.Options}}'

7. Firewall-Ports und Infrastrukturanforderungen

Ein Overlay-Netzwerk benötigt bestimmte offene Ports zwischen allen Swarm-Knoten, ohne die die Kapselung nicht funktioniert. Der TCP-Port 2377 wird für die Cluster-Verwaltung zwischen Manager-Knoten benötigt, TCP und UDP Port 7946 für das Gossip-Protokoll zur Knotenerkennung, und UDP Port 4789 für den eigentlichen VXLAN-Datenverkehr. Fehlt einer dieser Ports in der Firewall-Konfiguration zwischen den Hosts, entstehen schwer diagnostizierbare Probleme, bei denen einzelne Container im Overlay-Netzwerk zwar existieren, aber nicht erreichbar sind.

Cloud-Umgebungen mit Security Groups oder Netzwerksegmentierung zwischen Availability Zones erfordern besondere Aufmerksamkeit, weil diese Regeln oft restriktiver konfiguriert sind als eine klassische On-Premise-Firewall. Vor der produktiven Nutzung eines Overlay-Netzwerks über mehrere Cloud-Regionen oder Availability Zones hinweg lohnt sich ein expliziter Konnektivitätstest mit den drei genannten Ports, statt sich auf implizite Standard-Firewall-Regeln zu verlassen.

Ein einfacher, aber wirksamer Test vor der Einrichtung eines Overlay-Netzwerks prüft mit Werkzeugen wie nc direkt zwischen zwei zukünftigen Swarm-Knoten, ob die relevanten Ports tatsächlich erreichbar sind, statt sich erst nach dem Swarm-Beitritt mit kryptischen Fehlermeldungen auseinanderzusetzen. Gerade UDP-Port 4789 wird in Firewall-Regelwerken häufig übersehen, weil TCP-Ports in vielen Checklisten dominieren, während der eigentliche VXLAN-Datenverkehr vollständig über UDP läuft.

# Test manager port connectivity before joining the swarm
nc -zv 10.0.1.10 2377

# Test the gossip protocol port, both TCP and UDP
nc -zv 10.0.1.10 7946
nc -zuv 10.0.1.10 7946

# Test the VXLAN data port, UDP only, often overlooked in firewalls
nc -zuv 10.0.1.10 4789

8. Attachable-Netzwerke für Standalone-Container

Ohne die Option --attachable können ausschließlich Swarm-Services einem Overlay-Netzwerk beitreten, gewöhnliche Container über docker run bleiben ausgeschlossen. Das ist in vielen Fällen unpraktisch, etwa wenn ein temporärer Debug-Container oder ein einzelner Legacy-Dienst außerhalb der Swarm-Orchestrierung Zugriff auf Services im Overlay-Netzwerk braucht. Mit --attachable beim Anlegen des Netzwerks lässt sich diese Einschränkung aufheben.

Ein attachable Overlay-Netzwerk erlaubt es, mit docker run --network auch Standalone-Container direkt zu verbinden, ganz ohne sie als Swarm-Service zu deklarieren. Das ist besonders für Diagnosewerkzeuge nützlich, die kurzzeitig in das Overlay-Netzwerk eingeklinkt werden, um Konnektivität zwischen Services über mehrere Hosts hinweg zu testen, ohne dafür einen vollständigen Service definieren zu müssen.

9. Bridge, Overlay und Host-Netzwerk im Vergleich

Die folgende Tabelle vergleicht die drei Netzwerktreiber im Hinblick auf Multi-Host-Fähigkeit, um die Entscheidung für ein Overlay-Netzwerk gegenüber den Alternativen einzuordnen.

Diese Gegenüberstellung zeigt, dass ein Overlay-Netzwerk keine allgemeine Alternative zu Bridge-Netzwerken ist, sondern eine spezifische Antwort auf die Anforderung, Container über mehrere physische Hosts hinweg kommunizieren zu lassen. Wer nur einen einzelnen Host betreibt, hat schlicht keinen Anwendungsfall für ein Overlay-Netzwerk und sollte bei Bridge bleiben.

10. Zusammenfassung

Ein Overlay-Netzwerk löst genau das Problem, an dem Bridge-Netzwerke scheitern: Container-Kommunikation über die Grenze eines einzelnen Docker-Hosts hinaus. Über VXLAN-Kapselung transportiert Docker Swarm den Traffic zwischen den Hosts, während Anwendungen weiterhin über gewöhnliche Servicenamen kommunizieren, unabhängig davon, wo der Zielcontainer tatsächlich läuft. Eingebautes Load Balancing über virtuelle IPs verteilt Anfragen automatisch auf alle Replicas eines Services.

Verschlüsselung mit --opt encrypted schützt sensiblen Traffic zwischen Rechenzentren, attachable Netzwerke binden auch Standalone-Container ein, und die drei zentralen Firewall-Ports 2377, 7946 und 4789 müssen zwischen allen Knoten offen sein, damit ein Overlay-Netzwerk überhaupt funktioniert. Wer nur einen einzelnen Host betreibt, braucht kein Overlay-Netzwerk, sobald ein Cluster mit mehreren Knoten entsteht, ist es aber die einzige native Docker-Lösung für Container-übergreifende Kommunikation.

11. FAQ: Overlay-Netzwerke über mehrere Docker-Hosts