הגדרת Calico ל-Kubernetes: מדיניות רשת ו-BGP

למה Calico CNI נכשל כשהקלאסטר גדל

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

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

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

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

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

רשת קלאסטר מנוהלת: מה משתנה בפועל

מדיניות רשת כנקודת בקרה אחודה

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

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

בידוד סביבות וצמצום רדיוס הכשל

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

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

מצבי Calico CNI: אנקפסולציה מול ניתוב ישיר

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

מתי בוחרים באנקפסולציה של תעבורה

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

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

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

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

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

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

סכמת כתובות ותוכנית מעבר ללא השבתה

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

בדיקת מדיניות ותרחישי הדרדרות

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

מה נשאר לצוות הלקוח לאחר סיום העבודה

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

תצורות ותיאורי טופולוגיה

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

נוהל שינויים ומטריצת גישות

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

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

מקרה בוחן: איך רשת הקלאסטר הפסיקה להיות צוואר בקבוק

הקלאסטר גדל לכמה עשרות נודים ושלוש סביבות, והרשת עדיין התקיימה על נתיבים ידניים: המהנדס הוסיף רשומות סטטיות בין רשתות משנה וערך רשימות גישה במקומות שונים. חיבור צוות חדש או פריסת סביבה הפכו לעבודת לילה עם סיכון לפגוע בסביבה שכנה, והכללים עצמם постепенно התפצלו בין סביבות הבדיקה.

מה היה לפני: נתיבים ידניים וכללי גישה מתפצלים

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

הפקה ממערכת הניטור ויומני האירועים ברבעון שלפני היישום: התאוששות לאחר כשל רשת — כ-40 דקות, שיעור המנות האבודות בפריסת גרסה חדשה של האפליקציה — עד 1.8%, תקלות רשת עם התערבות ידנית — 3–4 פעמים בחודש.

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

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

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

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

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

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

הקריטריון לבחירה פשוט. אם נדרש חילופי נתיבים ב-BGP עם ציוד מחוץ לקלאסטר, מקור מדיניות אחיד והתנהגות צפויה בזמן גדילה — מחליפים את המודול. אם המשימה מסתכמת בסגמנטציה בתוך הקלאסטר ומדיניות רשת סטנדרטית מספיקה, זול יותר להשאיר את ה-CNI הנוכחי מאשר לתחזק שני בקרים. בנפרד בודקים תאימות: ענף Kubernetes הנדרש, מאזן עומסים בענן, ואינטראקציה עם מצב החלפת kube-proxy.

ספקות טכניים: תאימות, נסיגה, אבחון

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

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

איך לאבחן אובדן תעבורה?

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

האם זה תואם לקלאסטר הנוכחי?

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

איך לשמור על יכולת חיזוי של שינויים?

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

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

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

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

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