הגדרת GKE: אשכול מוכן לפרודקשן ב-GCP

הגדרת GKE ב-GCP: מה נשבר כשהעומס גדל

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

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

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

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

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

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

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

מה משתנה לאחר העברת העומס לאשכול מנוהל

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

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

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

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

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

השוואה בין מודלי העבודה של אשכול GKE

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

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

שלבי העבודה: מסיור שטח ועד מסירה לתפעול

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

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

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

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

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

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

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

התוצרים הנמסרים: סכימות, מדיניות, נהלים

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

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

מקרה בוחן: כיצד קיצרנו השבתות וזמן פריסת מהדורות

מתאר המוצר חי על מכונות וירטואליות שנבנו ידנית: התצורות סטו זו מזו בין הסביבות, וההתאוששות לאחר תקלה הייתה תלויה במי מהמהנדסים נמצא בקשר. המתאר נפל 3–4 פעמים בשבוע, ההתאוששות ארכה בין 40 ל-90 דקות, ומהדורה יצאה אחת לשבועיים-שלושה ורק בחלון מוסכם.

מה שינינו

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

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

מה היה לתוצאה

הפעלות מחדש בחירום ירדו מ-3–4 בשבוע למקרה אחד ברבעון, וההתאוששות — מ-40–90 דקות ל-6 דקות: הפוד נוצר מחדש לפי תיאור הצהרתי, ולא מתוקן ידנית. מחזור המהדורות הואץ לשניים-שלושה פרסומים בשבוע, ושיעור הפרסומים שדרשו חזרה אחורה ירד מחלק חמישי למקרים בודדים.

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

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

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

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

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

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

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

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

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

כיצד להפריד את הגישה של הצוותים בתוך האשכול?

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

מי אחראי לאשכול לאחר המסירה?

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

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

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

מה ייכלל בנתוני הבסיס:

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

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