דילוג על גרסה בשדרוג של מאגרי צמתים

בגרסה 1.29 ואילך, Google Distributed Cloud מאפשרת למישור הבקרה של אשכול משתמשים להיות עד שתי גרסאות משניות גבוהות יותר ממאגרי הצמתים באשכול. לדוגמה, אם מישור הבקרה של אשכול משתמשים הוא בגרסה 1.29, מאגרי הצמתים באשכול יכולים להיות בגרסה 1.16,‏ 1.28 או 1.29. בנוסף, Google Distributed Cloud מאפשר לדלג על גרסה משנית אחת כשמשדרגים מאגרי צמתים. בדוגמה הקודמת, אפשר לשדרג מאגרי צמתים בגרסה 1.16 ישירות לגרסה 1.29 ולדלג על השדרוג לגרסה 1.28. דילוג על גרסה משנית כשמשדרגים מאגרי צמתים נקרא שדרוג עם דילוג על גרסה.

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

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

מגבלות

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

  • שדרוגים של דילוג על גרסה נתמכים במאגרי צמתים של Ubuntu ו-COS, אבל לא במאגרי צמתים של Windows.

  • גרסה 1.31: התכונה הזו לא זמינה באשכולות מתקדמים.

  • גרסה 1.32 ואילך: התכונה הזו זמינה באשכולות מתקדמים.

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

היתרונות של שדרוגים לדילוג על גרסאות

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

קל יותר לשמור את האשכולות בגרסה נתמכת

גרסה משנית חדשה של Google Distributed Cloud יוצאת כל ארבעה חודשים, ולכל גרסה משנית יש חלון תמיכה של שנה אחת. כדי שהאשכולות יישארו במסגרת חלון הזמן הנתמך, צריך לבצע שדרוג של גרסה משנית בערך כל ארבעה חודשים, כמו שמוצג כאן:

Dec

ינואר

פברואר

מרס

אפריל

מאי

יוני

יולי

אוגוסט

ספטמבר

אוקטובר

נובמבר

Dec

ינואר

פברואר

מרס

אפריל

מאי

יוני

יולי

אוגוסט

ספטמבר

אוקטובר

נובמבר

Dec

ינואר

פברואר

מרס
‫1.14 שדרוג
1.15 שדרוג
1.16 שדרוג
‫1.28 שדרוג
1.29 שדרוג

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

Dec

ינואר

פברואר

מרס

אפריל

מאי

יוני

יולי

אוגוסט

ספטמבר

אוקטובר

נובמבר

Dec

ינואר

פברואר

מרס

אפריל

מאי

יוני

יולי

אוגוסט

ספטמבר

אוקטובר

נובמבר

Dec

ינואר

פברואר

מרס
‫1.14 שדרוג
1.15
1.16 שדרוג
‫1.28
1.29

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

חלון זמן קצר יותר לתחזוקה

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

סיכום

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

  • העברת אשכולות לגרסה נתמכת: Google Distributed Cloud תומך בשלוש הגרסאות המשניות האחרונות. אם האשכולות שלכם הם בגרסה לא נתמכת, בהתאם לגרסת האשכול, דילוג על גרסה משנית במהלך שדרוג מאגרי הצמתים יכול להביא את האשכולות לגרסה נתמכת עם פחות שדרוגים.

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

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

שליטה בגרסאות של רמת הבקרה ושל מאגר הצמתים במהלך שדרוג

בקובץ התצורה של אשכול המשתמשים, השדה nodePools[i].gkeOnPremVersion מאפשר למאגר צמתים ספציפי להשתמש בגרסה שונה מהשדה gkeOnPremVersion ברמה העליונה. שינוי הערך של השדה nodePools[i].gkeOnPremVersion מאפשר לכם לשלוט במועד השדרוג של מאגר הצמתים כשמריצים את הפקודה gkectl upgrade cluster. אם לא כוללים את nodePools[i].gkeOnPremVersion בקובץ ההגדרות, או אם מגדירים את השדה למחרוזת ריקה, מאגרי הצמתים משודרגים לאותה גרסת יעד שמציינים ב-gkeOnPremVersion.

כללי גרסה

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

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

  • בגרסאות 1.31 ואילך, גרסת אשכול האדמין, כולל גרסת התיקון, צריכה להיות גדולה או שווה לגרסת אשכול המשתמש. לדוגמה, אם גרסת אשכול האדמין היא 1.31.1, הגרסה הכי גבוהה שאפשר לשדרג אליה את אשכול המשתמש היא 1.31.1.

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

דילוג על רצף שדרוג הגרסה

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

