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

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

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

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

סקירה כללית

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איך 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 שיצא משימוש או מסיבות אחרות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות

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

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

בעיות מוכרות

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

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

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