אסטרטגיות לשדרוג צמתים

במאמר הזה נסביר על האסטרטגיות לשדרוג צמתים שאפשר להשתמש בהן באשכולות של Google Kubernetes Engine ‏ (GKE).

באשכולות GKE Standard, אפשר להגדיר אחת מהאסטרטגיות הבאות לשדרוג צמתים לכל מאגר צמתים Standard:

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

‫GKE בוחר באסטרטגיות הבאות לתרחישים הספציפיים האלה:

  • באשכולות Autopilot, ‏GKE משתמש בשדרוגי מתח. מידע נוסף זמין בקטע שדרוגים מהירים במסמך בנושא שדרוגי אשכולות ב-Autopilot.
  • במאגרי צמתים שמנוהלים על ידי Autopilot באשכולות Standard, ‏ GKE משתמש בשדרוגים מצטברים. אי אפשר לבחור שיטה אחרת או לשנות את ההגדרה.
  • בצמתים שמשתמשים ב-Flex-start VM, GKE משתמש בשדרוגים לזמן קצר. התכונה "התחלה גמישה" עם הקצאת משאבים בהמתנה תומכת בדגלים חדשים שהם חלק מהשקת גרסת טרום-ההשקה של "התחלה גמישה". התכונה 'התחלה גמישה' מבוססת על Dynamic Workload Scheduler.

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

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

שדרוגים משבשים למאגרי צמתים שמשתמשים במאיצים ומריצים עומסי עבודה של AI/ML

מכיוון שמופעי Compute Engine עם מאיצים (GPU או TPU) לא תומכים במיגרציה פעילה, מערכת Compute Engine צריכה לכבות את הצמתים וליצור אותם מחדש במהלך תחזוקת המארח. התהליך הזה עלול לשבש עומסי עבודה כמו אימון AI/ML או משימות הסקה. כדי למזער את ההפרעה, כדאי לבצע את התחזוקה של המארח ב-Compute Engine ואת השדרוגים של הצמתים ב-GKE בו-זמנית. מידע נוסף זמין במאמר בנושא ביצוע תחזוקת מארח לצמתים שמריצים עומסי עבודה של אימון והסקת מסקנות.

שדרוגי מתח

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

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

מתי כדאי לבחור בשדרוגים זמניים לסביבה

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

שדרוגים מהירים מתאימים במיוחד לתרחישים הבאים:

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

מתי GKE משתמש בשדרוגים של עומס תנועה

אם האפשרות מופעלת, GKE משתמש בשדרוגים זמניים כשמתרחשים השינויים הבאים:

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

הסבר על הגדרות השדרוג המתח

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

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

‫maxSurge: המערכת של GKE יוצרת צומת חדש לפני שהיא מסירה צומת קיים

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

  1. הקצאת צומת חדש.
  2. ממתינים עד שהצומת החדש יהיה מוכן.
  3. מבודדים את הצומת הקיים.
  4. ניקוז הצומת הקיים, בהתאם להגדרות PodDisruptionBudget ו- GracefulTerminationPeriod למשך עד שעה. אחרי שעה, כל ה-Pods שנותרו מפונים בכוח כדי שהשדרוג יוכל להמשיך.
  5. מוחקים את הצומת הקיים.

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

‫maxUnavailable: GKE משבית צומת קיים כדי ליצור אותו מחדש

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

כדי לשדרג צומת אחד, GKE מבצע את השלבים הבאים:

  1. מבודדים את הצומת הקיים.
  2. מרוקנים את הצומת הקיים, בהתאם לשיקולים הבאים:
    • ההגדרות של PodDisruptionBudget ו-GracefulTerminationPeriod נשמרות למשך עד שעה. אחרי שעה, כל ה-Pods שנותרו יפונו באופן מאולץ כדי שהשדרוג יוכל להמשיך.
    • אם אין קיבולת בצמתים אחרים, יכול להיות שעומסי העבודה שפועלים בצומת הקיים יצטרכו לחכות לשדרוג של הצומת הקיים. כשהעומסים האלה ממתינים, הפודים נמצאים במצב המתנה.
  3. יוצרים מחדש את הצומת הקיים עם ההגדרה החדשה.
  4. מחכים שהצומת הקיים יהיה מוכן.
  5. מבטלים את החסימה של הצומת המשודרג הקיים.