‫1.32 ומעלה

משתמשים ברצף הזה אם גרסת היעד היא 1.32 ומעלה. נניח שמישור הבקרה של אשכול המשתמשים וכל מאגרי הצמתים נמצאים בגרסה משנית 1.N. באופן כללי, שדרוג האשכול מ-1.N ל-1.N+2 באמצעות שדרוג מדלג מתבצע באופן הבא:

  1. משדרגים את אשכול הניהול מגרסה 1.N לגרסת ביניים, 1.N+1.
  2. משדרגים את אשכול האדמין מהגרסה הביניים, 1.N+1, לגרסת היעד 1.N+2.
  3. משדרגים רק את מישור הבקרה של אשכול המשתמשים מגרסת המקור, 1.N, לגרסת ביניים, 1.N+1. משאירים את מאגרי הצמתים בגרסת המקור. נדרשת גרסת ביניים כי צריך לשדרג את מישור הבקרה בגרסה משנית אחת בכל פעם.
  4. משדרגים את מישור הבקרה ואת מאגרי הצמתים לגרסת היעד, 1.N+2.

1.31

משתמשים ברצף המיוחד הזה אם אשכול המשתמשים הוא בגרסה 1.29, כלומר גרסת היעד היא 1.31. אם אשכול משתמשים הוא בגרסה 1.29, אשכול אדמין שמנהל את אשכול המשתמשים יכול להיות בגרסה 1.27, 1.28 או 1.29.

  1. אם אשכול האדמין שלכם הוא בגרסה 1.27, שדרגו אותו לגרסה 1.28.
  2. אם גרסת אשכול האדמין היא 1.28, צריך לשדרג אותה לגרסה 1.29.
  3. משדרגים רק את רמת הבקרה של אשכול המשתמשים מגרסת המקור, 1.29, לגרסת ביניים, 1.30. משאירים את מאגרי הצמתים בגרסת המקור. נדרשת גרסת הביניים 1.30 כי צריך לשדרג את מישור הבקרה בגרסה משנית אחת בכל פעם.
  4. משדרגים את אשכול האדמין מגרסה 1.29 לגרסת הביניים 1.30.
  5. משדרגים את אשכול האדמין לגרסת היעד, 1.31.
  6. משדרגים את מישור הבקרה של אשכול המשתמשים ואת מאגרי הצמתים לגרסת היעד, 1.31.

‫1.30 ומטה

משתמשים ברצף הזה אם גרסת היעד היא 1.30 או גרסה נמוכה יותר.

נניח שמישור הבקרה של אשכול המשתמשים וכל מאגרי הצמתים נמצאים בגרסה משנית 1.N. באופן כללי, שדרוג האשכול מ-1.N ל-1.N+2 באמצעות שדרוג מדלג מתבצע באופן הבא:

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

ביצוע שדרוג של דילוג על גרסה

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

לפני שמתחילים

  1. מוודאים שהגרסה הנוכחית (גרסת המקור) של האשכול היא גרסה 1.16 ואילך. חשוב לבדוק את הגרסה של מישור הבקרה (gkeOnPremVersion) ואת כל מאגרי הצמתים (nodePools[i].gkeOnPremVersion).

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

  3. כדי לשדרג לגרסה 1.28 ואילך, צריך להפעיל את kubernetesmetadata.googleapis.com ולהקצות את תפקיד ה-IAM‏ kubernetesmetadata.publisher לחשבון השירות של שירות הרישום ביומן והמעקב. פרטים נוספים זמינים במאמר דרישות של Google API ו-IAM.

ביצוע השדרוג

1.31

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

כשגרסת אשכול המשתמשים היא 1.29, גרסת אשכול האדמינים שמנהל את אשכול המשתמשים יכולה להיות 1.27,‏ 1.28 או 1.29.

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

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

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

    rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz

