Docker Swarm över VPN: uppgifterna kör, tjänstanrop misslyckas

Uppgifter körs på båda platserna och anrop mellan tjänster tajmar ut. Overlayet behöver nod-till-nod-rutter, oöversatta adresser och plats för 50 byte VXLAN.

Tre managers och fem workers över två platser, sammankopplade med en tunnel, och docker service ls visar uppgifter som kör på båda sidor medan anrop mellan tjänster tajmar ut. Ingenting i Swarms loggar ser fel ut. Den kombinationen är signaturen för ett problem i dataplanet: kontrollplanet hittade noderna, och de inkapslade ramarna gjorde aldrig resan.

Nätet måste finnas innan overlayet gör det

Swarms overlay skickar inkapslade ramar direkt mellan nodadresser, vilket betyder att varje nod behöver en adress som varje annan nod kan nå utan översättning, på det gränssnitt tunneln erbjuder. En tunnel som bara för klienter till en publicerad port räcker inte. Underlagret måste routa från nod till nod i båda riktningarna.

Testa det innan du rör Swarm. Från varje nod, kontrollera rutten till en peers tunneladress, pinga den och testa sedan kontrollporten. Om ping fungerar och porten inte, är tunneln okej och ett filter står i vägen.

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

Om rutten pekar på det fysiska gränssnittet i stället för tun0 eller wg0, kommer overlayet att kapsla in mot en adress som den avlägsna platsen inte kan nå, och symptomet kommer att läsas som paketförlust.

Kontrollera vilken adress varje nod annonserar

Daemonen annonserar en adress, och peers använder den för dataplanet. På en värd med flera nätverk är det lätt att annonsera LAN- eller den publika adressen medan tunneln bär något annat. Granska den i stället för att anta, och fäst den vid join med --advertise-addr när standardvärdet är fel. En nod som annonserar en adress som bara den själv kan nå går ändå med i swarmen, och felet visar sig senare som tjänster som inte kan prata mellan platser.

Att ändra den annonserade adressen senare är inte en konfigurationsändring, eftersom noden måste lämna och gå med igen.

Anteckna den annonserade adressen per nod i dina anteckningar, eftersom den förklarar de flesta asymmetriska fel.

Masquerade är den vanliga boven

När en gateway sitter mellan noderna och tunneln är det vanliga misstaget att masquerade allt som lämnar det fysiska gränssnittet. Det skriver också om overlayets inre adresser, så varje peer ser ut att komma från gatewayen och VXLAN-peers slutar känna igen varandra. Resultatet är saknad eller enkelriktad inkapslad trafik medan vanliga ping fortfarande fungerar.

Routa overlayets prefix genom gatewayen och låt det vara oöversatt. Om översättning verkligen behövs för ett annat prefix, begränsa den dit och aldrig till det intervall overlayet använder.

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

Kontrollera regelordningen såväl som regeltexten, eftersom ett brett MASQUERADE tidigare i kedjan vinner över ett smalt undantag senare.

VXLAN behöver plats i paketet

VXLAN lägger till 50 byte på ramarna den bär. Ett underlager på 1500 byte som bär en inre ram på 1500 byte ger ett inkapslat paket som ingen väg levererar, och felet ser ut som intermittent tjänsteupptäckt snarare än ett storleksproblem. Sänk antingen tunnelns MTU i båda ändar eller ställ in overlayets MTU så att drivrutinen annonserar en nyttolast som får plats.

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

Ingress-nätverket skapas automatiskt, så att ändra det betyder att ta bort och återskapa det i stället för att redigera det på plats.

Om du bara lagar ena sidan av tunneln är den mindre MTU:n fortfarande den som avgör.

Titta på dataplanet, inte på loggarna

Fånga VXLAN-porten i båda ändar. Ramar som lämnar en sida och anländer på den andra betyder att underlagret är okej och att problemet finns inuti overlayet. Ramar som lämnar och aldrig anländer betyder en rutt eller ett filter. Ramar som inte lämnar alls betyder att källadressen är fel.

Tjänsteupptäcktsfel som försvinner efter några sekunder pekar vanligtvis på paketbudgeten eller en fladdrande väg, inte på raft-kvorum.

Spara fångsten från ett fungerande fönster, eftersom att jämföra den med den trasiga är snabbare än att läsa konfigurationen igen.

Relaterade artiklar