‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

שדרוג אשכולות

כשמתקינים גרסה חדשה של bmctl, אפשר לשדרג את האשכולות הקיימים שנוצרו בגרסה קודמת. שדרוג אשכול לגרסה האחרונה של Google Distributed Cloud מוסיף לאשכול תכונות ותיקונים. כך גם תוכלו להמשיך לקבל תמיכה באשכול. אפשר לשדרג אשכולות של אדמין, היברידיים, עצמאיים או של משתמשים באמצעות הפקודה bmctl upgrade cluster, או באמצעות kubectl.

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

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

תכנון השדרוג

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

שיטות מומלצות

במאמר שיטות מומלצות לשדרוג אשכולות ב-Google Distributed Cloud מוסבר איך להתכונן לשדרוג אשכול.

בדיקות לפני השדרוג

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

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

בעיות מוכרות

למידע על בעיות פוטנציאליות שקשורות לשדרוגי אשכולות, קראו את המאמר בעיות מוכרות ב-Google Distributed Cloud ל-bare metal ובחרו בקטגוריית הבעיות שדרוגים ועדכונים.

הגדרת אפשרויות השדרוג

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

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

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

דילוג על השדרוגים

החל מגרסה 1.33, Google Distributed Cloud תומכת בדילוג על שדרוגים לכל סוגי האשכולות, ומאפשרת לשדרג אשכול לגרסת יעד (1.33 ואילך) שמתקדמת בשתי גרסאות משניות מהגרסה הנוכחית שלו בפעולה אחת. לדוגמה, אפשר לשדרג מגרסה 1.N.X ישירות לגרסה 1.N+2.Z בפעולה אחת.

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

‫1.34 ואילך: זמינות כללית (GA)
‫1.33: תצוגה מקדימה
‫1.32 ומטה: לא זמין

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

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

דילוג על שדרוגים של אשכולות נמצא בגרסת טרום-השקה (Preview) בגרסה 1.33. לא מומלץ לדלג על שדרוגים מגרסה 1.31 לגרסה 1.33 באשכולות בסביבת הייצור.

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

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

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

מוסיפים את ההערה preview.baremetal.cluster.gke.io/skip-minor-version-cluster-upgrade לקובץ התצורה של האשכול:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/skip-minor-version-cluster-upgrade: "enable"
spec:
  type: user
  profile: default
  anthosBareMetalVersion:   1.36.200-gke.118
  ...

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

כמו בשדרוגים רציפים, אתם יכולים להתחיל את השדרוג בדילוג באמצעות bmctl upgrade cluster או kubectl apply.

דרישה נוספת למאגרי מראות

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

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

משתמשים בגרסה של bmctl שתואמת לגרסת היעד של השדרוג בדילוג, כדי לגלות מהי גרסת הביניים של השדרוג בדילוג:
```
bmctl upgrade intermediate-version
```
התגובה לפקודה כוללת את גרסת התיקון הספציפית של Google Distributed Cloud שהמערכת משתמשת בה כגרסת הביניים במהלך השדרוג בדילוג. לדוגמה, בגרסה 1.33.0-gke.799 של bmctl, התגובה תיראה כך:
```
1.32.200-gke.104
```
מורידים את חבילות התמונות של גרסת היעד ושל גרסת הביניים.

מידע נוסף זמין במאמר הורדת חבילת התמונות.
לפני שמתחילים את השדרוג בדילוג, מעבירים את חבילות התמונות גם של גרסת היעד וגם של גרסת הביניים ל-registry mirror.

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

כמו בשדרוגים רציפים, אתם יכולים להתחיל את השדרוג בדילוג באמצעות bmctl upgrade cluster או kubectl apply.

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

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

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

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

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

באשכולות מגרסה 1.28 ואילך, גרסת מאגר צומתי העובדים יכולה להיות עד שתי גרסאות משניות לפני גרסת האשכול (מישור הבקרה). בזכות התמיכה בסטיית גרסה של n-2, אתם יכולים גם לדלג על גרסת הפצה משנית כשאתם משדרגים מאגר של צומתי עובדים משתי גרסאות משניות לפני האשכול לאותה גרסה משנית כמו האשכול.

התמיכה בגרסה n-2 של מאגרי צומתי העובדים מאפשרת לכם לתכנן את השדרוגים של ה-fleet בצורה גמישה יותר.

לדוגמה, אם יש לכם אשכול בגרסה 1.36, אתם יכולים להגדיר מאגרי צומתי עובדים בגרסאות נבחרות של 1.36, 1.35 ו-1.34.

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