כדי לשמור על הקיבולת הקיימת כשמשדרגים גרסאות בסביבה עם משאבים מוגבלים, צריך להגדיר ערך גדול מאפס בשדה maxUnavailable. לדוגמה, אפשר להגדיר את maxSurge=0 ו-maxUnavailable=1. לגבי יחידות GPU ו-TPU, אפשר לקרוא הנחיות נוספות במאמר בנושא שדרוג בסביבה עם מגבלות על משאבים.

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

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

לדוגמה, GKE לא משתמש מחדש במכונה הקיימת של Compute Engine, אלא מוחק ויוצר מחדש את המכונה בתרחישים הבאים:

  • עדכונים של מאגר הצמתים, מלבד שדרוגי גרסאות (כמו שינויים בסוג המכונה, בסוג הדיסק או בגודל הדיסק).
  • שדרוגי גרסאות של מאגרי צמתים שמכילים יחידות GPU או TPU.
  • שדרוגי גרסאות של מאגרי צמתים שמשתמשים ב-VM במודל Spot או ב-VM זמני.
  • ביטול של שדרוג מתח שלא הושלם.
  • תיקון אוטומטי של צומת.

דוגמה לשימוש בהגדרות maxSurge ו-maxUnavailable

לדוגמה, לאשכול GKE יש מאגר צמתים באזור אחד עם 30 צמתים והגדרת שדרוג המתח הבאה: maxSurge=2;maxUnavailable=1.

במהלך שדרוג מתח במאגר הצמתים הזה, בחלון זמן דינמי, GKE יוצר שני צמתים חדשים (maxSurge=2) ומיד משבית צומת קיים אחד (maxUnavailable=1). אחרי ששני הצמתים החדשים מוכנים, GKE משבית שני צמתים קיימים נוספים, ומשבש עד שלושה צמתים קיימים בכל פעם, תוך שמירה על מאגר הצמתים בין 29 ל-32 צמתים.

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

שיקולים להגדרות של שדרוג מתח

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

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

בטבלה הבאה מתוארים ארבעה פרופילים שונים של שדרוג כדוגמאות שיעזרו לכם להבין הגדרות שונות:

תיאור הגדרות אישיות תרחיש שימוש אופייני
מאוזנת (ברירת מחדל), איטית יותר אבל הכי פחות מפריעה maxSurge=1 maxUnavailable=0 רוב עומסי העבודה
סביבות מאוזנות עם משאבים מוגבלים, ללא משאבים נוספים maxSurge=0 maxUnavailable=1 מאגר צמתים עם משאבים מוגבלים
מהיר, ללא משאבים נוספים, הכי משבש maxSurge=0 maxUnavailable=100 מאגרי צמתים גדולים אחרי שהמשימות צריכות להסתיים
מהיר, הכי הרבה משאבים לשימוש במקרה של עומס ופחות הפרעות maxSurge=100 maxUnavailable=0 מאגרי צמתים גדולים

מאוזנת (ברירת מחדל)

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

מהיר וללא משאבים לזמני עומס

אם יש לכם מאגר גדול של צמתים ועומס העבודה לא רגיש לשיבושים (לדוגמה, משימה באצווה שהסתיימה), תוכלו להשתמש בהגדרה הבאה כדי למקסם את המהירות בלי להשתמש במשאבים נוספים: maxSurge=0;maxUnavailable=100. ההגדרה הזו לא מציגה צמתים נוספים של עלייה פתאומית בביקוש, ומאפשרת לשדרג 100 צמתים בו-זמנית.

מהיר ופחות מפריע

אם עומס העבודה שלכם רגיש לשיבושים וכבר הגדרתם PodDisruptionBudgets ‏(PDB), ואתם לא משתמשים ב-externalTrafficPolicy: Local שלא פועל עם ניקוז צמתים מקביל, אתם יכולים להגביר את מהירות השדרוג באמצעות maxSurge=100;maxUnavailable=0. ההגדרה הזו משדרגת 100 צמתים במקביל, בזמן שה-PDB מגביל את מספר ה-Pods שאפשר לרוקן בזמן נתון. למרות שההגדרות של ה-PDB עשויות להשתנות, אם יוצרים PDB עם maxUnavailable=1 לעומס עבודה אחד או יותר שפועלים במאגר הצמתים, אפשר לפנות רק Pod אחד של עומסי העבודה האלה בכל פעם, מה שמגביל את המקביליות של השדרוג כולו. כדי להשתמש בהגדרה הזו, צריך משאבים ליצירה זמנית של 100 צמתים חדשים.

