Docker Swarm caur VPN: uzdevumi darbojas, pakalpojumu izsaukumi neizdodas

Trīs pārvaldnieki un pieci darbinieki divās vietnēs, savienoti ar tuneli, un docker service ls rāda abās pusēs darbojošos uzdevumus, kamēr izsaukumi starp pakalpojumiem beidzas ar taimautu. Swarm žurnālos nekas neizskatās nepareizi. Šī kombinācija ir datu plaknes problēmas pazīme: vadības plakne atrada mezglus, un iekapsulētie kadri nekad netika veikuši ceļu.

Tīklam jābūt pirms overlay

Swarm overlay grūž iekapsulētos kadrus tieši starp mezglu adresēm, kas nozīmē, ka katram mezglam vajadzīga adrese, ko katrs cits mezgls var sasniegt bez tulkošanas, saskarnē, ko nodrošina tunelis. Tunelis, kas pārvadā tikai klientus uz publicētu portu, nav pietiekams. Apakšējam slānim jāmaršrutē no mezgla uz mezglu abos virzienos.

Pārbaudiet to pirms Swarm aiztikšanas. No katra mezgla pārbaudiet maršrutu uz partnera tuneļa adresi, pingojiet to un pēc tam pārbaudiet vadības portu. Ja ping darbojas un ports ne, tunelis ir kārtībā un ceļā ir filtrs.

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

Ja maršruts norāda uz fizisko saskarni, nevis tun0 vai wg0, overlay iekapsulēs uz adresi, ko tālā vietne nevar sasniegt, un simptoms izskatīsies kā pakešu zudums.

Pārbaudiet, kādu adresi katrs mezgls reklamē

Dēmons reklamē vienu adresi, un partneri to izmanto datu plaknei. Uz resursdatora ar vairākiem tīkliem ir viegli reklamēt LAN vai publisko adresi, kamēr tunelis pārvadā kaut ko citu. Pārbaudiet to, nevis pieņemiet, un pieslēgšanās laikā nofiksējiet to ar --advertise-addr, ja noklusējums ir nepareizs. Mezgls, kas reklamē adresi, ko var sasniegt tikai viņš pats, tomēr pievienojas swarm, un kļūme vēlāk izpaužas kā pakalpojumi, kas nevar sazināties starp vietnēm.

Reklamētās adreses maiņa vēlāk nav konfigurācijas labošana, jo mezglam jāiziet un jāpievienojas no jauna.

Pierakstiet reklamēto adresi katram mezglam savos pierakstos, jo tā izskaidro lielāko daļu asimetrisko kļūmju.

Masquerade ir ierastais vaininieks

Kad starp mezgliem un tuneli atrodas vārteja, biežā kļūda ir piemērot masquerade visam, kas iziet no fiziskās saskarnes. Tas pārraksta arī overlay iekšējās adreses, tāpēc katrs partneris izskatās nākam no vārtejas un VXLAN partneri pārstāj atpazīt viens otru. Rezultāts ir pazudis vai vienvirziena iekapsulētais trafiks, kamēr vienkārši ping joprojām darbojas.

Maršrutējiet overlay prefiksu caur vārteju un atstājiet to neiztulkotu. Ja tulkošana patiešām nepieciešama citam prefiksam, ierobežojiet to tur un nekad nepiemērojiet overlay izmantotajam diapazonam.

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

Pārbaudiet noteikumu secību un arī tekstu, jo plašs MASQUERADE agrāk ķēdē pārspēj šauru izņēmumu vēlāk.

VXLAN vajag vietu paketē

VXLAN pievieno 50 baitus pārvadātajiem kadriem. 1500 baitu apakšējais slānis, kas pārvadā 1500 baitu iekšējo kadru, rada iekapsulētu paketi, ko neviens ceļš nepiegādās, un kļūme izskatās kā pārtraukta pakalpojumu atklāšana, nevis izmēra problēma. Vai nu samaziniet tuneļa MTU abos galos, vai iestatiet overlay MTU tā, lai draiveris reklamētu ietilpīgu lietderīgo slodzi.

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

Ingress tīkls tiek izveidots automātiski, tāpēc tā maiņa nozīmē noņemšanu un atkārtotu izveidi, nevis rediģēšanu uz vietas.

Ja salabojat tikai vienu tuneļa pusi, mazākais MTU joprojām ir tas, kam ir nozīme.

Vērojiet datu plakni, nevis žurnālus

Tveriet VXLAN portu abos galos. Kadri, kas iziet no vienas puses un nonāk otrā, nozīmē, ka apakšējais slānis ir kārtībā un problēma ir overlay iekšienē. Kadri, kas iziet un nekad nenonāk, nozīmē maršrutu vai filtru. Kadri, kas vispār neiziet, nozīmē, ka avota adrese ir nepareiza.

Pakalpojumu atklāšanas kļūmes, kas pāriet pēc dažām sekundēm, parasti norāda uz pakešu budžetu vai nestabilu ceļu, nevis uz raft kvorumu.

Saglabājiet ierakstu no strādājoša perioda, jo salīdzināt to ar bojāto ir ātrāk nekā pārlasīt konfigurāciju.