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.

Збережіть захоплення з робочого вікна, бо порівняти його зі зламаним швидше, ніж перечитувати конфігурацію.

Схожі статті