אחרי שגרסת אשכול האדמין וכל אשכולות המשתמשים תהיה 1.29, תוכלו להתחיל את השדרוג של דילוג על גרסה.

  1. מגדירים את גרסת המקור (1.29), גרסת ביניים (1.30) וגרסת היעד (1.31) במשתני placeholder הבאים. כל הגרסאות צריכות להיות מספר הגרסה המלא בפורמט x.y.z-gke.N, למשל 1.29.700-gke.110.

    גרסה
    קבלת גרסה 1.29 של אשכול המשתמש הנוכחי. זו גרסת המקור. SOURCE_VERSION
    בוחרים גרסת ביניים 1.30. INTERMEDIATE_VERSION
    בוחרים את גרסת היעד 1.31. בוחרים את התיקון המומלץ מגרסה משנית 1.31. TARGET_VERSION

  2. משדרגים את תחנת העבודה של האדמין לגרסת הביניים 1.30, INTERMEDIATE_VERSION. מחכים להודעה שהשדרוג הושלם בהצלחה.

  3. מתקינים את החבילה המתאימה:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

  5. מתקינים את החבילה המתאימה:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  6. משדרגים רק את מישור הבקרה של אשכול המשתמשים לגרסת הביניים באופן הבא:

    1. מבצעים את השינויים הבאים בקובץ התצורה של אשכול המשתמשים:

      • מגדירים את השדה gkeOnPremVersion לגרסת הביניים, INTERMEDIATE_VERSION.

      • מגדירים את כל הגרסאות של מאגר הצמתים ב-nodePools[i].gkeOnPremVersion לגרסת המקור, SOURCE_VERSION.

      אחרי העדכון, קובץ התצורה אמור להיראות כך:

      gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...

    2. משדרגים את מישור הבקרה:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

      מחליפים את USER_CLUSTER_CONFIG בנתיב של קובץ התצורה של אשכול המשתמשים.

  7. מגדירים את השדה bundlePath בקובץ התצורה של אשכול הניהול לגרסת הביניים 1.30 של חבילת ה-App Bundle:

    bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"

  8. משדרגים את אשכול האדמין לגרסת הביניים 1.30:

    gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  9. מגדירים את השדה bundlePath בקובץ התצורה של אשכול הניהול לגרסת היעד 1.31 של החבילה:

    bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"

  10. Upgrade the admin cluster to the target 1.31 version:

    gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  11. משדרגים את מישור הבקרה ואת מאגרי הצמתים לגרסת היעד באופן הבא:

    1. מבצעים את השינויים הבאים בקובץ התצורה של אשכול המשתמשים:

      • מגדירים את השדה gkeOnPremVersion לגרסת היעד TARGET_VERSION.

      • מגדירים את כל nodePools[i].gkeOnPremVersion כמחרוזת ריקה.

      אחרי העדכון, קובץ התצורה אמור להיראות כך:

      gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...

    2. שדרוג מישור הבקרה ומאגרי הצמתים:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

‫1.30 ומטה

משתמשים ברצף הזה אם גרסת היעד היא 1.30 או גרסה נמוכה יותר.

  1. מגדירים את גרסת המקור (1.N), את גרסת הביניים (1.N+1) ואת גרסת היעד (1.N+2) במשתני ה-placeholder הבאים. כל הגרסאות צריכות להיות מספר הגרסה המלא בפורמט x.y.z-gke.N, למשל 1.16.11-gke.25.

    גרסה
    קבלת הגרסה הנוכחית של האשכול. זו גרסת המקור (1.N). SOURCE_VERSION
    בוחרים גרסת ביניים (1.N+1). INTERMEDIATE_VERSION
    בוחרים את גרסת היעד (1.N+2). בוחרים את התיקון המומלץ מגרסת המשנה של היעד. TARGET_VERSION

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

  3. מתקינים את החבילה המתאימה:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    מחליפים את ADMIN_CLUSTER_KUBECONFIG בנתיב של קובץ kubeconfig של אשכול האדמין.

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

  5. מתקינים את החבילה המתאימה:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  6. משדרגים רק את מישור הבקרה לגרסת הביניים באופן הבא:

    1. מבצעים את השינויים הבאים בקובץ התצורה של אשכול המשתמשים:

      • מגדירים את השדה gkeOnPremVersion לגרסת הביניים, INTERMEDIATE_VERSION.

      • מגדירים את כל הגרסאות של מאגר הצמתים ב-nodePools[i].gkeOnPremVersion לגרסת המקור, SOURCE_VERSION.

      אחרי העדכון, קובץ התצורה אמור להיראות כך:

      gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...

    2. משדרגים את מישור הבקרה:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

      מחליפים את USER_CLUSTER_CONFIG בנתיב של קובץ התצורה של אשכול המשתמשים.

  7. משדרגים את מישור הבקרה ואת מאגרי הצמתים לגרסת היעד באופן הבא:

    1. מבצעים את השינויים הבאים בקובץ התצורה של אשכול המשתמשים:

      • מגדירים את השדה gkeOnPremVersion לגרסת היעד TARGET_VERSION.

      • מגדירים את כל nodePools[i].gkeOnPremVersion כמחרוזת ריקה.

      אחרי העדכון, קובץ התצורה אמור להיראות כך:

      gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...

    2. שדרוג מישור הבקרה ומאגרי הצמתים:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

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

rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz

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