הגדרת תוסף Kubernetes CNI (Flannel) עבור רשת אוברליי

Flannel CNI ב-Kubernetes: מדוע רשת ה-overlay נקרעת

Flannel כפלאגין CNI של Kubernetes פותר משימה אחת: להקצות לכל צומת עבודה תת-רשת משלו ולקשר את תת-הרשתות הללו מעל הרשת הפיזית, כדי שפודים על צמתים שונים יתקשרו ישירות. כל עוד מפות הניתוב והשכנים בכל הצמתים מסונכרנות, רשת ה-overlay של האשכול מתנהגת באופן צפוי. הכשלים מתחילים היכן שהמצב מתפצל: צומת אחד כבר עדכן את מפת תת-הרשתות, ואחר עדיין מחזיק בקודמת.

הכשל הטיפוסי הראשון — אובדן קישוריות בין הצמתים: כל צומת רואה רק את הפודים שלו, והתעבורה בין הפודים נעלמת לאין. הסיבות שתיים: חכירה מיושנת של תת-רשת לאחר יצירה מחדש של צומת, וכשל בניתוב הפודים, כאשר הכללים בשרשראות ה-CNI נמחקו על ידי כלי אחר או אופסו בעת אתחול הריצה (runtime).

סוג הכשלים השני מתבטא בחוסר יציבות: כתובות הפודים משתנות לאחר אתחול. הכתובת שהתפנתה חוזרת למאגר באיחור, הפוד החדש מקבל כתובת אחרת, והצמתים השכנים עדיין מחזיקים ברשומה הישנה — חלק מהחיבורים יוצאים בנתיב שאינו קיים. מבחוץ זה נראה כמו «לפעמים עובד».

המקרה השלישי והיקר ביותר — חיבורים נתקעים ללא שגיאות ברורות באפליקציה. כאשר גודל החבילה עולה על המותר למנה (tunnel), והפיצול אסור, בקשות גדולות אובדות בשקט: המדדים של השירות נקיים, והמשתמש ממתין לתשובה עד ל-timeout. כשלים כאלה אינם נראים בלוגים של האפליקציה. בהמשך נסביר כיצד אנו מאתרים את המקור ומטפלים בו.

מה משתנה לאחר הגדרה נכונה של רשת overlay

רשת overlay אינה «מופעלת» פעם אחת — זהו מערך של פרמטרים שהתנהגות האשכול בעומס תלויה בהם: מצב האנקפסולציה, גודל תת-הרשת לכל צומת, ועקביות ה-MTU בכל הממשקים. Flannel מטפל בכך באופן צפוי, אם הפרמטרים נקבעים במכוון ולא נשארים כברירת מחדל.

זמן חיבור של צומת חדש

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

אובדן חבילות וכשלים חוזרים

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

בנפרד נעלם סוג הכשלים היקר מכולם: הצומת פורמלית חי, אך חלק מהנתיבים אל צמתים אחרים מתפצל, והתעבורה נעלמת לאין. האבחון של הרשת הופך למדיד — מצב הממשקים, מוני חבילות שנזרקו, בדיקת נגישות לכל זוג צמתים במקום מעבר ידני.

אפשרויות ארגון רשת overlay: השוואת מצבים

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

כיצד לבחור בהתאם לטופולוגיה שלכם

אם ה-L2 משותף — ניתוב ישיר נותן מקסימום בתקורה מינימלית; אם הצמתים מפוזרים — overlay, וההצפנה מונחת כשכבה במצב נפרד.

האפשרות ההיברידית עוברת בעצמה לניתוב ישיר עבור שכנים בתת-רשת משותפת ונכנסת לאנקפסולציה עבור האחרים, אך לנפות אותה קשה יותר: חלק מהנתיבים עובר בדרך אחת, וחלק בדרך אחרת.

סדר הגדרת הרשת ב-Kubernetes: שישה שלבים

סדר העבודה כאן אינו מקרי: הרשת היא השכבה היחידה שאי אפשר לאתחל «על חי». שגיאה בסכימת הכתובות מתגלה לא בעת ההתקנה, אלא לאחר שבועות, כאשר יגדלו מספר הצמתים ונפח התעבורה בין השירותים.

