Docker Swarm over VPN: opgaver kører, servicekald fejler

Opgaver kører på begge sites, og kald mellem tjenester timeouter. Overlayet har brug for node-til-node-ruter, uoversatte adresser og plads til 50 byte VXLAN.

Tre managere og fem arbejdere på tværs af to sites, forbundet af en tunnel, og docker service ls viser opgaver, der kører på begge sider, mens kald mellem tjenester timeouter. Intet i Swarm-loggene ser forkert ud. Den kombination er signaturen på et problem i dataplanet: kontrolplanet fandt noderne, og de indkapslede frames nåede aldrig frem.

Mesh'et skal findes, før overlayet gør

Swarm-overlayet sender indkapslede frames direkte mellem nodeadresser, hvilket betyder, at hver node har brug for en adresse, som enhver anden node kan nå uden oversættelse, på det interface som tunnelen stiller til rådighed. En tunnel, der kun fører klienter til en publiceret port, er ikke nok. Underlaget skal route fra node til node i begge retninger.

Test det, før du rører ved Swarm. Fra hver node kontrollerer du ruten til en peers tunneladresse, pinger den og tester derefter kontrolporten. Hvis ping virker, og porten ikke gør, er tunnelen fin, og et filter er i vejen.

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

Hvis ruten peger på det fysiske interface i stedet for tun0 eller wg0, vil overlayet indkapsle til en adresse, som det fjerne site ikke kan nå, og symptomet vil ligne pakketab.

Kontroller, hvilken adresse hver node annoncerer

Daemonen annoncerer én adresse, og peers bruger den til dataplanet. På en vært med flere netværk er det let at annoncere LAN- eller den offentlige adresse, mens tunnelen bærer noget andet. Undersøg den i stedet for at antage, og fastlås den ved join med --advertise-addr, når standarden er forkert. En node, der annoncerer en adresse, som kun den selv kan nå, joiner stadig swarmen, og fejlen viser sig senere som tjenester, der ikke kan tale sammen på tværs af sites.

At ændre den annoncerede adresse senere er ikke en konfigurationsrettelse, fordi noden skal forlade og joine igen.

Notér den annoncerede adresse pr. node i dine noter, fordi det forklarer de fleste asymmetriske fejl.

Masquerade er den sædvanlige synder

Når en gateway sidder mellem noderne og tunnelen, er den almindelige fejl at masquerade alt, der forlader det fysiske interface. Det omskriver også overlayets indre adresser, så hver peer ser ud til at komme fra gatewayen, og VXLAN-peers holder op med at genkende hinanden. Resultatet er manglende eller ensrettet indkapslet trafik, mens almindelige ping stadig virker.

Route overlay-prefixet gennem gatewayen, og lad det være uoversat. Hvis oversættelse virkelig er nødvendig for et andet prefix, så begræns den dertil og aldrig til det område, overlayet bruger.

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

Kontroller regelrækkefølgen såvel som regelteksten, fordi et bredt MASQUERADE tidligere i kæden vinder over en smal undtagelse senere.

VXLAN har brug for plads i pakken

VXLAN tilføjer 50 byte til de frames, den bærer. Et underlag på 1500 byte, der bærer en indre frame på 1500 byte, giver en indkapslet pakke, som ingen sti vil levere, og fejlen ligner periodisk service discovery snarere end et størrelsesproblem. Sænk enten tunnelens MTU i begge ender, eller sæt overlayets MTU, så driveren annoncerer en nyttelast, der passer.

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

Ingress-netværket oprettes automatisk, så at ændre det betyder at fjerne og genskabe det i stedet for at redigere det på stedet.

Retter du kun den ene side af tunnelen, er den mindste MTU stadig den, der betyder noget.

Hold øje med dataplanet, ikke loggene

Fang VXLAN-porten i begge ender. Frames, der forlader den ene side og ankommer til den anden, betyder, at underlaget er fint, og problemet er inde i overlayet. Frames, der forlader og aldrig ankommer, betyder en rute eller et filter. Frames, der slet ikke forlader, betyder, at kildeadressen er forkert.

Service discovery-fejl, der forsvinder efter få sekunder, peger normalt på pakkebudgettet eller en flappende sti, ikke på raft-quorum.

Gem optagelsen fra et fungerende vindue, fordi sammenligning med den ødelagte er hurtigere end at læse konfigurationen igen.

Relaterede artikler