מדוע בידוד סביבות ב-Kubernetes נשבר על משאבים משותפים
כאשר כמה צוותים יושבים באשכול אחד ללא גבולות מפורשים, הכשלים מתחילים לא ברגע השחרור, אלא ברגע שיא העומס. פודים ללא מגבלות ובקשות משאבים דוחקים שכנים מהצומת, וקורס לא השירות שיצר את הבעיה, אלא זה שהיה рядом.
זהו השכן הרועש באשכול: חישוב רקע של מישהו אחר או אינדוקס לילי צורך משאבים, והשירות הפרודקשני השכן נפגע.
תרחיש אופייני שני — התנגשות עומסים באשכול משותף ברשת ובמתזמן. כברירת מחדל ב-Kubernetes כל הפודים רואים זה את זה, ולכן סביבת בדיקה ללא מדיניות רשת מגיעה בשקט לשירותי פרודקשן ולמסדי נתונים.
במקביל, מרחב שמות ללא מכסות מאפשר לצוות אחד לתפוס את כל הצמתים: המתזמן לא מוצא מקום לפודים של האחרים, והם תלויים בהמתנה.
סוג שלישי — הרשאות מבולבלות, כאשר אשכול אחד לכמה צוותים משמעו סודות משותפים, תפקידים משותפים ונקודות כניסה משותפות. תקרית בסביבת בדיקה נחקרת לפי לוגים של סביבת הפרודקשן, סוד שנדרס בטעות במרחב שמות משותף שובר שחרור של מישהו אחר, וחזרה לאחור פוגעת בשכנים.
המחיר של שכנות כזו — לא רק תחקירי לילה, אלא גם אובדן שליטה: אי אפשר לחזות מה ישרוד בשיא עומס, ואי אפשר לנקוב באשם של הידרדרות. בהמשך נבחן כיצד בידוד סביבות ב-Kubernetes נסגר באמצעות גבולות של מרחבי שמות, מדיניות רשת ומכסות, שמחלקות משאבים מראש ולא ברגע התקלה.
מה נותן בידוד סביבות: השפעה לפי מדדי אמינות
כאשר כל הצוותים עובדים במרחב שמות אחד, כשל של שירות אחד גורר שכנים: פוד עם דליפת זיכרון דוחק פודים של אחרים, ושחרור כושל תופס משאבים של כל האשכול.
אנו מפרידים סביבות ב-Kubernetes באמצעות Namespace — dev, staging ו-production מפסיקים לראות אובייקטים זה של זה, ורדיוס הכשל מצטמצם לסביבה אחת. מחיר הטעות בסביבת בדיקה כבר אינו נמדד בקריסה של סביבת הפרודקשן.
את קו הרשת אנו סוגרים ב-NetworkPolicy: כברירת מחדל תעבורה בין מרחבי שמות אסורה, אנו מתירים רק זרימות שתוארו במפורש — שירות לשירות, סביבה לסביבה. פנייה מקרית של סביבת בדיקה למסד נתוני פרודקשן נעשית בלתי אפשרית לא לפי הסכמה אלא לפי תצורה.
תופעת לוואי: מפת הקשרים בין השירותים מפסיקה להיות ידע בראשיהם של מהנדסים בודדים והופכת לתיאור שניתן לבדוק.
צריכת המשאבים נעשית צפויה: ResourceQuota מגביל את סך הבקשות והמגבלות למרחב שמות, LimitRange קובע גבולות לפוד בודד. הצוות פיזית לא יכול לתפוס יותר מהמוקצה, המתזמן לא מחזיק פודים של אחרים בתור, ודחיקה בגלל חוסר זיכרון מפסיקה להיות פתאומית.
זמן ההתאוששות מתקצר הודות ללוקליות: חזרה לאחור, הפעלה מחדש ובנייה מחדש מתבצעות בתוך סביבה אחת ואינן פוגעות באחרות. זה נראה במדדים — שיעור הכשלים שנכנסו לזמן ההתאוששות היעד עולה, ומספר התקריות שפגעו בכמה צוותים בבת אחת שואף לאפס.
השוואת גישות: מרחבי שמות, מדיניות רשת, מכסות
הפרדת סביבות לעיתים רחוקות נסגרת במנגנון אחד: מרחב שמות נותן גבול לוגי, אך כברירת מחדל אינו מונע מפוד מסביבה שכנה לפנות לשירות זר או לתפוס זיכרון של צומת. לכן משווים לא פרימיטיבים בודדים אלא תרחישים — מהפרדה מהירה בתוך אשכול אחד ועד פיזור מלא בין אשכולות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מרחבי שמות באשכול משותף | צוות אחד, הפרדת סביבת בדיקה וסביבת פרודקשן כבר בהתחלה | שכבת ניהול וצמתים משותפים: הבידוד חלש, רעש משאבים וכשל בצומת פוגעים בשכנים |
| מרחבי שמות + מדיניות רשת ומכסות | כמה צוותים, צריך להגביל קשרי רשת ולקבוע תקרת משאבים | דורש משמעת בסימון פודים: מדיניות עם תוויות שגויות מעבירה תעבורה בשקט, מכסות נבחנות מחדש כשהעומס גדל |
| מאגר צמתים ייעודי לסביבה | סביבת פרודקשן עמוסה לצד סביבות בדיקה | לא מגן מפני טעויות בהגדרות משותפות ובשכבת הניהול, ומסבך תזמון פודים |
| אשכול נפרד לכל סביבה | דרישות רגולטוריות, קצב עדכונים שונה, בידוד קשיח של סביבת פרודקשן | יקר יותר לתחזוקה: יש לסנכרן תצורה וכללי גישה בין אשכולות |
הבחירה היא בדרך כלל משולבת: גבולות מרחבי שמות, מדיניות רשת ומכסות מסירים את רוב הסיכונים, ואשכול נפרד משאירים לסביבת פרודקשן או לסביבות עם דרישות מיוחדות. בניתוח התשתית אנו בוחנים היכן עובר כעת הגבול בין הסביבות ואיזה סוג כשל הוא אינו מחזיק.
שלבי העבודה: מביקורת האשכול ועד מסירת נהלים
את העבודה באשכול Kubernetes אנו מבצעים בסדר קבוע: תחילה עובדות, אחר כך שינויים. הסדר ההפוך — סיבה נפוצה לכך שבידוד מפיל את הפרודקשן: כללים נקבעים לפני שמכירים את הקשרים האמיתיים בין השירותים. כל שלב מסתיים בארטיפקט שנבדק לפני המעבר לשלב הבא.
- ביקורת אשכול ותלויות. אוספים מלאי של מרחבי שמות, עומסים ובעלים, בונים מפת קשרי רשת לפי יומנים: מי פונה למי, באילו פורטים, מי פונה החוצה.
- תכנון סכימת ההפרדה. מגדירים גבולות סביבות וכללי שמות, למי אילו מרחבי שמות זמינים. מחשבים מכסות למעבד, זיכרון ומספר אובייקטים, ומאשרים את הסכימה לפני היישום.
- הגדרת מדיניות רשת. מתרגמים את מפת הקשרים לכללים של "להתיר רק את ההכרחי": תעבורה כברירת מחדל סגורה, חריגים ניתנים באופן ממוקד, סביבות אינן רואות זו את זו.
- בדיקת עמידות בכשלים. מכבים צמתים, נותנים עומס שיא, מנסים לפרוץ את הבידוד מבפנים — פוד מסביבה אחת לא אמור לראות שירותים של סביבה שכנה. בנפרד בודקים את התנהגות המכסות בעומס יתר.
- מסירת נהלים לצוות. מוסרים תיאור סכימה, קבצי תצורה, סדר חיבור שירותים חדשים וסדר חזרה לאחור. מהנדס של הלקוח פורס את סביבת הבדיקה לפי ההוראות בעצמו.
מניפסטים, מדיניות גישה ונהלים בתוצר
העבודה מסתיימת לא בדוח אלא בסט ארטיפקטים שמיושמים מיד באשכול שלכם. הכול נמצא במאגר תחת בקרת גרסאות: שינויים עוברים סקירה ונפרסים באותה דרך שבה פורסים אפליקציות.
- תצורות אשכול ומניפסטים — Namespace נפרד לכל סביבה, ResourceQuota ו-LimitRange עם מגבלות מחושבות, כדי שצוות אחד לא יאכל את משאבי הצמתים.
- מדיניות גישה ותפקידים — קישורי מודל תפקידים לפי עיקרון ההרשאות המינימליות, חשבונות שירות נפרדים לבנייה ולפריסה, ואיסור גישה ישירה לסביבת הפרודקשן.
- סכימת קשרי רשת — מפה של כיוונים מותרים בין סביבות ושל כללי NetworkPolicy, שבהם כברירת מחדל הכול סגור והחריגים מפורטים במפורש.
- נהל עבודה לצוותים — כיצד פותחים סביבה חדשה, מי הבעלים של המכסה, באיזה סדר משנים מדיניות ומה נחשב להפרת בידוד.
- תיעוד תקריות — יומן תחקירים עם כשלים אופייניים: התנגשות מכסות, מדיניות שגויה, גישה שנשללה — וסדר הפעולות של התורן.
- צ'ק-ליסט קבלה — בדיקות שפוד מסביבה שכנה אינו נראה ברשת ואינו יכול לתפוס מכסה של אחרת; אותן בדיקות חוזרות בצינור לאחר כל שינוי.
את הארטיפקטים מוסרים יחד עם גישות ותחקיר בשיחת וידאו: המהנדסים מראים היכן כל דבר נמצא וכיצד לשנות מדיניות בלי לשבור את הבידוד בין הסביבות.
מקרה בוחן: כיצד הפרדנו סביבות והסרנו כשלים הדדיים
מה היה: namespace אחד להכול
כל הסביבות — פיתוח, בדיקות, קדם-פרודקשן ופרודקשן — עבדו באשכול Kubernetes אחד ללא גבולות: namespace כברירת מחדל, בלי מכסות ובלי מדיניות רשת. ריצת עומס בסביבת הבדיקה מיצתה את מגבלות הצמתים, ושירותי הפרודקשן החלו להחזיר timeout; הצומת נסתם בלוגים של דיבוג. צרה נפרדת — בנייה מסביבת הבדיקה ראתה את מסד הפרודקשן כשכן רגיל ברשת ויכלה לכתוב לתוכו.
מה שינינו ומה קיבלנו
פרשנו את הסביבות לפי namespace עם ResourceQuota ו-LimitRange: הפרודקשן קיבל מגבלות מובטחות, סביבות הבדיקה — תקרה שאי אפשר לעבור. NetworkPolicy "הכול אסור חוץ ממה שהותר במפורש" סגר את התעבורה בין הסביבות.
את הפרודקשן העברנו לצמתים נפרדים, ולכן עומס הדיבוג אינו יכול לתפוס את משאביו פיזית. תצורת המכסות והמדיניות נמצאת במאגר: סביבה חדשה עולה בהעתקת תבנית ולא בהגדרה ידנית.
תוצאת הרבעון הראשון: כשלים הדדיים בין סביבות — מכמה בחודש לאפס; זמן איתור האשם הצטמצם משעות לדקות, משום שגבולות הסביבות התיישרו עם גבולות האבחון. סוג הכשל "הפרודקשן נפל בגלל שכן" הפסיק להתקיים — התקריות שנותרו נגרמות רק משינויים בתוך הסביבה עצמה.
במה נבדלים מרחבי שמות מאשכול נפרד?
מרחבי שמות — גבול לוגי בתוך אשכול אחד, אשכול נפרד — גבול פיזי. הראשונים מפרידים אובייקטים, הרשאות, תעבורה ומכסות, אך משאירים משותפים את שכבת הניהול, תוסף הרשת והצמתים. האחרונים נותנים הפרדה מלאה במחיר של קו תחזוקה נפרד.
את הבחירה קובעים שלושה גורמים: דרישות להפרדה, צורך בגרסאות משלכם של רכיבי פלטפורמה והיקף עבודת התחזוקה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מרחבי שמות באשכול משותף | כמה צוותים וסביבות על אותה פלטפורמה | שכבת ניהול משותפת: כשל בצומת או עומס יתר נראים לכולם |
| מרחבי שמות עם מדיניות רשת ומכסות | יש צורך בתקרת צריכה ובאיסור תעבורה בין צוותים | הרשאות לאובייקטים ברמת האשכול נשארות משותפות |
| אשכול נפרד לכל קו | גרסאות שונות של רכיבים, משטר עדכונים משלכם, חשבון נפרד | כל אחד צריך עדכונים משלו, גיבויים ותורנות משלו |
עלויות התחזוקה גדלות בקפיצות: כל אשכול הוא מחזור עדכונים נפרד, סט משלו של שירותי פלטפורמה, סודות משלו ומלאי משאבים משלו לשיא. מרחבי שמות זולים יותר, אך דורשים משמעת: בלי מדיניות ומכסות הגבולות נשארים על הנייר.
אשכול נפרד מוצדק כאשר גרסאות הרכיבים מתנגשות, הצוות מפרסם אופרטורים ו-webhooks משלו עם הרשאות ברמת האשכול, הרגולטור דורש הפרדת צמתים ורשת, או שהעומס של קו אחד מפריע לאחרים. בשאר המקרים מספיקים מרחבי שמות.
ברירת המחדל העובדתית — אשכול משותף עם גבולות קשיחים, וקו נפרד רק לנתונים מוסדרים. מעבר אליו מאוחר יותר יקר יותר, ולכן את ההחלטה מקבעים בשלב תכנון הפלטפורמה.
שאלות טכניות: מדיניות, מכסות והרשאות גישה
לפני תחילת העבודה הלקוח בודק לא את הניסיון שלנו, אלא את הסיכונים לשירותים פעילים. להלן חמש התלבטויות טכניות שעולות בתדירות הגבוהה ביותר.
הבידוד ב-Kubernetes נשען על שלוש שכבות בלתי תלויות: namespace כגבול של שמות והרשאות, מדיניות רשת כגבול של חילוף, ומכסות כגבול של צריכה. השכבות מופעלות בנפרד — אפשר להתחיל היכן שהסיכון גבוה יותר.
אין הפרדה — מאיפה להתחיל בבטחה?
מתחילים מ-namespace ומכסות — הן אינן משנות את חילוף הרשת, והאפליקציות אינן מבחינות בשלב הזה. מדיניות כותבים תחילה במצב צפייה ומפעילים איסור לאחר ניתוח יומן הדחיות.
האם המדיניות לא תחסום תעבורה נדרשת?
עוברת רק תעבורה שתוארה במפורש לפי תוויות ופורטים — כולל DNS, איסוף מדדים ותורים. דחיות נכתבות תחילה ליומן ולא נחסמות.
איך להגביל משאבים של צוות באשכול?
המכסה קובעת תקרה למעבד, זיכרון, מספר פודים וכרכים, וערכי ברירת מחדל — לכל קונטיינר. הצוות רואה סירוב מובן, ולא דוחק שירותים שכנים.
איך לתת לקבלן גישה בלי למסור את האשכול?
התפקיד מצטמצם למרחב שמות אחד: קריאת יומנים ומצב, פריסת שירותים משלו. חשבון נפרד וניתן לשלילה, בלי גישה לשכנים ולהגדרות האשכול.
מה לעשות אם המדיניות חסמה חילוף פעיל?
התצורות נמצאות במערכת בקרת גרסאות: חזרה לאחור היא החזרת סט הכללים הקודם, ולא עריכה תחת עומס. הרכב השינוי מתקבעים מראש, כדי שהתקרית תיחקר לפי העובדות.
נדון במשימה: נבנה סכימת הפרדה בין סביבות
כדי לחזור עם תוכנית עבודה והערכה, ולא עם מחשבות כלליות, אנו זקוקים למבט על האשכול שלכם: כמה סביבות, מי פונה אליהן, היכן גבולות הגישה כבר מטושטשים. תארו את המשימה בטקסט חופשי — את הפרטים נחדד במהלך השיחה.
- מה יש כיום. אילו מרחבי שמות הוכרזו, כיצד הצוותים מחולקים בין סביבות ומה מחזיק היום את ההפרדה — כללי רשת, מכסות או הסכמה בעל פה.
- היכן כואב. מקרים שבהם עריכות בסביבת הבדיקה פגעו בסביבת הפרודקשן, משאבים של סטנד אחד אכלו את מלאי הצמתים, או דיבוג של מישהו אחר שינה נתונים של שכנים.
- דרישות להפרדה. מי חייב לתקשר עם מי, איזו תעבורה מותרת רק לפי כלל מפורש, למי מספיקה גישה לקריאה בלבד.
- מדיניות רשת ומכסות. סט כללי בידוד התחלתי, מגבלות צריכה לפי סביבות והתנהגות האשכול בחריגה מהן — מה יקרה לבנייה או לפריסה.
- תוכנית עבודה והערכה. רצף השינויים, הרכב העבודה, תפקידים בצד שלנו, מה יידרש מהצוות שלכם ואילו חלונות לתאם.
- חזרה לאחור וקבלה. כיצד להחזיר את התצורה הקודמת אם כלל חדש יחסום תעבורה פעילה, ולפי אילו בדיקות נחשב את המשימה לסגורה.
תארו את המשימה בצורה חופשית — נחזור עם תוכנית עבודה והערכה. כקבלן תשתיות אנו אחראים לפעילות השירותים לאחר השינויים, ולא לסט פורמלי של תצורות במאגר.