Docker Swarm през VPN: задачите вървят, извикванията към услуги се провалят

Задачите работят на двата сайта, а извикванията между услугите изтичат. Overlay слоят се нуждае от маршрути възел-възел, непреведени адреси и място за 50 байта VXLAN.

Три мениджъра и пет работника в два сайта, свързани с тунел, и docker service ls показва задачи, работещи от двете страни, докато извикванията между услугите изтичат. В логовете на Swarm нищо не изглежда грешно. Тази комбинация е подписът на проблем в плоскостта на данните: контролната плоскост намери възлите, а инкапсулираните кадри така и не изминаха пътя.

Мрежата трябва да съществува преди overlay слоя

Overlay слоят на Swarm изпраща инкапсулирани кадри директно между адресите на възлите, което означава, че всеки възел се нуждае от адрес, до който всеки друг възел може да стигне без транслация, на интерфейса, който тунелът предоставя. Тунел, който пренася само клиенти до публикуван порт, не е достатъчен. Долният слой трябва да маршрутизира възел към възел в двете посоки.

Проверете това, преди да пипате Swarm. От всеки възел проверете маршрута до тунелния адрес на партньор, пингнете го и след това тествайте контролния порт. Ако ping работи, а портът не, тунелът е наред и някой филтър пречи.

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

Ако маршрутът сочи към физическия интерфейс вместо tun0 или wg0, overlay слоят ще инкапсулира към адрес, който отдалеченият сайт не може да достигне, и симптомът ще изглежда като загуба на пакети.

Проверете какъв адрес обявява всеки възел

Демонът обявява един адрес и партньорите го използват за плоскостта на данните. На хост с няколко мрежи е лесно да обявите LAN или публичния адрес, докато тунелът носи нещо друго. Инспектирайте го, вместо да предполагате, и го фиксирайте при присъединяване с --advertise-addr, когато подразбиращото се е грешно. Възел, който обявява адрес, достъпен само за него, все пак се присъединява към swarm и отказът се появява по-късно като услуги, които не могат да говорят между сайтовете.

Промяната на обявения адрес по-късно не е редакция на конфигурацията, защото възелът трябва да излезе и да се присъедини отново.

Записвайте обявения адрес за всеки възел в бележките си, защото това обяснява повечето асиметрични откази.

Masquerade е обичайният виновник

Когато шлюз стои между възлите и тунела, честата грешка е да се прави masquerade на всичко, излизащо от физическия интерфейс. Това пренаписва и вътрешните адреси на overlay слоя, така че всеки партньор изглежда идващ от шлюза и VXLAN партньорите спират да се разпознават. Резултатът е липсващ или еднопосочен инкапсулиран трафик, докато обикновените ping още работят.

Маршрутизирайте префикса на overlay слоя през шлюза и го оставете без транслация. Ако транслация наистина е нужна за друг префикс, ограничете я там и никога до диапазона, който overlay слоят използва.

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

Проверете реда на правилата, както и текста им, защото широко MASQUERADE по-рано във веригата надделява над тясно изключение по-късно.

VXLAN се нуждае от място в пакета

VXLAN добавя 50 байта към кадрите, които носи. Долен слой от 1500 байта, носещ вътрешен кадър от 1500 байта, създава инкапсулиран пакет, който никой път няма да достави, и отказът изглежда като периодично откриване на услуги, а не като проблем с размера. Или намалете MTU на тунела в двата края, или задайте MTU на overlay слоя, така че драйверът да обявява полезен товар, който се побира.

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

Мрежата ingress се създава автоматично, така че промяната ѝ означава премахване и повторно създаване, а не редактиране на място.

Ако поправите само едната страна на тунела, по-малкото MTU пак остава това, което има значение.

Наблюдавайте плоскостта на данните, не логовете

Уловете VXLAN порта в двата края. Кадри, напускащи едната страна и пристигащи в другата, означават, че долният слой е наред и проблемът е в overlay слоя. Кадри, напускащи и никога не пристигащи, означават маршрут или филтър. Кадри, които изобщо не напускат, означават, че адресът на източника е грешен.

Откази в откриването на услуги, които изчезват след няколко секунди, обикновено сочат към пакетния бюджет или нестабилен път, а не към raft кворум.

Пазете улова от работещ прозорец, защото сравняването му със счупения е по-бързо от препрочитане на конфигурацията.

Подобни статии