לכן אנו מבצעים את הגדרת Flannel CNI ברצף קבוע — מהמלאי (inventory) ועד למסירה לתפעול, עם בדיקה בכל מעבר.

1. סקר קונפיגורציה. אנו אוספים את מצב הצמתים, טווחי הכתובות התפוסים וכללי הניתוב, כדי שרשת ה-overlay לא תחפוף לתת-הרשתות של המשרד והענן.
2. סכימת כתובות. אנו בוחרים טווח לרשת ה-pod ואת גודל תת-הרשת לכל צומת — ממנו תלוי המספר המרבי של הקונטיינרים והרזרבה לצמיחת האשכול; כתובות השירותים מתוכננות בטווח נפרד.
3. פריסת Flannel. אנו מתקינים את ה-CNI כרכיב מנוהל, מגדירים את מצב פעולת הרשת ואת פרמטרי הכתובות באופן דקלרטיבי — את הקונפיגורציה ניתן לשחזר על אשכול נקי.
4. בדיקת קישוריות. אנו מריצים תרחישי צומת-לצומת וקונטיינר-לקונטיינר בין אזורים שונים, ובנפרד מוודאים שמדיניות הרשת אינה מעבירה תעבורה מיותרת.
5. בדיקה תחת עומס. אנו מזרימים תעבורה גדלה בין השירותים, בוחנים השהיות, אובדן חבילות והתנהגות בעת כשל של צומת אחד, ומתעדים את הגבול שמעבר לו הרשת מדרדרת.
6. מסירה לתפעול. אנו מוסרים את סכימת הכתובות, הקונפיגורציות, סדר חיבורו של צומת חדש ומערך בדיקות למשמרת הכוננות.

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

קונפיגורציות, תרשימי רשת ותקנות תפעול

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

• קונפיגורציות עבודה. מניפסטים ופרמטרים של פלאגין הרשת (Flannel) עבור מישור הבקרה והסוכנים בכל צומת: מצב האנקפסולציה, גודל החבילה, מרווחי עדכון המצב. מיושמים באופן אידמפוטנטי — הרצה חוזרת אינה שוברת אשכול פעיל.
• סכימת כתובות. טווחי הכתובות של הפודים והשירותים, חלוקתם לפי צמתים ואזורים, ורזרבה לסביבות עתידיות. בנפרד מסומנים טווחים תפוסים מחוץ לאשכול, כדי שהחדשים לא יחפפו להם.
• תרשים קישוריות. כיצד הצמתים מוצאים זה את זה, היכן התעבורה עוברת ישירות והיכן דרך נתיבי ביניים, היכן היציאה לרשת החיצונית — עם סימון הקטעים שיתקלו בגבול התפוקה ראשונים.
• כללי גישה. מדיניות רשת: מי מתקשר עם מי ובאילו פורטים, ומה מבודד כברירת מחדל. שירות חדש מתחבר לפי הסכימה המתוארת, ולא «כמו אצל השכן».
• תקנון אבחון. סדר צעד-אחר-צעד בעת אובדן קישוריות: מה לבדוק בצומת, מה במישור הבקרה, אילו מדדים ולוגים לנתח ראשונים ולפי אילו סימנים מתמקדים במקור הבעיה.
• תקנון שינויים. באיזה סדר מתקנים פרמטרים ומעדכנים צמתים כדי לא להפיל את התעבורה, וכיצד לחזור למערך הקונפיגורציות הקודם.
• הוראות שחזור. סדר הקמת הרשת על אשכול נקי ולאחר החלפת צומת, עם בדיקות שמאשרות קישוריות ולא רק שהפודים עלו.

מקרה בוחן: רשת אשכול לא יציבה — מה היה ומה נהיה

התמונה ההתחלתית

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

שיעור הקריאות הכושלות בין השירותים עמד על כמה אחוזים, ולאחר תזמון מחדש של הפודים הרשת התאוששה עד חצי שעה ורק ידנית. בעיני הלקוח זה נראה כמו השבתות קצרות «מרחפות» בלי סיבה ברורה בלוגים.

