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.

احتفظ بالالتقاط من نافذة عمل، لأن مقارنته بالتقاط معطوب أسرع من إعادة قراءة الإعدادات.