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.

Захавайце захоп з працоўнага акна, бо параўнаць яго са зламаным хутчэй, чым перачытваць канфігурацыю.

Падобныя артыкулы