ריבוי רשתות Kubernetes: היכן נשברת הקישוריות בין הפודים
ריבוי רשתות Kubernetes נדרש במקום שבו פוד צריך להתקיים בו-זמנית בשתי מישורים: תעבורת שירות דרך ה-overlay, ונתונים — דרך ממשק נפרד לאחסון, ל-broker או לסגמנט ייעודי. כל עוד הממשק אחד, הכול עובד; ברגע שמופיע ממשק שני, נשבר מה שעד כה לא עורר שאלות.
הכשל הטיפוסי הראשון — ניתוב. הממשק השני עולה, מקבל כתובת, אבל טבלת הניתוב נשארת אחת: התעבורה אל תת-הרשת הנדרשת יוצאת אל שער ברירת המחדל של ה-overlay ואינה מגיעה. הפוד רואה את הממשק, ping לפי שם אינו עובר, האפליקציה נופלת עקב timeout של חיבור.
הכשל השני — קישוריות בין הפודים זה לזה: פודים על צמתים שונים מקבלים כתובות מטווחים שאינם חופפים, ובלי ניתוב מתואם בין הצמתים חלק מהזוגות "מקור-יעד" פשוט אינם רואים זה את זה.
הכשל השלישי — סדר האתחול. אם הממשק הנוסף מתחבר לאחר עליית האפליקציה, השירות מספיק לתפוס פורט על הממשק הראשי ומאזין לכתובת הלא נכונה.
הרביעי — חפיפה של טווחי כתובות בין המישורים: שני ממשקים באותו פוד מקבלים כתובות מאותה תת-רשת, וה-kernel בוחר את המסלול לפי ההתאמה הראשונה, ולא לפי זה שנדרש.
קטגוריה נפרדת — מדיניות רשת. כללים שנכתבו עבור רשת אחת אינם חלים על השנייה: התעבורה עוברת בעקיפין למגבלות, וזה מתברר כבר בשלב בדיקת הגישה, ולא בעת ניפוי קישוריות.
מפרקים כיצד זה נסגר: כיצד להפריד מישורי מיעון, לקבע מסלולים עבור כל ממשק ולבדוק קישוריות לפני שתעבורה תפעולית תיכנס ל-cluster.
מה נותנת ריבוי-רשתות: אפקט מדיד
כאשר ממשק פיזי אחד נושא גם תעבורת ניהול שוטפת, גם חילופי נתונים בין יישומים וגם פניות לשירותים חיצוניים, כל פרץ עומס פוגע בכולם בבת אחת. המתזמן ובקרי האשכול מתחילים לאבד חבילות heartbeat, צמתים עוברים לסטטוס NotReady, ובקשות יישום מקבלות השהיות שלא היו קיימות בשגרה.
ריבוי-רשתות Kubernetes מפריד את הזרמים הללו לממשקים נפרדים: תעבורת ניהול, תעבורת יישום ותעבורת שירות עוברות באופן בלתי תלוי, ועומס יתר באחד אינו פוגע באחרים.
הפרדת התעבורה מספקת בידוד רשתות ישיר: פודי יישום מתקשרים דרך הממשק שלהם, פודי שירות דרך שלהם, ותקלה או סערה במקטע אחד אינה זולגת לאחר.
זה גם מסיר התנגשויות מיעון, כאשר מחלקות משימות שונות זקוקות לטווחים חופפים, ומפשט את יישום מדיניות הרשת — הכללים נכתבים עבור מקטע מסוים, ולא עבור כל האשכול בבת אחת.
מבחינת ביצועים האפקט מדיד: תעבורת השירות מפסיקה להתחרות עם תעבורת היישום על רוחב הפס, הג'יטר בבקשות קריטיות יורד, ופרצי שיא של חילופי נתונים כבר אינם גורמים לעלייה בהשהיות הניהול.
עמידות האשכול לתקלות עולה בנפרד — כאשר ערוץ אחד נפגע, האחרים ממשיכים לפעול, והצמתים אינם נופלים בגלל חבילת שירות שלא נמסרה.
עבור הלקוח הדבר מתבטא בהתנהגות צפויה תחת עומס ובכך שאירוע במקטע אחד נשאר מקומי. אנו מפרטים כיצד זה נסגר ברמת התצורה.
אפשרויות לארגון ריבוי רשתות באשכול
ריבוי רשתות ב-Kubernetes מתחיל בבחירת המודל הבסיסי: רשת שטוחה אחת, שכבת-על מעליה, או מספר ממשקים בלתי תלויים לכל פוד. מכך תלוי כיצד התעבורה תעבור בין הפודים, הנודים והסגמנטים החיצוניים, ועד כמה ההתנהגות צפויה תחת עומס.
רשת שטוחה מספקת תקורה מינימלית וניתוב ישיר — הפודים רואים זה את זה ללא אנקפסולציה, אך דורשים מיעון מתואם ברמת התשתית ומתקשים להתאים את עצמם להרחבה מעבר לסגמנט אחד.
שכבת-על פותרת את שאלת הקישוריות בין הנודים והאזורים, אך מוסיפה אנקפסולציה ומסבכת את האבחון: חלק מהבעיות של השהיות ואובדן חבילות מתגלות רק בגבול המנהרות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| רשת שטוחה אחת | סגמנט אחד, השהיה נמוכה, שליטה בניתוב | מתקשה להימתח בין אזורים, דורשת מיעון ידני |
| שכבת-על | נודים ואזורים רבים, נדרשת קישוריות "מהקופסה" | אנקפסולציה, אבחון מורכב יותר, תקורה גבוהה יותר |
| מספר ממשקים דרך תוסף | הפרדת תעבורה: שירותית, אחסון, ניהול | נדרש בחירת תוסף ומצבי חיבור מפורשים לכל פוד |
מספר ממשקי רשת לכל פוד — סוג נפרד של משימות: תעבורה שירותית, גישה לאחסון ומעגל ניהול מופרדים לרשתות שונות כדי לא להפריע זה לזה.
כאן מופיעים תוספי הרשת עם תמיכה בחיבורים נוספים: הבסיסי אחראי על הרשת הראשית, והממשקים הנוספים מתחברים דרך תצורות ומצבים נפרדים — גשר, מקוולן או ממשק ישיר.
בפועל הבחירה אינה בינארית: לעתים קרובות משאירים את שכבת-העל לקישוריות שירותית, ואת התעבורה הקריטית מוציאים לסגמנט שטוח או לממשק ייעודי. בהמשך נבחן כיצד זה מוגדר ואילו מצבי חיבור כדאי לבדוק לפני העלאה לפרודקשן.
שלבי הטמעת ריבוי רשתות Kubernetes
הטמעת ריבוי רשתות אינה מתחילה בהתקנת תוסף, אלא בביקורת של מצב האשכול הנוכחי. המהנדסים אוספים מפת תעבורת רשת: אילו פודים מתקשרים ביניהם, היכן עובר הגבול בין תעבורה שירותית לתעבורה יישומית, והאם קיימות דרישות לבידוד או לרוחב פס. ללא מפה זו, כל סכמת מיעון תהיה מבוססת ניחושים — והקונפליקט הראשון של תת-רשתות יעצור את הפריסה.
- ביקורת רשת. מתעדים את הטופולוגיה הנוכחית, טווחי הכתובות, נקודות היציאה החוצה וצווארי בקבוק בתעבורה. התוצר — מסמך עם תמונה אמיתית, ולא הנחות.
- תכנון סכמת מיעון. מפרידים בין הרשת השירותית לרשת היישומית לטווחים שונים, ומ� исключаем חפיפות עם התשתית של הלקוח. הסכמה מאושרת לפני תחילת העבודה — תיקונים בשלב זה זולים מכל שינוי בייצור.
- הכנת צמתים וממשקים. בכל צומת מוגדרים ממשקי רשת נוספים, נבדקת הזמינות שלהם ויציבות הקישורים. טעות כאן תתגלה רק תחת עומס, ולכן בודקים מראש.
- הגדרת תוסף ריבוי הרשתות. מתקינים ומגדירים את Multus כתוסף-על, מחברים את ה-CNI הנדרשים לכל רשת, ומגדירים את הצמדת הפודים לממשקים באמצעות אנוטציות. תעבורה שירותית נשארת ברשת הראשית, ותעבורה יישומית עוברת לרשת הייעודית.
- בדיקת קישוריות. מריצים בדיקות בין פודים ברשתות שונות, בודקים זמינות החוצה, התנהגות בעת אתחול מחדש של פודים וצמתים. בנפרד בודקים שהבידוד עובד ושהתעבורה אינה "דולפת" בין המקטעים.
- בדיקות עומס. בודקים רוחב פס ויציבות תחת פרופיל תעבורה אמיתי. זה חושף בעיות ניתוב שאינן נראות במצב סרק.
- מסירה לתפעול. מוסרים קונפיגורציות, סכמת מיעון, הנחיות לאבחון ותקנון להוספת רשתות חדשות. צוות הלקוח יכול לפתח את הקונפיגורציה בלעדינו.
כל שלב מסתיים בתוצאה ניתנת לבדיקה, ולא בדוח עבודות. אם בביקורת מתברר שריבוי רשתות אינו נדרש — אומרים זאת ישירות ומציעים פתרון פשוט יותר.
ארטיפקטים: תצורות, סכמות, נהלים
לאחר הטמעת ריבוי רשתות Kubernetes הלקוח מקבל לא "אשכול עובד באופן כללי", אלא ערכה שלפיה ניתן להפעיל את התשתית, להרחיב אותה ולהעביר אותה לצוות אחר ללא הסברים בעל פה. להלן — מה בדיוק נשאר בידיים.
- תצורות רשת. מניפסטים של NetworkAttachmentDefinition לכל רשת: שם, סוג, טווח כתובות, שער, מזהה VLAN, מצב חיבור. בנפרד — הצמדות של פודים ועומסי עבודה לממשקים הנדרשים, כך שניתוב התעבורה יהיה משוחזר, ולא "מוגדר ידנית על צומת אחד".
- סכמת מיעון. מפה אחודה: אילו תת-רשתות הוקצו לתעבורת שירות, יישום וניהול, היכן עוברים הגבולות ביניהן, אילו כתובות שמורות. לפיה רואים לאן לחבר עומס חדש והיכן נגמר המרחב הפנוי.
- סכמת ניתוב ובידוד. כיצד התעבורה עוברת בין הרשתות, היכן ממוקמים הכללים המפרידים בין קווי המתאר, ומה יקרה בעת כשל באחד הערוצים. הסכמה משקפת את הטופולוגיה בפועל, ולא את זו התכנונית.
- נוהל הפעלה. סדר הוספת רשת חדשה, שינוי טווחים, חיבור פודים והוצאת צמתים משירות. עם תיאור אילו צעדים בטוחים על אשכול פעיל ואילו דורשים חלון תחזוקה.
- תיעוד האשכול. תיאור רכיבים, גרסאות, תלויות בין רשתות ומערכות חיצוניות, נקודות כשל. מספיק כדי שמהנדס חדש ית�צא את ידיו ללא מחבר ההטמעה.
- בדיקות וניטור. מערך בדיקות זמינות ממשקים, מדדים לתעבורה ולשגיאות, כללי התראה בעת ירידת ביצועי רשת. בנוסף — תרחישי אבחון לתקלות אופייניות.
- תוכנית נסיגה. מה ובאיזה סדר מנותק, אם התצורה החדשה שוברת את הקישוריות, וכיצד לחזור למצב הקודם ללא אובדן יכולת השליטה.
את הערכה מעבירים למאגר של הלקוח עם היסטוריית שינויים — בהמשך הצוות מנהל אותה באופן עצמאי. תארו את המשימה שלכם, ונחזור עם הערכה ותוכנית עבודה.
מקרה בוחן: הפרדת תעבורה לשלוש רשתות
הלקוח — מפעיל פלטפורמה עם כמה צוותי מוצר. אשכול משותף אחד, וכל התעבורה — תעבורת לקוחות, תעבורת שירות ותעבורת אחסון — עברה דרך ממשק אחד. בעומסי שיא משימות השירות (שכפול, איסוף מדדים, גיבוי) מילאו את רוחב הפס, ובקשות הלקוחות החלו לאבד מנות. האבחון נתקע בעובדה שבזרם אחד לא ניתן היה להפריד בין הסיבה לתוצאה.
מה עשינו
פרסנו את Multus כמטא-תוסף מעל ממשק הרשת הראשי והקמנו שלוש רשתות עצמאיות: רשת לקוחות, רשת שירות ורשת אחסון. לכל צומת עבודה הוספנו ממשקים נפרדים, ולאפליקציות הוענקה אנטציה עם הרשת הנדרשת — ה-pod בוחר אותה אוטומטית בעת העלייה. תעבורת השירות ותעבורת האחסון הפסיקו להתחרות עם תעבורת הלקוחות על אותו רוחב פס.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| אובדן מנות בשיא | עד 4% | < 0,1% |
| השהיית בקשות לקוחות | גדלה פי 3-4 תחת עומס | יציבה |
| זמן שכפול אחסון | התחרה עם הלקוחות | רוחב פס נפרד, ללא השפעה |
| אבחון תקלה | שעות על הפרדת זרמים | הסיבה נראית לפי רשת מיד |
התוצאה
הפרדת הזרמים הסירה את ההשפעה ההדדית: משימות השירות כבר אינן מפילות את שירות הלקוחות, ותקלות מאותרות לפי רשת ספציפית ולא לפי כל האשכול. כשל של רשת אחת אינו משפיע על האחרות — הפלטפורמה עומדת בעומסי שיא ללא ירידה בביצועי בקשות הלקוחות.
במה שונה ריבוי רשתות מרשת אחת עם מדיניות?
מדיניות רשת פועלת בתוך מרחב כתובות שטוח אחד: פודים רואים זה את זה ישירות, והכללים רק מסננים מי יכול לתקשר עם מי. זה נוח כל עוד כל האפליקציה חיה באשכול אחד ובפלח מהימן אחד.
ברגע שמופיע תעבורה שאסור לה אפילו תיאורטית להצטלב עם תעבורת האפליקציה — חילופי שירות של בסיסי נתונים, זרם מציוד תעשייתי, ערוץ של שער תשלומים — הסינון מפסיק להיות ערובה מספקת. אפשר להחליש כלל בטעות בעריכה אחת של מניפסט, והבידוד נעלם.
ריבוי רשתות בנוי אחרת: הפוד מקבל כמה ממשקים, וכל אחד מהם מחובר לפלח משלו עם כתובות משלו. תעבורת האפליקציה עוברת דרך ממשק אחד, תעבורת השירות — דרך השני, תעבורת שותפים חיצוניים — דרך השלישי.
ההפרדה מוגדרת ברמת החיבור, ולא ברמת הכללים: גם אם המדיניות על ממשק האפליקציה תוגדר באופן שגוי, הפלח הזר לא יימצא פיזית באותו מרחב כתובות. זהו סוג אחר לחלוטין של ערובה — לא "אסור על פי כלל", אלא "בלתי מושג על פי המבנה".
השוואת הגישות מצטמצמת לשלושה צירים. בבידוד תעבורה מדיניות נותנות גבול לוגי, ריבוי רשתות — גבול טופולוגי. בניהוליות רשת אחת פשוטה יותר: פחות ישויות, פחות נקודות כשל, אבחון מוכר. ריבוי רשתות דורש תכנון כתובות, תיאום מסלולים ותשומת לב לשאלה איזה ממשק האפליקציה בוחרת כברירת מחדל.
בתאימות מדיניות עובדות עם כל פוד ללא שינויים, ואילו כמה ממשקים דורשים שהאפליקציה או sidecar ידעו לפנות לפלח הנכון.
המסקנה המעשית אינה שאחד טוב מהשני. מדיניות נשארות שכבה בסיסית מחייבת — הן סוגרות lateral movement בתוך האשכול ועולות בזול. ריבוי רשתות מתווסף באופן ממוקד, במקום שבו נדרש גבול אמיתי: פלחים רגולטוריים, רשתות ציוד, הפרדה בין תעבורת פרודקשן לתעבורת שירות. בפועל משלבים ביניהם: מדיניות מנהלות גישה בתוך כל פלח, וכמה ממשקים לא מאפשרים לפלחים להיפגש.
שאלות טכניות נפוצות בנושא ריבוי רשתות
ריבוי רשתות ב-Kubernetes כמעט תמיד נתקל לא בפלאגין עצמו, אלא בשאלות של תאימות ואבחון שעולות כבר בסביבת הבדיקה. להלן מה שמהנדסים שואלים לרוב לפני שהם מכניסים תבנית כזו לפרודקשן.
האם זה תואם לאשכול הנוכחי ול-CNI שכבר מותקן?
כן, Multus פועל כמטא-פלאגין מעל ה-CNI הראשי: הוא לא מחליף אותו, אלא מוסיף ממשקים נוספים לפוד. ה-CNI הראשי נשאר ברירת המחדל וממשיך להיות אחראי על תעבורת השירות, והרשת השנייה והבאות אחריה מתחברות דרך NetworkAttachmentDefinition.
אנו בודקים בסביבת הבדיקה את תאימות הגרסאות של הפלאגין הראשי ושל Multus, את סדר הממשקים בפוד, ואת העובדה שניתוב ברירת המחדל אינו נחטף על ידי ממשק נוסף.
אילו מגבלות יש לריבוי רשתות שכדאי להכיר מראש?
ממשקים נוספים מוסיפים תקורה על נתיב הרשת ומסבכים את ניפוי השגיאות: לפוד מתווספות מספר כתובות, והאפליקציה צריכה לבחור במפורש דרך איזה ממשק לתקשר. חלק ממדיניויות הרשת ומאזני העומס מתייחסים כברירת מחדל רק לממשק הראשי — יש להתחשב בכך בתכנון. כמו כן כדאי להגדיר מראש אילו רשתות מספקות קישוריות L2 ואילו מספקות רק גישה מנותבת.
כיצד לאבחן שהפוד קיבל ממשק לא נכון או שאין קישוריות?
מתחילים בתיאור הפוד: ניתן לראות אילו ממשקים וכתובות הוקצו בפועל. לאחר מכן בודקים את אובייקט ה-NetworkAttachmentDefinition עצמו — נכונות ההפניה לפלאגין ולמסכת המשנה. אם יש כתובת אך אין תעבורה, בודקים את טבלאות הניתוב בתוך הפוד ובצומת, וכן את כללי הסינון. לעתים קרובות הסיבה היא התנגשות בנתיב ברירת המחדל או ממשק אב שנבחר באופן שגוי בצומת.
האם ניתן לחזור אחורה אם התבנית לא תתפוס?
כן. רשתות נוספות מתחברות באופן הצהרתי, ולכן חזרה אחורה היא מחיקת ההצמדות והחזרת הפודים לממשק ראשי אחד. את ה-CNI הראשי אין נוגעים, ותעבורת השירות אינה נפגעת. אנו תמיד מגדירים תוכנית חזרה אחורה כזו לפני תחילת העבודה, כדי שניתן יהיה להסיר את השינוי ללא השבתה.
תארו את המשימה שלכם — נחזור עם הערכה ותוכנית יישום.
בואו נדון במשימה שלכם עם ריבוי רשתות
פיצול תעבורה למספר רשתות באשכול — זו משימה שבה מחיר הטעות בתכנון נראה לא מיד, אלא לאחר שבועות של תפעול. לכן אנחנו לא מתחילים בהגדרה, אלא קודם מנתחים את הטופולוגיה שלכם: כמה רשתות נדרשות, איזו תעבורה תעבור דרכן, האם יש דרישות לבידוד ולקיבולת. זה קובע גם את בחירת המצב וגם את סדר העבודה.
- ניתוח המשימה. אוספים נתונים ראשוניים: אילו פודים צריכים לראות מספר ממשקים, האם נדרש בידוד ביניהם, האם יש דרישות חיצוניות לכתובות. מתעדים מה קריטי ומה ניתן לפתור באמצעים סטנדרטיים.
- הערכת העבודה. לפי תוצאות הניתוח חוזרים עם הערכת לוחות זמנים והיקף — בלי "תלוי במורכבות" מופשט, אלא עם רשימה קונקרטית של שינויים בהגדרות האשכול.
- תוכנית יישום. מתאמים את הרצף: הכנת צמתים, התקנה והגדרה של התוסף, תיאור אובייקטים ברשת, קישור פודים לממשקים הנדרשים. כל שלב עם נקודת שחזור.
- פיילוט על צומת אחד או סביבת בדיקה. בודקים שהניתוב בין הרשתות עובד כמתוכנן, ושהתעבורה הראשית לא נפגעת. רק לאחר מכן פורסים על כל האשכול.
- פריסה ובדיקה. מיישמים את ההגדרה בשלבים, תוך בקרה על מצב הצמתים והפודים. בנפרד בודקים תרחישי כשל — מה יקרה בעת אובדן אחת הרשתות.
- מסירה ותיעוד. מוסרים את תרשים הרשתות, ההגדרות והנחיות לשינוי — כדי שהצוות שלכם יוכל לפתח את הפתרון בלעדינו.
אם כבר יש לכם אשכול וצריך להוסיף ריבוי רשתות ללא השבתה — זה תרחיש נפרד, גם אותו ננתח. תארו את המשימה: כמה רשתות, איזו תעבורה, אילו מגבלות זמינות. נחזור עם הערכה ותוכנית יישום, ובמידת הצורך נחבר מהנדס לניתוח בצד שלכם.