הגדרת Selectel MKS: Terraform, סקיילינג אוטומטי, GitOps

Selectel Managed Kubernetes: היכן נקרעת התשתית

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

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

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

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

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

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

מה נותן קלאסטר מנוהל בתפעול היומיומי

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

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

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

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

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

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

אפשרויות פריסה: צמתים מנוהלים או צמתים משלכם

בחירת הסכמה ב-Selectel Managed Kubernetes היא לא ויכוח «ענן או שרתים משלכם», אלא שלוש חלוקות אחריות שונות. ממנה תלוי מי מוביל עדכוני צמתים, איך מאגר מתרחב לפי עומס, ובאיזו עומק אפשר להשפיע על שיבוץ פודים.

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

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

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

סדר ההטמעה: מאודיט ועד מסירה לתמיכה

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

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

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

3. פריסה. את הקלאסטר והמאגרים מתארים ב-Terraform, את המניפסטים של השירותים מחזיקים במאגר Git ופורסים דרך GitOps. אוטוסקיילינג מפעילים מיד — גם ברמת הצמתים וגם ברמת הפודים, עם תגובה שונה לגידול הדרגתי ולפרץ חד.

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

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

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

מה נשאר במאגר ובתיעוד

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

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

מקרה בוחן: העברת שירות עמוס בלי השבתה

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

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

מה השתנה במטריקות

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

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

Kubernetes במו ידיכם או שירות מנוהל

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

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

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

ספקות טכניים לפני תחילת העבודה

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

איך עוברים עדכוני הפלטפורמה?

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

איך מחלקים הרשאות ואיפה נשמרים הסודות?

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

מה אם עדכון לא הצליח?

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

איך סוגרים עומס לא אחיד?

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

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

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

כדי לדון במשימה באופן ענייני, שלחו:

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית הטמעה.