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

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

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

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

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

תכנון השדרוג

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

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

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

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

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

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

בעיות מוכרות

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

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

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

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

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

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

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

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

‫1.34 ואילך: GA
‫1.33: תצוגה מקדימה
גרסה 1.32 ומטה: לא זמין

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

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

האפשרות לדלג על שדרוגים של אשכולות נמצאת בתצוגה מקדימה בגרסה 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.35.300-gke.87
  ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

‫1.30 ומעלה

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

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

1.29

בגרסה 1.29, תמיכה בהטיה בגרסת n-2 למאגרי צמתים של עובדים זמינה לכולם (GA) לכל סוגי האשכולות. התכונה הזו מופעלת כברירת מחדל באשכולות בגרסה 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 למאגרי צמתי עובדים זמינה בגרסה 1.28 בתצוגה מקדימה. כדי להפעיל את היכולת הזו של תצוגה מקדימה, מוסיפים את ההערה 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:
...

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

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

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

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

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

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

לדוגמה, נניח שהאשכול שלכם הוא בגרסה 1.34.0 ויש לו שני מאגרי צמתים של עובדים: wpool01 ו-wpool02. נניח שרוצים לשדרג את רמת הבקרה ואת wpool01 לגרסה 1.35.300-gke.87, אבל רוצים ש-wpool02 יישאר בגרסה 1.34.0.

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

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.35.300-gke.87
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.35.300-gke.87
  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.34.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 בקובץ ההגדרות של האשכול עבור מאגרי הצמתים של העובדים שרוצים להעלות לגרסה הנוכחית של האשכול. מגדירים את הערך של [anthosBareMetalVersion] לגרסה הנוכחית של האשכול (אחרי השדרוג).

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

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

לדוגמה, נניח ששדרגתם את האשכול לגרסה 1.35.300-gke.87, אבל מאגר הצמתים wpool02 עדיין בגרסת האשכול הישנה שלפני השדרוג, 1.34.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.35.300-gke.87
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.35.300-gke.87
  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), היכולת להחזיר את מאגר הצמתים לגרסה קודמת היא GA ומופעלת כברירת מחדל.

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.34.700-gke.93
  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 מבצע את הפעולות הבאות לכל צומת:
- מעבירים את הצומת למצב תחזוקה.
- מריצים משימת איפוס בצומת כדי להחזיר אותו למצב נקי.
- מריצים בדיקות לפני ההפעלה של המכונה בצומת.
- מריצים עבודת אתחול של מכונה בצומת כדי להתקין אותה מחדש בגרסת היעד של החזרה (לפני השדרוג).
- מסירים את הצומת ממצב תחזוקה.
בסיום מוצלח של החזרה לגרסה קודמת, הערך של nodePool.status.anthosBareMetalVersion במשאב NodePool מוגדר לגרסה שאליה רוצים לחזור.

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

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

`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.34.700-gke.93
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...

שומרים את משאב NodePool וסוגרים אותו בעורך.

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

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

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

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

שדרוג צמתים במקביל: אתם יכולים להגדיר את מאגרי הצמתים של העובדים כך שכמה צמתים ישודרגו במקביל. שדרוגים מקבילים של צמתים מוגדרים במפרט 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.35.300-gke.87
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...
```
בדוגמה הזו, השדה concurrentNodePools מוגדר לערך 0, כלומר כל מאגרי צמתים עובדים משודרגים בו-זמנית במהלך שדרוג האשכול. אסטרטגיית השדרוג של הצמתים במאגרי הצמתים מוגדרת במפרטים של NodePool.
משדרגים את האשכול כמו שמתואר בקטע הקודם שדרוג אשכולות של אדמין, אשכולות עצמאיים, אשכולות היברידיים או אשכולות משתמשים.

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

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

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

שדה	ערך ברירת המחדל	משמעות
`nodePoolUpgradeStrategy.concurrentNodePools` (מפרט אשכול)	`1`	משדרגים את מאגרי הצמתים של העובדים באופן עוקב, אחד אחרי השני.
‫`upgradeStrategy.parallelUpgrade.concurrentNodes` (NodePool spec)	`1`	משדרגים את הצמתים ברצף, אחד אחרי השני.
‫`upgradeStrategy.parallelUpgrade.minimumAvailableNodes` (NodePool spec)	ערך ברירת המחדל `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.35.300-gke.87
```
משתמשים בפקודה bmctl upgrade cluster כדי להשלים את השדרוג:
```
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול שרוצים לשדרג.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
הערה: הפקודה bmctl upgrade מעדכנת רק את הערך anthosBareMetalVersion ואת הערות התצוגה המקדימה במשאב המותאם אישית Cluster. אם רוצים לשנות שדות אחרים במפרט האשכול, משתמשים בפקודה bmctl update. מידע נוסף זמין במאמר בנושא עדכון אשכולות.

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

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

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

`kubectl`

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

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

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

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

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

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

התכונה הזו זמינה בגרסת טרום-השקה לאשכולות עם כל הצמתים של מישור הבקרה בגרסה משנית 1.28 ומעלה. התכונה זמינה לשימוש כללי באשכולות עם כל הצמתים של מישור הבקרה בגרסה משנית 1.29 ומעלה.

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

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

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

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

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

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

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

‫Google Distributed Cloud 1.35

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

‫Google Distributed Cloud‏ 1.34

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

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

מוסיפים את ההערה 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

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

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

תכנון השדרוג

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

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

בעיות מוכרות

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

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

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

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

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

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

‫1.30 ומעלה

1.29

‫1.28

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

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

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

‫1.30 ומעלה

1.29

‫1.28

bmctl

kubectl

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

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

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

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

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

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

bmctl

kubectl

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

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

‫Google Distributed Cloud 1.35

‫Google Distributed Cloud‏ 1.34

השהיית שדרוג

המשכת שדרוג שהושהה

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

`bmctl`

`kubectl`

`bmctl`

`kubectl`