לדוגמה, אם יש לכם אשכול בגרסה 1.29 ומאגרי צומתי עובדים בגרסאות 1.29,‏ 1.28 ו-1.16, אתם צריכים לשדרג את מאגרי הצמתים בגרסה 1.16 לגרסה 1.28 או 1.29 לפני שתוכלו לשדרג את האשכול לגרסה 1.30.

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

‫1.30 ומעלה

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

אפשר לשדרג מאגרי צמתים בכל גרסת תיקון של הגרסאות המשניות 1.28 ו-1.29 לכל גרסת תיקון של 1.30, אם גרסת מאגר הצמתים זהה לגרסת האשכול או נמוכה ממנה.

1.29

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

בזמן שאנחנו מעבירים את התכונה הזו מגרסת Public Preview לזמינות לכלל המשתמשים (GA), אשכולות היברידיים עדיין דורשים את ההערה של גרסת טרום-השקה במצב הבא. אם יש לכם אשכול היברידי בגרסה 1.28.x עם מאגר צומתי עובדים בגרסה 1.16.y, אתם צריכים להוסיף את ההערה preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable לאשכול לפני שאתם משדרגים אותו לגרסה 1.29.z:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.28.400-gke.77
  ...

1.28

התמיכה בסטיית הגרסה n-2 למאגרי צומתי עובדים זמינה בגרסת טרום-השקה (Preview) בגרסה 1.28. כדי להפעיל את היכולת הזו בגרסת טרום-השקה (Preview), מוסיפים את ההערה preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable לקובץ התצורה של האשכול:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
...

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

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

שדרוג של מישור הבקרה של האשכול ומאגרי הצמתים שנבחרו

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

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

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

לדוגמה, נניח שהאשכול שלכם הוא בגרסה 1.35.0 ויש לו שני מאגרים של צומתי עובדים: wpool01 ו-wpool02. נניח שאתם רוצים לשדרג את מישור הבקרה ואת wpool01 לגרסה ‎1.36.200-gke.118, אבל אתם רוצים ש-wpool02 יישאר בגרסה ‎1.35.0.

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

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.36.200-gke.118
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.36.200-gke.118
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.35.0
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

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

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

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

עורכים את המפרטים של NodePool בקובץ התצורה של האשכול, למאגרי צומתי ה-worker שרוצים לשדרג לגרסה הנוכחית של האשכול. מגדירים את anthosBareMetalVersion לגרסת האשכול הנוכחית (אחרי השדרוג).

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

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

לדוגמה, נניח ששדרגתם את האשכול לגרסה ‎1.36.200-gke.118, אבל מאגר הצמתים wpool02 עדיין בגרסה הישנה של האשכול לפני השדרוג, ‎1.35.0. עומסי העבודה פועלים כמו שצריך במאגר הצמתים המשודרג, wpool01, ועכשיו אתם רוצים לשדרג גם את wpool02 לגרסה הנוכחית של האשכול. כדי לשדרג את wpool02, אפשר להסיר את השדה anthosBareMetalVersion או להגדיר את הערך שלו כמחרוזת ריקה.

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

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.36.200-gke.118
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.36.200-gke.118
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: ""
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

חזרה לגרסה קודמת של מאגר צמתים

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

התכונה הזו לא נמצאת באותו שלב השקה בכל גרסאות האשכולות הנתמכות:

‫1.30 ומעלה

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

1.29

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

preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable

1.28

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

כדי להחזיר את מאגר הצמתים לגרסה קודמת:

`bmctl`

כשמשתמשים ב-bmctl כדי להחזיר לאחור שדרוג של מאגר צמתים, עורכים את קובץ התצורה של האשכול ומחילים את השינויים באמצעות הפקודה bmctl update:

