מידע על פריסה בשלבים עם שלבים בהתאמה אישית

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

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

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

סקירה כללית

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

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

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

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

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

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

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

הפעלת רצף של פריסה עם שלבים בהתאמה אישית

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

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

השיטה הזו מאפשרת גמישות רבה ושליטה מדויקת בשדרוגים של האשכול. כדי לטרגט קבוצות משנה ספציפיות של אשכולות בצי, משתמשים ב-label-selector כדי לטרגט רק את האשכולות שיש להם תוויות ספציפיות של Kubernetes.

בתרשים הבא מוצג תהליך שבו GKE משדרג אוטומטית אשכולות ברצף של פריסה הדרגתית שכולל שלבים בהתאמה אישית. השלב מכוון לאשכולות עם label-selector בשם canary ב-Fleet prod:

רצף השקה עם שלבים מותאמים אישית ב-GKE.
איור: רצף השקה עם שלבים מותאמים אישית

כש-GKE משיק גרסה חדשה, GKE משדרג קודם את האשכולות ב-Fleet הבדיקה, ואז את האשכולות ב-Fleet ההכנה. לאחר מכן, ב-Fleet של סביבת הייצור, GKE נותן עדיפות לאשכולות שתואמים ל-label-selector. מכיוון ש-prod-cluster-1 מסומן בתווית canary: true, האשכול הזה ישודרג ב-GKE בשלב הבא. ‫GKE משדרג את כל האשכולות שנותרו ב-Fleet הייצור (בשלב הראשי) בסוף התהליך, כי לשלב הזה אין בורר תוויות.

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

מושגים מרכזיים

  • זמן השהייה: תקופת המתנה שניתנת להגדרה, שמתרחשת אחרי שכל האשכולות בשלב מסוים משודרגים. זמן הטבילה הזה מאפשר לכם לאמת את הגרסה החדשה בסביבה אחת ולזהות בעיות פוטנציאליות לפני שהשדרוג ממשיך לסביבה הבאה. אתם יכולים להגדיר תקופת המתנה של עד 30 ימים לכל שלב ברצף. זמן שהייה ארוך יותר בשלב הקדם-ייצור מאפשר לכם יותר זמן לאימות.
  • ‫RolloutSequence: האובייקט הזה הוא המשאב הראשי שמשמש להגדרת רצף השדרוג. ‫RolloutSequence מכיל סדרה מסודרת של שלבים, שמוודאת שהשדרוג של האשכולות בשלבים הקודמים הושלם ושהם סיימו את תקופת ההרצה שלהם לפני שהשדרוג ממשיך לשלב הבא. לכל RolloutSequence יש Rollout אחד לכל גרסה חדשה שמופצת.
  • ‫Rollout: האובייקט הזה מאפשר לכם לעקוב אחר ההתקדמות של שדרוג גרסה יחיד ברצף. אפשר להשתמש ב-Rollout כדי לראות את סטטוס ההשקה, לעקוב אחרי ההתקדמות ולבדוק אם יש אשכולות שלא עומדים בדרישות לשדרוג ולמה. כל Rollout משויך לRolloutSequence ספציפי שמייצג את הרצף שבו הגרסה מושקת.
  • פרויקט ייעודי למארח: מומלץ להשתמש בCloud de Confiance by S3NS פרויקט ייעודי לאירוח אובייקט RolloutSequence. הצבת הרצף בפרויקט ייעודי מספקת נקודת בקרה מרכזית וניטרלית לרצף ההשקה, וזו שיטה מומלצת דומה לניהול צינורות CI/CD.
שיטה מומלצת:

יוצרים ומנהלים את משאב RolloutSequence בפרויקט ייעודי לאירוח.

  • שלבים: שלב הוא צעד ברצף ההשקה. כל שלב מכיל קבוצה של אשכולות שמשודרגים יחד.
  • Fleets: fleets הם הדרך העיקרית לקבץ אשכולות. שלב ברצף השקה יכול להתייחס לצי אחד או יותר של מכשירים. רצף פריסה אחד יכול לכלול צי של מכשירים שמתארחים בכמה ארגונים. Cloud de Confiance by S3NS
  • סלקטורים של תוויות: רצף השקה מורכב משלב אחד או יותר. כל שלב מכיל אשכולות מצי אחד או יותר, ואפשר להשתמש בבוררי תוויות באשכולות כדי לפצל צי למספר שלבים. הגישה הזו מאפשרת להשתמש באסטרטגיות כמו השקות מדורגות, שבהן משדרגים קודם קבוצת משנה קטנה של אשכולות ייצור.

