מדוע Weave Net ב-Kubernetes מאבד חבילות בעת התרחבות
בעשרה עד חמישה-עשר צמתים האשכול מתנהג באופן צפוי, אך לאחר המעבר מעבר לכמה עשרות מתחילים שירותים "להבהב". חלק מפגישות ה-TCP נקטעות באמצע, חלק מה-SYN אינם מגיעים אל הפוד, קריאות בין-שירותיות נופלות בזמן קצוב — ובמקביל מדדי הצמתים נקיים, והפודים עצמם חיים. אובדן חבילות באשכול נראה כרעש אקראי: אינו משוחזר בכל זוג צמתים ולא בכל פעם.
הסיבה מורכבת בדרך כלל משלושה רבדים. הראשון — אנקפסולציה: ה-overlay עוטף את התעבורה בכותרת משלו, ה-MTU האפקטיבי של הממשק יורד, וחבילות גדולות עם איסור פיצול אובדות בשקט על המנהרה.
השני — חילופי טופולוגיה: עם גידול מספר הצמתים הסוכנים מתכנסים זמן רב יותר לתמונה עקבית של מסלולים, ובחלון ההתכנסות חלק מהנתיבים מובילים לשום מקום. השלישי — NetworkPolicy עם סלקטור שגוי: התעבורה נזרקת בלי אף רשומה ביומני האפליקציה.
תקלות קישוריות של ה-overlay לא נעימות מפני שאבחון רשת האשכול נתקל בהיעדר תרשים. המהנדס רואה חבילות קטועות על צומת אחד, אך אינו מבין היכן בדיוק אובד הנתיב: ביציאה מהפוד, במנהרה בין הצמתים או כבר במקבל.
אין מפת תת-רשתות, מיעון של פודים ושירותים, אין רשימה של טווחים חופפים — והחקירה הופכת לסבב השערות ישירות על אשכול חי.
לכן אנו מתחילים לא מתיקון הקונפיגורציה, אלא משחזור תמונת הרשת — ומפרקים כיצד זה נסגר.
מה נותנת רשת ה-overlay של האשכול: אפקט מדיד
רשת ה-overlay של האשכול קובעת שני פרמטרים מדידים: זמן התאוששות הצומת וחלק הבקשות שאבדו בעת בנייה מחדש של מסלולים. כל עוד הרשת מורכבת מהגדרות מפוזרות, כל נוד חדש או מעבר פוד נותן זינוק בשגיאות — ההפסדים נספרים באחוזים, ולא בעשיריות.
אנו פורסים את Weave Net כשכבת רשת אחודה: מיעון, ניתוב בין צמתים וכללי גישה חיים בקונפיגורציה אחת, ולא בשלושה מקומות שונים. את המדידות אנו לוקחים על קווי מתאר לבדיקה לפני ואחרי ההטמעה — ועליהן בונים את המסקנות.
הצפנת תעבורה בין צמתים בלי אובדן מהירות
הצפנת תעבורה בין צמתים מופעלת ברמת הרשת: האפליקציה אינה יודעת עליה ואינה דורשת התאמות. לפני ההפעלה אנו מריצים תרחיש עומס ומשווים תפוקה — בהגדרות תקינות הירידה נשארת בגבולות טעות המדידה, והתעבורה בין הנודים אינה עוברת יותר בטקסט גלוי.
התאוששות צפויה לאחר כשל צומת
נפילת צומת מפסיקה להיות אירוע בעל תוצאה לא ודאית: המסלולים נבנים מחדש בתוך שניות, הפודים עוברים לצמתים חיים, וחלק הבקשות שאבדו נשאר בעשיריות האחוז. בד בבד נעלם סוג שלם של כשלים — כאשר לאחר הפעלה מחדש חלק מהתעבורה הולך לשום מקום והשירות פורמלית עולה, אך מגיב בשגיאות.
אנו בודקים זאת לא במילים: מכבים נוד תחת עומס, בוחנים את זמן ההתאוששות ואת ההפסדים, ובנפרד מוודאים שכללי הגישה אינם מכניסים תעבורה מיותרת. אם המספרים חורגים מהמצופה — מתקנים את ההגדרות, ולא את הדוח.
מצבי פעולה של רשת ה-overlay: השוואת אפשרויות
בחירת המצב קובעת כיצד החבילות עוברות בין הצמתים וכמה משאבים נדרשים לכל צומת חדש. overlay מעל רשת הצמתים עוטף את התעבורה, המצב הישיר מוסר את הניתוב לליבה, וההיברידי משלב את שניהם. להלן השוואה לפי שני צירים: מתי האפשרות מתאימה ובמה היא מגבילה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| overlay מעל רשת הצמתים | אשכול בענן או בכמה תת-רשתות, שבהן נתיב ישיר בין הצמתים אינו זמין | האנקפסולציה גוזלת חלק מרוחב הפס, הגודל המרבי של החבילה נמוך יותר — חבילות גדולות מפוצלות |
| מצב ניתוב ישיר | דומיין קישוריות אחד או רשת מנוהלת, שבה הצמתים רואים זה את זה ישירות | תלוי במדיניות הרשת: החלפת תת-רשת או מסננים שוברים מסלולים בין הצמתים |
| היברידי | תשתית מעורבת: חלק מהצמתים בענן, חלק על חומרה שלכם | הקונפיגורציה מורכבת יותר, ויש לסמן תקלות בנפרד לפי כל תת-רשת |
מתי ה-overlay מוצדק
את ה-overlay מפעילים כאשר הצמתים חיים בתת-רשתות שונות והרשת אינה מאפשרת הכרזת מסלולים ביניהם. Weave Net במצב זה סוגר את הקישוריות ואת הצפנת התעבורה, והמדיניות הרשתיות מתוארות באופן זהה לכל אפשרות — החלפת המצב אינה מחייבת לכתוב מחדש את הכללים.
מגבלות בעומס אמיתי
במשימות זרימה האנקפסולציה מורגשת בזמן התגובה, ולכן את מסד הנתונים ואת אפיק האירועים מוציאים לרוב למצב ישיר. אך שגיאה במסלולים שם מביאה לכך שחלק מהצמתים מפסיקים לראות זה את זה. לכן את שני הפרופילים אנו מריצים על קווי מתאר לבדיקה עם אופי תעבורה ייצורי לפני המעבר.
סדר הפריסה: מאבחון הרשת ועד למסירה
הפריסה מתחילה לא בהתקנה, אלא באבחון רשת האשכול: אילו טווחי כתובות תפוסים, כיצד בנוי הניתוב בין הצמתים, היכן עוברים גבולות האמון. שגיאה כאן צפה מאוחר יותר — חלק מהפודים אינו רואה שירותים, והאבחון נמתח לימים. לכן ששת השלבים נעים בסדר קפדני, וכל אחד מסתיים בתוצאה ניתנת לבדיקה.
מה בודקים בכניסה
אוספים מפת אשכול: טווחים תפוסים ופנויים, חפיפות עם רשתות המשרד ואתרי הענן, כללי הגישה הפעילים בין השירותים. מתעדים אילו מרחבי שמות נשארים מבודדים ולמי יש הרשאות לשנות את קונפיגורציית הרשת.
- אבחון רשת האשכול — מלאי של צמתים, טווחים ומסלולים, איתור חפיפות עם התשתית הקיימת.
- תרשים מיעון — מאגר כתובות לפודים ולשירותי מערכת, תוכנית לפי מרחבי שמות.
- התקנה והגדרת הצפנה — פריסת Weave Net באשכול, הפעלת הצפנת תעבורה בין הצמתים, סדר החלפת מפתחות.
- מדיניות גישה — קישורים מותרים בין שירותים ודחייה כברירת מחדל למרחבי שמות רגישים.
- בדיקת קישוריות תחת עומס — בדיקות בין צמתים ואתרים, התנהגות בנפילת צומת, מדידת השהיות.
- הדרכת הצוות ומסירה — סקירת קונפיגורציות, תרשים ותרחישי אבחון.
קריטריונים למוכנות למסירה
המסירה אפשרית כאשר התעבורה בין הצמתים מוצפנת, המדיניות מיושמת על כל השירותים הנדרשים, והתאוששות הצומת נבדקה בפועל. בידי הצוות נשארים תרשים המיעון, הנחיות לתקלות אופייניות וסדר השינויים.
ערכת מסירה: קונפיגורציות, תרשים, נהלים
אשכול עובד ואשכול שניתן למסור לתחזוקה — אינם אותו דבר. לכן המסירה אינה הדגמה של קונטיינרים פועלים, אלא ערכת תיעוד שלפיה הצוות שלכם יפרס את המערך מאפס, ירחיב את הרשת ויטפל בתקלה בלעדינו.
מה נכלל בערכה
- קונפיגורציות רשת: מניפסטים של התקנה, פרמטרים של ה-overlay וערכים המוצאים לקבצים נפרדים — פריסת המערך חוזרת אחד לאחד.
- מפת מיעון: טווחים של פודים ושירותים, כתובות צמתים, תת-רשתות תפוסות — בעת הרחבת האשכול איננו מתנגשים ברשת הארגונית.
- מדיניות גישה: אילו מרחבי שמות ושירותים נגישים למי, באילו פורטים, איזו תעבורה מוצפנת בין הצמתים.
- תרשים מעבר התעבורה: נתיב החבילה מפוד לפוד, נקודות ההצפנה והצמתים שבהם נלקח האבחון.
- נהלי תחזוקה: עדכוני צמתים מתוכננים, סדר הוצאת צומת לטיפול מונע, החלפת מפתחות הצפנה.
- סדר פעולות בעת תקלה: תרחישים לניתוק קשר בין צמתים, לירידת ביצועי ה-overlay ולאובדן צומת — עם פקודות בדיקה בכל שלב.
- רשימת תיוג לקבלה: מערכת בדיקות לפני כל מהדורה, כדי ששינוי קונפיגורציה לא ישבור את הקישוריות.
נהלים לאירועים אופייניים
בנפרד מתעדים מי עושה מה בעת תקלה: היכן בוחנים מדדים, כיצד מבודדים צומת בעייתי, ובאיזה רגע מחזירים את הקונפיגורציה לגרסה קודמת. נהלי התחזוקה סוגרים עבודות מתוכננות, וסדר הפעולות בעת תקלה — את הלא-מתוכננות, ולכן המהנדס התורן אינו מחפש פתרון מאפס.
מקרה בוחן: רשת אשכול תחת עומס לפני ואחרי
מצב התחלתי ומגבלות
אשכול של כמה עשרות צמתים נבנה בהדרגה, והרשת לא הספיקה מאחוריו: חלק מהתעבורה עבר ישירות דרך L2, וחלק — דרך שכבת overlay בהרכבה עצמית. ההצפנה בין הצמתים הייתה כבויה, הפרדת הגישה נשענה על תת-רשתות וכללי חומת אש ידניים, ואי-סנכרון MTU בממשקים שונים גרם לאובדן חבילות.
בשעות שיא הקישוריות ירדה: שירותים התחברו מחדש, חלק מהבקשות הסתיימו בזמן קצוב, והתורן לא יכול היה להפריד במהירות בין בעיית רשת לבעיה יישומית.
התוצאה במדדים לפני ואחרי
פרסנו Weave Net עם הצפנת תעבורה בין הצמתים, יישרנו MTU בכל הממשקים והעברנו את הפילוח למדיניות גישה הצהרתית. בנוסף הוצאנו מדדי קישוריות, כדי שהירידה בביצועים תהיה נראית לפני שהמשתמשים יבחינו בה.
| מדד | לפני | אחרי |
|---|---|---|
| אובדן חבילות בין צמתים בשעות שיא | 8-12% | 0.1% |
| טיפול באירוע קישוריות | כ-5 שעות | כ-35 דקות |
| אירועים בלי סיבה ברורה | 40% | 5% |
| הכנסת צומת חדש לרשת | 40 דקות ידנית | 3 דקות אוטומטית |
הקישוריות הפסיקה להיות מקור לתקלות אקראיות, ונוהל הטיפול הצטמצם לשלושה שלבים: מדדי ה-overlay, מצב הערוצים בין הצמתים, הפעלת המדיניות. התורנים הפסיקו להסלים שאלות רשת באקראי, והעומס על צוות התחזוקה התאזן באותו היקף תעבורה.
מה לעשות אם ב-Kubernetes כבר פועל מודול רשת אחר
אפשר לעבור, אך "ישר" — להסיר מודול אחד ולהתקין אחר — לא יצליח. בזמן החלפת מודול הרשת הפודים מאבדים כתובות, ויחד עם האובייקטים של המודול הישן נעלמות גם המדיניות הרשתיות. לכן המעבר מתבצע בשלבים: לצד הקיים מרימים מודול חדש, מעבירים את הכללים, ורק אז מסירים את הישן.
הצעד הראשון הוא מלאי של מה שבאמת פועל באשכול. בוחנים אילו מדיניות רשתיות מיושמות (חלק מהאובייקטים מתבררים בדרך כלל כטיוטות), האם יש פודים עם הצמדה ישירה לרשת הצומת, והאם טווחי הכתובות של המודול הישן והחדש חופפים.
חפיפת תת-רשתות ואי-התאמה במצב הניתוב — הסיבה הנפוצה ביותר לכך שהחלפת מודול רשת דורשת תיקון ידני, ולא החלפה פשוטה.
תאימות מודולי הרשת נבדקת לפני המעבר, ולא במהלכו. את המודול החדש מעמידים במצב שבו הוא רואה צמתים וקורא את מצב האשכול, אך אינו מחלק כתובות — הניתוב נשאר כשהיה. שגיאה בשלב זה עולה צומת אחד, ולא את כל האשכול.
את המדיניות הרשתיות מעבירים בנפרד: הסלקטורים והכללים שונים בין המודולים, ומדיניות שחסמה קודם תעבורה עשויה להתפרש אחרת במודול החדש. כל כלל נבדק בסביבת בדיקה, ורק כאשר השירותים מגיבים — האובייקטים הישנים נמחקים.
מעבר בלי זמן השבתה מתבצע צומת-צומת: מוציאים את הצומת מהתחזוקה, מחליפים, בודקים קישוריות ומחזירים לאשכול. דרוש עודף קיבולת — האשכול צריך לשרוד אובדן של צומת אחד. את הקונפיגורציה של המודול הישן מחזיקים קפואה כתוכנית נסיגה, ומסירים אותה רק לאחר כל הבדיקות.
ספקות טכניים נפוצים לגבי רשת ה-overlay
ספקות לגבי רשת ה-overlay Weave Net באשכול צפים בדרך כלל לא בהתקנה, אלא בתפעול: כיצד היא מתנהגת תחת עומס, מה יקרה בעת אובדן צומת, במה תסתיים הפעלת הצפנה. להלן מה שהמהנדסים שלנו בודקים על המערך לפני הוצאת האשכול לתפעול ייצורי.
בכמה האנקפסולציה מוסיפה השהיה בין שירותים?
האנקפסולציה מוסיפה כותרת לכל חבילה, וחלק מהנתיב עובר מחוץ למחסנית הליבה הרגילה, ולכן ההשהיה גדלה. בעומסים אינטרנטיים אופייניים מדובר בשברי מילישנייה, אך בחילופי בקשות קטנות בתדירות גבוהה ההבדל הופך מורגש.
אנו מודדים את ההשהיה לפני ואחרי הפעלת ה-overlay ומשאירים נתיבים ישירים במקומות שבהם הצמתים נמצאים באותה תת-רשת.
כיצד מופעלת ההצפנה ומה היא משנה?
ההצפנה מופעלת ברמת ה-overlay ומכסה את כל התעבורה בין הצמתים, כולל תעבורת מערכת. המחיר — עומס נוסף על המעבד וירידה בתפוקה בזרמים גדולים. לכן מפעילים באופן סלקטיבי: עבור סביבות שבהן התעבורה עוברת בסגמנטים לא מהימנים, ותמיד עם נטילת מדידות לפני ואחרי.
מה קורה בעת כשל של צומת?
הצמתים שנותרו בונים מחדש מסלולים לתת-הרשתות האבודות, והבקרים יוצרים מחדש פודים על מכונות חיות. זמן ההתאוששות מורכב מזמני הבדיקות ומזמן עליית הקונטיינרים — אנו מודדים אותו ומקבעים אותו כיעד, כדי שהירידה בביצועים תהיה צפויה ולא אקראית.
האם אפשר להחליף מיעון של תת-רשתות באשכול חי?
את טווח הכתובות מחליפים בשלבים: תחילה מרימים מאגר חדש, אחר כך מעבירים אליו צמתים אחד אחד, ובודקים קישוריות לאחר כל שלב. החלפה מלאה של המיעון עם יצירת האשכול מחדש פשוטה יותר וצפויה יותר — הבחירה תלויה בכמה שירותים קשורים לכתובות הישנות.
כיצד לאבחן בעיות רשת?
הולכים מהפשוט למורכב: קישוריות בין פודים על צמתים שונים, מצב סוכן הרשת בכל מכונה, מוני חבילות שנזרקו, ואז כללי הגישה בין מרחבי השמות. כך בעיית ה-overlay מופרדת משגיאות בקונפיגורציית השירותים ובמדיניות.
נדון במשימה: נתאים מצב ונחזור עם תוכנית
כדי שההערכה תהיה עניינית ולא "לפי תמונה", בשיחה הראשונה מספיקים נתוני פתיחה על האשכול: כמה צמתים ובאילו תת-רשתות, איזו שכבת רשת פועלת כעת, האם יש מגבלות על זמן השבתה ומי אחראי על המסלולים בין הסגמנטים. הרשאות "ליתר ביטחון" אינן נדרשות — די בתיאור ובמניפסטים הקיימים.
בעקבות השיחה נחזור עם הערכה ותוכנית עבודה:
- תרשים פריסה: כיצד Weave Net Kubernetes ישב על המיעון הקיים ולא יחפוף לטווחי השירותים;
- התאמת מצב הרשת — overlay מעל הניתוב או מצב ישיר, והיכן נדרש ערוץ מוצפן בין הצמתים;
- תוכנית מעבר שלב-שלב עם נקודות נסיגה לשכבת הרשת הקודמת;
- רשימת מדיניויות בידוד תעבורה בין מרחבי שמות: מה כבר מכוסה, ומה עוד צריך לתאר;
- הערכה לפי לוחות זמנים והרכב העבודה בחלוקה לשלבים;
- רשימת מה שנדרש מצדכם: הרשאות, חלון תיאום, איש קשר של התורן.
תחזוקת האשכול — קו נפרד: עדכון שכבת הרשת, בקרת קישוריות הצמתים, תגובה לירידה בביצועים ומסירת התיעוד לצוות שלכם, כדי שהקונפיגורציה לא תישאר "קופסה שחורה".
תארו את המשימה ושלחו את נתוני הפתיחה — נחזור עם הערכה, תוכנית עבודה והרכב השלבים.