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

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

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

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

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

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

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

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

שדרוגים של Surge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מהיר וללא משאבי גל

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

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

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

Slow but no surge resources

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

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

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

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

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

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

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

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

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

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

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

ביטול שדרוג מתח

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שלב 2: מאגר Cordon blue

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

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

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

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

אפשר לשלוט בגודל של הקבוצות באמצעות אחת מההגדרות הבאות:

  • ‫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.

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

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

בשלב הזה, התוסף Cluster Autoscaler יכול להגדיל או להקטין את המאגר הירוק כרגיל.

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

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

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

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

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

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

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

ביטול (השהיה) של שדרוג כחול-ירוק

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מתי כדאי לבחור בשדרוגים אוטומטיים של סביבת Blue-Green

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

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

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

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

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

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

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

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

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

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

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

  5. מערכת GKE מדלגת על השלב soak node pool.

  6. ‫GKE מוחק את מאגר המשאבים הכחול.

שיטות מומלצות לשדרוגים של blue-green עם שינוי גודל אוטומטי

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

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

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

הגדרת ה-Pod

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

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

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

מתי GKE משתמש בשדרוגים אוטומטיים של blue-green

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

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

כדי להגדיר שדרוגים אוטומטיים של blue-green, צריך גם להגדיר את הכלי להתאמת גודל האשכול.

אם משתמשים בשדרוגים אוטומטיים של blue-green, המערכת לשינוי גודל האשכול באופן אוטומטי מבצעת את הפעולות הבאות:

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

שדרוגים לזמן קצר (רק בהקצאת משאבים עם התחלה גמישה ובהקצאת משאבים בתור)

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

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

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

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

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

מתי GKE משתמש בשדרוגים לזמן קצר

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

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

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