איך 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

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

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

כדי ליישם את התוכנית הזו, האדמין מחיל את התוויות הבאות על האשכולות ב-Fleet של Production:

  • אשכולות ב-us-west1 (תנועה נמוכה יותר) מסומנים בתווית prod-region: us-west1.
  • אשכולות ב-europe-west1 (תנועה גבוהה יותר) מסומנים בתווית prod-region: europe-west1.
  • אשכולות ב-us-east1 (התנועה הקריטית ביותר) לא מסומנים. השלב האחרון של צי בתוך רצף חייב לשמש כ 'פתרון' לכל האשכולות שנותרו. לכן, האדמין לא צריך להוסיף תוויות לאשכולות הנותרים.

לאחר מכן, בפרויקט מארח ייעודי שמשמש לניהול הגדרות CI/CD, הם מגדירים אובייקט RolloutSequence. לרצף החדש יש חמישה שלבים נפרדים:

  1. בדיקה: השלב הזה כולל את כל האשכולות ב-Fleet testing. האדמין מגדיר זמן טבילה של שלושה ימים כדי לאפשר אימות יסודי.
  2. הכנה: השלב הזה כולל את כל האשכולות בצי staging, עם תקופת הרצה של שלושה ימים.
  3. ייצור באזור us-west1: בשלב הזה מטרגטים את צי הייצור, אבל משתמשים ב-label-selector כדי לכלול רק את האשכולות עם התווית prod-region: us-west1. בשלב הזה האדמין יכול לעקוב אחרי בעיות בקבוצת משנה קטנה של אשכולות ייצור עם תקופת הרצה של שלושה ימים.
  4. Production in region europe-west1 (ייצור באזור ): השלב הזה כולל את האשכולות ב-Fleet production עם התווית prod-region: europe-west1. האדמין מגדיר תקופת הרצה ארוכה יותר של ארבעה ימים כדי לבצע אימות יסודי יותר.
  5. ייצור באזור us-east1: השלב הסופי הזה כולל את האשכולות שנותרו בצי production, כלומר את כל האשכולות ב-us-east1.

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

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

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

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

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

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

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

איך GKE מתחיל את ההשקה של גרסה חדשה

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

אבל אפשר גם לבחור גרסה שרוצים ש-GKE ישיק.

השקת גרסה ספציפית

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

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

בחירת סוגי השדרוגים ש-GKE מבצע ברצף השקה

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

יש ארבעה סוגים עיקריים של שדרוגים:

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

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

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

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

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

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

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

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

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

מידע נוסף על כללי המדיניות האלה מופיע בסעיפים הבאים:

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

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

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

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

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

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

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

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

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

השריה כפויה אחרי 30 ימים

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

איך רצף ההשקה פועל עם תכונות שדרוג אחרות

התכונה 'השקה מדורגת' פועלת בשילוב עם תכונות אחרות של שדרוג GKE:

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

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

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

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

  • ערוצי הפצה: מומלץ לרשום את כל האשכולות לרצף פריסה באותו ערוץ הפצה.

  • זיהוי שימוש בהוצאה משימוש: זיהוי השימוש בהוצאה משימוש ב-GKE עדיין פועל כמצופה, ויכול להיות ששדרוגים יושהו באשכולות שמשתמשים ב-API שהוצא משימוש.

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

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

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

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

שיקולים לבחירת רצף ההשקה

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

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

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

התראות על רצף ההשקה

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

ניהול השקה

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

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

השהיית השקת תכונה

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

כדי להשהות את ההשקה, אפשר לעיין במאמר בנושא השהיית השקה.

אחרי שמשהים את ההשקה, אפשר להמשיך או לבטל אותה. אפשר להשהות השקה למשך עד 90 יום. אחרי 90 יום, מערכת GKE מבטלת את ההשקה.

