Docker Swarm preko VPN-a: zadaci rade, pozivi servisa ne uspevaju

Tri menadžera i pet radnika na dva lokaliteta, povezanih tunelom, i docker service ls pokazuje zadatke koji rade sa obe strane, dok pozivi između servisa ističu. Ništa u Swarm zapisima ne izgleda pogrešno. Ta kombinacija je potpis problema u ravni podataka: kontrolna ravan je pronašla čvorove, a inkapsulirani okviri nikada nisu prešli put.

Mreža mora postojati pre overlay-a

Swarm overlay gura inkapsulirane okvire direktno između adresa čvorova, što znači da svakom čvoru treba adresa do koje svaki drugi čvor može doći bez prevoda, na interfejsu koji tunel pruža. Tunel koji prenosi samo klijente do objavljenog porta nije dovoljan. Donji sloj mora da rutira od čvora do čvora u oba smera.

Testirajte to pre nego što dirnete Swarm. Sa svakog čvora proverite rutu do tunelske adrese partnera, pingujte je, a zatim testirajte kontrolni port. Ako ping radi a port ne, tunel je u redu i neki filter stoji na putu.

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

Ako ruta pokazuje na fizički interfejs umesto na tun0 ili wg0, overlay će inkapsulirati na adresu do koje udaljeni lokalitet ne može doći, a simptom će izgledati kao gubitak paketa.

Proverite koju adresu svaki čvor oglašava

Daemon oglašava jednu adresu i partneri je koriste za ravan podataka. Na hostu sa više mreža lako je oglašavati LAN ili javnu adresu dok tunel nosi nešto drugo. Pregledajte je umesto da pretpostavljate i fiksirajte je pri pridruživanju pomoću --advertise-addr kada je podrazumevana pogrešna. Čvor koji oglašava adresu dostupnu samo njemu ipak se pridružuje swarmu, a kvar se kasnije pokaže kao servisi koji ne mogu da komuniciraju između lokaliteta.

Promena oglašene adrese kasnije nije uređivanje konfiguracije, jer čvor mora da izađe i ponovo se pridruži.

Zabeležite oglašenu adresu po čvoru u svoje beleške, jer to objašnjava većinu asimetričnih kvarova.

Masquerade je uobičajeni krivac

Kada gateway stoji između čvorova i tunela, česta greška je primeniti masquerade na sve što izlazi sa fizičkog interfejsa. To prepisuje i unutrašnje adrese overlay-a, pa svaki partner izgleda kao da dolazi sa gateway-a i VXLAN partneri prestaju da prepoznaju jedni druge. Rezultat je izgubljen ili jednosmeran inkapsulirani saobraćaj dok obični pingovi još rade.

Rutirajte prefiks overlay-a kroz gateway i ostavite ga neprevedenog. Ako je prevod zaista potreban za drugi prefiks, ograničite ga tamo i nikada na raspon koji overlay koristi.

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

Proverite redosled pravila kao i tekst pravila, jer široko MASQUERADE ranije u lancu pobeđuje uski izuzetak kasnije.

VXLAN zahteva prostor u paketu

VXLAN dodaje 50 bajtova okvirima koje nosi. Donji sloj od 1500 bajtova koji nosi unutrašnji okvir od 1500 bajtova stvara inkapsulirani paket koji nijedna putanja neće dostaviti, a kvar izgleda kao povremeno otkrivanje servisa, a ne kao problem veličine. Ili smanjite MTU tunela na oba kraja ili postavite MTU overlay-a tako da drajver oglašava korisni teret koji staje.

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

Ingress mreža se stvara automatski, pa njena promena znači uklanjanje i ponovno stvaranje, a ne uređivanje na mestu.

Ako popravite samo jednu stranu tunela, manji MTU ipak ostaje onaj koji je važan.

Gledajte ravan podataka, a ne zapise

Snimite VXLAN port na oba kraja. Okviri koji napuštaju jednu stranu i stižu na drugu znače da je donji sloj u redu i da je problem unutar overlay-a. Okviri koji odlaze i nikada ne stižu znače rutu ili filter. Okviri koji uopšte ne odlaze znače da je izvorna adresa pogrešna.

Kvarovi otkrivanja servisa koji nestanu posle nekoliko sekundi obično upućuju na budžet paketa ili nestabilnu putanju, a ne na raft kvorum.

Sačuvajte snimak iz radnog perioda, jer je poređenje sa pokvarenim brže od ponovnog čitanja konfiguracije.