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

Tri menadžera i pet radnika na dva lokaliteta, povezanih tunelom, i docker service ls pokazuje zadatke koji rade s obje 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 enkapsulirani okviri nikada nisu prešli put.

Mreža mora postojati prije overlay mreže

Swarm overlay gura enkapsulirane okvire direktno između adresa čvorova, što znači da svakom čvoru treba adresa do koje svaki drugi čvor može doći bez translacije, na interfejsu koji tunel pruža. Tunel koji prenosi samo klijente do objavljenog porta nije dovoljan. Donji sloj mora rutirati 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 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 umjesto na tun0 ili wg0, overlay će enkapsulirati 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 ravan 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 ponovo 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 greška je primijeniti masquerade na sve što izlazi s fizičkog interfejsa. To prepisuje i unutrašnje adrese overlaya, pa svaki partner izgleda kao da dolazi s gatewaya i VXLAN partneri prestaju prepoznavati jedni druge. Rezultat je izgubljen ili jednosmjeran enkapsulirani promet dok obični pingovi još rade.

Rutirajte prefiks overlaya kroz gateway i ostavite ga netransliranog. Ako je translacija doista potrebna za drugi prefiks, ograničite je 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 usko izuzetak kasnije.

VXLAN-u treba prostor u paketu

VXLAN dodaje 50 bajtova okvirima koje nosi. Donji sloj od 1500 bajtova koji nosi unutrašnji okvir od 1500 bajtova stvara enkapsulirani 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 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 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 bitan.

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 overlaya. Okviri koji odlaze i nikada ne stižu znače rutu ili filter. 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 budžet paketa ili nestabilnu putanju, a ne na raft kvorum.

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