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

Tri upravitelja i pet radnika na dva lokaliteta, povezanih tunelom, i docker service ls pokazuje zadatke koji rade s obje strane, dok pozivi između servisa istječu. Ništa u Swarm zapisima ne izgleda pogrešno. Ta kombinacija je potpis problema u ravnini podataka: kontrolna ravnina pronašla je čvorove, a inkapsulirani okviri nikada nisu prešli put.

Mreža mora postojati prije overlayja

Swarmov overlay gura inkapsulirane okvire izravno između adresa čvorova, što znači da svaki čvor treba adresu do koje svaki drugi čvor može doći bez prijevoda, na sučelju koje tunel pruža. Tunel koji prenosi samo klijente do objavljenog porta nije dovoljan. Donji sloj mora usmjeravati od čvora do čvora u oba smjera.

Testirajte to prije nego dirnete Swarm. Sa svakog čvora provjerite rutu do tunelske adrese partnera, pingajte je, a zatim testirajte kontrolni port. Ako ping radi, a port ne, tunel je u redu i neki filtar 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čko sučelje umjesto 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.

Provjerite koju adresu svaki čvor oglašava

Daemon oglašava jednu adresu i partneri je koriste za ravninu podataka. Na hostu s više mreža lako je oglašavati LAN ili javnu adresu dok tunel nosi nešto drugo. Pregledajte je umjesto da pretpostavljate i fiksirajte je pri pridruživanju pomoću --advertise-addr kada je zadana 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 komunicirati između lokaliteta.

Promjena oglašene adrese kasnije nije uređivanje konfiguracije, jer čvor mora izaći i ponovno se pridružiti.

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

Masquerade je uobičajeni krivac

Kada gateway stoji između čvorova i tunela, česta je pogreška primijeniti masquerade na sve što izlazi s fizičkog sučelja. To prepisuje i unutarnje adrese overlaya, pa svaki partner izgleda kao da dolazi s gatewayja i VXLAN partneri prestaju prepoznavati jedni druge. Rezultat je izgubljen ili jednosmjeran inkapsulirani promet dok obični pingovi još rade.

Usmjerite prefiks overlaya kroz gateway i ostavite ga neprevedenog. Ako je prijevod doista 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

Provjerite redoslijed pravila kao i tekst pravila, jer široko MASQUERADE ranije u lancu pobjeđuje usku iznimku kasnije.

VXLAN treba prostor u paketu

VXLAN dodaje 50 bajtova okvirima koje nosi. Donji sloj od 1500 bajtova koji nosi unutarnji 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 overlaya tako da upravljački program oglašava korisni teret koji stane.

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

Ingress mreža stvara se automatski, pa njezina promjena znači uklanjanje i ponovno stvaranje, a ne uređivanje na mjestu.

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

Gledajte ravninu 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 overlaya. Okviri koji odlaze i nikada ne stižu znače rutu ili filtar. Okviri koji uopće ne odlaze znače da je izvorna adresa pogrešna.

Kvarovi otkrivanja servisa koji nestanu nakon nekoliko sekundi obično upućuju na proračun paketa ili nestabilnu putanju, a ne na raft kvorum.

Sačuvajte snimku iz radnog razdoblja, jer je usporedba s pokvarenom brža od ponovnog čitanja konfiguracije.