Docker Swarm přes VPN: úlohy běží, volání mezi službami selhávají

Tři manažeři a pět pracovníků na dvou lokalitách, spojených tunelem, a docker service ls ukazuje úlohy běžící na obou stranách, zatímco volání mezi službami vyprávějí. V protokolech Swarmu nic nevypadá špatně. Tahle kombinace je podpisem problému v datové rovině: řídicí rovina uzly našla a zapouzdřené rámce cestu nikdy nevykonaly.

Síť musí existovat dřív než overlay

Overlay ve Swarmu posílá zapouzdřené rámce přímo mezi adresami uzlů, což znamená, že každý uzel potřebuje adresu, na kterou každý jiný uzel dosáhne bez překladu, na rozhraní, které tunel poskytuje. Tunel, který přenáší jen klienty k publikovanému portu, nestačí. Spodní vrstva musí směrovat od uzlu k uzlu v obou směrech.

Otestujte to, než se Swarmu dotknete. Z každého uzlu zkontrolujte trasu k tunelové adrese protějšku, pingněte ji a potom otestujte řídicí port. Pokud ping funguje a port ne, tunel je v pořádku a v cestě stojí filtr.

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

Pokud trasa ukazuje na fyzické rozhraní místo tun0 nebo wg0, overlay zapouzdří na adresu, na kterou vzdálená lokalita nedosáhne, a příznak bude vypadat jako ztráta paketů.

Zkontrolujte, jakou adresu každý uzel inzeruje

Démon inzeruje jednu adresu a protějšky ji používají pro datovou rovinu. Na hostiteli s více sítěmi je snadné inzerovat LAN nebo veřejnou adresu, zatímco tunel nese něco jiného. Prohlédněte si ji, místo abyste předpokládali, a při připojení ji zafixujte pomocí --advertise-addr, když je výchozí špatná. Uzel, který inzeruje adresu dostupnou jen jemu, se do swarmu stejně připojí a selhání se projeví později jako služby, které spolu přes lokality nemohou mluvit.

Změna inzerované adresy později není úprava konfigurace, protože uzel musí odejít a znovu se připojit.

Zapište si inzerovanou adresu každého uzlu do poznámek, protože vysvětluje většinu asymetrických selhání.

Masquerade je obvyklý viník

Když mezi uzly a tunelem stojí brána, častou chybou je dělat masquerade na všem, co vychází z fyzického rozhraní. To přepisuje i vnitřní adresy overlaye, takže každý protějšek vypadá, že přichází z brány, a protějšky VXLAN se přestanou navzájem poznávat. Výsledkem je chybějící nebo jednosměrný zapouzdřený provoz, zatímco obyčejné pingy stále fungují.

Směrujte prefix overlaye přes bránu a nechte ho nepřeložený. Pokud je překlad opravdu potřeba pro jiný prefix, omezit ho tam a nikdy na rozsah, který overlay používá.

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

Zkontrolujte pořadí pravidel i jejich text, protože široké MASQUERADE dříve v řetězci vyhrává nad úzkou výjimkou později.

VXLAN potřebuje v paketu místo

VXLAN přidává k přenášeným rámcům 50 bajtů. Spodní vrstva 1500 bajtů, která nese vnitřní rámec 1500 bajtů, vytvoří zapouzdřený paket, který žádná cesta nedoručí, a selhání vypadá jako občasné objevování služeb, ne jako problém velikosti. Buď snižte MTU tunelu na obou koncích, nebo nastavte MTU overlaye tak, aby ovladač inzeroval užitečné zatížení, které se vejde.

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

Síť ingress se vytváří automaticky, takže její změna znamená odebrání a nové vytvoření, ne úpravu na místě.

Pokud opravíte jen jednu stranu tunelu, menší MTU pořád zůstává tím, na kterém záleží.

Sledujte datovou rovinu, ne protokoly

Zachyťte port VXLAN na obou koncích. Rámce, které opouštějí jednu stranu a dorazí na druhou, znamenají, že spodní vrstva je v pořádku a problém je uvnitř overlaye. Rámce, které odcházejí a nikdy nedorazí, znamenají trasu nebo filtr. Rámce, které neodejdou vůbec, znamenají špatnou zdrojovou adresu.

Selhání objevování služeb, která po pár sekundách zmizí, obvykle ukazují na paketový rozpočet nebo nestabilní cestu, ne na raft kvorum.

Uchovejte zachycení z fungujícího okna, protože srovnání s rozbitým je rychlejší než znovu číst konfiguraci.