Docker Swarm prek VPN: opravila tečejo, klici med storitvami spodletijo

Trije upravitelji in pet delavcev na dveh lokacijah, povezanih s tunelom, in docker service ls prikazuje opravila, ki tečejo na obeh straneh, medtem ko klici med storitvami potečejo. V dnevnikih Swarma nič ne izgleda narobe. Ta kombinacija je podpis težave v ravnini podatkov: krmilna ravnina je našla vozlišča, inkapsulirani okviri pa poti nikoli niso opravili.

Omrežje mora obstajati pred overlayjem

Overlay Swarma potiska inkapsulirane okvire neposredno med naslove vozlišč, kar pomeni, da vsako vozlišče potrebuje naslov, do katerega vsako drugo vozlišče doseže brez prevajanja, na vmesniku, ki ga ponuja tunel. Tunel, ki prevaža le odjemalce do objavljenih vrat, ne zadostuje. Spodnja plast mora usmerjati od vozlišča do vozlišča v obe smeri.

To preizkusite, preden se dotaknete Swarma. Z vsakega vozlišča preverite pot do tunelskega naslova partnerja, ga pingajte in nato preizkusite krmilna vrata. Če ping deluje, vrata pa ne, je tunel v redu in na poti je filter.

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

Če pot kaže na fizični vmesnik namesto na tun0 ali wg0, bo overlay inkapsuliral na naslov, ki ga oddaljena lokacija ne doseže, simptom pa bo videti kot izguba paketov.

Preverite, kateri naslov oglašuje vsako vozlišče

Demon oglašuje en naslov in partnerji ga uporabljajo za ravnino podatkov. Na gostitelju z več omrežji je enostavno oglaševati naslov LAN ali javni naslov, medtem ko tunel prevaža nekaj drugega. Preglejte ga, namesto da bi ga predpostavljali, in ga pri pridružitvi pritrdite z --advertise-addr, ko je privzeta vrednost napačna. Vozlišče, ki oglašuje naslov, dosegljiv samo njemu, se vseeno pridruži swarmu, napaka pa se pozneje pokaže kot storitve, ki se ne morejo pogovarjati med lokacijami.

Sprememba oglaševanega naslova pozneje ni urejanje konfiguracije, ker mora vozlišče oditi in se znova pridružiti.

Zapišite oglaševani naslov za vsako vozlišče v svoje zapiske, ker pojasnjuje večino asimetričnih napak.

Masquerade je običajni krivec

Ko med vozlišči in tunelom stoji prehod, je pogosta napaka uporabiti masquerade za vse, kar zapusti fizični vmesnik. To prepiše tudi notranje naslove overlaya, zato je videti, kot da vsak partner prihaja s prehoda, in partnerji VXLAN se prenehajo prepoznavati. Rezultat je manjkajoč ali enosmeren inkapsuliran promet, medtem ko običajni ping še deluje.

Usmerite predpono overlaya skozi prehod in jo pustite neprevedeno. Če je prevajanje res potrebno za drugo predpono, ga omejite tja in nikoli na obseg, ki ga uporablja overlay.

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

Preverite vrstni red pravil in tudi besedilo, ker široko MASQUERADE prej v verigi premaga ozko izjemo pozneje.

VXLAN potrebuje prostor v paketu

VXLAN doda 50 bajtov okvirom, ki jih prevaža. Spodnja plast 1500 bajtov, ki prevaža notranji okvir 1500 bajtov, ustvari inkapsuliran paket, ki ga nobena pot ne bo dostavila, in napaka je videti kot občasno odkrivanje storitev, ne kot težava z velikostjo. Bodisi znižajte MTU tunela na obeh koncih bodisi nastavite MTU overlaya tako, da gonilnik oglašuje koristni tovor, ki se prilega.

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

Omrežje ingress se ustvari samodejno, zato njegova sprememba pomeni odstranitev in ponovno ustvarjanje, ne urejanja na mestu.

Če popravite samo eno stran tunela, manjši MTU še vedno ostaja tisti, ki šteje.

Opazujte ravnino podatkov, ne dnevnikov

Zajemite vrata VXLAN na obeh koncih. Okviri, ki zapustijo eno stran in prispejo na drugo, pomenijo, da je spodnja plast v redu in da je težava znotraj overlaya. Okviri, ki odidejo in nikoli ne prispejo, pomenijo pot ali filter. Okviri, ki sploh ne odidejo, pomenijo, da je izvorni naslov napačen.

Napake pri odkrivanju storitev, ki izginejo po nekaj sekundah, običajno kažejo na proračun paketov ali nestabilno pot, ne na raft kvorum.

Shranite zajem iz delujočega okna, ker je primerjava s pokvarjenim hitrejša od ponovnega branja konfiguracije.