עורכים את המפרט של NodePool בקובץ התצורה של האשכול, למאגרי צומתי העובדים שרוצים להחזיר לגרסה הקודמת. מגדירים את anthosBareMetalVersion לגרסת האשכול הקודמת (לפני השדרוג).
```
...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.35.600-gke.141
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
```
אם בוחרים כמה מאגרי צמתים עובדים להחזרה למצב קודם, הערך של spec.nodePoolUpgradeStrategy.concurrentNodePools במפרט האשכול קובע כמה מאגרי צמתים יוחזרו למצב קודם במקביל. אם אתם לא רוצים להחזיר לגרסה קודמת את מאגרי הצמתים העובדים בו-זמנית, בחרו מאגר צמתים אחד בכל פעם להחזרה לגרסה קודמת או עדכנו את ההגדרות של nodePoolUpgradeStrategy. באופן דומה, הערך של spec.upgradeStrategy.parallelUpgrade.concurrentNodes במפרט של NodePool קובע כמה צמתים יוחזרו לגרסה קודמת במקביל.
משתמשים ב-bmctl update כדי להחיל את השינויים במפרט של NodePool:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם האשכול שרוצים לעדכן.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של האשכול המנהל (אדמין, היברידי או עצמאי).
החזרה לגרסה קודמת מתחילה באופן אוטומטי. הפקודה bmctl update cluster מסתיימת מיד, אבל תהליך החזרה למצב הקודם ממשיך. אל תבצעו פעולות אחרות באשכול בזמן שהחזרה למצב הקודם מתבצעת.
בזמן שהחזרה לגרסה הקודמת פועלת, Google Distributed Cloud מבצע את הפעולות הבאות בכל צומת:
- מעבירים את הצומת למצב תחזוקה.
- מריצים משימת איפוס בצומת כדי להביא אותו למצב נקי.
- מריצים בדיקות מקדימות של המכונה בצומת.
- מריצים משימת machine-init בצומת כדי להתקין אותו מחדש בגרסת היעד של החזרה למצב קודם (לפני השדרוג).
- מסירים את הצומת ממצב תחזוקה.
בסיום החזרה מוצלחת לגרסה קודמת, הערך של nodePool.status.anthosBareMetalVersion במשאב NodePool מוגדר לגרסת היעד של החזרה לגרסה קודמת.

אל תשתמשו ב-bmctl update וב-kubectl apply -f לסירוגין כשאתם עורכים את קובץ התצורה של האשכול. אם משתמשים בפקודות האלה לסירוגין, יכול להיות שתוכן שמאוכלס על ידי הכותרת של מפרט האשכול יוסר בטעות. לדוגמה, אתם יכולים להשתמש ב-bmctl update כדי לעדכן את קובץ התצורה של האשכול כדי להגדיר שיקוף של מאגר. לאחר ההתאמה, האשכול יכלול את spec.nodeConfig.registryMirrors.

אם תנסו לבצע שינויים באשכול באמצעות הגדרת האשכול עם הפקודה kubectl apply -f, השדה spec.nodeConfig.registryMirrors שמאוכלס על ידי ה-reconciler באשכול יוסר. זה קורה כי ההגדרה לא קיימת במפרט של הגדרת האשכול, אבל היא קיימת באשכול.

`kubectl`

כדי להחזיר את מאגר הצמתים לגרסה הקודמת, אפשר להשתמש ב-kubectl כדי לערוך את המשאב NodePool ישירות:

