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

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

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

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

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

תכנון השדרוג

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

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

מידע שיעזור לכם להתכונן לשדרוג אשכול מופיע במאמר שיטות מומלצות לשדרוג אשכולות ב-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.36.100-gke.144
  ...

מעדכנים את הערך 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.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 למאגרי צמתי עובדים זמינה לכולם (GA) לכל סוגי האשכולות. התכונה הזו מופעלת כברירת מחדל באשכולות בגרסה 1.30.

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

1.29

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

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

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

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

לדוגמה, נניח ששדרגתם את האשכול לגרסה 1.36.100-gke.144, אבל מאגר הצמתים 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.100-gke.144
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.36.100-gke.144
  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). בזמן שהתכונה הזו נמצאת בגרסת הבדיקה, צריך להוסיף את ההערה הבאה למשאב 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.500-gke.142
  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.35.500-gke.142
  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.36.100-gke.144
  ...
  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.36.100-gke.144
```
משתמשים בפקודה 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.36

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

‫Google Distributed Cloud‏ 1.35

בזמן שהיכולת להשהות ולחדש את השדרוג נמצאת בשלב התצוגה המקדימה, אפשר להפעיל אותה באמצעות הערה במשאב 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

בדוגמה הזו, הצומת הוא בגרסה 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`