Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

כשמתקינים גרסה חדשה של 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.34.100-gke.93
  ...

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

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

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

לדוגמה, אם יש לכם אשכול בגרסה 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.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.33.0 ויש לו שני מאגרי צמתים של עובדים: wpool01 ו-wpool02. נניח שאתם רוצים לשדרג את רמת הבקרה ואת wpool01 לגרסה 1.34.100-gke.93, אבל אתם רוצים ש-wpool02 יישאר בגרסה 1.33.0.

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

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.34.100-gke.93
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.34.100-gke.93
  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.33.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.34.100-gke.93, אבל מאגר הצמתים wpool02 עדיין בגרסה הישנה של האשכול לפני השדרוג, 1.33.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.34.100-gke.93
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.34.100-gke.93
  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

היכולת לבטל את השינויים ב-node pool זמינה בגרסת 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.33.500-gke.63
  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.33.500-gke.63
  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 Boolean במפרט האשכול קובע אם לשדרג את כל מאגרי צמתי העובדים באשכול בו-זמנית. כברירת מחדל (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.34.100-gke.93
  ...
  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.34.100-gke.93
```
משתמשים בפקודה 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.34

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

‫Google Distributed Cloud 1.33

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

‫Google Distributed Cloud 1.33

השהיית שדרוג

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

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

`bmctl`

`kubectl`

`bmctl`

`kubectl`