כשמשדרגים את Google Distributed Cloud, תהליך השדרוג כולל כמה שלבים ורכיבים. כדי לעקוב אחרי סטטוס השדרוג או לאבחן ולפתור בעיות, כדאי לדעת מה קורה כשמריצים את הפקודה bmctl upgrade
cluster. במסמך הזה מפורטים הרכיבים והשלבים של שדרוג אשכול.
סקירה כללית
במהלך תהליך השדרוג, אשכול Google Distributed Cloud עובר מהגרסה הנוכחית לגרסה חדשה יותר.
פרטי הגרסה האלה מאוחסנים במיקומים הבאים כחלק מהמשאב המותאם אישית של האשכול באשכול האדמין:
status.anthosBareMetalVersion: מגדיר את הגרסה הנוכחית של האשכול.
spec.anthosBareMetalVersion: מגדיר את גרסת היעד, ומוגדר כשמתחיל תהליך השדרוג.
במהלך פעולת שדרוג מוצלחת, מתבצעת התאמה בין status.anthosBareMetalVersion לבין spec.anthosBareMetalVersion, כך שבשניהם מוצגת גרסת היעד.
הבדלים בגרסאות של האשכול
ההטיה בגרסת האשכול היא ההבדל בגרסאות בין אשכול ניהול (היברידי או אדמין) לבין אשכולות המשתמשים המנוהלים שלו. כשמוסיפים או משדרגים אשכול משתמשים, חלים הכללים הבאים לגבי גרסאות:
1.30 ומעלה
הכללים הבאים חלים על אשכולות משתמשים שמנוהלים על ידי אשכול אדמין או אשכול היברידי בגרסה 1.30 ואילך:
גרסאות של אשכולות משתמשים לא יכולות להיות גבוהות יותר מהגרסה של אשכול הניהול (אדמין או היברידי).
אפשר להשתמש באשכולות משתמשים בגרסה שקטנה בשתי גרסאות משניות מהגרסה של האשכול המנהל. לדוגמה, אשכול אדמין בגרסה 1.30 יכול לנהל אשכול משתמשים בגרסה 1.28. היכולת הזו של ניהול הטיה בגרסה n-2 זמינה ב-GA לניהול אשכולות בגרסה 1.30.
במקרה של אשכול ניהול בגרסה 1.30 ואילך, לא צריך שגרסת המשנה של אשכולות המשתמשים תהיה זהה. לדוגמה, אשכול אדמין בגרסה 1.30 יכול לנהל אשכולות משתמשים בגרסה 1.30, בגרסה 1.29 ובגרסה 1.28.
היכולת לנהל כמה מק"טים מאפשרת לכם גמישות רבה יותר בתכנון השדרוגים של צי המטוסים. לדוגמה, אתם לא צריכים לשדרג את כל אשכולות המשתמשים בגרסה 1.28 לגרסה 1.29 לפני שתוכלו לשדרג את אשכול הניהול לגרסה 1.30.
1.29
הכללים הבאים חלים על אשכולות משתמשים שמנוהלים על ידי אשכול אדמין בגרסה 1.29 או על ידי אשכול היברידי:
גרסאות של אשכולות משתמשים לא יכולות להיות גבוהות יותר מהגרסה של אשכול הניהול (אדמין או היברידי).
(1.29 תצוגה מקדימה) גרסאות של אשכולות משתמשים יכולות להיות עד שתי גרסאות משניות מתחת לגרסה של האשכול המנהל. לדוגמה, אדמין של אשכול בגרסה 1.29 יכול לנהל אשכול משתמשים בגרסה 1.16. הניהול הזה של הטיית גרסה n-2 זמין כתכונת Preview לניהול אשכולות בגרסה 1.29.
(1.29 תצוגה מקדימה) באשכול ניהול נתון, לא צריך שגרסת המשנה של אשכולות המשתמשים תהיה זהה. לדוגמה, אדמין בגרסה 1.29 של אשכול יכול לנהל אשכולות משתמשים בגרסאות 1.29, 1.28 ו-1.16. הניהול הזה של גרסאות מעורבות זמין כתכונת Preview לניהול אשכולות בגרסה 1.29.
היכולת תצוגה מקדימה של ניהול כמה מק"טים מאפשרת לכם לתכנן את השדרוגים של צי הרכבים בצורה גמישה יותר. לדוגמה, לא צריך לשדרג את כל אשכולות המשתמשים בגרסה 1.16 לגרסה 1.28 כדי לשדרג את אשכול האדמין לגרסה 1.29.
1.28 ומטה
הכללים הבאים חלים על אשכולות משתמשים שמנוהלים על ידי אשכול אדמין או אשכול היברידי בגרסה 1.28 או בגרסה קודמת:
גרסאות של אשכולות משתמשים לא יכולות להיות גבוהות יותר מהגרסה של אשכול הניהול (אדמין או היברידי).
אפשר להשתמש באשכולות משתמשים בגרסה אחת מינורית מתחת לגרסה של האשכול המנהל. לדוגמה, אשכול אדמין בגרסה 1.28 לא יכול לנהל אשכול משתמשים בגרסה 1.15.
בכל אשכול ניהול, כל אשכולות המשתמשים המנוהלים צריכים להיות באותו מספר גרסה משנית.
מידע על כללי הטיה של גרסאות למאגרי צמתים זמין במאמר כללי גרסאות של מאגרי צמתים.
כללי גרסה
כשמורידים ומתקינים גרסה חדשה של bmctl, אפשר לשדרג את האשכולות של האדמין, ההיברידי, העצמאי והמשתמשים שנוצרו או שודרגו באמצעות גרסה קודמת של bmctl. אי אפשר לשנמך אשכול לגרסה קודמת.
אפשר לשדרג אשכול רק לגרסה שתואמת לגרסה של bmctl שבה אתם משתמשים. כלומר, אם אתם משתמשים בגרסה 1.36.100-gke.144 של bmctl, אתם יכולים לשדרג אשכול רק לגרסה 1.36.100-gke.144.
שדרוגים של גרסאות תיקון
בגרסה משנית מסוימת, אפשר לשדרג לכל גרסה גבוהה יותר עם תיקון. כלומר, אפשר לשדרג אשכול בגרסה 1.36.X לגרסה 1.36.Y כל עוד Y גדול מ-X. לדוגמה, אפשר לשדרג מ-1.35.0 ל-1.35.100 ומ-1.35.100 ל-1.35.300. כדאי לשדרג לגרסת התיקון המומלצת העדכנית ביותר בכל הזדמנות, כדי לוודא שבאשכולות שלכם יש את תיקוני האבטחה העדכניים ביותר.
במאמר תמיכה בגרסאות ובשדרוגים מפורטים התיקונים המומלצים העדכניים.
שדרוגים של גרסאות משניות
כשמשדרגים אשכול לגרסה משנית חדשה, מקבלים תכונות ויכולות חדשות, בנוסף לתיקונים ולשיפורים. הכללים לשדרוג גרסאות משניות תלויים בגרסה:
1.33 ומעלה
אפשר לשדרג אשכולות מגרסה משנית אחת לגרסה המשנית הבאה, בלי קשר לגרסת התיקון. כלומר, אפשר לשדרג מ-1.N.X ל-1.N+1.Y, כאשר 1.N.X היא הגרסה של האשכול ו-N+1 היא הגרסה המשנית הזמינה הבאה. גרסאות הפאצ'ים, X ו-Y, לא משפיעות על לוגיקת השדרוג במקרה הזה. לדוגמה, אפשר לשדרג מ-1.35.500-gke.142 ל-1.36.100-gke.144.
החל מגרסה 1.33, Google Distributed Cloud תומך בדילוג על שדרוגים (שדרוג של שתי גרסאות משניות בפעולה אחת). כלומר, אפשר לשדרג אשכול מגרסה 1.N.X, כאשר N הוא 31 ומעלה, ישירות לגרסה 1.N+2.Z בפעולה אחת.
אפשר לדלג על שדרוגים בגרסת Preview לגרסת היעד 1.33. בזמן שהיכולת הזו נמצאת בגרסת Preview, אנחנו לא ממליצים לבצע שדרוגים מדלגים מגרסה 1.31 לגרסה 1.33 עם אשכולות ייצור. אפשר לדלג על שדרוגים ב-GA לגרסאות יעד 1.34 ומעלה.
1.32 ומטה
אפשר לשדרג אשכולות מגרסה משנית אחת לגרסה המשנית הבאה, בלי קשר לגרסת התיקון. כלומר, אפשר לשדרג מ-1.N.X ל-1.N+1.Y, כאשר 1.N.X היא הגרסה של האשכול ו-N+1 היא הגרסה המשנית הזמינה הבאה. גרסאות הפאצ'ים, X ו-Y, לא משפיעות על לוגיקת השדרוג במקרה הזה. לדוגמה, אפשר לשדרג מ-1.35.500-gke.142 ל-1.36.100-gke.144.
לפני גרסה 1.33, אי אפשר לדלג על גרסאות משניות כשמשדרגים אשכולות. אם תנסו לשדרג לגרסה משנית שהיא שתי גרסאות משניות או יותר מעל גרסת האשכול הנוכחית, bmctl יציג שגיאה. לדוגמה, אי אפשר לשדרג אשכול בגרסה 1.30.0
לגרסה 1.32.0 בשלב אחד.
כמו שצוין קודם, אשכול אדמין יכול לנהל אשכולות משתמשים שנמצאים באותה גרסה או בגרסה ישנה יותר. ההבדל בגרסאות בין אשכולות המשתמשים לבין האשכול המנהל שלהם (שנקרא לפעמים הטיה בגרסה) משתנה בהתאם לגרסת האשכול. לפני שמשדרגים אשכול ניהול לגרסה משנית חדשה, חשוב לוודא שהגרסאות של אשכולות משתמשים מנוהלים יישארו בהתאם לכללים של הטיית גרסת האשכול עבור גרסת השדרוג.
כללים לניהול גרסאות של מאגר צמתים
כשמשדרגים מאגרי צמתים באופן סלקטיבי, חלים הכללים הבאים לגבי הגרסה:
1.30 ומעלה
גרסת האשכול צריכה להיות גדולה מגרסת מאגר צומתי העובדים או שווה לה.
ההבדל המקסימלי בין הגרסה של מאגר צמתי העובדים לבין הגרסה של האשכול הוא שתי גרסאות משניות.
מאגרי צמתים של עובדים יכולים להיות בכל גרסת תיקון של גרסה משנית תואמת.
1.29
גרסת האשכול צריכה להיות גדולה מגרסת מאגר צומתי העובדים או שווה לה.
(1.29 GA) ההבדל המקסימלי בין הגרסה של מאגר צמתי העובדים לבין הגרסה של האשכול הוא שתי גרסאות משניות.
מאגרי צמתים של עובדים לא יכולים להיות בגרסה שיצאה בסדר כרונולוגי מאוחר יותר מגרסת האשכול. בגרסה הקודמת חסרים הפרטים המלאים שקיימים בגרסה החדשה, וזהו תנאי לתאימות.
לדוגמה, גרסה 1.16.6 הושקה אחרי שגרסה 1.28.100-gke.146 הושקה, ולכן אי אפשר לשדרג את האשכול מגרסה 1.16.6 לגרסה 1.28.100-gke.146 ולהשאיר מאגר של צומתי עובדים בגרסה 1.16.6. באופן דומה, אם שדרגתם את האשכול לגרסה 1.28.100-gke.146, אבל בחרתם להשאיר מאגר צמתים של Worker בגרסה 1.16.5, לא תוכלו לשדרג את מאגר הצמתים של Worker לגרסה 1.16.6 בזמן שהאשכול נמצא בגרסה 1.28.100-gke.146.
1.28
גרסת האשכול צריכה להיות גדולה מגרסת מאגר צומתי העובדים או שווה לה.
(1.28 Preview) סטיית הגרסה המקסימלית בין מאגר של צמתי Worker לבין האשכול היא שתי גרסאות משניות כשמופעלת התכונה n-2 Preview של סטיית הגרסה. אם לא מפעילים את היכולת הזו, ההבדל המקסימלי בין הגרסאות של מאגר צמתי העובדים והאשכול הוא גרסה משנית אחת.
מאגרי צמתים של עובדים לא יכולים להיות בגרסה שיצאה בסדר כרונולוגי מאוחר יותר מגרסת האשכול. בגרסה הקודמת חסרים הפרטים המלאים שקיימים בגרסה החדשה, וזהו תנאי לתאימות.
לדוגמה, גרסה 1.16.6 הושקה אחרי שגרסה 1.28.100-gke.146 הושקה, ולכן אי אפשר לשדרג את האשכול מגרסה 1.16.6 לגרסה 1.28.100-gke.146 ולהשאיר מאגר של צומתי עובד בגרסה 1.16.6. באופן דומה, אם שדרגתם את האשכול לגרסה 1.28.100-gke.146, אבל בחרתם להשאיר מאגר צמתים של Worker בגרסה 1.16.5, לא תוכלו לשדרג את מאגר הצמתים של Worker לגרסה 1.16.6 בזמן שהאשכול נמצא בגרסה 1.28.100-gke.146.
1.16
גרסת האשכול צריכה להיות גדולה מגרסת מאגר צומתי העובדים או שווה לה.
ההבדל המקסימלי בין גרסאות של מאגר צמתים של עובדים לבין האשכול הוא גרסה משנית אחת.
מאגרי צמתים של עובדים לא יכולים להיות בגרסה שיצאה בסדר כרונולוגי מאוחר יותר מגרסת האשכול. בגרסה הקודמת חסרים הפרטים המלאים שקיימים בגרסה החדשה, וזהו תנאי לתאימות.
לדוגמה, גרסה 1.16.6 הושקה אחרי שגרסה 1.28.100-gke.146 הושקה, ולכן אי אפשר לשדרג את האשכול מגרסה 1.16.6 לגרסה 1.28.100-gke.146 ולהשאיר מאגר של צומתי עובד בגרסה 1.16.6. באופן דומה, אם שדרגתם את האשכול לגרסה 1.28.100-gke.146, אבל בחרתם להשאיר מאגר צמתים של Worker בגרסה 1.16.5, לא תוכלו לשדרג את מאגר הצמתים של Worker לגרסה 1.16.6 בזמן שהאשכול נמצא בגרסה 1.28.100-gke.146.
בטבלה הבאה מפורטות גרסאות מאגרי הצמתים הנתמכות שמותרות לגרסה ספציפית של אשכול:
1.30 ומעלה
בגרסאות אשכול 1.30 ואילך, גרסאות מאגר הצמתים יכולות להיות נמוכות עד שתי גרסאות משניות. כל גרסאות התיקון של מאגר הצמתים בגרסאות משניות תואמות הן תואמות.
1.29
| גרסת האשכול (מישור הבקרה) | גרסאות נתמכות של מאגר צמתי Worker (הגרסאות שנוספו מודגשות) | |||
|---|---|---|---|---|
| 1.29.1200-gke.98 |
|
|
|
|
| 1.29.1100-gke.84 |
|
|
|
|
| 1.29.1000-gke.93 |
|
|
|
|
| 1.29.900-gke.180 |
|
|
|
|
| 1.29.800-gke.111 |
|
|
|
|
| 1.29.700-gke.113 |
|
|
|
|
| 1.29.600-gke.105 |
|
|
|
|
| 1.29.500-gke.162 |
|
|
|
|
| 1.29.400-gke.86 |
|
|
|
|
| 1.29.300-gke.185 |
|
|
|
|
| 1.29.200-gke.243 |
|
|
|
|
| 1.29.100-gke.251 |
|
|
|
|
| 1.29.0-gke.1449 |
|
|
|
|
1.28
| גרסת האשכול (מישור הבקרה) | גרסאות נתמכות של מאגר צמתי Worker (הגרסאות שנוספו מודגשות) | |||
|---|---|---|---|---|
| 1.28.1400-gke.79 |
|
|
|
|
| 1.28.1300-gke.59 |
|
|
|
|
| 1.28.1200-gke.83 |
|
|
|
|
| 1.28.1100-gke.94 |
|
|
|
|
| 1.28.1000-gke.60 |
|
|
|
|
| 1.28.900-gke.112 |
|
|
|
|
| 1.28.800-gke.111 |
|
|
|
|
| 1.28.700-gke.150 |
|
|
|
|
| 1.28.600-gke.163 |
|
|
|
|
| 1.28.500-gke.120 |
|
|
|
|
| 1.28.400-gke.77 |
|
|
|
|
| 1.28.300-gke.131 |
|
|
|
|
| 1.28.200-gke.118 |
|
|
|
|
| 1.28.100-gke.146 |
|
|
|
|
| 1.28.0-gke.425 |
|
|
|
|
1.16
| גרסת האשכול (מישור הבקרה) | גרסאות נתמכות של מאגר צמתי Worker (הגרסאות שנוספו מודגשות) | |||
|---|---|---|---|---|
| 1.16.12 |
|
|
|
|
| 1.16.11 |
|
|
|
|
| 1.16.10 |
|
|
|
|
| 1.16.9 |
|
|
|
|
| 1.16.8 |
|
|
|
|
| 1.16.7 |
|
|
|
|
| 1.16.6 |
|
|
|
|
| 1.16.5 |
|
|
|
|
| 1.16.4 |
|
|
|
|
| 1.16.3 |
|
|
|
|
| 1.16.2 |
|
|
|
|
| 1.16.1 |
|
|
||
| 1.16.0 |
|
|
||
שדרוג רכיבים
הרכיבים משודרגים ברמת הצומת וברמת האשכול. ברמת האשכול, הרכיבים הבאים משודרגים:
- רכיבי אשכולות לרשת, לניראות ולאחסון.
- במקרים של אדמין, היברידי וקלאסטרים עצמאיים, בקרי מחזור החיים.
- ה
gke-connect-agent.
צמתים באשכול פועלים כאחד מהתפקידים הבאים, ורכיבים שונים משודרגים בהתאם לתפקיד של הצומת:
| תפקיד הצומת | תפקיד | רכיבים לשדרוג |
|---|---|---|
| עובד | הפעלת עומסי עבודה של משתמשים | Kubelet, זמן ריצה של קונטיינר (Docker או containerd) |
| מישור הבקרה | מריץ את מישור הבקרה של Kubernetes, את בקרי מחזור החיים של האשכול ואת Google Cloud תוספי הפלטפורמה | Pods סטטיים של מישור הבקרה של Kubernetes (kubeapi-server, kube-scheduler, kube-controller-manager, etcd)
בקרי מחזור חיים כמו lifecycle-controllers-manager ו-anthos-cluster-operatorתוספים לפלטפורמה Google Cloud כמו stackdriver-log-aggregator ו-gke-connect-agent |
| מאזן עומסים של מישור הבקרה | מריצים את HAProxy ואת Keepalived שמשרתים תנועה אל
kube-apiserver, ומריצים רכיבי MetalLB כדי לתבוע כתובות IP וירטואליות |
מאזני עומסים של מישור הבקרה, תרמילי Pod סטטיים (HAProxy, Keepalived)
רמקולים של MetalLB |
הציפייה לגבי זמן השבתה
בטבלה הבאה מפורט זמן ההשבתה הצפוי וההשפעה הפוטנציאלית כשמשדרגים אשכולות. הטבלה הזו מניחה שיש לכם כמה צמתי אשכול ומישור בקרה עם זמינות גבוהה. אם אתם מפעילים אשכול עצמאי או שאין לכם מישור בקרה של זמינות גבוהה, צפוי זמן השבתה נוסף. אלא אם צוין אחרת, זמן ההשבתה הזה חל על שדרוגים של אשכולות אדמין ושל אשכולות משתמשים:
| רכיבים | ציפיות לגבי זמן השבתה | מתי מתרחשת השבתה |
|---|---|---|
שרת API של מישור הבקרה של Kubernetes (kube-apiserver), etcd ומתזמן |
ללא זמן השבתה | לא רלוונטי |
בקרי מחזור חיים וansible-runner משימות (באשכולות של אדמין בלבד) |
ללא זמן השבתה | לא רלוונטי |
מישור הבקרה של Kubernetes loadbalancer-haproxy ו-
keepalived |
השבתה זמנית (פחות מדקה עד 2 דקות) כשמאזן העומסים מפנה את התנועה. | תחילת תהליך השדרוג. |
ניראות (observability) pipeline-stackdriver וגם metrics-server |
ה-Operator רוקן ושודרג. ההשבתה צריכה להימשך פחות מ-5 דקות.
ה-DaemonSets ממשיכים לפעול ללא זמן השבתה. |
אחרי שהשדרוג של הצמתים ברמת הבקרה מסתיים. |
| ממשק רשת של קונטיינר (CNI) | אין השבתה של מסלולי רשת קיימים. DaemonSet שנפרס בזוגות ללא זמן השבתה. המפעיל מרוקן ומשודרג. זמן ההשבתה הוא פחות מ-5 דקות. |
אחרי ששדרוג הצמתים במישור הבקרה מסתיים. |
| MetalLB (אשכול משתמש בלבד) | ה-Operator רוקן ושודרג. ההשבתה נמשכת פחות מ-5 דקות.
השירות הקיים מושבת באופן זמני (לפחות לדקה אחת) כשמאזן העומסים מפנה את התנועה. |
אחרי ששדרוג הצמתים במישור הבקרה מסתיים. |
| CoreDNS ומידרוג אוטומטי של DNS (רק באשכול משתמשים) | ל-CoreDNS יש כמה עותקים משוכפלים עם קנה מידה אוטומטי. בדרך כלל אין השבתה. | אחרי שהשדרוג של הצמתים ברמת הבקרה מסתיים. |
| ספק נפח אחסון מקומי | אין זמן השבתה לנפחי אחסון קיימים שמוקצים באופן קבוע (PV).
יכול להיות שיהיה זמן השבתה של 5 דקות אצל הספק. |
אחרי ששדרוג הצמתים במישור הבקרה מסתיים. |
| Istio / ingress | ה-operator של Istio מנוקז ומשודרג. כ-5 דקות של השבתה. הגדרות קיימות של תעבורת נכנסת ימשיכו לפעול. |
אחרי ששדרוג הצמתים במישור הבקרה מסתיים. |
| מפעילים אחרים של מערכות | 5 דקות של השבתה כשמרוקנים את הסוללה ומשדרגים. | אחרי ששדרוג הצמתים במישור הבקרה מסתיים. |
| עומסי עבודה של משתמשים | תלוי בהגדרה, למשל אם יש זמינות גבוהה. כדאי לבדוק את פריסות עומסי העבודה שלכם כדי להבין את ההשפעה הפוטנציאלית. |
כשצומת העובד או צמתי העובדים משודרגים. |
פרטי שדרוג של אשכול משתמשים
בקטע הזה מפורט סדר השדרוגים של הרכיבים ומידע על הסטטוס של שדרוג אשכול משתמשים. בקטע הבא מפורטים חריגות מהתהליך הזה לשדרוגים של אדמינים, שדרוגים היברידיים או שדרוגים של אשכולות עצמאיים.
בתרשים הבא מוצג תהליך בדיקת ההתאמה לשדרוג של אשכול משתמשים:
בתרשים שלמעלה מפורטים השלבים שמתרחשים במהלך שדרוג:
- הפקודה
bmctl upgrade clusterיוצרת משאב מותאם אישיתPreflightCheck. - בדיקת ה-preflight הזו מריצה בדיקות נוספות, כמו בדיקות שדרוג של אשכולות, בדיקות תקינות של רשתות ובדיקות תקינות של צמתים.
- התוצאות של הבדיקות הנוספות האלה משולבות בדוח כדי להציג את היכולת של האשכול לשדרג בהצלחה לגרסת היעד.
אם הבדיקות המקדימות מסתיימות בהצלחה ואין בעיות שמונעות את השדרוג, הרכיבים באשכול משודרגים בסדר מסוים, כמו שמוצג בתרשים הבא:
בתרשים שלמעלה, הרכיבים משודרגים לפי הסדר הבא:
השדרוג מתחיל בעדכון השדה
spec.anthosBareMetalVersion.מאזני העומסים של מישור הבקרה משודרגים.
מאגר הצמתים של מישור הבקרה משודרג.
אחרי שמאגר הצמתים של רמת הבקרה משודרג, הרכיבים הבאים משודרגים במקביל:
- חיבור סוכן
- תוספים לאשכולות
- מאגר צמתים של מאזן עומסים
אחרי שמאגר הצמתים של מאזן העומסים ישודרג בהצלחה, ישודרגו מאגרי צמתים של העובדים.
אחרי שכל הרכיבים משודרגים, מופעלות בדיקות תקינות של האשכול.
בדיקות התקינות ממשיכות לפעול עד שכל הבדיקות עוברות.
השדרוג מסתיים כשכל בדיקות התקינות עוברות בהצלחה.
לכל רכיב יש שדה סטטוס משלו בתוך המשאב המותאם אישית Cluster. כדי להבין את התקדמות השדרוג, אפשר לבדוק את הסטטוס בשדות האלה:
| רצף | שם השדה | משמעות |
|---|---|---|
| 1 | status.controlPlaneNodepoolStatus |
הסטטוס מועתק מהסטטוס של מאגר הצמתים של מישור הבקרה. השדה כולל את הגרסאות של הצמתים של מאגרי הצמתים של מישור הבקרה |
| 2 | status.anthosBareMetalLifecycleControllersManifestsVersion
|
הגרסה של lifecycles-controllers-manager שהוחלה על האשכול. השדה הזה זמין רק באשכולות אדמין, אשכולות עצמאיים או אשכולות היברידיים. |
| 2 | status.anthosBareMetalManifestsVersion |
הגרסה של האשכול מהמניפסט האחרון שהוחל. |
| 2 | status.controlPlaneLoadBalancerNodepoolStatus |
הסטטוס מועתק מהסטטוס של מאגר הצמתים של מאזן העומסים של מישור הבקרה. השדה הזה ריק אם לא מציינים מאזן עומסים נפרד של מישור הבקרה ב-Cluster.Spec. |
| 3 | status.anthosBareMetalVersions |
מפת גרסאות מצטברת של גרסה למספרי צמתים. |
| 4 | status.anthosBareMetalVersion |
הסטטוס הסופי של הגרסה המשודרגת. |
פרטים על שדרוג של אשכולות אדמין, אשכולות משולבים ואשכולות עצמאיים
החל מגרסה 1.15.0 של bmctl, התנהגות השדרוג שמוגדרת כברירת מחדל לאשכולות בניהול עצמי (אדמין, היברידי או עצמאי) היא שדרוג במקום.
כלומר, כשמשדרגים אשכול לגרסה 1.15.0 ואילך, השדרוג משתמש בבקרי מחזור חיים, במקום באשכול אתחול, כדי לנהל את כל תהליך השדרוג. השינוי הזה מפשט את התהליך ומפחית את דרישות המשאבים, וכך משדרג את האשכולות בצורה אמינה יותר וניתנת להרחבה.
למרות שלא מומלץ להשתמש באשכול bootstrap לשדרוג, האפשרות הזו עדיין זמינה. כדי להשתמש באשכול bootstrap כשמשדרגים, מריצים את הפקודה bmctl upgrade עם הדגל --use-bootstrap=true.
שלבי השדרוג משתנים בהתאם לשיטה שבה משתמשים.
שדרוגים במקום
תהליך השדרוג שמוגדר כברירת מחדל באשכולות בניהול עצמי דומה לתהליך השדרוג של אשכולות משתמשים. עם זאת, כשמשתמשים בתהליך השדרוג במקום, גרסה חדשה של preflightcheck-operator נפרסת לפני שמתבצעת בדיקת קדם-הפעלה של האשכול ובדיקות תקינות:
בדומה לשדרוג של אשכול משתמשים, תהליך השדרוג מתחיל בעדכון השדה Cluster.spec.anthosBareMetalVersion לגרסת היעד. לפני עדכון הרכיבים מתבצעים שני שלבים נוספים, כפי שמוצג בתרשים הבא: lifecycle-controller-manager משדרג את עצמו לגרסת היעד, ואז פורס את גרסת היעד של anthos-cluster-operator. הקוד anthos-cluster-operator מבצע את שאר השלבים בתהליך השדרוג:
אם הפעולה מצליחה, anthos-cluster-operator מתאים את גרסת היעד מ-spec.anthosBareMetalVersion ל-status.anthosBareMetalVersion.
שדרוג באמצעות אשכול bootstrap
התהליך לשדרוג אשכול אדמין, אשכול היברידי או אשכול עצמאי דומה לתהליך לשדרוג אשכול משתמש שמוסבר בקטע הקודם.
ההבדל העיקרי הוא שהפקודה bmctl upgrade cluster מתחילה תהליך ליצירת אשכול bootstrap. אשכול האתחול הוא אשכול זמני שמנהל את האשכול ההיברידי, האדמיניסטרטיבי או העצמאי במהלך השדרוג.
התהליך של העברת הבעלות על הניהול של האשכול לאשכול האתחול נקרא pivot. המשך השדרוג מתבצע באותו אופן כמו שדרוג של אשכול משתמשים.
במהלך תהליך השדרוג, המשאבים באשכול היעד נשארים לא עדכניים. התקדמות השדרוג משתקפת רק במשאבים של אשכול האתחול.
במקרה הצורך, אפשר לגשת לאשכול bootstrap כדי לעזור בניטור ובניפוי באגים של תהליך השדרוג. אפשר לגשת לאשכול האתחול דרך bmctl-workspace/.kindkubeconfig.
כדי להעביר בחזרה את הבעלות על ניהול האשכול אחרי שהשדרוג מסתיים, האשכול מעביר את המשאבים מאשכול האתחול לאשכול המשודרג. אין שלבים ידניים שצריך לבצע כדי לשנות את הכיוון של האשכול במהלך תהליך השדרוג. אשכול האתחול נמחק אחרי ששדרוג האשכול מסתיים בהצלחה.
הפסקת הפעילות של צומת
שדרוגים של אשכולות ב-Google Distributed Cloud עלולים להוביל לשיבוש באפליקציה, כי הצמתים מתרוקנים. תהליך הניקוי הזה גורם לכל ה-Pods שפועלים בצומת להיסגר ולהיפתח מחדש בצמתים שנותרו באשכול.
אפשר להשתמש בפריסות כדי להתמודד עם שיבושים כאלה. בפריסה אפשר לציין כמה עותקים של אפליקציה או שירות צריכים לפעול. במהלך שדרוגים, לא אמורים להיות שיבושים באפליקציה עם כמה עותקים משוכפלים, או שהשיבושים יהיו מינוריים.
PodDisruptionBudgets (PDBs)
כשמשדרגים אשכול, Google Distributed Cloud משתמש בתהליך של מצב תחזוקה כדי לנקז את הצמתים.
החל מגרסה 1.29, הניקוז של הצמתים מתבצע באמצעות Eviction API, שמכבד את PodDisruptionBudgets (PDB). אפשר להשתמש ב-PDB כדי לוודא שמספר מוגדר של רפליקות תמיד פועל באשכול בתנאי הפעלה רגילים.
מדיניות PDB מאפשרת להגביל את השיבוש בעומס עבודה כשצריך לתזמן מחדש את הפודים שלו. התכונה 'הפסקת פעילות של צומת על סמך פינוי' זמינה כ-GA בגרסה 1.29.
בגרסאות 1.28 ומטה, מערכת Google Distributed Cloud לא מכבדת PDBs כשמתבצע ניקוי של הצמתים במהלך שדרוג. במקום זאת, תהליך ניקוי הצמתים מתבצע כמיטב היכולת. יכול להיות שחלק מה-Pods ייתקעו במצב Terminating ולא יפנו את המקום בצומת. השדרוג ממשיך, גם אם יש פודים תקועים, כשתהליך הניקוי של הצומת נמשך יותר מ-20 דקות.
מידע נוסף מופיע במאמר בנושא העברת צמתים למצב תחזוקה.
המאמרים הבאים
- שיטות מומלצות לשדרוגים של Google Distributed Cloud
- שדרוג של Google Distributed Cloud
- פתרון בעיות בשדרוג אשכולות