Docker Swarm over VPN: taken draaien, serviceaanroepen mislukken

Drie managers en vijf workers over twee locaties, verbonden door een tunnel, en docker service ls toont taken die aan beide kanten draaien terwijl aanroepen tussen services in een time-out lopen. Niets in de Swarm-logs ziet er verkeerd uit. Die combinatie is de signatuur van een probleem in het dataplane: het controlplane vond de nodes, en de ingekapselde frames hebben de reis nooit gemaakt.

Het mesh moet er zijn voordat de overlay dat is

De overlay van Swarm duwt ingekapselde frames rechtstreeks tussen nodeadressen, wat betekent dat elke node een adres nodig heeft dat elke andere node zonder vertaling kan bereiken, op de interface die de tunnel biedt. Een tunnel die alleen clients naar een gepubliceerde poort brengt, is niet genoeg. De onderlaag moet in beide richtingen van node naar node routeren.

Test dat voordat je Swarm aanraakt. Controleer vanaf elke node de route naar het tunneladres van een peer, ping het en test dan de controlepoort. Als ping werkt en de poort niet, is de tunnel in orde en staat er een filter in de weg.

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

Als de route naar de fysieke interface wijst in plaats van tun0 of wg0, kapselt de overlay in naar een adres dat de verre locatie niet kan bereiken, en het symptoom leest als pakketverlies.

Controleer welk adres elke node aankondigt

De daemon kondigt één adres aan, en peers gebruiken het voor het dataplane. Op een host met meerdere netwerken is het makkelijk om het LAN- of openbare adres aan te kondigen terwijl de tunnel iets anders draagt. Inspecteer het in plaats van het aan te nemen, en zet het vast bij het joinen met --advertise-addr wanneer de standaardwaarde verkeerd is. Een node die een adres aankondigt dat alleen hij kan bereiken, joint nog steeds de swarm, en de storing verschijnt later als services die niet tussen locaties kunnen praten.

Het aangekondigde adres later wijzigen is geen configuratiebewerking, want de node moet vertrekken en opnieuw joinen.

Noteer het aangekondigde adres per node in je notities, want het verklaart de meeste asymmetrische storingen.

Masquerade is de gebruikelijke boosdoener

Als er een gateway tussen de nodes en de tunnel zit, is de gebruikelijke fout om masquerade toe te passen op alles wat de fysieke interface verlaat. Dat herschrijft ook de interne adressen van de overlay, zodat elke peer van de gateway lijkt te komen en VXLAN-peers elkaar niet meer herkennen. Het resultaat is ontbrekend of eenrichtingsverkeer in ingekapseld verkeer terwijl gewone pings nog werken.

Routeer het overlay-prefix via de gateway en laat het onvertaald. Als vertaling echt nodig is voor een ander prefix, beperk die dan daartoe en nooit tot het bereik dat de overlay gebruikt.

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

Controleer de regelvolgorde én de regeltekst, want een breed MASQUERADE eerder in de keten wint van een smalle uitzondering later.

VXLAN heeft ruimte in het pakket nodig

VXLAN voegt 50 bytes toe aan de frames die het draagt. Een onderlaag van 1500 bytes die een binnenframe van 1500 bytes draagt, levert een ingekapseld pakket op dat geen pad zal afleveren, en de storing lijkt op periodieke service discovery in plaats van een grootteprobleem. Verlaag de MTU van de tunnel aan beide uiteinden of stel de MTU van de overlay zo in dat de driver een payload aankondigt die past.

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

Het ingress-netwerk wordt automatisch aangemaakt, dus het wijzigen ervan betekent verwijderen en opnieuw aanmaken in plaats van ter plaatse bewerken.

Als je maar één kant van de tunnel repareert, blijft de kleinere MTU toch degene die telt.

Let op het dataplane, niet op de logs

Leg de VXLAN-poort aan beide uiteinden vast. Frames die aan de ene kant vertrekken en aan de andere kant aankomen, betekenen dat de onderlaag in orde is en het probleem in de overlay zit. Frames die vertrekken en nooit aankomen, betekenen een route of een filter. Frames die helemaal niet vertrekken, betekenen dat het bronadres verkeerd is.

Service discovery-storingen die na een paar seconden verdwijnen, wijzen meestal op het pakketbudget of een flapperend pad, niet op het raft-quorum.

Bewaar de capture uit een werkend venster, want die vergelijken met de kapotte is sneller dan de configuratie opnieuw lezen.