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

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

כדי להבין את המסמך הזה, אתם צריכים להכיר את הנושאים הבאים:

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

סקירה כללית

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

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

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

בחירת אסטרטגיה לרצף ההשקה

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

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

שאר המסמך הזה רלוונטי רק לרצף השקה שמבוסס על צי.

רצף השקה מבוסס-צי

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

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

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

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

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

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

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

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

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

דוגמה: בנק קהילתי משיק בהדרגה שינויים מסביבת הבדיקה לסביבת הייצור

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

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

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

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

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

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

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

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

הדרישות להשקה לפי צי

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

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

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

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

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

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

לדוגמה, אם הקבוצה במעלה הזרם אישרה את השדרוג לגרסה 1.32, ובקבוצה במורד הזרם יש אשכולות שפועלים בגרסאות 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.

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

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

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

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

מגבלות על רצף ההשקה לפי צי

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

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

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

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

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