Docker Swarm tra VPN: taskoj funkcias, servaj alvokoj malsukcesas

Taskoj funkcias en ambaŭ lokoj kaj alvokoj inter servoj tempas. La overlay bezonas itinerojn de nodo al nodo, netradukitajn adresojn kaj lokon por 50 bajtoj da VXLAN.

Tri administrantoj kaj kvin laborantoj en du lokoj, kunligitaj per tunelo, kaj docker service ls montras taskojn funkciantajn ambaŭflanke, dum alvokoj inter servoj tempas. Nenio en la Swarm-protokoloj aspektas malĝuste. Tiu kombinaĵo estas la signo de problemo en la datenebeno: la rega ebeno trovis la nodojn, kaj la enkapsulitaj kadroj neniam faris la vojaĝon.

La maŝo devas ekzisti antaŭ ol la overlay

La overlay de Swarm puŝas enkapsulitajn kadrojn rekte inter nodaj adresoj, kio signifas, ke ĉiu nodo bezonas adreson, kiun ĉiu alia nodo povas atingi sen traduko, sur la interfaco, kiun la tunelo provizas. Tunelo, kiu portas nur klientojn al publikigita pordo, ne sufiĉas. La suba tavolo devas enkursigi de nodo al nodo en ambaŭ direktojn.

Testu tion antaŭ ol tuŝi Swarm. El ĉiu nodo, kontrolu la itineron al la tunela adreso de samtavolano, ping ĝin, kaj poste testu la regan pordon. Se ping funkcias kaj la pordo ne, la tunelo estas en ordo kaj filtrilo staras sur la vojo.

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

Se la itinero montras al la fizika interfaco anstataŭ al tun0 aŭ wg0, la overlay enkapsuligos al adreso, kiun la fora loko ne povas atingi, kaj la simptomo aspektos kiel perdo de pakaĵoj.

Kontrolu, kiun adreson ĉiu nodo anoncas

La demono anoncas unu adreson, kaj la samtavolanoj uzas ĝin por la datenebeno. Sur gastiganto kun pluraj retoj facile anonciĝas la LAN aŭ publika adreso, dum la tunelo portas ion alian. Ekzamenu ĝin anstataŭ supozi, kaj fiksu ĝin ĉe aliĝo per --advertise-addr kiam la defaŭlta estas malĝusta. Nodo, kiu anoncas adreson atingeblan nur de ĝi mem, tamen aliĝas al la swarm, kaj la fiasko montriĝas poste kiel servoj, kiuj ne povas interparoli inter lokoj.

Ŝanĝi la anoncitan adreson poste ne estas redakto de agordo, ĉar la nodo devas foriri kaj realiĝi.

Notu la anoncitan adreson por ĉiu nodo en viaj notoj, ĉar ĝi klarigas la plej multajn nesimetriajn fiaskojn.

Masquerade estas la kutima kulpulo

Kiam pordego sidas inter la nodoj kaj la tunelo, la ofta eraro estas apliki masquerade al ĉio, kio eliras la fizikan interfacon. Tio reverkas ankaŭ la internajn adresojn de la overlay, do ĉiu samtavolano ŝajnas veni de la pordego kaj VXLAN-samtavolanoj ĉesas rekoni unu la alian. La rezulto estas mankanta aŭ unudirekta enkapsulita trafiko, dum ordinaraj ping ankoraŭ funkcias.

Enkursigu la antaŭfiksaĵon de la overlay tra la pordego kaj lasu ĝin netradukita. Se traduko vere necesas por alia antaŭfiksaĵo, limigu ĝin tie kaj neniam al la gamo, kiun la overlay uzas.

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

Kontrolu la ordon de la reguloj same kiel ilian tekston, ĉar larĝa MASQUERADE pli frue en la ĉeno venkas mallarĝan escepton poste.

VXLAN bezonas lokon en la pakaĵo

VXLAN aldonas 50 bajtojn al la kadroj, kiujn ĝi portas. Suba tavolo de 1500 bajtoj portanta internan kadron de 1500 bajtoj produktas enkapsulitan pakaĵon, kiun neniu vojo liveros, kaj la fiasko aspektas kiel intermita malkovro de servoj, ne kiel grandproblemo. Aŭ malaltigu la MTU de la tunelo ĉe ambaŭ finoj, aŭ agordu la MTU de la overlay tiel, ke la pelilo anoncas utilan ŝarĝon, kiu eniras.

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

La ingress-reto kreiĝas aŭtomate, do ŝanĝi ĝin signifas forigi kaj rekrei ĝin, ne redakti ĝin surloke.

Se vi riparas nur unu flankon de la tunelo, la pli malgranda MTU tamen restas la grava.

Observu la datenebanon, ne la protokolojn

Kaptu la VXLAN-pordon ĉe ambaŭ finoj. Kadroj, kiuj forlasas unu flankon kaj alvenas al la alia, signifas, ke la suba tavolo estas en ordo kaj la problemo estas ene de la overlay. Kadroj, kiuj foriras kaj neniam alvenas, signifas itineron aŭ filtrilon. Kadroj, kiuj tute ne foriras, signifas, ke la fonta adreso estas malĝusta.

Fiaskoj de malkovro de servoj, kiuj malaperas post kelkaj sekundoj, kutime montras al la pakaĵa buĝeto aŭ al flirtanta vojo, ne al raft-kvorumo.

Konservu la kaptaĵon el funkcianta fenestro, ĉar kompari ĝin kun la rompita estas pli rapida ol relegi la agordon.

Rilataj artikoloj