Docker Swarm על גבי VPN: המשימות רצות, קריאות השירות נכשלות

שלושה מנהלים וחמישה עובדים בשני אתרים, מחוברים במנהרה, ו-docker service ls מציג משימות שרצות בשני הצדדים בעוד הקריאות בין השירותים נגמרות בזמן. שום דבר ביומני Swarm לא נראה שגוי. הצירוף הזה הוא החתימה של בעיה במישור הנתונים: מישור הבקרה מצא את הצמתים, והמסגרות העטופות מעולם לא עשו את הדרך.

הרשת חייבת להתקיים לפני ה-overlay

ה-overlay של Swarm דוחף מסגרות עטופות ישירות בין כתובות הצמתים, כלומר כל צומת זקוק לכתובת שכל צומת אחר יכול להגיע אליה בלי תרגום, בממשק שהמנהרה מספקת. מנהרה שמעבירה רק לקוחות לפורט מפורסם אינה מספיקה. השכבה התחתונה חייבת לנתב מצומת לצומת בשני הכיוונים.

בדקו זאת לפני שנוגעים ב-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 הוא החשוד הרגיל

כששער נמצא בין הצמתים למנהרה, הטעות הנפוצה היא לעשות masquerade לכל מה שיוצא מהממשק הפיזי. זה משכתב גם את הכתובות הפנימיות של ה-overlay, כך שכל עמית נראה כאילו הגיע מהשער ועמיתי VXLAN מפסיקים לזהות זה את זה. התוצאה היא תעבורה עטופה חסרה או חד-כיוונית בזמן שפינגים רגילים עדיין עובדים.

נתבו את קידומת ה-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.

שמרו את הלכידה מחלון שעובד, כי השוואה שלה לזו השבורה מהירה יותר מקריאה חוזרת של התצורה.