Docker Swarm per VPN: užduotys veikia, paslaugų kvietimai nepavyksta
Užduotys veikia abiejose vietose, o kvietimai tarp paslaugų baigiasi skirtuoju laiku. Overlay reikia maršrutų tarp mazgų, neišverstų adresų ir vietos 50 baitų VXLAN.
Trys valdytojai ir penki darbininkai dviejose vietose, sujungtose tuneliu, ir docker service ls rodo abiejose pusėse veikiančias užduotis, o kvietimai tarp paslaugų baigiasi skirtuoju laiku. Swarm žurnaluose niekas neatrodo neteisingai. Šis derinys yra duomenų plokštumos problemos požymis: valdymo plokštuma rado mazgus, o inkapsuliuoti kadrai taip ir neįveikė kelio.
Tinklas turi egzistuoti prieš overlay
Swarm overlay stumia inkapsuliuotus kadrus tiesiai tarp mazgų adresų, o tai reiškia, kad kiekvienam mazgui reikia adreso, kurį kiekvienas kitas mazgas pasiektų be vertimo, sąsajoje, kurią suteikia tunelis. Tunelis, kuris veža tik klientus į paskelbtą prievadą, nepakanka. Apatinis sluoksnis turi maršrutizuoti nuo mazgo iki mazgo abiem kryptimis.
Išbandykite tai prieš liesdami Swarm. Iš kiekvieno mazgo patikrinkite maršrutą į partnerio tunelio adresą, pinginkite jį ir tada patikrinkite valdymo prievadą. Jei ping veikia, o prievadas ne, tunelis geras, o kelyje stovi filtras.
ip -brief address
ip route get 10.20.0.12
ping -c3 10.20.0.12
nc -vz 10.20.0.12 2377
Jei maršrutas rodo į fizinę sąsają, o ne į tun0 ar wg0, overlay inkapsuliuos į adresą, kurio tolima vieta negali pasiekti, ir simptomas atrodys kaip paketų praradimas.
Patikrinkite, kokį adresą skelbia kiekvienas mazgas
Daimonas skelbia vieną adresą, o partneriai jį naudoja duomenų plokštumai. Kelių tinklų hoste lengva paskelbti LAN arba viešą adresą, kai tunelis veža ką nors kita. Patikrinkite jį, o ne darykite prielaidų, ir prisijungdami prisekite jį su --advertise-addr, kai numatytasis neteisingas. Mazgas, skelbiantis adresą, kurį pasiekia tik jis pats, vis tiek prisijungia prie swarm, o gedimas vėliau pasirodo kaip paslaugos, kurios negali susikalbėti tarp vietų.
Paskelbto adreso keitimas vėliau nėra konfigūracijos redagavimas, nes mazgas turi išeiti ir vėl prisijungti.
Užsirašykite paskelbtą adresą kiekvienam mazgui savo užrašuose, nes tai paaiškina daugumą asimetriškų gedimų.
Masquerade yra įprastas kaltininkas
Kai tarp mazgų ir tunelio stovi tinklo vartai, dažna klaida yra taikyti masquerade viskam, kas išeina iš fizinės sąsajos. Tai perrašo ir vidinius overlay adresus, todėl kiekvienas partneris atrodo ateinantis iš vartų ir VXLAN partneriai nustoja atpažinti vienas kitą. Rezultatas yra dingęs arba vienkryptis inkapsuliuotas srautas, kol paprasti ping dar veikia.
Maršrutizuokite overlay priešdėlį per vartus ir palikite jį neišverstą. Jei vertimas tikrai reikalingas kitam priešdėliui, apribokite jį ten ir niekada netaikykite overlay naudojamam diapazonui.
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
Patikrinkite taisyklių tvarką ir tekstą, nes platus MASQUERADE anksčiau grandinėje nugali siaurą išimtį vėliau.
VXLAN reikia vietos pakete
VXLAN prideda 50 baitų prie vežamų kadrų. 1500 baitų apatinis sluoksnis, vežantis 1500 baitų vidinį kadrą, sukuria inkapsuliuotą paketą, kurio joks kelias nepristatys, ir gedimas atrodo kaip protarpinis paslaugų aptikimas, o ne dydžio problema. Arba sumažinkite tunelio MTU abiejuose galuose, arba nustatykite overlay MTU taip, kad tvarkyklė skelbtų telpančią naudingąją apkrovą.
docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1400 swarm-overlay
Ingress tinklas sukuriamas automatiškai, todėl jį pakeisti reiškia pašalinti ir sukurti iš naujo, o ne redaguoti vietoje.
Jei sutaisysite tik vieną tunelio pusę, mažesnis MTU vis tiek išlieka svarbiausias.
Stebėkite duomenų plokštumą, o ne žurnalus
Užfiksuokite VXLAN prievadą abiejuose galuose. Kadrai, išeinantys iš vienos pusės ir atvykstantys į kitą, reiškia, kad apatinis sluoksnis geras, o problema yra overlay viduje. Kadrai, išeinantys ir niekada neatvykstantys, reiškia maršrutą arba filtrą. Kadrai, visai neišeinantys, reiškia, kad šaltinio adresas neteisingas.
Paslaugų aptikimo gedimai, išnykstantys po kelių sekundžių, paprastai nurodo paketų biudžetą arba nepastovų kelią, o ne raft kvorumą.
Išsaugokite įrašą iš veikiančio lango, nes palyginti jį su sugedusiu greičiau nei iš naujo skaityti konfigūraciją.