כדי להחזיר את מאגר הצמתים העובדים לגרסה קודמת, פותחים את המשאב NodePool לעריכה:
```
kubectl edit nodepool NODE_POOL_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NODE_POOL_NAME: שם מאגר הצמתים שאתם מחזירים לגרסה קודמת.
- ‫CLUSTER_NAMESPACE: השם של מרחב השמות שבו נפרס מאגר הצמתים. זהו מרחב השמות של האשכול.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של האשכול המנהל (אדמין, היברידי או עצמאי).

משנים את הערך של spec.anthosBareMetalVersion לגרסה הקודמת (לפני השדרוג).

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.35.600-gke.141
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...

שומרים וסוגרים את המשאב NodePool בכלי העריכה.

החזרה לגרסה קודמת מתחילה באופן אוטומטי. אל תבצעו פעולות אחרות באשכול בזמן שהחזרה למצב הקודם מתבצעת.
בזמן שהחזרה לגרסה הקודמת פועלת, Google Distributed Cloud מבצע את הפעולות הבאות בכל צומת:
- מעבירים את הצומת למצב תחזוקה.
- מריצים משימת איפוס בצומת כדי להביא אותו למצב נקי.
- מריצים בדיקות מקדימות של המכונה בצומת.
- מריצים משימת machine-init בצומת כדי להתקין אותו מחדש בגרסת היעד של החזרה למצב קודם (לפני השדרוג).
- מסירים את הצומת ממצב תחזוקה.
בסיום החזרה מוצלחת לגרסה קודמת, הערך של nodePool.status.anthosBareMetalVersion במשאב NodePool מוגדר לגרסת היעד של החזרה לגרסה קודמת.

שדרוגים מקבילים

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

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

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

אסטרטגיית שדרוג הצמתים

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

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

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

הערך של concurrentNodes לא יכול להיות גדול מ-50% ממספר הצמתים במאגר הצמתים, או מהמספר הקבוע 15, הקטן מביניהם. לדוגמה, אם במאגר הצמתים יש 20 צמתים, אי אפשר לציין ערך שגדול מ-10. אם במאגר הצמתים יש 100 צמתים, הערך המקסימלי שאפשר לציין הוא 15.
כשמשתמשים ב-concurrentNodes יחד עם minimumAvailableNodes, הערכים המשולבים לא יכולים לחרוג מהמספר הכולל של הצמתים במאגר הצמתים. לדוגמה, אם במאגר הצמתים יש 20 צמתים והערך של minimumAvailableNodes הוא 18, הערך של concurrentNodes לא יכול להיות גדול מ-2. באופן דומה, אם המדיניות concurrentNodes מוגדרת לערך 10, הערך של המדיניות minimumAvailableNodes לא יכול להיות גדול מ-10.

בדוגמה הבאה מוצג מאגר צומתי עובדים np1 עם 10 צמתים. במהלך שדרוג, הצמתים משודרגים בקבוצות של 5 צמתים בכל פעם, ולפחות 4 צמתים צריכים להישאר זמינים כדי שהשדרוג ימשיך:

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  - address:  10.200.0.4
  - address:  10.200.0.5
  - address:  10.200.0.6
  - address:  10.200.0.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  - address:  10.200.0.10 
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 4

אסטרטגיית שדרוג של מאגר צמתים

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

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

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

איך מבצעים שדרוג מקביל

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

כדי לשדרג במקביל מאגרים של צומתי עובדים וצמתים במאגר של צומתי עובדים:

מוסיפים קטע upgradeStrategy למפרט של NodePool.

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

הנה דוגמה:
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-ci-bf8b9aa43c16c47
spec:
  clusterName: ci-bf8b9aa43c16c47
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.30
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 10
```
בדוגמה הזו, הערך של השדה concurrentNodes הוא 5, כלומר 5 צמתים משודרגים במקביל. השדה minimumAvailableNodes מוגדר לערך 10, כלומר לפחות 10 צמתים צריכים להישאר זמינים לעומסי עבודה במהלך השדרוג.

הערה: אי אפשר לציין אסטרטגיית שדרוג צמתים למאגרי צמתים של מישור הבקרה או של מאזן העומסים.
מוסיפים קטע nodePoolUpgradeStrategy למפרט של האשכול בקובץ התצורה של האשכול.
```
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user001
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.36.200-gke.118
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...
```
בדוגמה הזו, השדה concurrentNodePools מוגדר לערך 0, כלומר כל מאגרי צמתים עובדים משודרגים בו-זמנית במהלך שדרוג האשכול. אסטרטגיית השדרוג של הצמתים במאגרי הצמתים מוגדרת במפרטים של NodePool.
משדרגים את האשכול כמו שמתואר בקטע הקודם, שדרוג אשכולות אדמין, אשכולות עצמאיים, אשכולות היברידיים או אשכולות משתמש.

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

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

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

שדה	ערך ברירת המחדל	משמעות
‫`nodePoolUpgradeStrategy.concurrentNodePools` (מפרט אשכול)	`1`	לשדרג את מאגרי הצמתים העובדים ברצף, אחד אחרי השני.
‫`upgradeStrategy.parallelUpgrade.concurrentNodes` (מפרט של NodePool)	`1`	משדרגים את הצמתים ברצף, אחד אחרי השני.
‫`upgradeStrategy.parallelUpgrade.minimumAvailableNodes` (מפרט של NodePool)	ערך ברירת המחדל של `minimumAvailableNodes` תלוי בערך של `concurrentNodes`. אם לא מציינים את `concurrentNodes`, הערך של `minimumAvailableNodes` הוא 2/3 מגודל מאגר הצמתים כברירת מחדל. אם מציינים את `concurrentNodes`, אז `minimumAvailableNodes` כברירת מחדל הוא גודל מאגר הצמתים פחות `concurrentNodes`.	השדרוג נעצר כשמגיעים ל-`minimumAvailableNodes`, וממשיך רק כשמספר הצמתים הזמינים גדול מ-`minimumAvailableNodes`.

התחלת השדרוג של האשכול

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

`bmctl`

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

