אפשר לנהל את הסדר של שדרוגים אוטומטיים של אשכולות ב-Google Kubernetes Engine (GKE) בסביבות שונות באמצעות תזמון פריסה. לדוגמה, אפשר להכשיר גרסה חדשה באשכולות של סביבת טרום-ייצור לפני שמשדרגים את אשכולות הייצור. GKE מספק גם גרסה של פריסה מדורגת שמשתמשת בשלבים מותאמים אישית (תצוגה מקדימה) כדי לתת לכם שליטה מפורטת יותר בשדרוגי אשכולות.
במסמך הזה אנחנו מניחים שאתם מכירים את הנושאים הבאים:
כדי להגדיר רצף של השקות, אפשר לעיין במאמר הגדרת רצף להשקת שדרוגים של אשכולות.סקירה כללית
התכונה 'פריסת שדרוגים ב-GKE' מאפשרת להגדיר רצף ספציפי ומסודר לשדרוג אשכולות בסביבות שונות – למשל, שדרוג קודם של האשכולות בסביבת הפיתוח, אחר כך בסביבת הבדיקה ולבסוף בסביבת הייצור. האסטרטגיה הזו מספקת זמן המתנה מובנה, ומאפשרת לכם לגלות בעיות פוטנציאליות ולצמצם אותן לפני שהשדרוג מגיע למערכות הקריטיות ביותר שלכם.
הפריסה בשלבים מבוססת על הקונספט של צי, שהוא קבוצה לוגית של אשכולות GKE שממופים לסביבה (לדוגמה, בדיקה). כדי להשתמש בתכונה הזו, צריך להגדיר רצף שמורכב מצי של מכונות ולהגדיר את זמן הטבילה בין כל קבוצה. כש-GKE בוחר גרסה חדשה, האשכולות משודרגים לפי הסדר שהוגדר, וכך אפשר לאמת את עומסי העבודה לפני שהגרסה נפרסת באופן מלא בסביבת הייצור.
Fleets תומך בחברות קלות משקל, שמאפשרות לקבץ אשכולות באופן הגיוני לצורך פריסה מדורגת, בלי להפעיל את כל ההגדרות והתכונות ברמת ה-Fleet. מינוי קל הוא בחירה טובה אם רוצים להשתמש בהפצה מדורגת בלי חלק מההשלכות האחרות של ניהול מלא של צי הרכבים, כמו מרחב שמות זהה ברמת צי הרכבים. מידע נוסף זמין במאמר בנושא חברות קלות.
בחירת אסטרטגיה להשקה מדורגת
ב-GKE יש שתי גרסאות של רצף השקה. שתי הגרסאות מבוססות על אותם עקרונות ליבה של שדרוגים מתקדמים שמבוססים על צי, אבל הן מציעות רמות שונות של גמישות. בקטע הזה מוסבר איך לבחור את הגרסה הכי מתאימה לתרחיש השימוש שלכם.
פריסה מדורגת שמבוססת על צי (GA): הגרסה הזו היא האסטרטגיה המומלצת לרוב התרחישים לדוגמה של הפקה. הפצה מדורגת מבוססת-ציים מספקת שיטה יציבה ונתמכת להפצה מדורגת של שדרוגים בסביבות שונות (כמו בדיקה, Staging וייצור), והיא משתמשת ברצף לינארי של ציים.
פריסה בשלבים עם שלבים בהתאמה אישית (גרסת טרום-השקה): הגרסה הזו היא התפתחות של המודל מבוסס-הצי, ומציעה שליטה וגמישות ברמה מפורטת יותר. בעזרת שלבים בהתאמה אישית, אתם יכולים להגדיר שלבים ספציפיים בצי של מכשירים באמצעות תוויות. זו אפשרות טובה לאסטרטגיות השקה מורכבות יותר, כמו פריסת גרסה חדשה בקבוצת משנה קטנה של אשכולות ייצור לפני השקה רחבה יותר. מומלץ לבחור באפשרות הזו אם אתם רוצים גמישות רבה יותר או אם אתם רוצים לראות תצוגה מקדימה של היכולות העדכניות של רצף ההשקה.
רצף השקה שמבוסס על צי
כדי לשדרג אשכולות באופן אוטומטי באמצעות פריסה מדורגת, משתמשים ב-fleets שבהם קיבצתם את האשכולות עם אותו ערוץ הפצה ואותה גרסה משנית לשלבי פריסה. מגדירים את רצף הציים ואת משך ההרצה שרוצים בין כל קבוצת אשכולות. לאחר מכן, כש-GKE בוחר גרסה חדשה לשדרוגים אוטומטיים בערוץ ההפצה, קבוצות האשכולות משודרגות ברצף שהגדרתם, ואתם יכולים לוודא שעומסי העבודה פועלים כצפוי עם גרסה חדשה לפני שהשדרוגים מתחילים באשכולות הייצור.
התרשים הבא ממחיש כיצד GKE משדרג אשכולות באופן אוטומטי ברצף פריסה מאורגן באמצעות Fleet:
בסדרת שדרוגים מבוססת-צי, כש-GKE מפרסם גרסת שדרוג חדשה בערוץ ההפצה שבו רשומים כל האשכולות בסדרה הזו, GKE משדרג את ציי האשכולות האלה בסדרה, כאשר האשכולות בצי במעלה הזרם מאשרים את הגרסה החדשה לאשכולות בצי במורד הזרם, עד חמישה ציים. במהלך השקת תכונה, המונח 'במעלה הזרם' מתייחס לקבוצה הקודמת, והמונח 'במורד הזרם' מתייחס לקבוצה הבאה.
במהלך זמן הטבילה שהוגדר בין צי אחד למשנהו, תוכלו לוודא שעומסי העבודה פועלים כמצופה באשכולות המשודרגים.
הפעלת רצף של השקות עם שלבים מותאמים אישית
כשמשתמשים בהפצה מדורגת עם שלבים מותאמים אישית, מגדירים את סדר השדרוגים של צי המכשירים ואת משך הזמן של תקופת ההרצה. בנוסף, אפשר גם:
- אפשר להגדיר רצף עם שלבים מפורטים שיכולים לטרגט קבוצות משנה ספציפיות של אשכולות בצי באמצעות תוויות. לכן, זו בחירה טובה לאסטרטגיות כמו השקות מדורגות.
- אובייקטים חדשים של API
RolloutSequenceו-Rolloutמאפשרים לכם ליהנות משליטה רבה יותר ומשקיפות משופרת.
השיטה הזו מאפשרת לכם גמישות מקסימלית ושליטה מפורטת בשדרוגים של האשכול. כדי לטרגט קבוצות משנה ספציפיות של אשכולות בצי, משתמשים ב-label-selector כדי לטרגט רק את האשכולות שיש להם תוויות ספציפיות של Kubernetes.
הדיאגרמה הבאה ממחישה כיצד GKE משדרג אשכולות באופן אוטומטי ברצף של פריסה שמשתמשת בשלבים בהתאמה אישית. השלב מכוון לאשכולות עם label-selector בשם canary בצי prod:
כשגרסת יעד חדשה לשדרוג הופכת לזמינה בערוץ ההפצה שבו רשומים כל האשכולות ברצף הזה, מערכת GKE משדרגת קודם את האשכולות בקבוצת הבדיקה ואחר כך את האשכולות בקבוצת ההכנה. לאחר מכן, בצי הייצור, GKE נותן עדיפות לאשכולות שתואמים ל-label-selector. מכיוון שהתווית prod-cluster-1 מצורפת ל-canary: true, האשכול הזה ישודרג ב-GKE בשלב הבא.
מערכת GKE משדרגת את כל האשכולות שנותרו בצי Production (בשלב הראשי) בסוף התהליך, כי לשלב הזה אין בורר תוויות.
במהלך זמן הטבילה שהגדרתם בין השלבים, תוכלו לוודא שעומסי העבודה פועלים כמצופה באשכולות המשודרגים. בדוגמה הקודמת מוצג שלב אחד בהתאמה אישית בצי Production, אבל אפשר להוסיף כמה שלבים לכל צי או להשתמש רק בצי אחד עם כמה שלבים.
מידע נוסף על פריסה בשלבים עם שלבים מותאמים אישית זמין במאמר מידע על פריסה בשלבים עם שלבים מותאמים אישית.שאר המסמך הזה מתייחס רק לרצף השקה שמבוסס על צי.
איך GKE משדרג אשכולות ברצף השקה
כש-GKE משדרג אשכול, קודם משודרג מישור הבקרה ואז משודרגים הצמתים. במהלך פריסה, האשכולות עדיין משודרגים באמצעות התהליך הזה, אבל אתם גם קובעים את הסדר שבו קבוצות (ציים) של אשכולות משודרגות. מגדירים גם זמן השהיה שקובע כמה זמן GKE משהה את השדרוגים לפני שהם ממשיכים מקבוצה אחת לקבוצה הבאה.
שדרוגי אשכולות ברצף השקה מתבצעים לפי השלבים הבאים:
- GKE מגדיר יעד חדש לשדרוג אוטומטי של אשכולות בגרסה משנית בערוץ הפצה ספציפי, עם הערת גרסה שדומה להודעה הבאה: "מישורי בקרה וצמתים עם שדרוג אוטומטי מופעל בערוץ הרגיל ישודרגו מגרסה 1.29 לגרסה 1.30.14-gke.1150000 עם הגרסה הזו".
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 משדרגת את האשכולות שעומדים בדרישות של גרסת היעד לשדרוג ומתעלמת מהאשכולות שכבר פועלת בהם גרסה חדשה יותר. ההתנהגות הזו לא מונעת את התקדמות רצף ההשקה, כל עוד לפחות אשכול אחד בקבוצת הצאצא עומד בדרישות לשדרוג.
לדוגמה, אם קבוצת ה-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 שדרג את האשכולות בקבוצת ה-upstream כמה פעמים לפני שדרוג האשכולות בקבוצת ה-downstream, GKE ישדרג את האשכולות בקבוצת ה-downstream לגרסה העדכנית ביותר שעומדת בדרישות של קבוצת ה-upstream, ושמתאימה לאשכולות בקבוצת ה-downstream. לשדרוגים של רמת הבקרה, הגרסה הזו יכולה להיות לכל היותר גרסה משנית אחת מאוחרת יותר מגרסת רמת הבקרה של האשכולות בקבוצת ה-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ומועברים לקבוצה במורד הזרם.