סביבות מאוזנות עם משאבים מוגבלים

אם אתם לא יכולים להשתמש במשאבים נוספים, אתם יכולים להשתמש ב-maxSurge=0;maxUnavailable=1 כדי ליצור מחדש צומת אחד בכל פעם.

שליטה בשדרוג של נפח תנועה גבוה

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

ביטול (השהיה) של שדרוג מהיר

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

כשמבטלים שדרוג, GKE מבצע את הפעולות הבאות בכל אחד מהצמתים:

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

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

איך מבטלים שדרוג של מאגר צמתים

המשך של שדרוג מתח

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

החזרה לגרסה קודמת של שדרוג

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

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

שדרוגים כחול-ירוק (blue-green upgrades)

שדרוגים כחולים-ירוקים הם אסטרטגיית שדרוג חלופית לאסטרטגיית ברירת המחדל של שדרוג מתח. בשדרוגים כחול-ירוק, GKE יוצר קודם קבוצה חדשה של משאבי צמתים (צמתים "ירוקים") עם הגדרת הצומת החדשה, לפני פינוי עומסי העבודה במשאבים המקוריים (צמתים "כחולים"). ‫GKE שומר את המשאבים "הכחולים", אם צריך, כדי להחזיר למצב קודם (roll back) את עומסי העבודה עד לסיום זמן הטבילה שלהם. אתם יכולים להתאים את קצב השדרוגים ואת זמן הטבילה בהתאם לצרכים של הסביבה שלכם.

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

מתי כדאי לבחור בשדרוגים כחולים-ירוקים לסביבה שלכם

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

שדרוגים כחול-ירוק הם אופטימליים לתרחישים הבאים:

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

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

מתי GKE משתמש בשדרוגים מסוג blue-green

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

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

שלבים בשדרוגים כחול-ירוק

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

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

שלב 1: יצירת מאגר ירוק

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

המערכת תבדוק את Quota לפני שתתחיל להקצות משאבים ירוקים חדשים.

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

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

שלב 2: מאגר כחול קורדון

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

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

שלב 3: ניקוז המאגר הכחול

בשלב הזה, הצמתים המקוריים במאגר הכחול (קבוצות MIG קיימות) ינוקזו בקבוצות. כש-Kubernetes מרוקן צומת, נשלחות בקשות פינוי לכל ה-Pods שפועלים בצומת. הפודים יתוזמנו מחדש. אם יש Pods עם הפרות של PodDisruptionBudget או עם ערך גבוה של terminationGracePeriodSeconds במהלך הניקוז, הם יימחקו בשלב Delete blue pool כשהצומת יימחק. כדי להאריך את התקופה לפני מחיקת Pods, אפשר להשתמש ב-BATCH_SOAK_DURATION וב-NODE_POOL_SOAK_DURATION, שמתוארים כאן ובקטע הבא.

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

  • ‫BATCH_NODE_COUNT: המספר המוחלט של הצמתים שצריך לנקז באצווה.
  • ‫BATCH_PERCENT: אחוז הצמתים שצריך לרוקן באצווה, מבוטא כמספר עשרוני בין 0 ל-1, כולל. אם האחוז הוא לא מספר שלם של צמתים, GKE מעגל כלפי מטה לאחוז הקרוב ביותר של צמתים, עד לערך מינימלי של צומת אחד.

אם אחת מההגדרות האלה מוגדרת לאפס, GKE מדלג על השלב הזה ועובר לשלב Soak node pool.

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

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

שלב 4: בדיקת מאגר הצמתים

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

זמן ההשריה מוגדר באמצעות NODE_POOL_SOAK_DURATION, בשניות. כברירת מחדל, משך הזמן מוגדר לשעה אחת (3,600 שניות). אם משך ההמתנה הכולל מגיע ל-7 ימים (604,800 שניות), מתחיל מיד השלב של מחיקת המאגר הכחול.

משך ההשריה הכולל הוא סכום הערכים של NODE_POOL_SOAK_DURATION, ועוד BATCH_SOAK_DURATION כפול מספר המנות, שנקבע לפי BATCH_NODE_COUNT או BATCH_PERCENT.

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

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

בשלב הזה, מידרוג אוטומטי של אשכולות יכול להגדיל או להקטין את מאגר היעד כרגיל.

שלב 5: מחיקת המאגר הכחול

