Docker Swarm преко VPN-а: задаци раде, позиви сервиса не успевају

Три менаџера и пет радника на два локалитета, повезаних тунелом, и docker service ls показује задатке који раде са обе стране, док позиви између сервиса истичу. Ништа у Swarm записима не изгледа погрешно. Та комбинација је потпис проблема у равни података: контролна раван је пронашла чворове, а инкапсулирани оквири никада нису прешли пут.

Мрежа мора постојати пре overlay-а

Swarm overlay гура инкапсулиране оквире директно између адреса чворова, што значи да сваком чвору треба адреса до које сваки други чвор може доћи без превода, на интерфејсу који тунел пружа. Тунел који преноси само клијенте до објављеног порта није довољан. Доњи слој мора да рутира од чвора до чвора у оба смера.

Тестирајте то пре него што дирнете Swarm. Са сваког чвора проверите руту до тунелске адресе партнера, пинг-ујте је, а затим тестирајте контролни порт. Ако пинг ради а порт не, тунел је у реду и неки филтер стоји на путу.

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 је уобичајени кривац

Када gateway стоји између чворова и тунела, честа грешка је применити masquerade на све што излази са физичког интерфејса. То преписује и унутрашње адресе overlay-а, па сваки партнер изгледа као да долази са gateway-а и VXLAN партнери престају да препознају једни друге. Резултат је изгубљен или једносмеран инкапсулирани саобраћај док обични пинг-ови још раде.

Рутирајте префикс overlay-а кроз gateway и оставите га непреведеног. Ако је превод заиста потребан за други префикс, ограничите га тамо и никада на распон који 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 кворум.

Сачувајте снимак из радног периода, јер је поређење са поквареним брже од поновног читања конфигурације.