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

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

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

  • שדרוגים מהירים: שדרוג הצמתים מתבצע בחלון מתגלגל. אתם יכולים לקבוע כמה צמתים אפשר לשדרג בו-זמנית, ועד כמה השדרוגים משבשים את עומסי העבודה.
  • שדרוגים מסוג blue-green: הצמתים הקיימים נשארים זמינים להחזרה לגרסה הקודמת בזמן שהעומסים מאומתים בהגדרת הצומת החדשה.
  • שדרוגים אוטומטיים של 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 כדי לבחור את המספר המקסימלי של צמתים נוספים שנוצרים באופן אוטומטי, שאפשר להוסיף למאגר הצמתים במהלך שדרוג, לכל אזור. כך מגדילים את הסיכוי שעומסי עבודה שפועלים בצומת הקיים יוכלו לעבור מיד לצומת חדש. ברירת המחדל היא אחת. כדי לשדרג צומת אחד, מערכת 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=100 מאגרי צמתים גדולים אחרי שהעבודות צריכות לפעול עד הסוף
מהיר, עם הכי הרבה משאבים בזמן עלייה בביקוש ופחות שיבושים maxSurge=100 maxUnavailable=0 מאגרי צמתים גדולים
האיטיות ביותר, שיבושים, ללא משאבים לשיפור הביצועים maxSurge=0 maxUnavailable=1 מאגר צמתים עם מגבלות על משאבים והזמנה

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

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

מהיר וללא משאבים עודפים

אם יש לכם מאגר גדול של צמתים ועומס העבודה לא רגיש לשיבושים (למשל, משימה באצווה שהסתיימה), תוכלו להשתמש בהגדרה הבאה כדי למקסם את המהירות בלי להשתמש במשאבים נוספים: 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 מבצעת את הפעולות הבאות בכל אחד מהצמתים:

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

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

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

המשך שדרוג מהיר

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

ביטול שדרוג זמני

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בשלב הזה, כל הצמתים המקוריים במאגר הכחול (קבוצות 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: מחיקת המאגר הכחול

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

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

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

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

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

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

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

כשמבטלים שדרוג מסוג 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 מוסבר על השלבים באסטרטגיית השדרוג הרגילה.

כשהמדיניות של שדרוגים כחול-ירוק עם שינוי גודל אוטומטי מופעלת, 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 או --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 עם שינוי גודל אוטומטי, אבל לא תוכלו לבטל את השדרוג שבוטל.
  • כשמאגר המשאבים הכחול מוקצה ומנוקז, יכול להיות שאי אפשר יהיה לתזמן זמנית את ה-Pods אם לא ניתן להגדיל את מאגר המשאבים הירוק באמצעות שינוי גודל אוטומטי של האשכול בגלל מכסות ומגבלות או זמינות משאבים, כי מאגר המשאבים הירוק נוצר עם אפס צמתים.
  • אפשר לשדרג מאגרי צמתים באמצעות שדרוגים אוטומטיים של blue-green רק אם רמת הבקרה של האשכול מריצה את גרסה 1.34.0-gke.2201000 ואילך, והמידרוג האוטומטי של האשכול מופעל.

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

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

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

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

אם משתמשים בשדרוגים אוטומטיים של blue-green, התוסף Cluster Autoscaler מבצע את הפעולות הבאות:

  • במהלך השלב שבו GKE ממתין לניקוז המאגר הכחול, לא מתבצעת סילומיות אנכית (scale up) של המאגר הכחול, ורק מתבצעת סילומיות אופקית (scale down) על ידי הכלי לשינוי גודל האשכול כשניצול הצמתים נמוך. המידרוג האוטומטי של האשכול יכול להקטין את מאגר המכונות הכחול לאפס, בלי להתחשב בפרמטרים --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 ואילך, משתמשים גם בשדרוגים לזמן קצר.

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

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