Kubernetes מנוהל ב-Selectel: Terraform, Ingress, StorageClass

Kubernetes מנוהל ב-Selectel: היכן התשתית נשברת

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

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

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

שחזור לאחר תקלה בלי חזרה גנרלית — זה הימור. עותק מצב האשכול לא נבדק, StorageClass עם מדיניות מחיקת volume נושא את הנתונים יחד עם ה-PVC, ואת סדר העלאת השירותים התלויים לא תיעד אף אחד. אז זמן ההשבתה נמדד לא בשעות של עבודה מתוכננת, אלא ביממות של ניסויים.

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

האפקט של אשכול ייעודי: מה משתנה בתפעול

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

• פריסת סביבה — מימים לעשרות דקות. תיאור התשתית כקוד נותן סביבות זהות לפיתוח, לבדיקות ולסביבת הייצור: אתר חדש עולה עם אותה תצורה שכבר נבדקה, והפערים בין הסביבות מפסיקים להיות משימה נפרדת.
• שחזור השירות — לפי נוהל, ולא לפי הזיכרון. צמתים נוצרים מחדש אוטומטית, העומס מתחלק מחדש בין הנותרים, ומצב האחסון מתואר באמצעות מחלקת אחסון. זמן ההשבתה של השירות נמדד בדקות ואינו תלוי במי מהמהנדסים נמצא בכוננות.
• שיעור הפעולות הידניות יורד. עדכון גרסאות, שינוי גודל, הנפקת תעודות וניתוב תעבורה מבוצעים באופן דקלרטיבי: תיקון בתיאור התשתית מיושם על האשכול כולו, בלי להיכנס למכונות בודדות.
• סוג התקלות «תיקנו ידנית ושכחנו» נעלם. התצורה מפסיקה להתקיים רק בראשים של המנהלים; כל סטייה נראית בהחלה הבאה של התיאור, ואז או שהיא מתבטלת או שהיא מוכנסת إليه במודע.

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

מצבי הפעולה של אשכול מנוהל: השוואת אפשרויות

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

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

להלן ארבעה מצבים שביניהם באמת בוחרים ב-Kubernetes מנוהל.

מה נשאר משותף בכל מצב

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

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

כיצד מתבצעת ההטמעה: שלבי עבודות ההנדסה

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

סדר העבודות

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

מה נשאר אצל הלקוח: תצורות, סכמות, נהלים

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

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

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

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

מה היה לפני המעבר

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

מה שינינו

את התשתית העברנו לתיאור דקלרטיבי: Terraform יוצר את האשכול, מאגרי הצמתים והרשת, Ingress חי כעצם נפרד, ו-StorageClass עם מדיניות שימור קשור ל-volumes של בסיסי הנתונים.

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

מדדים לפני ואחרי

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

במה תיאור התשתית כקוד עדיף על הגדרה ידנית

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

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

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

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

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

התלבטויות טכניות: הרשאות גישה, אחסון, עדכונים

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

איזו מחלקת אחסון לבחור לבסיסי נתונים וללוגים?

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

האם העדכונים מתבצעים בלי השבתה?

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

מה עם גיבוי ושחזור?

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

נדבר על המשימה: ממה מתחילה העבודה

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

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

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

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