Docker Swarm über VPN: Tasks laufen, Service-Aufrufe scheitern

Tasks laufen auf beiden Standorten, und Aufrufe zwischen Diensten laufen in Timeouts. Das Overlay braucht Knoten-zu-Knoten-Routen, unübersetzte Adressen und Platz für 50 Byte VXLAN.

Drei Manager und fünf Worker an zwei Standorten, verbunden durch einen Tunnel, und docker service ls zeigt Tasks, die auf beiden Seiten laufen, während Aufrufe zwischen Diensten in Timeouts laufen. In den Swarm-Logs sieht nichts falsch aus. Diese Kombination ist die Signatur eines Data-Plane-Problems: die Control Plane fand die Knoten, und die gekapselten Frames haben die Reise nie geschafft.

Das Mesh muss vor dem Overlay da sein

Das Overlay von Swarm schiebt gekapselte Frames direkt zwischen Knotenadressen, was bedeutet, dass jeder Knoten eine Adresse braucht, die jeder andere Knoten ohne Übersetzung erreicht, auf dem Interface, das der Tunnel bereitstellt. Ein Tunnel, der nur Clients zu einem veröffentlichten Port bringt, reicht nicht. Das Underlay muss in beide Richtungen von Knoten zu Knoten routen.

Testen Sie das, bevor Sie Swarm anfassen. Prüfen Sie von jedem Knoten die Route zur Tunneladresse eines Peers, pingen Sie sie und testen Sie dann den Control-Port. Funktioniert Ping und der Port nicht, ist der Tunnel in Ordnung und ein Filter steht im Weg.

ip -brief address
ip route get 10.20.0.12
ping -c3 10.20.0.12
nc -vz 10.20.0.12 2377

Zeigt die Route auf das physische Interface statt auf tun0 oder wg0, kapselt das Overlay auf eine Adresse, die der ferne Standort nicht erreicht, und das Symptom liest sich wie Paketverlust.

Prüfen Sie, welche Adresse jeder Knoten ankündigt

Der Daemon kündigt eine Adresse an, und Peers nutzen sie für die Data Plane. Auf einem Host mit mehreren Netzen ist es leicht, die LAN- oder öffentliche Adresse anzukündigen, während der Tunnel etwas anderes trägt. Prüfen Sie sie, statt sie anzunehmen, und fixieren Sie sie beim Join mit --advertise-addr, wenn der Standard falsch ist. Ein Knoten, der eine Adresse ankündigt, die nur er erreicht, tritt trotzdem dem Swarm bei, und der Fehler zeigt sich später als Dienste, die nicht über Standorte hinweg sprechen können.

Die angekündigte Adresse später zu ändern ist keine Konfigurationsänderung, denn der Knoten muss austreten und erneut beitreten.

Notieren Sie die angekündigte Adresse pro Knoten in Ihren Notizen, denn sie erklärt die meisten asymmetrischen Fehler.

Masquerade ist der übliche Übeltäter

Wenn ein Gateway zwischen den Knoten und dem Tunnel sitzt, ist der häufige Fehler, auf alles MASQUERADE anzuwenden, was das physische Interface verlässt. Das schreibt auch die inneren Adressen des Overlays um, sodass jeder Peer vom Gateway zu kommen scheint und VXLAN-Peers aufhören, einander zu erkennen. Das Ergebnis ist fehlender oder einseitiger gekapselter Verkehr, während einfache Pings weiter funktionieren.

Routen Sie das Overlay-Präfix durch das Gateway und lassen Sie es unübersetzt. Wenn Übersetzung für ein anderes Präfix wirklich nötig ist, begrenzen Sie sie darauf und niemals auf den Bereich, den das Overlay nutzt.

ip route add 172.16.0.0/22 via 10.20.0.1
iptables -t nat -I POSTROUTING -o tun0 -s 172.16.0.0/22 -j ACCEPT

Prüfen Sie die Regelreihenfolge wie den Regeltext, denn ein breites MASQUERADE früher in der Kette gewinnt gegen eine schmale Ausnahme später.

VXLAN braucht Platz im Paket

VXLAN fügt den Frames, die es trägt, 50 Byte hinzu. Ein 1500-Byte-Underlay, das einen inneren Frame von 1500 Byte trägt, erzeugt ein gekapseltes Paket, das kein Pfad zustellt, und der Fehler sieht wie zeitweise Service Discovery aus, nicht wie ein Größenproblem. Senken Sie entweder die MTU des Tunnels an beiden Enden oder setzen Sie die Overlay-MTU so, dass der Treiber eine Nutzlast ankündigt, die hineinpasst.

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1400 swarm-overlay

Das Ingress-Netz wird automatisch erstellt, eine Änderung bedeutet also Entfernen und Neuerstellen statt Bearbeiten an Ort und Stelle.

Wenn Sie nur eine Seite des Tunnels reparieren, bleibt die kleinere MTU trotzdem die, auf die es ankommt.

Beobachten Sie die Data Plane, nicht die Logs

Fangen Sie den VXLAN-Port an beiden Enden ab. Frames, die eine Seite verlassen und auf der anderen ankommen, bedeuten, dass das Underlay in Ordnung ist und das Problem im Overlay liegt. Frames, die abgehen und nie ankommen, bedeuten eine Route oder einen Filter. Frames, die gar nicht abgehen, bedeuten, dass die Quelladresse falsch ist.

Service-Discovery-Fehler, die nach wenigen Sekunden verschwinden, deuten meist auf das Paketbudget oder einen flatternden Pfad hin, nicht auf ein Raft-Quorum.

Heben Sie den Mitschnitt aus einem funktionierenden Fenster auf, denn der Vergleich mit dem defekten ist schneller als das erneute Lesen der Konfiguration.

Ähnliche Artikel