הגדרת Managed Kubernetes ב-Google GKE: מרעיון ועד סביבת ייצור

Managed Kubernetes ב-Google GKE: היכן הקלאסטר נשבר

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

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

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

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

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

מה נותן קלאסטר מנוהל: זמן, עמידות, זמן השבתה

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

מה משתנה בגדלים מדידים

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

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

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

מה נשאר באחריות הצוות

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

אפשרויות פריסה: מנוהל, עצמאי, היברידי

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

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

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

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

שלבי יישום: מביקורת ועד מסירה לתפעול

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

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

מה מקבלים לידיים: קונפיגורציות, סכמות, נהלים

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

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

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

קייס: העברת שירות לקלאסטר מנוהל

שירות של 14 מיקרו־שירותים חי על צי מכונות וירטואליות, שנבנו ידנית ועודכנו לפי נוהל. הוצאת גרסה חדשה ארכה 40–60 דקות והתבצעה רק בחלון לילה, עם מהנדס תורן ליד הקונסול — מחצית מהשינויים נדחו לסוף השבוע. צמתים נפלו 3–4 פעמים בחודש, לרוב בגלל דליפות זיכרון בשירותים שכנים, והשחזור נמשך 1.5–2 שעות.

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

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

במה שונה Kubernetes מנוהל מ-Kubernetes עצמאי?

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

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

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

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

ספקות טכניים נפוצים לפני התחלה

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

איך מפרידים הרשאות בין צוותים?

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

אפשר להעביר קלאסטר פעיל בלי השבתה?

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

מה יקרה עם גידול בתעבורה?

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

נדון במשימה: מהיכן מתחילים ומה נדרש מצדכם

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

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

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