מגדירים את פרטי הכניסה של המשתמש כ-Application Default Credentials ‏ (ADC):
```
gcloud auth application-default login
```
פועלים לפי ההנחיות כדי לבחור את חשבון Google ל-ADC. מידע נוסף זמין במאמר הגדרת Application Default Credentials.
מורידים את הגרסה האחרונה של bmctl, כמו שמתואר במאמר הורדות של Google Distributed Cloud.
מעדכנים את anthosBareMetalVersion בקובץ התצורה של האשכול לגרסת היעד של השדרוג.

גרסת היעד לשדרוג חייבת להתאים לגרסה של קובץ ה-bmctl שהורדתם. בקטע הקוד הבא של קובץ התצורה של האשכול, השדה anthosBareMetalVersion מעודכן לגרסה העדכנית:
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  type: admin
  # Anthos cluster version.
  anthosBareMetalVersion: 1.36.200-gke.118
```
משתמשים בפקודה bmctl upgrade cluster כדי להשלים את השדרוג:
```
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם האשכול שרוצים לשדרג.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
הערה: הפקודה bmctl upgrade מעדכנת רק את הערך של anthosBareMetalVersion ואת ההערות של גרסת טרום-ההשקה (Preview) במשאב המותאם אישית של האשכול. כדי לשנות שדות אחרים במפרט האשכול, צריך להשתמש בפקודה bmctl update. למידע נוסף, ראו עדכון אשכולות.

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

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

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

`kubectl`

כדי לשדרג אשכול באמצעות kubectl:

עורכים את קובץ התצורה של האשכול כדי להגדיר את anthosBareMetalVersion לגרסת היעד של השדרוג.
כדי להתחיל את השדרוג, מריצים את הפקודה הבאה:
```
kubectl apply -f CLUSTER_CONFIG_PATH
```
מחליפים את CLUSTER_CONFIG_PATH בנתיב של קובץ התצורה הערוך של האשכול.

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

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

השהיה והמשך של שדרוגים

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

התכונה הזו זמינה בגרסת טרום-השקה (Preview) לאשכולות שבהם כל הצמתים במישור הבקרה הם בגרסה משנית 1.28 ואילך. התכונה זמינה באופן כללי (GA) באשכולות שבהם כל הצמתים של מישור הבקרה הם בגרסה משנית 1.29 ואילך.

יכול להיות שתרצו להשהות שדרוג מהסיבות הבאות:

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

בזמן שהשדרוג של האשכול מושהה, אפשר לבצע את הפעולות הבאות:

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

בזמן שהשדרוג של האשכול מושהה, אי אפשר לבצע את הפעולות הבאות באשכול:

אי אפשר להתחיל שדרוג חדש של אשכול בזמן ששדרוג פעיל של אשכול מושהה.

הפעלת השהיה והמשך של השדרוג

‫Google Distributed Cloud גרסה 1.36

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

‫Google Distributed Cloud בגרסה 1.35

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

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

מוסיפים את ההערה preview.baremetal.cluster.gke.io/upgrade-pause-and-resume לקובץ התצורה של האשכול:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/upgrade-pause-and-resume: enable
spec:
...

כדי להחיל את השינוי, מעדכנים את האשכול:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם האשכול שרוצים לעדכן.
- ‫ADMIN_KUBECONFIG: באשכולות של אדמין, היברידיים או עצמאיים, מזינים את הנתיב לקובץ kubeconfig של האשכול. באשכול משתמש, מזינים את הנתיב לקובץ kubeconfig של אשכול האדמין.
אפשר לשנות את השדה nodePoolUpgradeStrategy.pause. אפשר להוסיף ולעדכן את המידע בכל שלב.

השהיית השדרוג

כדי להשהות שדרוג של אשכול, מגדירים את nodePoolUpgradeStrategy.pause ל-true במפרט של האשכול.

כדי להשהות שדרוג פעיל של אשכול:

מוסיפים את nodePoolUpgradeStrategy.pause לקובץ התצורה של האשכול ומגדירים אותו ל-true:
```
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  ...
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: true
  ...
```
אם השתמשתם ב-bmctl כדי להתחיל את השדרוג, תצטרכו לפתוח חלון טרמינל חדש כדי לבצע את השלב הבא.
כדי להחיל את השינוי, מעדכנים את האשכול:
```
bmctl update CLUSTER_NAME
```
פעולת השדרוג מושהית. לא מופעלים שדרוגים חדשים של צמתים.
אם השתמשתם ב-bmctl כדי להתחיל את השדרוג ואתם מתכננים הפסקה ארוכה, לחצו על Control+C כדי לצאת מ-bmctl. אחרת, המשיכו להפעיל את bmctl.

