Docker Swarm over VPN: oppgaver kjører, tjenestekall feiler

Tre managere og fem arbeidere på tvers av to nettsteder, forbundet med en tunnel, og docker service ls viser oppgaver som kjører på begge sider mens kall mellom tjenester timer ut. Ingenting i Swarm-loggene ser galt ut. Den kombinasjonen er signaturen på et problem i dataplanet: kontrollplanet fant nodene, og de innkapslede rammene nådde aldri fram.

Nettet må finnes før overlayet gjør det

Overlayet i Swarm skyver innkapslede rammer direkte mellom nodeadresser, som betyr at hver node trenger en adresse som hver annen node kan nå uten oversettelse, på grensesnittet tunnelen tilbyr. En tunnel som bare fører klienter til en publisert port er ikke nok. Underlaget må rute fra node til node i begge retninger.

Test det før du rører Swarm. Fra hver node, sjekk ruten til en peers tunneladresse, ping den, og test deretter kontrollporten. Hvis ping virker og porten ikke, er tunnelen i orden og et filter står i veien.

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 peker på det fysiske grensesnittet i stedet for tun0 eller wg0, vil overlayet kapsle inn mot en adresse det fjerne nettstedet ikke kan nå, og symptomet vil se ut som pakketap.

Sjekk hvilken adresse hver node annonserer

Damen annonserer én adresse, og peers bruker den for dataplanet. På en vert med flere nett er det lett å annonsere LAN- eller den offentlige adressen mens tunnelen bærer noe annet. Undersøk den i stedet for å anta, og fest den ved join med --advertise-addr når standardverdien er feil. En node som annonserer en adresse bare den selv kan nå, blir likevel med i swarmen, og feilen viser seg senere som tjenester som ikke kan snakke sammen på tvers av nettsteder.

Å endre den annonserte adressen senere er ikke en konfigurasjonsendring, fordi noden må forlate og bli med på nytt.

Noter den annonserte adressen per node i notatene dine, fordi den forklarer de fleste asymmetriske feil.

Masquerade er den vanlige synderen

Når en gateway sitter mellom nodene og tunnelen, er den vanlige feilen å masquerade alt som forlater det fysiske grensesnittet. Det skriver også om overlayets indre adresser, slik at hver peer ser ut til å komme fra gatewayen og VXLAN-peers slutter å kjenne hverandre igjen. Resultatet er manglende eller ensrettet innkapslet trafikk mens vanlige ping fortsatt virker.

Rut overlay-prefikset gjennom gatewayen og la det være uoversatt. Hvis oversettelse virkelig er nødvendig for et annet prefiks, begrens den dit og aldri til området overlayet bruker.

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

Sjekk regelrekkefølgen så vel som regelteksten, fordi et bredt MASQUERADE tidligere i kjeden vinner over et smalt unntak senere.

VXLAN trenger plass i pakken

VXLAN legger til 50 byte på rammene den bærer. Et underlag på 1500 byte som bærer en indre ramme på 1500 byte gir en innkapslet pakke som ingen sti vil levere, og feilen ser ut som periodisk tjenesteoppdagelse snarere enn et størrelsesproblem. Senk enten MTU-en til tunnelen i begge ender eller sett MTU-en til overlayet slik at driveren annonserer en nyttelast som passer.

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

Ingress-nettet opprettes automatisk, så å endre det betyr å fjerne og gjenopprette det i stedet for å redigere det på stedet.

Hvis du bare fikser én side av tunnelen, er den minste MTU-en fortsatt den som betyr noe.

Følg med på dataplanet, ikke loggene

Fang VXLAN-porten i begge ender. Rammene som forlater den ene siden og ankommer den andre, betyr at underlaget er i orden og problemet er inne i overlayet. Rammene som forlater og aldri ankommer, betyr en rute eller et filter. Rammene som ikke forlater i det hele tatt, betyr at kildeadressen er feil.

Tjenesteoppdagelsesfeil som forsvinner etter noen sekunder peker vanligvis på pakkebudsjettet eller en ustabil sti, ikke på raft-kvorum.

Ta vare på opptaket fra et fungerende vindu, fordi å sammenligne det med det ødelagte er raskere enn å lese konfigurasjonen på nytt.