מידע על עדכוני מתח

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

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

איך פועלים עדכונים מתגלגלים רגילים

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

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

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

אלה השלבים שמתבצעים ב-GKE ב-AWS במהלך עדכון בהדרגה (rolling) רגיל:

1. בוחר צומת ממאגר הצמתים ומסמן את הצומת כלא זמין כדי לוודא שלא יופעלו בו פודים חדשים – הפעולה הזו נקראת הסגר.
2. מעביר את ה-Pods הפעילים מהצומת המבודד לצמתים זמינים אחרים באשכול. אם יש לצמתים אחרים קיבולת מספקת, הם יכילו את ה-Pods שהוצאו. אחרת, המידרוג האוטומטי של האשכול, שנשאר פעיל במהלך עדכון בהדרגה (rolling), מתחיל להגדיל את הקיבולת ומקצה צמתים נוספים כדי לוודא שיש מספיק קיבולת לתזמון של ה-Pods שהוצאו. מידע על האמצעים שננקטים כדי להגן על עומסי עבודה במהלך התהליך הזה מופיע במאמר הגנה על עומסי עבודה במהלך שינוי הגודל.
3. הפסקת הפעולה של הצומת המבודד.
4. הוא מחליף את הצומת המבודד בצומת חדש עם ההגדרות המעודכנות.
5. מבצע בדיקת תקינות בצומת החדש שהופעל. אם בדיקת התקינות של מאגר הצמתים נכשלת, הוא מסומן בסטטוס DEGRADED. כדי לראות את הסטטוס הזה, מריצים את הפקודה gcloud container aws node-pools describe. כשמאגר צמתים מסומן כ-DEGRADED, יכול להיות שלא יתוזמנו פודים חדשים בצמתים שבמאגר הזה.
6. העדכון ממשיך, צומת אחרי צומת, עד שכל הצמתים במאגר מעודכנים.

איך פועלים עדכונים על עלייה בביקוש

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

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

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

1. יצירה של קבוצת התאמה אוטומטית לעומס חדשה: ‏ GKE ב-AWS מקצה צמתים חדשים עם השינויים שצוינו בפקודת העדכון, ומקצה את הצמתים החדשים האלה לקבוצת התאמה אוטומטית לעומס (ASG) חדשה ב-AWS.
2. התנהגות של המידרוג האוטומטי של האשכול: כשהעדכון מתחיל, המידרוג האוטומטי של האשכול מופעל עבור קבוצת המידרוג האוטומטי החדשה. המידרוג האוטומטי של האשכול עבור קבוצת ההתאמה לעומס המקורית מושבת. כך המערכת מבטיחה שכל פעולות ההרחבה יטרגטו רק את הקבוצה החדשה.
3. החלפת צומת: בהתאם לפרמטרים של עדכון העלייה הפתאומית, נעשה שימוש באסטרטגיות שונות להחלפת צומת:
   • ‫create before terminate: האסטרטגיה הזו מופעלת כשהפרמטר max-surge-update מוגדר לערך שגדול מאפס. הוא יוצר צמתים חדשים בקבוצת ה-ASG החדשה לפני שהוא מפסיק את הצמתים הישנים בקבוצת ה-ASG המקורית, במטרה למזער את השיבושים בשירות.
   • ‫'terminate before create': השיטה הזו מופעלת כשהפרמטר max-surge-update מוגדר לאפס ולפרמטר max-unavailable-update יש ערך גדול מאפס. קודם מסיימים את הפעולה של הצמתים מקבוצת ה-ASG המקורית, ואז יוצרים צמתים חדשים בקבוצת ה-ASG החדשה.
4. שינויים בגודל מאגר הצמתים: במהלך העדכון, גודל מאגר הצמתים (כלומר, סכום הצמתים ב-ASG הישן וב-ASG החדש) עשוי להשתנות מעל או מתחת למספר הצמתים המקורי שהיו במאגר הצמתים לפני תחילת העדכון. באופן ספציפי, המטרה של GKE ב-AWS היא לשמור על מספר הצמתים הכולל בטווח של (original_count - max-unavailable-update) עד (original_count + max-surge-update). בסופו של דבר, הצמתים ב-ASG הישן (original_count) מוחלפים בצמתים מעודכנים ב-ASG החדש. יכול להיות שהמידרוג האוטומטי של האשכול יפעיל עוד צמתים ב-ASG החדש אם הוא יזהה שלא ניתן לתזמן את ה-Pods, אבל הוא יישאר במסגרת המגבלות שהוגדרו על ידי min-nodes ו-max-nodes.

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

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

  gcloud container aws node-pools update production-node-pool
      --cluster my-cluster \
      --location us-west1 \
      --max-surge-update 2 \
      --max-unavailable-update 1 \
      --node-version 1.27.6-gke.700

