מידע על שדרוגי אשכולות עם פריסה מדורגת

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

במסמך הזה אנחנו מניחים שאתם מכירים את הנושאים הבאים:

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

סקירה כללית

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

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

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

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

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

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

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

השקה מדורגת מבוססת-צי

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

הדיאגרמה הבאה ממחישה איך GKE משדרג אוטומטית אשכולות ברצף השקה מאורגן באמצעות Fleet:

רצף השקה שמבוסס על צי, שבו מקבצים אשכולות לציים.
איור: רצף השקה שמבוסס על צי

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

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

איך GKE משדרג אשכולות ברצף השקה

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

שדרוגי אשכולות ברצף השקה מתבצעים לפי השלבים הבאים:

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

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

  3. ‫GKE מבצע את השלבים הבאים לשדרוג מישור הבקרה:

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

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

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

  4. במקביל לשדרוגים של מישור הבקרה, GKE מבצע את השלבים הבאים לשדרוגים של הצמתים:

    1. אחרי שכל שדרוגי הצמתים באשכולות בקבוצה הראשונה מסתיימים, GKE מתחיל את תקופת ההמתנה לשדרוגי הצמתים. בנוסף, תקופת ההמתנה ב-GKE מתחילה אם חלפו יותר מ-30 ימים מאז שהתחילו השדרוגים של הצמתים.
    2. אחרי שתקופת ההרצה של שדרוגי הצמתים בקבוצה הראשונה תסתיים, GKE יתחיל לשדרג את הצמתים בקבוצה השנייה לגרסה החדשה. עם זאת, חשוב לשים לב לשיקולים הבאים:
      • במקרים מסוימים, יכול להיות ש-GKE ישדרג את צמתי האשכול של הקבוצה הראשונה כמה פעמים לפני שהוא ישדרג את צמתי האשכול של הקבוצה השנייה. במצב כזה, GKE בוחר את הגרסה העדכנית ביותר שיש לה גם את המאפיינים הבאים:
        • הגרסה מתאימה לקבוצה הראשונה.
        • הגרסה לא חדשה יותר מגרסת מישור הבקרה של האשכול של הקבוצה השנייה.
      • ‫GKE לא משדרג את הצמתים של אשכולות בקבוצה השנייה שיש להם גרסה מאוחרת יותר מהגרסה שמוגדרת בקבוצה הראשונה.

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

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

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

איך שולטים בשדרוגים ברצף השקה

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

דוגמה: בנק קהילתי מבצע בהדרגה שינויים מ-Testing ל-Production

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

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

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

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

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

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

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

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

עמידה בדרישות להשקה מבוססת-צי

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

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

במאמר פתרון בעיות שקשורות לעמידה בדרישות להשקה מוסבר איך לפתור בעיות שקשורות לעמידה בדרישות להשקה.

דוגמה לגרסת GKE

לדוגמה, בגרסה 2025-R45 הוגדר יעד שדרוג לכמה גרסאות משנה באשכולות שרשומים לערוץ הרגיל. יעד השדרוג יכול להיות גרסה משנית חדשה (1.30 עד 1.31) או רק גרסת תיקון חדשה (1.31.x-gke.x עד 1.31.13-gke.1023000). במהדורה הזו, בערוץ הרגיל, הגרסאות החדשות הבאות זמינות לקלאסטרים בגרסאות משניות ספציפיות:

  • אשכולות בגרסה 1.30 שודרגו לגרסה 1.31.13-gke.1023000.
  • אשכולות בגרסה 1.31 שודרגו לגרסה 1.32.9-gke.1108000.
  • אשכולות בגרסה 1.32 שודרגו לגרסה 1.33.5-gke.1162000.

הקבוצה הכי גבוהה בשרשרת מקבלת את כל יעדי השדרוג