הסיבות הצטברו לסטאק: טווחי כתובות חופפים של תת-הרשתות של הצמתים, עריכה ידנית של נתיבים בעת הכנסת מכונה חדשה, היעדר בקרה על גודל החבילה בעת אנקפסולציית תעבורה, ואפס נראות (observability) על המנות. Flannel היה מותקן באשכול, אך הוגדר חלקית — ומכאן רשת «מהבהבת» במקום ערוץ צפוי.

מה עשינו ומה השגנו

את הכתובות בנינו מחדש: לכל צומת — טווח נפרד ובלתי חופף מהמאגר המשותף, ואת הנתיבים יוצר פלאגין ה-CNI עצמו עם הופעתו ועזיבתו של צומת.

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

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

במה נבדל מצב ניתוב ישיר מאנקפסולציה?

ניתוב ישיר ואנקפסולציה פותרים משימה אחת — לקשר פודים על צמתים שונים — אך משלמים על כך מחיר שונה. בניתוב ישיר הצומת רושם נתיבים אל תת-הרשתות של השכנים ומעביר את החבילה כפי שהיא: הכותרות אינן נכתבות מחדש, ולא נוסף שלב פענוח מיותר. באנקפסולציה, הפריים (frame) של הפוד נארז בחבילה חיצונית, מועבר עד לצומת היעד ושם נפתח.

מכאן ההבדל בביצועים: המצב הישיר חוסך מחזורי מעבד על האריזה ואינו מוותר על חלק מהחבילה לטובת כותרת שירות — התפוקה וההשהיה טובות יותר.

המחיר — דרישות לטופולוגיה: הצמתים חייבים להיות בסגמנט שכבתי שני אחד או לקיים ניתוב ביניהם, אחרת יהיה צורך לנהל את הנתיבים ידנית גם בצמתים וגם בציוד הרשת.

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

הבחירה נכפית על ידי הטופולוגיה, לא על ידי העדפות. סגמנט L2 אחד ושירותים רגישים להשהיה — מצב ישיר; אתרים מפוזרים וענן היברידי — אנקפסולציה, משום שתחזוקת הניתוב ביניהם ארוכה ושברירית יותר.

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

ספקות טכניים נפוצים לפני הגדרת הרשת

לפני שינוי שכבת הרשת, מהנדסים שואלים את אותן שאלות: מה לעשות עם התוסף (add-on) שכבר פרוס, האם יהיה צורך לעצור שירותים, האם הרשת תעמוד בצמיחת האשכול, והאם לא נתקל במגבלות גישה. להלן תשובות קצרות, כדי שתוכלו להשוותן לקונפיגורציה שלכם לפני תחילת העבודה.

נבהיר מיד: מצב הפעולה ומאגרי הכתובות נבחרים לפי הטופולוגיה שלכם, ולא לפי ברירת המחדל של הפלאגין. לכן תחילה אנו ממפים את הרשת הנוכחית, ואחר כך מציעים סכימת מעבר.

האם יהיה צורך לעצור שירותים בזמן המעבר?

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

מה עם הרחבת האשכול ומדיניות הגישה?

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

נדון במשימה: כיצד אנו מעריכים את היקף העבודה

הערכת העבודה על רשת האשכול מתחילה בדיון על המשימה: אנו זקוקים לתקציר טכני קצר, בדרך כלל שיחה אחת וגישה לתיאור המצב הנוכחי. מכאן והלאה, את ההיקף אנו מחשבים — מצד הלקוח אין צורך להכין מפרט טכני.

לצורך החישוב די ב:

• טופולוגיה: מספר הצמתים, אזורים, אשכול מנוהל או עצמאי;
• כיצד מוקצית הרשת כעת ומה בדיוק אינו מתאים — כשלי קישוריות, עריכה ידנית של קונפיגורציות, מחסור בכתובות;
• דרישות לבידוד בין מרחבי שמות ולגישה חיצונית;
• האם עצירת שירותים מותרת או שנדרש מעבר ללא השבתה;
• מגבלות: ספק הענן, מדיניות אבטחה, סדר מתן ההרשאות.

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

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