אחרי שתקופת זמן הטבילה תסתיים, הצמתים הכחולים במאגר יוסרו ממאגר היעד. אי אפשר להשהות את השלב הזה. בנוסף, בשלב הזה לא מתבצע פינוי, אלא ניסיון למחוק את ה-Pods. בניגוד לפינוי, המחיקה לא מכבדת את ה-PDB ומוחקת את ה-Pods באופן כפוי. המחיקה מגבילה את ה-terminationGracePeriodSeconds של Pod ל-60 דקות לכל היותר. אחרי הניסיון האחרון למחוק את ה-Pods שנותרו, הצמתים של המאגר הכחול נמחקים ממאגר הצמתים.

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

איך המידרוג האוטומטי של האשכול עובד עם שדרוגים מסוג blue-green

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

שליטה בשדרוג כחול-ירוק שמתבצע

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

ביטול (השהיה) של שדרוג blue-green

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

איך מבטלים שדרוג של מאגר צמתים

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

המשך שדרוג blue-green

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

אם תמשיכו, תהליך השדרוג ימשיך מהשלב שבו הוא הושהה. במאמר המשך השדרוג של מאגר צמתים מוסבר איך ממשיכים את השדרוג של מאגר צמתים.

החזרה לגרסה קודמת של שדרוג כחול-ירוק

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

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

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

השלמת שדרוג כחול-ירוק

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

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

שדרוגים כחול-ירוק עם שינוי גודל אוטומטי

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

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

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

מתי כדאי לבחור בשדרוגים כחול-ירוק עם התאמה אוטומטית לעומס בסביבה שלכם

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

שדרוגים כחול-ירוק (blue-green) עם שינוי גודל אוטומטי מתאימים לכם אם התרחישים הבאים רלוונטיים:

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

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

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

שלבים בשדרוגים אוטומטיים של כחול-ירוק

כש-GKE משדרג מאגרי צמתים באמצעות שדרוגים כחול-ירוק עם שינוי גודל אוטומטי, השלבים שונים מאלה של שדרוגים כחול-ירוק רגילים. במאמר שלבי השדרוג בשיטת blue-green מוסבר על השלבים באסטרטגיית השדרוג הרגילה.

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

  1. ‫GKE יוצר את מאגר המשאבים הירוק. עם זאת, המאגר הירוק מתחיל עם אפס צמתים. כש-GKE מפנה Pods מהמאגר הכחול בשלב מאוחר יותר, המידרוג האוטומטי של האשכול מגדיל את המאגר הירוק כדי להריץ את ה-Pods האלה.
  2. ‫GKE cordons the blue pool.

  3. ‫GKE ממתין פרק זמן מסוים, שאפשר להגדיר בין אפס לשבעה ימים (ברירת המחדל היא שלושה ימים). במהלך פרק הזמן הזה, GKE מבצע את הפעולות הבאות:

  4. ‫GKE מרוקן את המאגר הכחול, ומרוקן את הצמתים שנותרו במאגר הכחול עד 20 בכל פעם במקביל. ‫GKE פועל לפי ההגדרות של PodDisruptionBudget למשך עד שעה, ולפי ההגדרות של terminationGracePeriodSeconds למשך עד 24 שעות.

  5. ‫GKE מדלג על שלב מאגר הצמתים להרצה זמנית.

  6. ‫GKE מוחק את המאגר הכחול.

שיטות מומלצות לשדרוגים כחול-ירוק עם שינוי גודל אוטומטי

בקטעים הבאים מפורטות שיטות מומלצות לשימוש באשכול, במאגר הצמתים וב-Pods, כדי למזער את שיבוש עומס העבודה במהלך שדרוגים אוטומטיים של blue-green.

הגדרת האשכול ומאגר הצמתים

  • ‫GKE מכבד את מגבלות ההתאמה האוטומטית לעומס כשמגדילים את מאגר המשאבים הירוק. מגדירים את הפרמטרים --max-nodes או --total-max-nodes כך שיהיו גבוהים מספיק כדי שהמידרוג האוטומטי של האשכול יוכל להרחיב אנכית את מאגר הצמתים הירוק כש-GKE מתזמן מחדש עומסי עבודה מהמאגר הכחול למאגר הירוק. ‫GKE לא מתייחס לפרמטרים --min-nodes או --total-min-nodes כשמצמצמים את מאגר המשאבים הכחול.
  • אם רוצים ש-GKE יצמצם את הצמתים שלא מנוצלים מספיק במאגר הכחול בצורה אגרסיבית יותר, מגדירים את פרופיל ההתאמה האוטומטית לעומס (autoscaling) של optimize-utilization. מידע נוסף זמין במאמר פרופילים של התאמה לעומס (scaling).
  • אל תעדכנו מאגרי צמתים שנוצרו באמצעות הקצאת צמתים אוטומטית כדי להשתמש בשדרוגים כחול-ירוק עם התאמה אוטומטית לעומס. בנוסף, אל תגדירו את האשכול לשימוש בשדרוגים כחול-ירוק עם התאמה אוטומטית לעומס (autoscaling) למאגרי צמתים חדשים עם הקצאת משאבים אוטומטית.