לגבי אשכולות בקבוצה הראשונה ברצף, שאין לה קבוצה במעלה הזרם כדי להכשיר גרסאות חדשות, מערכת GKE משדרגת את כל האשכולות עם יעדי שדרוג מתאימים, ללא קשר אם יעדי השדרוג האלה שונים זה מזה. לדוגמה, בקבוצה הראשונה של רצף, אם חלק מהאשכולות פועלים בגרסה 1.30, אפשר לשדרג את האשכולות האלה לגרסה 1.31.13-gke.1023000, ואם חלק מהאשכולות פועלים בגרסה 1.32, אפשר לשדרג אותם לגרסה 1.33.5-gke.1162000. הסיבה לכך היא שבקבוצה הראשונה ברצף, GKE מחשיב את כל יעדי השדרוג כמתאימים לאשכולות האלה, כי אין קבוצה במעלה הזרם שתקבע אם גרסה חדשה מתאימה.

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

כדי שאשכולות בקבוצה כלשהי במורד הזרם יתחילו לשדרג, הקבוצה במעלה הזרם צריכה לעמוד בהצלחה בדרישות של יעד שדרוג יחיד משותף שכל האשכולות בקבוצה במורד הזרם עומדים בו. אם בקבוצת ה-upstream יש אשכולות ששודרגו בהצלחה לשתי גרסאות שונות (כמו שיכול לקרות אם קבוצת ה-upstream היא הקבוצה הראשונה ברצף), אז קבוצת ה-upstream מגדירה את הגרסה הנמוכה מבין שתי הגרסאות כיעד השדרוג המשותף לקבוצת ה-downstream. לדוגמה, אם בקבוצה במעלה הזרם יש כמה אשכולות ששודרגו לגרסה 1.31.13-gke.1023000 ואשכולות אחרים ששודרגו לגרסה 1.33.5-gke.1162000, אז הגרסה 1.31.13-gke.1023000 היא יעד השדרוג המשותף לקבוצה במורד הזרם.

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

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

לדוגמה, אם קבוצת ה-upstream עומדת בדרישות לשדרוג לגרסה 1.32, וקבוצת ה-downstream כוללת אשכולות שפועלות בהם גרסאות 1.31 ו-1.33, ‏ GKE ישדרג את האשכולות שפועלת בהם גרסה 1.31 לגרסה 1.32, ויתעלם מהאשכולות שפועלת בהם גרסה 1.33.

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

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

לדוגמה, אם כל האשכולות בקבוצה הראשונה שודרגו לגרסה ‎1.31.13-gke.1023000, אבל האשכולות בקבוצה השנייה מריצים גרסה חדשה יותר, כמו ‎1.32.9-gke.1108000, האשכולות בקבוצה השנייה לא ישודרגו באופן אוטומטי. הקבוצה הראשונה עומדת בדרישות לגרסה 1.31.13-gke.1023000, אבל האשכולות בקבוצה השנייה (שפועלים כרגע בגרסה 1.32) עומדים בדרישות רק לגרסת השדרוג 1.33.5-gke.1162000, ולכן GKE לא יכול לשדרג את האשכולות האלה באופן אוטומטי. כדי לקדם שדרוגים במצב הזה, אפשר לעיין במאמר פתרון בעיות שקשורות לזכאות בין קבוצות.

הקבוצה במעלה הזרם עמדה בדרישות של כמה יעדי שדרוג לקבוצה במורד הזרם

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

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

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

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

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

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

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

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

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

איך רצף השקת תכונות מבוסס-צי פועל עם זיהוי שימוש בהוצאה משימוש

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

איך רצף ההשקה פועל עם שיטות לשדרוג צמתים

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

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

איך פריסה מדורגת עובדת עם ערוצי הפצה

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

קבלת כמה שדרוגים ברצף

אם גרסה חדשה הופכת ליעד שדרוג בערוץ ההפצה בזמן ששדרוגים של אשכולות ליעד שדרוג קודם עדיין מתבצעים ברצף ההשקה, קבוצה במעלה הזרם יכולה להתחיל בהשקת גרסה חדשה בזמן שקבוצה במורד הזרם עדיין מקבלת את השדרוג הקודם. לדוגמה, אם הגרסה של הקבוצה השלישית ברצף היא 1.31.12-gke.1265000, יכול להיות שהגרסה של הקבוצה הראשונה ברצף היא 1.31.13-gke.1008000.

שיקולים לבחירת רצף פריסה מבוסס-צי

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

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

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

המגבלות של פריסת רצפים מבוססת-צי

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

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

בעיות מוכרות ברצף של השקה מבוססת-צי

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

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