בדוגמה הזו, הערך של max-surge-update הוא 2, הערך של max-unavailable-update הוא 1, ואתם מספקים גרסה חדשה של מאגר הצמתים (כלומר, אתם משנים את גרסת GKE שפועלת בצמתים במאגר הצמתים).

הפעלת הפקודה הזו מפעילה עדכון של עלייה זמנית, ו-GKE ב-AWS מבצע את הפעולות הבאות:

1. נוצרים 2 צמתים נוספים כי הערך של max-surge-update שווה ל-2.
2. מערכת Google Cloud מקצה את 2 הצמתים הנוספים האלה לקבוצת התאמה אוטומטית לעומס חדשה של AWS.
3. הסרת צמתים מקבוצת הגידול האוטומטי המקורית אחרי שהצמתים החדשים האלה מתחילים לפעול. ‫GKE ב-AWS משבית עד 3 צמתים (הערך המשולב של max-surge-update ו-max-unavailable-update), אבל מוודא שרק צומת אחד לכל היותר לא יהיה זמין בכל רגע נתון (בגלל הערך max-unavailable-update של 1).
4. חוזרים על השלבים האלה עד שכל הצמתים במאגר הצמתים מתעדכנים לגרסה החדשה של GKE.

במהלך העדכון הזה, מאגר הצמתים מכיל בין 4 ל-7 צמתים תפעוליים.

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

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

• יכול להיות שמספר המופעים הנוספים שנוצרו כחלק משלב העלייה החדה הזה יעלה על מכסת המופעים המקסימלית שלכם ב-AWS. אם אין לכם מספיק מכסה ולא ניתן להקצות את המופעים הנוספים האלה, יכול להיות שהעדכון ייכשל.
• אם הערך של max-unavailable-update הוא 0, עדיין יכולות להיות הפרעות בעומסי העבודה כי ה-Pods מפונים ומתוזמנים מחדש בצמתים החדשים יותר.
• המספר המקסימלי של צמתים שאפשר לעדכן בו-זמנית שווה לסכום של max-surge-update ו-max-unavailable-update, והוא מוגבל ל-20.

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

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

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

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

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

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

הדרך הכי פשוטה להשתמש בעדכונים של עומס פתאומי היא עם הגדרות ברירת המחדל של max-surge-update=1 ו-max-unavailable-update=0. ההגדרה הזו מוסיפה רק צומת אחד של עלייה זמנית בביקוש למאגר הצמתים במהלך העדכון, ורק צומת אחד מתעדכן בכל פעם, לפי הגישה של 'יצירה לפני סיום'. בהשוואה לעדכון בהדרגה (rolling) רגיל ללא הגדלת מספר העותקים, ששווה ל-max-surge-update=0, max-unavailable-update=1, השיטה הזו פחות משבשת, מאיצה את ההפעלה מחדש של ה-Pod במהלך העדכונים, והיא שמרנית יותר בהתקדמות שלה.

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

עדכונים מהירים ללא צורך במשאבים נוספים

לעומסי עבודה שיכולים לעמוד בהפרעות, יכול להיות שגישת עדכון מהירה יותר תתאים. כדי לעשות את זה, צריך להגדיר את max-surge-update=0 ואת max-unavailable-update=20. במסגרת ההגדרה הזו, אפשר לעדכן 20 צמתים בו-זמנית בלי להוסיף צמתים לטיפול בעומס. שיטת העדכון הזו מבוססת על הגישה 'סיום לפני יצירה'. בגלל שלא נוספים צמתים נוספים במהלך התהליך, זו גם השיטה הכי משתלמת, כי היא מונעת הוצאות נוספות שקשורות לצמתים זמניים.

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

אם עומסי העבודה שלכם רגישים לשיבושים, אתם יכולים להגדיל את מהירות העדכון באמצעות ההגדרות הבאות: max-surge-update=20 ו-max-unavailable-update=0. ההגדרה הזו מעדכנת 20 צמתים במקביל בשיטה של 'יצירה לפני סיום'.

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

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

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

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