Cilium CNI עם eBPF: ביצועים ואבטחה ב-Kubernetes

Cilium CNI: היכן נשברת הרשת בתוך הקלאסטר

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

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

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

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

Cilium CNI משנה את הנקודה שבה מתקבלות ההחלטות: במקום שרשראות ארוכות של תרגום כתובות — תוכניות eBPF ישירות בגרעין, המחוברות לממשקי רשת, עם טבלאות חיבורים ואיזון עומסים ברמת ה-socket. בהמשך ננתח היכן בדיוק אובדת התעבורה בסכמות כאלה ומה משתנה בעת כשל של נוד.

מה נותנת מודל הרשת מבוסס eBPF: השהיות, כשלים, בידוד

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

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

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

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

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

Cilium CNI ומצבי רשת חלופיים: השוואה

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

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

סדר ההטמעה: מביקורת רשת ועד מסירת נהלים

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

1. ביקורת רשת. אוספים מפת זרימות בין השירותים, עורכים מלאי של המדיניות, מחפשים חוקים של "לאשר הכול" ושירותים ללא הגבלות. בפלט — רשימת סיכונים וצווארי בקבוק, ולא המלצות כלליות.
2. תכנון הסכמה. מגדירים מרחבי כתובות, נקודות יציאה של התעבורה ומדיניות ברירת מחדל: איסור הכול, אישורים — נקודתית. את הסכמה מתאמים עם הצוות שלכם לפני תחילת ההגדרה.
3. הגדרה על עותק של הקלאסטר. פורסים Cilium CNI על סביבת בדיקה, מעבירים מדיניות, מפעילים נראות: מטריקות לפי זרימות ויומן של חיבורים שנדחו. כאן גם מתרגלים את הליך החזרה לאחור.
4. בדיקה על סטנד. מריצים עומס קרוב לזה של הפרודקשן, בודקים את ההתנהגות בעת כשל של נוד ואובדן ערוץ חיצוני, בוחנים השהיות ושיעור החבילות האבודות.
5. החלפה ללא השבתה. מעבירים את עומסי העבודה לפי מאגרי נודים: החדשים עולים על הסכמה היעד, את הישנים מוציאים לאחר שהתעבורה עליהם פסקה. השירותים זמינים כל הזמן הזה.
6. מסירת נהלים. מוסרים את הסכמה, התצורות והמדיניות במערכת בקרת גרסאות, מתארים את סדר האבחון והחזרה לאחור, ומכשירים את משמרת התורנות.

מדיניות גישה וסכמת הרשת: מה נשאר בפרויקט

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

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

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

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

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

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

מה שינינו

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

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

מה לעשות אם בקלאסטר כבר פרוס מודול רשת אחר?

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

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

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

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

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

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

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

שאלות טכניות בנוגע לתאימות ולעומס

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

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

כיצד המעבר ישפיע על העומס בנודים?

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

באיזה סדר לעדכן את הקלאסטר?

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

האם האפליקציות הפעילות תישברנה?

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

נדון במשימה: נחזור עם הערכה ותוכנית עבודה

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

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

לפי תוצאות הניתוח נחזור עם חבילה שכוללת:

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

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

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