Docker Swarm përmes VPN: detyrat ekzekutohen, thirrjet midis shërbimeve dështojnë

Tre menaxherë dhe pesë punëtorë në dy lokalitete, të lidhur me një tunel, dhe docker service ls tregon detyra që ekzekutohen në të dyja anët ndërsa thirrjet midis shërbimeve skadojnë. Asgjë në regjistrat e Swarm nuk duket e gabuar. Ky kombinim është nënshkrimi i një problemi në planin e të dhënave: plani i kontrollit gjeti nyjet, dhe kornizat e kapsuluara nuk e bënë kurrë udhëtimin.

Rrjeta duhet të ekzistojë para overlay

Overlay i Swarm shtyn kornizat e kapsuluara drejtpërdrejt midis adresave të nyjeve, që do të thotë se çdo nyje ka nevojë për një adresë që çdo nyje tjetër mund ta arrijë pa përkthim, në ndërfaqen që ofron tuneli. Një tunel që çon vetëm klientë në një port të publikuar nuk mjafton. Shtresa e poshtme duhet të rrugëtojë nga nyja në nyje në të dy drejtimet.

Testojeni këtë para se të prekni Swarm. Nga çdo nyje, kontrolloni rrugën drejt adresës së tunelit të një partneri, bëni ping dhe më pas testoni portin e kontrollit. Nëse ping funksionon dhe porti jo, tuneli është në rregull dhe një filtër është në rrugë.

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

Nëse rruga tregon ndërfaqen fizike në vend të tun0 ose wg0, overlay do të kapsulojë drejt një adrese që lokaliteti i largët nuk mund ta arrijë, dhe simptoma do të duket si humbje paketash.

Kontrolloni çfarë adrese shpall çdo nyje

Daemoni shpall një adresë, dhe partnerët e përdorin atë për planin e të dhënave. Në një host me shumë rrjeta është e lehtë të shpallësh adresën LAN ose publike ndërsa tuneli mbart diçka tjetër. Inspektojeni në vend që ta supozoni, dhe fiksojeni gjatë bashkimit me --advertise-addr kur parazgjedhja është e gabuar. Një nyje që shpall një adresë që vetëm ajo mund ta arrijë prapëseprapë bashkohet me swarm, dhe dështimi shfaqet më vonë si shërbime që nuk mund të komunikojnë midis lokaliteteve.

Ndryshimi i adresës së shpallur më vonë nuk është redaktim konfigurimi, sepse nyja duhet të dalë dhe të bashkohet përsëri.

Shënoni adresën e shpallur për çdo nyje në shënimet tuaja, sepse shpjegon shumicën e dështimeve asimetrike.

Masquerade është fajtori i zakonshëm

Kur një portë qëndron midis nyjeve dhe tunelit, gabimi i zakonshëm është të aplikosh masquerade për gjithçka që del nga ndërfaqja fizike. Kjo rishkruan edhe adresat e brendshme të overlay, kështu që çdo partner duket se vjen nga porta dhe partnerët VXLAN ndalojnë së njohuri njëri-tjetrin. Rezultati është trafik i kapsuluar që mungon ose njëdrejtimësh, ndërsa ping-et e thjeshta vazhdojnë të funksionojnë.

Rrugëtoni prefiksin e overlay përmes portës dhe lëreni të papërkthyer. Nëse përkthimi është vërtet i nevojshëm për një prefiks tjetër, kufizojeni atje dhe kurrë në intervalin që përdor overlay.

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

Kontrolloni renditjen e rregullave si dhe tekstin, sepse një MASQUERADE i gjerë më herët në zinxhir mund një përjashtim të ngushtë më vonë.

VXLAN ka nevojë për hapësirë në paketë

VXLAN shton 50 bajt në kornizat që mbart. Shtresa e poshtme prej 1500 bajt që mbart një kornizë të brendshme prej 1500 bajt prodhon një paketë të kapsuluar që asnjë rrugë nuk do ta dorëzojë, dhe dështimi duket si zbulim shërbimesh i ndërprerë, jo si problem madhësie. Ose ulni MTU-në e tunelit në të dy skajet, ose vendosni MTU-në e overlay në mënyrë që drejtuesi të shpallë një ngarkesë që përshtatet.

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

Rrjeta ingress krijohet automatikisht, pra ndryshimi i saj nënkupton heqje dhe rikrijim, jo redaktim në vend.

Nëse rregulloni vetëm njërën anë të tunelit, MTU-ja më e vogël mbetet ajo që ka rëndësi.

Vëzhgoni planin e të dhënave, jo regjistrat

Kapni portin VXLAN në të dy skajet. Kornizat që largohen nga njëra anë dhe mbërrijnë në tjetrën tregojnë se shtresa e poshtme është në rregull dhe problemi është brenda overlay. Kornizat që largohen dhe nuk mbërrijnë kurrë tregojnë një rrugë ose një filtër. Kornizat që nuk largohen fare tregojnë se adresa e burimit është e gabuar.

Dështimet e zbulimit të shërbimeve që zhduken pas disa sekondash zakonisht tregojnë buxhetin e paketave ose një rrugë të paqëndrueshme, jo kuorumin raft.

Ruani kapjen nga një dritare që funksionon, sepse krahasimi me atë të prishur është më i shpejtë sesa rileximi i konfigurimit.