Managed Kubernetes של VK Cloud: היכן נקרע הקלאסטר
Managed Kubernetes של VK Cloud מכסה עבור הצוות את ה-control plane, אבל הקלאסטר עצמו נשאר אזור של עבודה ידנית. צמתים מתווספים דרך הפאנל לפי בקשה מהמפתחים, מאגרי pools חיים עם סוגי מכונות ותוויות מגוונים, וה-autoscaling מופעל באופן פורמלי.
כעבור כמה חודשים כבר אף אחד לא מעז להסביר למה עומס מסוים מוצמד דווקא ל-pool הזה ומה יקרה אם יסירו אותו.
במקביל, הקונפיגורציות מתפשטות: חלק מהשינויים עוברים דרך Helm, חלק — על ידי עריכת מניפסטים ישירות, וחלק — ידנית בפאנל. מצב הקלאסטר מפסיק להתאים לריפוזיטורי, וחזרה לריליס קודם הופכת לפעולה נפרדת עם תוצאה לא ברורה. הגדרת הקלאסטר מאבדת יכולת שחזור: הקמת סביבה חדשה אורכת יותר מאשר תיקון סביבה פעילה.
צוואר בקבוק נפרד בתשתית — ההתנהגות בזמן כשל של אזור ובזמן עדכון גרסה. אם לא הוגדרו כללים לפיזור פודים בין אזורים ולפינוי מתוכנן, בזמן תקלה העומס לא עובר אלא ממתין להתערבות ידנית של התורן.
העדכון מתבצע בלי תרגול צמתים, הגרסאות מתפצלות, חלק מהרכיבים המערכתיים לא עולים — והריליס נדחה למועד לא ידוע.
המחיר של מצב כזה צפוי: ריליסים ממתינים לחלון, התורן מכבה אותם אינצידנטים שוב ושוב, וכל שינוי נדון בחשש מהתקלה הקודמת. אנחנו סוקרים איך זה נסגר.
מה משתנה אחרי המעבר לקלאסטר מנוהל
קלאסטר מנוהל VK Cloud לוקח על עצמו את רכיבי הניהול: עדכונים, תעודות, זמינות של צמתי שירות. בצד שלנו נשארים עומסי העבודה, המדיניות וה-Observability — ובדיוק כאן מופיעים שינויים מדידים.
מהירות הפריסה והחזרה של ריליסים
הריליס מתבצע באסטרטגיית עדכון מדורג עם readiness probes: התעבורה מוסרת מה-pod הישן רק אחרי שהחדש מוכן לקבל בקשות, ולכן הפריסה לא הופכת לחלון של השבתה.
הפרמטרים maxSurge ו-maxUnavailable מגבילים כמה רפליקות מוחזקות מעבר לנורמה וכמה אפשר להוציא זמנית — העדכון מסתיים בדקות גם תחת עומס. החזרה מסתכמת בחזרה לרוויזיה הקודמת של ה-deployment, ולא בהרכבה מחדש של הסביבה ביד; את הפרקטיקה אנחנו מצליבים עם תיאור מחזור החיים של pod.
עמידות בתקלות וזמן התאוששות
הצמתים מפוזרים בין אזורי זמינות, וקבוצות צמתים מתכווננות אוטומטית לפי בקשת המשאבים בפועל: pod שלא נמצא לו מקום לא ממתין למהנדס.
PodDisruptionBudget לא נותן לעבודות מתוכננות להפיל את השירות כולו, ובזמן כשל צומת המתזמן יוצר מחדש את העומס על צמתים חיים — ההתאוששות אורכת דקות במקום שעות של טיפול ידני.
נעלם סוג הכשלים של «נגמרו המשאבים באזור» ו«שכחו להעלות node», וחלק הפעולות הידניות בתחזוקה יורד לפעולות בודדות.
מצבי פריסה: מנוהל, צמתים משלך, היברידי
הפלטפורמה מציעה שלוש סכמות פריסה, והבחירה ביניהן היא לא «טוב יותר או פחות», אלא כמה שליטה הצוות שלך באמת צריך.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מנוהל לחלוטין | אין צוות תפעול משלך, צריך סביבות מהירות | גרסאות, רשת ועדכונים של לוח הבקרה נקבעים על ידי הספק |
| לוח בקרה מנוהל, צמתים משלך | מכונות לא סטנדרטיות, אימג'ים משלך, דרישות מיקום מחמירות | צמתים, העדכון והסקיילינג שלהם — בצד שלך |
| סכמה היברידית | הנתונים חייבים להישאר בקונטור שלך או שכבר יש ציוד משלך | רשת וניתוב בין קונטורים מורכבים יותר, הרשאות מטופלות בנפרד |
היכן עובר גבול האחריות מול הספק
הספק אחראי ללוח הבקרה: הזמינות שלו, עדכונים, תעודות, אחסון מצב הקלאסטר. כל מה שמעל — צמתי עבודה, מדיניות רשת, תפקידי גישה, איזון עומסים, כרכים והאפליקציות עצמן — נשאר על הצוות שלך, גם אם הצמתים גם הם מנוהלים.
האחריות מכסה את לוח הבקרה, לא את השירות שלך, ולכן התראות ו-Observability על האפליקציות מתוכננים כאזור שלך מההתחלה.
מתי הסכמה ההיברידית מוצדקת
היברידי מוצדק כשיש דרישה להחזיק נתונים בקונטור שלך, כשהציוד כבר נרכש וצריך לעבוד, או כשהשירותים רגישים להשהיה לאתר מסוים. אם הסיבה היא רק «רוצים שליטה מלאה», הסכמה לא משתלמת: מספר נקודות הכשל עולה, העדכונים וטיפול בתקלות נעשים מורכבים יותר.
סדר היישום: מהביקורת ועד העברה לתמיכה
את סדר העבודה בונים כך שכל שלב יניב תוצאה ניתנת לבדיקה, ולא סטטוס «בתהליך». להלן — איך נראה יישום של קלאסטר Managed Kubernetes מהשיחה הראשונה ועד לרגע שבו הוא עובד בלי מעורבות שלנו.
איך עוברת הביקורת ומה נכנס לסכמה
ביקורת התשתית מתחילה באיסוף עובדות: אילו שירותים כבר פעילים, איך הם קשורים זה לזה, היכן נקודות הכשל ואיזה מרווח משאבים נדרש בשיא. בסיום — סכמת קלאסטר עם מספר צמתים, סימון סביבות וגבולות של מדיניות רשת: מה נגיש למי ולמה דווקא כך.
- ביקורת של הקונטור הנוכחי — מיפוי שירותים, תלויות ופרופיל עומס.
- סכמה וחישוב משאבים — טופולוגיית קלאסטר, מאגרי צמתים, מגבלות, autoscaling.
- סימון סביבות — סביבות נפרדות לפיתוח, בדיקות ותפעול, בידוד של מרחבי שמות, תפקידי גישה.
- רשת ומדיניות — סגמנטציה, כללים לתעבורה נכנסת ויוצאת, אחסון סודות.
- בדיקת כשל — הוצאה מבוקרת של צמתים ואזורים מכלל פעולה.
- העברה לתמיכה — נהלים, ניטור, הדרכת הצוות שלך.
בדיקת כשל לפני מסירה
קלאסטר נחשב מוכן רק אחרי שהוא עבר אובדן של צומת או אזור בלי התערבות ידנית. אנחנו מכבים רכיבים בכוונה, בוחנים איך העומס מתפזר מחדש, ורושמים את זמן ההתאוששות. תוצאות הבדיקה יחד עם הוראות התפעול עוברות לצוות שלך.
מה מועבר לידיים אחרי מסירת הקלאסטר
מסירת קלאסטר ב-VK Cloud היא לא גישה ללוח הבקרה, אלא סט ארטיפקטים שלפיהם הצוות שלך ממשיך לעבוד בעצמו.
- סכמת סביבות: קונטורים נפרדים לפיתוח, קדם-ייצור ועומס ייצורי — עם מרחבי שמות, מכסות ומגבלות משלהם.
- מניפסטים וקונפיגורציות במאגר git: מקור אמת אחיד, שינויים עוברים רוויו, מצב הקלאסטר משוחזר מאפס.
- רישום אימג'ים עם מדיניות אחסון: בנייה טרייה נשארת זמינה לחזרה, ישנה מנוקה אוטומטית, נפח האחסון לא גדל.
- ניטור והתראות: צמתים, פודים ושירותים מרכזיים תחת מעקב, לכל סף מוגדר מסלול התראה עד למהנדס תורן.
- תיעוד הקלאסטר: סכמת רשת, נקודות כשל, אנשי קשר אחראים והוראה לתורן במקרה של אי-זמינות צומת.
מדיניות גישה ותפקידי צוותים
הרשאות ניתנות לפי עקרון המינימום הנדרש: למפתחים אין גישה לקונטור הייצורי, חשבונות שירות מופרדים מחשבונות אנושיים. כל הפעולות נרשמות ביומן ביקורת, והתפקידים מתוארים כך שניתן לחבר מהנדס חדש בערב אחד, בלי לבנות הרשאות מחדש מאפס.
נהלי עדכונים וגיבויים
מוגדרים חלון עדכונים, סדר פריסה ותוכנית חזרה לגרסת הצמתים הקודמת. הגיבויים מבוצעים לפי לוח זמנים — בנפרד קונפיגורציית הקלאסטר ונתוני הכרכים; פעם ברבעון אנחנו בודקים שחזור בקונטור בדיקות, ולא מסתמכים רק על עצם קיומם של גיבויים.
מקרה בוחן: מיגרציה של שירות לקלאסטר מנוהל
שירות עם שיא תעבורה יומי חי על שלוש מכונות וירטואליות שהורכבו ידנית: עדכון גרסה הפך לפעולת לילה של עשרה שלבים, וכשל צומת означал העברה ידנית והתאוששות במשך כמה שעות.
המיגרציה לקלאסטר מנוהל VK Cloud החלה לא בהעברה, אלא במיפוי: תיארנו תלויות, הפרדנו בין מצב לאפליקציה, כדי שהנתונים לא יעברו יחד עם הקונטיינרים.
מה שינינו
את הפריסה העברנו למניפסטים דקלרטיביים: מה שקודם נעשה ביד לפי צ'ק-ליסט, עכשיו מיושם בפקודה אחת — מספר הפעולות הידניות ירד מעשרה לאחת. העדכונים מתבצעים עם החלפה הדרגתית של מופעים ובדיקת מוכנות, ולכן חלק ההשבתה בריליס ירד לאפס במקום חלון לילה.
העמידות בתקלות חדלה להיות עבודה ידנית: צומת שנפל מוחלף אוטומטית, המופעים עוברים לצמתים חיים, זמן ההתאוששות ירד משעות לדקות. תחת עומס שיא הפעלנו autoscaling לפי עומס ואורך התור — הקלאסטר מוסיף יכולות לפני שהתור גדל, ולא אחרי נפילה.
מה התוצאה
לסיכום כמה חודשים: ריליסים מדי יום במקום פעם בשבוע, אי-זמינות בעדכונים — אפס, בשיא פי שלושה מהקודם השירות מחזיק בזמן תגובה יעד. ניתוח של מקרה המיגרציה הזה עם מדדים לפני ואחרי פרסמנו בנפרד — עם סכמת הקלאסטר ומדיניות העדכונים.
במה קלאסטר מנוהל שונה מקלאסטר עצמאי על שרתים משלך?
בקלאסטר עצמאי על שרתים משלך כל האחריות מוטלת על הצוות שלך: לפרוס את שכבת הניהול, להבטיח את עמידותה בתקלות, לעקוב אחרי תעודות, לעדכן את אחסון המצב, לתקן את הרשת בין הצמתים. הספק כאן אחראי רק על המכונות והערוץ. כל כשל של שכבת הניהול — אינצידנט של המשמרת התורנית שלך.
בקלאסטר מנוהל הגבול עובר אחרת. לוח הבקרה — שכבת הניהול, הסקיילינג שלו, גיבויי מצב, תעודות והחלפת גרסה — מכוסים על ידי הספק. לך נשארים צמתי העבודה ומה שרץ עליהם.
צמתים — כבר האזור שלך. את הגודל שלהם, הקבוצות, חלונות התחזוקה ומדיניות העדכון בוחר הצוות, והספק נותן את המנגנון: צומת מוצא אחד אחד, העומס עובר. אבל כדי שעדכון צמתים לא יהפוך להשבתה, צריך בדיקות מוכנות ותקציב הפרעות — אותם מגדיר אתה, לא הספק.
מכאן מתחיל מה שלא מואצל לאף אחד: הרשאות וסודות, מדיניות רשת בין שירותים, מגבלות משאבים, איסוף לוגים ומטריקות של אפליקציות. הספק לא מכיר את תחום המומחיות שלך, ולכן את השכבות האלה מתכננת ומתחזקת הצוות.
הבחירה מצטמצמת לשאלה היכן הצוות יוצר יותר ערך. אם הוא חזק יותר בפלטפורמה מאשר במוצר, קלאסטר עצמאי נותן שליטה מלאה על גרסאות והגדרות רשת. אם הערך במוצר — קונטור מנוהל ב-VK Cloud מסיר את התחזוקה של שכבת הניהול, ומשאיר לך את ארכיטקטורת העומס ואת ה-Observability של האפליקציות.
ספקות טכניים לפני תחילת העבודה
ב-Managed Kubernetes של VK Cloud חלק מהמשימות סוגר הספק, אבל המהנדסים של הלקוח עדיין שואלים את אותן שאלות: מה עם העומס ברגע המיתוג, מי אחראי לעדכונים, איך הקונטור ישרוד אובדן אזור. להלן — תשובות קצרות לחמש מהן.
איך מעבירים עומס בלי השבתה?
מקימים קונטור יעד לצד הקיים, פורסים שירותים ובודקים אותם על חלק מהתעבורה. מסלולי ה-load balancer מוחלפים בהדרגה, הקונטור הישן נשאר חי עד סוף ההעברה — החזרת מסלול אורכת שניות.
מי אחראי לעדכוני גרסאות?
את חלק הניהול מעדכן הספק בחלונות מוסכמים, ואת העובדים — אנחנו: בגלים לפי קבוצות צמתים, עם פינוי פודים והתחשבות בתקציבי הפרעות. שומרים על ענף מעודכן וגרסת מינור קודמת.
מה יקרה בזמן כשל של אזור זמינות?
הצמתים מפוזרים בין אזורים לפי כללי מיקום, ולכן פודים מהאזור שאבד מתוזמנים מחדש באזורים ששרדו. עבור שירותים עם דיסקים, רפליקות ממוקמות באזורים שונים מראש — אחרת הכרך נשאר לא זמין יחד עם האזור.
איך הקונטור מתכוונן לגדילת עומס?
פודים מתכווננים לפי מטריקות, צמתים מתווספים אוטומטית כשחסרה קיבולת. התנאי — בקשות ומגבלות משאבים נכונות, אחרת המתזמן לא יראה את הצריכה האמיתית; בודקים זאת בהרצת עומס לפני ההפעלה.
איך מופרדים תפקידים והרשאות?
מרחבי שמות לפי צוותים וסביבות, תפקידים עם ההרשאות המינימליות הנדרשות, פרטי התחברות נפרדים לאדם ולמערכות שירות, יומן ביקורת של פעולות בקלאסטר. הרשאות ניתנות לזמן מוגבל, לא «ליתר ביטחון».
נדון במשימה: מה מבררים לפני תחילת העבודה
הערכת העברת שירותים ל-Managed Kubernetes ב-VK Cloud לא מחושבת לפי תבנית: עומק העבודה תלוי במספר השירותים, ביחסם למצב ובזמני ההשבתה המותרים. לכן לפני ההתחלה אנחנו מפרקים את הנתונים — מהם נבנה תוכנית יישום עם שלבים, אחראים וקריטריון מוכנות בכל שלב.
מה נדרש ממך כדי לחזור עם הערכה ותוכנית:
- פרופיל עומס: כמה שירותים, אילו שומרים מצב, איך התעבורה מתנהגת בשיאים יומיים ושבועיים.
- דרישות זמינות: זמן השבתה מותר, האם נדרשת עמידות בתקלות ברמת אזורים, אילו חלונות תחזוקה מקובלים.
- קונטור נוכחי: מה כבר עובד — מכונות וירטואליות, קווי בנייה, ניטור, אחסון סודות וקונפיגורציות.
- מגבלות אבטחה: מדיניות רשת, הפרדת הרשאות בין צוותים, דרישות לביקורת פעולות ואחסון יומנים.
- לוחות זמנים למעבר: תאריכים קשיחים, שירותים שאסור לעצור, וסדר הוצאה של סביבות ישנות משימוש.
- אינטגרציות: רישום אימג'ים, מאזני עומסים, DNS, תורים, בסיסי נתונים חיצוניים ותלויות בצוותים משיקים.
לפי הנתונים האלה אנחנו מקבעים את רצף ההעברה, נקודות החזרה ואת האופן שבו העומס מוחלף בלי לאבד בקשות. תאר את המשימה — נחזור עם הערכה ותוכנית עבודה.