מדוע Kubernetes מנוהל ב-Azure נופל תחת עומס
Kubernetes מנוהל ב-Azure מסיר מהצוות את תחזוקת מישור הבקרה, אבל לא את פיזור העומס: המתזמן, המגבלות וכללי הסקאלינג נשארים בצד הצוות. הידרדרות האשכול לעיתים רחוקות נראית כמו כשל — זה גידול איטי בהשהיות, שמבחינים בו רק לפי תלונות.
התרחיש הראשון — חוסר איזון בפיזור. פודים מתקבצים על שניים-שלושה צמתים, והשאר עומדים ללא שימוש: בקשות המשאבים מוגדרות נמוך מהצריכה בפועל, המתזמן מחשיב את הצמתים כפנויים, וכללי המיקום לפי אזורים לא הוגדרו. בשיא, הצמתים החמים מגיעים למחסור, בעוד מחצית מהקבוצה אינה מנוצלת.
הסיבה השנייה — מגבלות משאבים שהוגדרו 'על העין'. מגבלה נמוכה מדי גורמת לאתחולים של מכולות בגלל זיכרון, גבוהה מדי לא מאפשרת לצומת להתהדק ומחזיקה רזרבה שלעולם אינה מנוצלת. כל עוד בקשות המשאבים לא מכוילות לפי פרופיל אמיתי, החלטות סקאלינג מתקבלות לפי נתונים מעוותים.
השלישית — היעדר סקאלינג אוטומטי של צמתים. רפליקות של פודים מתווספות, אבל קבוצת הצמתים לא גדלה, פודים חדשים נשארים בהמתנה, וכל התעבורה עוברת למופעים עמוסים מדי. הטעות ההפוכה — הספים מופעלים אחרי השיא, וצמתים מופיעים כשהאשכול כבר בהידרדרות.
לבסוף, כשלים 'שקטים': אתחולים של מכולות וגידול בהשהיות לא צפים בהתראות, כי מדדים נאספים, אבל אין להם ספים. אנו מפרטים איך זה נסגר: מפיזור עומס וכיול מגבלות ועד אותות שמתריעים על הידרדרות מבעוד מועד.
מה משתנה בעבודת השירותים לאחר הגדרת האשכול
לאחר הגדרת Kubernetes מנוהל ב-Azure, את השינויים רואים לא לפי תרשימים, אלא לפי ארבעה מדדים שנאספים מהאשכול עצמו: זמן תגובה בשיא, שיעור הפצות מוצלחות, זמן שחזור השירות לאחר כשל של צומת ומספר תקריות בגלל עריכות ידניות.
זמן התגובה תחת עומס מפסיק להיות תלוי במי שתורן. קיבולת מתווספת לפי מדדי צריכה, ולא לפי שיחה, לכן השיא נפתר בהרחבה סטנדרטית ותור הבקשות לא גדל. רזרבת המשאבים נקבעת במדיניות — השירות שומר על זמן תגובה רגיל גם ברקע יומיומי וגם ברגע מבצע.
עדכון ללא השבתה נשען על הפצה בחלקים עם בדיקת מוכנות של כל עותק חדש: תעבורה עוברת רק למופעים שהגיבו, ולא מוכנים מוצאים מאיזון העומסים. אם הבדיקות לא עברו, ההפצה נעצרת בעצמה, והגרסה חוזרת לקודמת.
שיעור ההפצות המוצלחות עולה לא потому, שהשחרורים נעשו פשוטים יותר, אלא потому, ששחרור שגוי כבר לא מגיע לכולם בבת אחת.
עמידות האשכול לתקלות פועלת ברמה אחרת: עם אובדן צומת, העומס שלו מתוכנן מחדש על צמתים פנויים, ולא ממתין למהנדס. זמן שחזור השירות נמדד בדקות ואינו תלוי בשעה ביממה — התרחיש מתואר מראש ונבדק בתרגילים.
נעלם גם סוג שלם של כשלים בגלל עריכות ידניות: התצורה מתוארת בקבצים, שינויים עוברים בדיקה, ופערים בין המצב בפועל למתואר מוחזרים אוטומטית.
דרכים לארגון האשכול והמגבלות הטכניות שלהן
הבחירה מצטמצמת לשתי שאלות: למי שייך מישור הבקרה ועל אילו מכונות רצים צמתי העבודה. אשכול מנוהל לחלוטין מוסר את הפאנל לספק — עדכונים, עמידות לתקלות ותעודות באזורו, ואתם נשארים עם מאגרי צמתים, מניפסטים ואפליקציות. היברידי משאיר את הפאנל מנוהל, אבל ממקם את הצמתים על ציוד שלכם: במתחם סגור, בענן אחר או בארון שרתים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אשכול מנוהל לחלוטין | יש צורך בהתחלה מהירה ומינימום תפעול, העומס נכנס לענן של הספק | אין גישה לצמתי מישור הבקרה, חלק מתוספי הרשת ומצבים מורשים אינם זמינים |
| היברידי: פאנל מנוהל וצמתי עבודה משלכם | הנתונים חייבים להישאר במתחם שלכם, אבל אין משאבים לתחזק את הפאנל | יש צורך בערוצים מאובטחים לפאנל, סוכני איסוף מדדים ולוגים משלכם, סדר עדכון נפרד לצמתים |
| אשכול על מכונות שלכם | דרישות נוקשות לבידוד או לציוד, יש צוות תפעול | פאנל, אחסון מצב, תעודות ועדכונים — באחריותכם המלאה |
חשוב להכיר מראש את המגבלות של האפשרות המנוהלת: אי אפשר לשנות פרמטרים של שרת API, להתקין תוספים שרירותיים על מישור הבקרה ולסמוך על גישה ללוגים שלו. כל מה שדורש הרשאות על הצמתים או תרשים רשת מיוחד מועבר למאגרים משלכם או נסגר בהיברידי.
בפועל, לרוב דווקא התצורה ההיברידית מנצחת: פאנל מנוהל מסיר את עיקר התפעול, וצמתים משלכם סוגרים את דרישות הנתונים והציוד. אנו מתאימים את האפשרות למגבלות של מתחם מסוים ומקבעים מה בדיוק נשאר באזור האחריות של הצוות שלכם.
שלבי יישום: מביקורת ועד מסירה לייצור
יישום אשכול אינו התקנה חד-פעמית, אלא רצף שבו כל שלב נשען על הקודם. טעות בתכנון רשתות או הרשאות גישה צפה לאחר חודשים, כשהתיקון שלה הוא היקר ביותר. להלן שבעה שלבים שלפיהם מתבצעת העבודה.
- ביקורת תשתית. מפרקים את השירותים הנוכחיים, פרופיל העומס, השיאים, התלויות והדרישות לבידוד נתונים. בתוצאה — מפה: מה מעבירים לאשכול, ומה הגיוני להשאיר כפי שהוא.
- תכנון התרשים. מפרשים עומסים לפי מאגרי צמתים, מגדירים כללי סקאלינג אוטומטי, גבולות רשת, תרשים הנפקת תעודות והפרדת הרשאות.
- הכנת סביבות. יוצרים מתחמים נפרדים לבדיקות ולייצור, מחברים מאגר תמונות, אחסון סודות, איסוף מדדים ולוגים.
- הגדרת האשכול. מקימים Kubernetes מנוהל, מפעילים עדכונים אוטומטיים וגיבוי מצב, בודקים שכשל של צומת בודד אינו מורגש בשירותים.
- בדיקת עומס. מריצים פרופיל תעבורה אמיתי, בוחנים את התנהגות הסקאלינג האוטומטי בשיא, ומוציאים צומת מכלל פעולה בכוונה — המעבר צריך לעבור בלי בקשות אבודות.
- נהלים והרשאות. מקבעים מדיניות גישה, סבב סודות, מגבלות משאבים, סדר עדכונים ותוכנית פעולה במקרה תקלה עם אחראים בכל צד.
- מסירה לייצור. מלמדים את הצוות שלכם להפיץ עדכון ולבצע חזרה לאחור, לקרוא מדדים והתראות, לנתח כשלים אופייניים. תצורות, הרשאות ותיעוד נשארים אצלכם.
מה נשאר אצלכם: תצורות, תרשימים, נהלי גישה
האשכול נמסר לא "פעיל", אלא מתואר: כל רכיב משוחזר ממאגר, ואת ההחלטה אפשר לנמק בפני אבטחת מידע. להלן חפצים שנשארים במתחם שלכם ומאפשרים להפעיל את הפלטפורמה בלעדינו.
- תיאורים דקלרטיביים של תצורה: מניפסטים של האשכול, מאגרי צמתים ותוספי רשת במערכת בקרת גרסאות — עם היסטוריית שינויים וחזרה למצב קודם.
- תרשים רשת: מרחבי כתובות ורשתות משנה, ניתוב לרשת הארגונית, נקודות פרסום שירותים, גישה סגורה לצמתים.
- מדיניות גישה: תפקידים והקשרים שלהם, חיבור לספריית חשבונות ארגונית, הפרדת הרשאות בין פיתוח לתפעול, כללי גישה לסודות.
- נוהל עדכון: סדר עדכון גרסאות הפלטפורמה והצמתים, חלונות, בדיקת תאימות מקדימה של עומסי עבודה, תוכנית חזרה למצב קודם.
- נוהל שחזור: הרכב גיבויים, תדירות, זמן השבתה מותר ונקודת שחזור, פרוטוקול שחזור תרגולי — גיבוי נחשב שמיש רק לאחר בדיקה.
- מתחם ניטור: רשימת מדדים ולוגים, ספי התראות, נתיבי הודעות, הרכב משמרת תורנית.
- הוראות לפעולות אופייניות: חיבור שירות, הנפקת הרשאות, סקאלינג של מאגר צמתים, אבחון כשלים שכיחים — עם פקודות ותוצאה צפויה.
תרשימים משווים למצב בפועל בעת הקבלה: פערים מסלקים לפני החתימה, כדי שהתיעוד לא יתפצל מהאשכול מהיום הראשון.
מקרה בוחן: קיצרנו את זמן השחזור והסרנו את ההידרדרות
מה היה לפני
הלקוח — שירות עם שיא עומס מובהק: כמה שעות ביממה התעבורה עלתה פי כמה, בשאר הזמן המערכת שקטה.
האשכול רץ על שירות מנוהל Azure Kubernetes Service, אבל התפעול נשען על צעדים ידניים: ההפצה הופעלה מהטרמינל של המהנדס, מספר הצמתים כוונן מראש לשיא ובאופן אקראי, והחזרה לגרסה קודמת הייתה קיימת רק על הנייר ומעולם לא נבדקה במתחם חי. בעת כשל של צומת, השחזור נמשך עשרות דקות, בעוד התורן גילה מה בדיוק נפל.
מה שינינו
תיאור התשתית הועבר למאגר — מניפסטים וצ'ארטים הפכו לנקודת אמת יחידה. ההפצה הפכה לשלב בצינור עם בדיקת מצב הפודים לאחר כל שלב וחזרה לאחור אוטומטית, אם הבנייה לא עוברת בדיקות מוכנות.
הוספנו סקאלינג אוטומטי של צמתים לפי עומס, מגבלות משאבים לכל שירות ומדיניות רשת, כדי ששירות אחד לא יאכל את משאבי האשכול. הגדרנו גיבויים של המצב, ואחת לרבעון מריצים שחזור על עותק של המתחם.
מה נהיה
זמן השחזור לאחר כשל של צומת הצטמצם מארבעים דקות לחמש — הפודים עוברים אוטומטית. פעולות ידניות בהפצה הצטמצמו משתים עשרה לאחת, וגם היא מסתכמת באישור השחרור.
בשיא, בקשות כבר לא נקטעות בגלל זמן המתנה: צמתים מתווספים תוך דקה, ולא מחזיקים קיבולת עם מרווח 'על העין', לכן צריכת המשאבים הפסיקה לגדול יחד עם השיא.
מה לעשות אם אשכול Kubernetes כבר פרוס ידנית
אין צורך להרוס אשכול שהוקם ידנית — תחילה אנו מתארים את מצבו בפועל: היכן רצים עומסי העבודה, אילו אובייקטים נערכים ידנית, מה חי רק בסקריפטים ובזיכרון של המהנדסים. בלי מלאי כזה, מיגרציה של האשכול הופכת להעברה של אותן בעיות לפלטפורמה חדשה.
תצורה מורשת בדרך כלל מכילה גם ערך אמיתי — כמה התאמות לא סטנדרטיות למשימה אמיתית — וגם עשרה סטיות מהתרשים האופייני, שנמשכות שנים.
כל סטייה מקבלת החלטה מפורשת: מעבירים כמו שהיא, מביאים לצורה אופיינית או מוותרים עליה כמיושנת. חלק מהתוספים העצמיים מכוסים באמצעים הסטנדרטיים של המתחם המנוהל, חלק נשאר שכבה נפרדת מעליו עם בעלים ברור. כך המעבר לאשכול מנוהל לא מאבד את העבודה שנעשתה ובמקביל מסיר מהצוות את התחזוקה הידנית.
המתחם החדש מוקם במקביל ואינו מפריע לישן. עומסי העבודה עוברים בקבוצות — לפי שירותים או לפי צוותים, ולא כולם בבת אחת: תחילה אלה שאינם מחזיקים מצב, אחר כך אלה שעובדים עם דיסקים. המעבר מתבצע ברמת נקודת הכניסה: עד שהמתחם החדש מאשר יציבות לפי מדדים, המשקל מוחזר לישן בעריכה אחת.
בנפרד לגבי מצב — כרכים מועברים בשכפול עם בדיקת ביקורת, תורים ומשימות רקע ממתינים לעיבוד, חלון של עומס נמוך נבחר לפי גרף, לא לפי לוח שנה. העברת עומס ללא השבתה נשענת בדיוק על הפיכות: עד השלב הסופי האשכול הישן נשאר פעיל ומסוגל לקבל את העומס בחזרה.
ספקות טכניים נפוצים לפני תחילת העבודה
לפני ההתחלה, צוותי ההנדסה של הלקוח שואלים כמעט את אותו סט שאלות: היכן הגבול בין העבודה שלנו לתפעול שלהם, מתי האשכול מתעדכן ומה יקרה לו בעלייה חדה בעומס. אנו עונים לפני הקומיט הראשון — ב-Azure Kubernetes Service זה מסיר את רוב ההפתעות בעת העלייה לייצור.
גבולות מקבעים במטריצת אחריות. שכבת הניהול, עדכונים, ניטור, מדיניות גישה וגיבוי — אזור שלנו; לוגיקה עסקית, גישות למאגרים ונתונים נשארים אצל הלקוח. זה סוגר את הוויכוח 'מי אשם' כשהתראת תורנות מופעלת בלילה.
איך מתאמים חלונות עדכון?
את לוח הזמנים בונים מהגרף שלכם להפצת גרסאות: שכבת הניהול מתעדכנת בחלון מוסכם, מאגרי העבודה — בגלים, עם הרחבת צמתים לפני הוצאת הישנים מכלל פעולה. בזמן הקפאת שחרורים החלון נדחה, מצב ידני נשאר זמין.
מי אחראי לאבטחת האשכול המנוהל?
את המתחם התשתיתי אנחנו סוגרים: הפרדת תפקידים, מדיניות רשת, בידוד מרחבי שמות, סבב סודות, ביקורת גישה ובדיקת תמונות לפני הפצה. סודות והרשאות בתוך האפליקציות נשארים על צוות הלקוח.
מה יקרה בעלייה בעומס?
סקאלינג אוטומטי של צמתים ופודים מגדירים מראש, יחד עם מכסות מנוי ומאגר ביטחון לשיאים. בהתחלה מריצים פרופיל עומס ורואים היכן האשכול יתקל ראשון — במגבלות או באפליקציה עצמה.
נדון במשימה ונחזור עם הערכה ותוכנית יישום
להתחלה אין צורך בתיעוד מוכן: די בגישה למנוי במצב קריאה, רשימת שירותים שעוברים ל-Kubernetes מנוהל ב-Azure, ודרישות לזמינות — השבתה מותרת, חלון תחזוקה, עומס שיא. מה שלא מעוגן במילים, נשחזר מתצורות ולוגים של המתחם הנוכחי.
הניתוח אורך כמה ימים. בסיומו נחזור עם הערכת הפרויקט ותוכנית יישום, שבה כל עבודה משויכת לשלב ולתוצאה ניתנת לבדיקה.
- תרשים של ארכיטקטורת היעד: מאגרי צמתים לפרופילי עומס שונים, הפרדת מרחבי שמות, מדיניות רשת ותפקידי גישה.
- תוכנית יישום לפי שלבים: הכנת המנוי והרשת, פריסת האשכול, העברת שירותים, הגדרת עדכונים וגיבוי.
- הערכת היקף ולוחות זמנים — לפי שלבים, עם גבול ברור: מה אנחנו עושים, ומה נשאר בצד הלקוח.
- רשימת סיכונים ונקודות חזרה: מה קורה בעדכון צמתים כושל ואיך חוזרים למצב הקודם.
- דרישות להרשאות: איזו רמת הרשאות באשכול ובמנוי מקבל כל אחד מהמהנדסים שלכם.
- נוהל קבלה: אילו בדיקות מאשרות שהאשכול מוכן לקבל עומס עבודה.
בשלב הראשון אנחנו בדרך כלל מעבירים את תצורת האשכול ואת עומס העבודה לתיאורים שאפשר לנהל בגרסאות ולשחזר — בהמשך כל שינוי עובר דרכם, ולא ידנית בקונסולה. הרכב העבודות וההתחלה מקבעים לאחר אישור התוכנית: תארו את המשימה — נחזור עם הערכה, לוחות זמנים וצעד ראשון ברור.