ה-CLI של bmctl לא מזהה שינויים בסטטוס ההשהיה של השדרוג, ולכן הוא לא נסגר באופן אוטומטי. עם זאת, כשיוצאים מ-bmctl, התהליך מפסיק לתעד את התקדמות השדרוג בקובץ היומן cluster-upgrade-TIMESTAMP בתיקיית האשכול בתחנת הניהול וב-Cloud Logging. לכן, אם אתם עושים הפסקות קצרות, כדאי להשאיר את bmctl פועל. אם משאירים את bmctl פועל למשך תקופה ארוכה בזמן שהשדרוג מושהה, בסופו של דבר הזמן הקצוב לתפוגה יסתיים.

המשך שדרוג שהושהה

כדי להמשיך שדרוג אשכול שהושהה, מגדירים את nodePoolUpgradeStrategy.pause ל-false במפרט האשכול או מסירים את nodePoolUpgradeStrategy.pause מהמפרט.

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

מגדירים את nodePoolUpgradeStrategy.pause בקובץ התצורה של האשכול ומגדירים אותו ל-false:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  ...
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: false
  ...

אפשר גם להסיר את השדה pause, כי ברירת המחדל שלו היא false.

כדי להחיל את השינוי, מעדכנים את האשכול:
```
bmctl update CLUSTER_NAME
```
פעולת השדרוג תמשיך מהמקום שבו היא הופסקה.
כדי לבדוק את סטטוס השדרוג, קודם צריך לקבל רשימה של המשאבים שכוללים את anthosBareMetalVersion ב-status שלהם:
```
kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫RESOURCE: שם המשאב שרוצים לקבל. המשאבים Cluster,‏ NodePool ו-BareMetalMachine מכילים את פרטי הסטטוס של anthosBareMetalVersion.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
הדוגמה הבאה מציגה את הפורמט של התגובה ל-BareMetalMachine משאבים מותאמים אישית. כל BareMetalMachine תואם לצומת באשכול.
```
NAMESPACE              NAME         CLUSTER        READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
cluster-nuc-admin001   192.0.2.52   nuc-admin001   true    baremetal://192.0.2.52   192.0.2.52   1.28.0        1.28.0
cluster-nuc-user001    192.0.2.53   nuc-user001    true    baremetal://192.0.2.53   192.0.2.53   1.16.2        1.16.2
cluster-nuc-user001    192.0.2.54   nuc-user001    true    baremetal://192.0.2.54   192.0.2.54   1.16.2        1.16.2
```

כדי לבדוק את status.anthosBareMetalVersion (הגרסה הנוכחית של המשאב), מאחזרים פרטים של משאבים ספציפיים:

kubectl describe RESOURCE RESOURCE_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

בדוגמה הבאה מוצגים פרטי BareMetalMachine של צומת האשכול עם כתובת ה-IP‏ 192.0.2.53:

Name:         192.0.2.53
Namespace:    cluster-nuc-user001
...
API Version:  infrastructure.baremetal.cluster.gke.io/v1
Kind:         BareMetalMachine
Metadata:
  Creation Timestamp:  2023-09-22T17:52:09Z
  ...
Spec:
  Address:                    192.0.2.53
  Anthos Bare Metal Version:  1.16.2
  ...
Status:
  Anthos Bare Metal Version:  1.16.2

בדוגמה הזו, הצומת הוא בגרסה 1.16.2 של Google Distributed Cloud.

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

תכנון השדרוג

שיטות מומלצות

בדיקות לפני השדרוג

בעיות מוכרות

הגדרת אפשרויות השדרוג

דילוג על השדרוגים

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

דרישה נוספת למאגרי מראות

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

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

‫1.30 ומעלה

1.29

1.28

שדרוג של מישור הבקרה של האשכול ומאגרי הצמתים שנבחרו

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

חזרה לגרסה קודמת של מאגר צמתים

‫1.30 ומעלה

1.29

1.28

bmctl

kubectl

שדרוגים מקבילים

אסטרטגיית שדרוג הצמתים

אסטרטגיית שדרוג של מאגר צמתים

איך מבצעים שדרוג מקביל

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

התחלת השדרוג של האשכול

bmctl

kubectl

השהיה והמשך של שדרוגים

הפעלת השהיה והמשך של השדרוג

‫Google Distributed Cloud גרסה 1.36

‫Google Distributed Cloud בגרסה 1.35

השהיית השדרוג

המשך שדרוג שהושהה

שדרוג אשכולות

`bmctl`

`kubectl`

`bmctl`

`kubectl`