הגדרת Pod

  • כדי לוודא שה-Pods לא יפונו במהלך ההשהיה לפני ניקוז המאגר הכחול, צריך להוסיף את ההערה "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" ל-Pods האלה. האנוטציה הזו מונעת מהמידרוג האוטומטי של האשכול להוציא את ה-Pod אם הצומת של ה-Pod לא מנוצל מספיק.
  • כמו בשדרוגים רגילים של כחול-ירוק, כדי להבטיח ש-Pods שסולקו מצמתים במאגר הכחול יתוזמנו מחדש רק לצמתים במאגר הירוק, צריך להוסיף nodeSelector לתווית cloud.google.com/gke-nodepool:NODE_POOL_NAME לעומס העבודה. אם לא מציינים את התווית הזו ויש עוד מאגרי צמתים באשכול, יכול להיות שה-Pods שסולקו יתוזמנו לצמתים במאגרי הצמתים האחרים האלה.

המגבלות של שדרוגים כחול-ירוק עם התאמה אוטומטית לעומס

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

מתי GKE משתמש בשדרוגים כחול-ירוק עם התאמה אוטומטית לעומס

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

איך המידרוג האוטומטי של האשכול פועל עם שדרוגים כחולים-ירוקים עם מידרוג אוטומטי

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

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

  • במהלך השלב שבו GKE ממתין לניקוז המאגר הכחול, המאגר הכחול לא עובר הרחבה אנכית (scale up) ורק עובר צמצום אנכי (scale down) על ידי הכלי למידרוג אוטומטי של האשכול, כשהשימוש בצמתים נמוך מדי. המידרוג האוטומטי של האשכול יכול לצמצם אנכית את מאגר הצמתים הכחול לאפס, בלי להתחשב בפרמטרים --min-nodes או --total-min-nodes. בכל השלבים האחרים, המידרוג האוטומטי של האשכול לא מגדיל או מקטין את המאגר הכחול.
  • המידרוג האוטומטי של האשכול מגדיל את המאגר הירוק מאפס צמתים, או מקטין אותו להגדרה --min-nodes, לפי הצורך בכל השלבים של אסטרטגיית השדרוג.

שדרוגים לטווח קצר (רק התחלה גמישה והקצאת משאבים בהמתנה)

שדרוגים זמניים הם אסטרטגיית שדרוג צמתים שמיועדת לשימוש רק עם צמתים שמשתמשים במכונות וירטואליות מסוג Flex-start וצמתים שמשתמשים בהקצאת משאבים בהמתנה (עם גרסה ‎1.32.2-gke.1652000 ואילך), שניהם מופעלים על ידי Dynamic Workload Scheduler. מידע נוסף על הצמתים שמשתמשים בשדרוגים לטווח קצר זמין במאמר מידע על צריכת GPU,‏ TPU ו-H4D במצב הקצאה "התחלה גמישה".

‫GKE משתמש באסטרטגיית השדרוגים לטווח קצר עבור מאגרי צמתים מסוג Standard וקבוצות של צמתים באשכולות Autopilot.

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

  1. הצמתים הקיימים פועלים עד שהם מופקעים.
  2. הצמתים החדשים משתמשים בהגדרות הצומת החדשות.
  3. במשך שבעה ימים לכל היותר, הצמתים עוברים מהרצת ההגדרות הקיימות להרצת ההגדרות החדשות.

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

מתי GKE משתמש בשדרוגים קצרי-טווח

מערכת GKE מגדירה באופן אוטומטי צמתים שמשתמשים ב-Flex-start VM כדי להחיל שדרוגים לזמן קצר. צמתים שמשתמשים רק בהקצאת משאבים בהמתנה, אבל פועלים באשכולות בגרסה 1.32.2-gke.1652000 ואילך של GKE, משתמשים גם בשדרוגים לטווח קצר.

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

המאמרים הבאים