אפשר לנהל את הסדר של שדרוגים אוטומטיים של אשכולות ב-Google Kubernetes Engine (GKE) בסביבות שונות באמצעות הגדרת רצף פריסה. לדוגמה, אפשר להכשיר גרסה חדשה באשכולות של סביבת טרום-ייצור לפני שמשדרגים את אשכולות הייצור. ב-GKE יש גם גרסה חדשה יותר של התכונה הזו, השקה מדורגת עם שלבים מותאמים אישית, עם פונקציונליות רחבה יותר. הגרסה הזו כוללת שליטה מפורטת יותר בשדרוגים של אשכולות, והיא מומלצת לסביבות חדשות.
במסמך הזה אנחנו מניחים שאתם מכירים את הנושאים הבאים:
כדי להגדיר רצף של השקות, אפשר לעיין במאמר הגדרת רצף להשקת שדרוגים של אשכולות.סקירה כללית
רצף השקת הגרסה ב-GKE מאפשר להגדיר רצף ספציפי ומסודר לשדרוג אשכולות בסביבות שונות – למשל, שדרוג קודם של האשכולות בסביבת הפיתוח, אחר כך בסביבת הבדיקה ולבסוף בסביבת הייצור. האסטרטגיה הזו מספקת זמן המתנה מובנה, שמאפשר לכם לגלות בעיות פוטנציאליות ולצמצם אותן לפני שהשדרוג מגיע למערכות הקריטיות ביותר שלכם.
הפריסה בשלבים מבוססת על הקונספט של צי, שהוא קיבוץ לוגי של אשכולות GKE שממופים לסביבה (לדוגמה, בדיקה). כדי להשתמש בתכונה הזו, צריך להגדיר רצף שמורכב מציים ולהגדיר את זמן ההרצה בין כל קבוצה. כש-GKE בוחר גרסה חדשה, השדרוג של האשכולות מתבצע לפי הסדר שהוגדר, וכך אפשר לאמת את עומסי העבודה לפני שהגרסה נפרסת באופן מלא בסביבת הייצור.
Fleets תומך בחברות קלות משקל, שמאפשרות לקבץ אשכולות באופן הגיוני לצורך פריסה מדורגת בלי להפעיל את כל ההגדרות והתכונות ברמת ה-Fleet. מינוי קל הוא בחירה טובה אם רוצים להשתמש בהפצה מדורגת בלי ההשלכות האחרות של ניהול מלא של צי הרכבים, כמו מרחב שמות זהה ברמת צי הרכבים. מידע נוסף זמין במאמר בנושא חברות קלות משקל.
בחירת אסטרטגיה להשקה מדורגת
ב-GKE יש שתי גרסאות של רצף השקה. שני הגרסאות מבוססות על אותם עקרונות ליבה של שדרוגים הדרגתיים שמבוססים על צי, אבל אנחנו ממליצים להשתמש ברצף השקה עם שלבים מותאמים אישית לסביבות חדשות:
- השקה מדורגת עם שלבים מותאמים אישית (מומלץ לסביבות חדשות): הגרסה הזו היא התפתחות של המודל מבוסס-הצי, ומציעה שליטה וגמישות ברמה יותר מפורטת, אבל אין בה תמיכה במסוף. Cloud de Confiance באמצעות שלבים מותאמים אישית, אפשר להגדיר שלבים ספציפיים בצי של מכונות באמצעות תוויות, ולכן זו בחירה טובה לאסטרטגיות השקה מורכבות יותר, כמו פריסת גרסה חדשה בקבוצת משנה קטנה של אשכולות ייצור לפני השקה רחבה יותר. בנוסף, יש לכם יותר שליטה על ההשקות, למשל: התחלת השקה לגרסה ספציפית, בחירת סוגי השדרוגים להשקה ברצף והשהיה או ביטול של השקות. בוחרים באפשרות הזו אם זו הפעם הראשונה שיוצרים רצף השקה.
- השקה הדרגתית מבוססת-צי: זו הגרסה היחידה של התכונה שאפשר להשתמש בה עם מסוף Cloud de Confiance , אבל הפונקציונליות שלה מוגבלת יותר, ולא מומלץ להשתמש בה אם אתם יוצרים רצף השקה בפעם הראשונה.
שאר המסמך הזה מתייחס רק לרצף פריסה שמבוסס על צי.
השקה מדורגת מבוססת-צי
כדי לשדרג אוטומטית אשכולות באמצעות פריסה מדורגת, משתמשים בציים שבהם קיבצתם את האשכולות עם אותו ערוץ הפצה וגרסה משנית לשלבי פריסה. מגדירים את רצף צי הרכבים ואת משך ההרצה שרוצים בין כל קבוצת אשכולות. לאחר מכן, כש-GKE בוחר גרסה חדשה לשדרוגים אוטומטיים בערוץ ההפצה, קבוצות האשכולות משודרגות ברצף שהגדרתם, ואתם יכולים לוודא שעומסי העבודה פועלים כצפוי עם גרסה חדשה לפני שהשדרוגים מתחילים באשכולות הייצור.
בתרשים הבא מוצג תהליך השדרוג האוטומטי של אשכולות ב-GKE ברצף פריסה שמסודר באמצעות צי GKE:
בסדרת שדרוגים מבוססת-צי, כש-GKE מפרסם גרסת שדרוג חדשה בערוץ ההפצה שבו רשומים כל האשכולות בסדרה הזו, GKE משדרג את ציי האשכולות האלה בסדרה הזו, כאשר האשכולות בצי במעלה הזרם מאשרים את הגרסה החדשה לאשכולות בצי במורד הזרם, עד חמישה ציים. במהלך השקת תכונה, המונח 'במעלה הזרם' מתייחס לקבוצה הקודמת, והמונח 'במורד הזרם' מתייחס לקבוצה הבאה.
במהלך תקופת ההמתנה שהגדרתם בין צי אחד למשנהו, תוכלו לוודא שעומסי העבודה פועלים כמצופה באשכולות המשודרגים.
איך GKE משדרג אשכולות ברצף השקה
כש-GKE משדרג אשכול, קודם משודרגת רמת הבקרה ואז משודרגים הצמתים. במהלך פריסה, האשכולות עדיין משודרגים באמצעות התהליך הזה, אבל אתם גם קובעים את סדר השדרוג של קבוצות (ציים) של אשכולות. מציינים גם זמן השהיה שקובע כמה זמן GKE משהה לפני שהשדרוגים עוברים מקבוצה אחת לקבוצה הבאה.
שדרוגי אשכולות ברצף השקה מתבצעים לפי השלבים הבאים:
- GKE מתחיל השקה חדשה ברצף ההשקות. ההשקה מתחילה כברירת מחדל כש-GKE מגדיר יעד חדש לשדרוג אוטומטי לאשכולות בגרסה משנית בערוץ הפצה ספציפי. אם משתמשים בשלבים מותאמים אישית להשקה, אפשר גם להפעיל השקה חדשה ברצף השקה לגרסה ספציפית שתבחרו.
GKE מתחיל לשדרג את מישורי הבקרה של האשכולים לגרסה החדשה בקבוצת האשכולות הראשונה. אחרי ש-GKE משדרג את מישור הבקרה של אשכול, הוא מתחיל לשדרג את הצמתים של האשכול. GKE מתחשב בזמינות לתחזוקה כשמשדרגים אשכולות ברצף פריסה.
GKE מבצע את השלבים הבאים לשדרוג מישור הבקרה:
- אחרי שכל השדרוגים של מישור הבקרה של האשכול בקבוצה הראשונה מסתיימים, GKE מתחיל את תקופת ההמתנה לשדרוגים של מישור הבקרה. בנוסף, תקופת ההמתנה מתחילה ב-GKE אם חלפו יותר מ-30 יום מאז שהתחילו השדרוגים של מישור הבקרה.
אחרי שתקופת ההמתנה תסתיים בשדרוגים של מישור הבקרה של האשכול בקבוצה הראשונה, GKE יתחיל לשדרג את מישורי הבקרה של הקבוצה השנייה לגרסה החדשה. עם זאת, חשוב לשים לב לשיקולים הבאים:
- במקרים מסוימים, יכול להיות ש-GKE ישדרג את מישורי הבקרה של האשכול של הקבוצה הראשונה כמה פעמים לפני שהוא ישדרג את מישורי הבקרה של האשכול של הקבוצה השנייה. במצב כזה, GKE בוחר את הגרסה העדכנית ביותר שיש לה גם את המאפיינים הבאים:
- הגרסה מוגדרת על ידי הקבוצה הראשונה.
- הגרסה היא לכל היותר גרסה משנית אחת אחרי גרסת מישור הבקרה של האשכולות בקבוצה השנייה.
- GKE לא משדרג את רמת הבקרה של אשכולות בקבוצה השנייה שיש להם גרסה מאוחרת יותר מהגרסה שמוגדרת בקבוצה הראשונה.
- במקרים מסוימים, יכול להיות ש-GKE ישדרג את מישורי הבקרה של האשכול של הקבוצה הראשונה כמה פעמים לפני שהוא ישדרג את מישורי הבקרה של האשכול של הקבוצה השנייה. במצב כזה, GKE בוחר את הגרסה העדכנית ביותר שיש לה גם את המאפיינים הבאים:
במקביל לשדרוגים של מישור הבקרה, GKE מבצע את השלבים הבאים לשדרוגים של הצמתים:
- אחרי שכל שדרוגי הצמתים באשכולות בקבוצה הראשונה מסתיימים, מתחיל ב-GKE תקופת ההמתנה לשדרוגי צמתים. בנוסף, תקופת ההרצה מתחילה ב-GKE אם חלפו יותר מ-30 ימים מאז שהתחילו השדרוגים של הצמתים.
- אחרי שתקופת ההרצה של שדרוגי הצמתים בקבוצה הראשונה תסתיים, GKE יתחיל לשדרג את הצמתים בקבוצה השנייה לגרסה החדשה. עם זאת, חשוב לשים לב לשיקולים הבאים:
- במקרים מסוימים, יכול להיות ש-GKE ישדרג את צמתי האשכול של הקבוצה הראשונה כמה פעמים לפני שהוא ישדרג את צמתי האשכול של הקבוצה השנייה. במצב כזה, GKE בוחר את הגרסה האחרונה שיש לה גם את המאפיינים הבאים:
- הגרסה מוגדרת על ידי הקבוצה הראשונה.
- הגרסה לא חדשה יותר מגרסת רמת הבקרה של האשכול של הקבוצה השנייה.
- GKE לא משדרג את הצמתים של אשכולות בקבוצה השנייה שיש להם גרסה מאוחרת יותר מהגרסה שמוגדרת בקבוצה הראשונה.
- במקרים מסוימים, יכול להיות ש-GKE ישדרג את צמתי האשכול של הקבוצה הראשונה כמה פעמים לפני שהוא ישדרג את צמתי האשכול של הקבוצה השנייה. במצב כזה, GKE בוחר את הגרסה האחרונה שיש לה גם את המאפיינים הבאים:
GKE חוזר על השלבים האלה מהקבוצה השנייה לקבוצה השלישית, עד שכל האשכולות בכל הקבוצות ברצף ההשקה משודרגים לגרסה החדשה.
במהלך תקופת ההרצה, בזמן שמתבצע שדרוג של האשכולות בכל קבוצה, צריך לוודא שעומסי העבודה עם האשכולות שפועלים בגרסה החדשה של GKE פועלים כמצופה.
יכול להיות ששדרוג של אשכולות יימנע גם בגלל חלונות תחזוקה או החרגות, שימוש ב-API שיצא משימוש או מסיבות אחרות.
איך שולטים בשדרוגים ברצף השקה
כשמשדרגים אשכולות ברצף השקה, קבוצות של אשכולות משודרגות לפי הסדר שהגדרתם, והן עוברות תקופת הרצה בכל קבוצה למשך הזמן שבחרתם. במהלך השדרוג, תוכלו לבדוק את הסטטוס ולנהל את רצף ההשקה לפי הצורך. אפשר גם לשלוט בתהליך בדרכים הבאות:
- אם אתם צריכים תקופת הרצה ארוכה או קצרה יותר לגרסה מסוימת, אתם יכולים לשנות את תקופת ההרצה שמוגדרת כברירת מחדל לקבוצה ברצף ההשקה.
- כדי לשדרג אשכולות בודדים, אפשר להשתמש בכלים הבאים:
- שליטה ידנית בשדרוגים באמצעות פעולות כמו ביטול, הפעלה מחדש, חזרה לגרסה קודמת או השלמת שדרוגים של מאגר צמתים.
- אפשר להשתמש בחלונות תחזוקה והחרגות כדי להחליט מתי אפשר לשדרג אשכול ומתי אי אפשר.
- הגדרת אסטרטגיות לשדרוג הצמתים כדי ליצור איזון בין מהירות לבין סובלנות לסיכון, בהתאם לעומסי העבודה שפועלים בצמתים האלה.
דוגמה: בנק קהילתי מבצע בהדרגה שינויים מהבדיקה לייצור
לדוגמה, מנהל הפלטפורמה בבנק קהילתי מנהל שלוש סביבות פריסה עיקריות: בדיקה, הכנה וייצור. לכל סביבה יש קבוצה של אשכולות שמסודרים בצי. כפי שנדרש לצורך פריסה מדורגת, האדמין רשם כל אשכול בכל שלושת צי הרכבים באותו ערוץ הפצה – הערוץ הרגיל בצי הרכבים האלה – וכל האשכולות מריצים את אותה גרסה משנית.
האדמין משתמש בהפצה מדורגת כדי להגדיר את הסדר שבו GKE משדרג את האשכולות בסביבות האלה. הזמנת ההשקה מאפשרת לאדמין לוודא שעומסי העבודה פועלים כמצופה עם אשכולות בגרסה חדשה של GKE, לפני שמשדרגים את סביבת הייצור לגרסה החדשה. הרצף הזה מודגם בתרשים הרצף של הפריסה שמבוססת על צי.
האדמין משתמש בתקופת ההרצה בין צי הרכבים כדי לוודא שעומסי העבודה פועלים כמצופה בגרסה החדשה של GKE. בצי הבדיקה, האדמין מגדיר את זמן ההרצה ל-14 ימים, כדי שיהיו לו שבועיים מלאים לבדוק איך עומסי העבודה פועלים. בסביבת Staging, הם הגדירו את זמן ההמתנה ל-7 ימים כי הם לא צריכים כל כך הרבה זמן נוסף אחרי שהעומסים כבר פעלו בסביבת Testing.
האדמין יכול גם לשנות את ברירת המחדל של זמן ההמתנה לשדרוגים לגרסאות ספציפיות, למשל באחד מהמקרים הבאים:
- האדמין מסיים את תהליך האימות של הגרסה לפני שזמן ההמתנה מסתיים, והוא רוצה שהשדרוגים ימשיכו לצי הבא, לכן הוא מגדיר את זמן ההמתנה לאפס.
- האדמין צריך יותר זמן כדי לבדוק את הגרסה החדשה לפני שמתחילים בשדרוגים, כי הוא הבחין בבעיה בחלק מעומסי העבודה. לכן הוא מגדיר את תקופת ההרצה ל-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 משדרגת את האשכולות שעומדים בדרישות לשדרוג ומתעלמת מהאשכולות שכבר פועלת בהם גרסה חדשה יותר. ההתנהגות הזו לא מונעת את התקדמות רצף ההשקה, כל עוד לפחות אשכול אחד בקבוצת ה-downstream עומד בדרישות לשדרוג.
לדוגמה, אם קבוצת ה-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. לשדרוגי צמתים, הגרסה הזו יכולה להיות שווה לגרסת מישור הבקרה של האשכולות בקבוצת הצאצא, אבל לא מאוחרת ממנה.
לדוגמה, התרחיש הזה רלוונטי אם הגדרתם החרגות מתחזוקה כדי למנוע זמנית שדרוגים לקבוצת ה-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ומועברים לקבוצה במורד הזרם.