השהיה של השקה לא מונעת את ההתחלה של השקות עתידיות. עם זאת, ההשקות האלה לא יחליפו את שלב ההשקה שהושהה. לדוגמה, אם GKE כבר פרס את גרסה 1.34.8-gke.1000000 בשלבים הראשון והשני, ואתם משהים את הפריסה בשלב השלישי, GKE יכול להתחיל פריסה חדשה לגרסה 1.35.5-gke.1163000 ולשדרג את האשכולות בשני השלבים הראשונים. עם זאת, GKE לא יתחיל שדרוגים לגרסה ‎1.35.5-gke.1163000 בשלב השלישי עד שההשקה של גרסה ‎1.34.8-gke.1000000 בשלב השלישי תסתיים או תבוטל.

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

המשך השקה

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

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

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

ביטול פריסה

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

כדי לבטל השקה, אפשר לעיין במאמר בנושא ביטול השקה.

אם אתם צריכים להשיק את אותה גרסה שבוטלה, משיקים גרסה ספציפית.

השלמת שלב בהשקה

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

במאמר השלמת שלב בהשקה מוסבר איך להשלים שלב בהשקה.

ניהול השקה באמצעות שינוי רצף ההשקה

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

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

שליטה בשדרוגים של אשכולות ספציפיים כדי לנהל את ההשקה

כדי לשדרג אשכולות בודדים, אפשר להשתמש בכלים הבאים לניהול שדרוגים:

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

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

ניהול רצף השקה

כדי לנהל רצף של השקת תכונות, אפשר לבצע פעולות בסיסיות כמו:

  • רשימת רצף ההשקה
  • תארו רצף השקה

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

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

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

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

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

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

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

שינוי רצף ההשקה

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

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

אם משנים רצף השקה, קורה הדבר הבא:

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

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

אם משנים את האשכולות ברצף, קורה הדבר הבא:

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

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

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

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

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

    • אם מעבירים אשכול לשלב שכבר הושלם, GKE לא משדרג את האשכול באותו שלב.
    • אם מעבירים אשכול שכבר שודרג בהשקה לשלב מאוחר יותר שלא הושלם, GKE מתעלם מהאשכול ולא יפריע להתקדמות ההשקה.

כדי לשנות את האשכולות ברצף, אפשר לעיין במאמר רישום אשכול ב- Cloud de Confiance by S3NS ב-Fleet.

מגבלות

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

  • אי אפשר להשתמש במסוף Cloud de Confiance כדי ליצור או להציג רצפים של השקות עם שלבים מותאמים אישית.
  • כשמגדירים רצף השקה שמתייחס לצי, צריך לכלול את כל הצי. המשמעות של המגבלה הזו היא שאם מגדירים שלב שמטרגט רק קבוצת משנה של אשכולות מצי של אשכולות עם label-selector (למשל, לפריסה מדורגת), צריך להגדיר גם שלב 'catch-all' עוקב שכולל את כל האשכולות שנותרו מאותו צי. השלב הזה הוא שלב כללי שמטרגט את אותה קבוצת מכונות, אבל לא כולל label-selector, ולכן הוא כולל באופן אוטומטי את כל האשכולות שלא נבחרו בשלבים הקודמים ברצף.
  • אם משנים רצף במהלך השקה, במיוחד שינויים שמשפיעים על האשכולות המשתתפים, GKE מבטל באופן מיידי את כל ההשקות הקיימות. אם משנים רק את זמן הטבילה של רצף, GKE לא מבטל את ההשקה.
  • אפשר להפנות ל-Fleet אחד רק ברצף השקה אחד. שתי רצפים של השקה לא יכולים להפנות לאותו צי.
  • אפשר ליצור רק אובייקט אחד מסוג RolloutSequence לכל פרויקט מארח.
  • אי אפשר לשדרג אשכולות עם רצף השקה שמשתמשים בשדרוגים אוטומטיים של תיקוני אבטחה מואצים.
  • אפשר ליצור רצף השקה עם עד 15 שלבים.
  • אפשר לכלול עד 250 אשכולות ב-Fleet. במקרה של אשכולות עם חברות קלה, אפשר לבקש להגדיל את המכסה לעד 2,000 אשכולות בצי. מידע נוסף מופיע במאמר בנושא מכסות ומגבלות.
  • אפשר להגדיר זמן השהיה מקסימלי לכל רצף של עד 90 ימים בכל השלבים.

בעיות מוכרות

בקטע הזה מפורטות הבעיות הידועות שקשורות להפצה מדורגת עם שלבים מותאמים אישית.

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

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