Docker Swarm روی VPN: وظیفه‌ها اجرا می‌شوند، فراخوانی سرویس‌ها شکست می‌خورد

سه مدیر و پنج کارگر در دو سایت، متصل با یک تونل، و docker service ls وظیفه‌هایی را نشان می‌دهد که در هر دو طرف اجرا می‌شوند، در حالی که فراخوانی‌های بین سرویس‌ها به پایان مهلت می‌رسند. هیچ چیز در گزارش‌های Swarm اشتباه به نظر نمی‌رسد. این ترکیب نشانهٔ مشکلی در لایهٔ داده است: لایهٔ کنترل گره‌ها را پیدا کرد، و قاب‌های کپسوله‌شده هرگز سفر نکردند.

مش باید پیش از overlay وجود داشته باشد

overlay در Swarm قاب‌های کپسوله‌شده را مستقیماً بین نشانی‌های گره هل می‌دهد، یعنی هر گره به نشانی‌ای نیاز دارد که هر گرهٔ دیگر بدون ترجمه به آن برسد، روی واسطی که تونل فراهم می‌کند. تونلی که فقط کارخواه‌ها را به یک درگاه منتشرشده می‌برد کافی نیست. لایهٔ زیرین باید در هر دو جهت از گره به گره مسیریابی کند.

پیش از دست زدن به Swarm این را آزمایش کنید. از هر گره، مسیر تا نشانی تونل یک همتا را بررسی کنید، به آن ping بزنید و سپس درگاه کنترل را آزمایش کنید. اگر 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.

ضبط را از پنجرهٔ سالم نگه دارید، چون مقایسهٔ آن با نسخهٔ خراب سریع‌تر از بازخوانی پیکربندی است.