כשמשדרגים את 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. הניהול הזה של גרסאות מעורבות זמין כתכונה בגרסת טרום-השקה לניהול אשכולות בגרסה 1.29.
היכולת החדשה לניהול כמה מק"טים בתצוגה מקדימה מאפשרת לכם לתכנן את השדרוגים של צי המכשירים בצורה גמישה יותר. לדוגמה, לא צריך לשדרג את כל אשכולות המשתמשים בגרסה 1.16 לגרסה 1.28 כדי לשדרג את אשכול האדמין לגרסה 1.29.
גרסה 1.28 ומטה
הכללים הבאים חלים על אשכולות משתמשים שמנוהלים על ידי אשכול אדמין או אשכול היברידי בגרסה 1.28 או בגרסה מוקדמת יותר:
הגרסאות של אשכולות המשתמשים לא יכולות להיות גבוהות מהגרסה של אשכול הניהול (אדמין או היברידי).
אפשר להשתמש באשכולות משתמשים בגרסה משנית אחת מתחת לגרסה של האשכול המנהל. לדוגמה, אשכול אדמין בגרסה 1.28 לא יכול לנהל אשכול משתמשים בגרסה 1.15.
בכל אשכול ניהול, כל אשכולות המשתמשים המנוהלים צריכים להיות באותו גרסה משנית.
מידע על כללים לגבי הבדלי גרסאות במאגרי צמתים זמין במאמר בנושא כללים לגבי גרסאות של מאגרי צמתים.
כללי גרסה
כשמורידים ומתקינים גרסה חדשה של bmctl, אפשר לשדרג את האשכולות שלכם מסוג admin, hybrid, standalone ו-user שנוצרו או שודרגו באמצעות גרסה קודמת של bmctl. אי אפשר לשדרג לאחור אשכולים לגרסה קודמת.
אפשר לשדרג אשכול רק לגרסה שתואמת לגרסה של bmctl שבה אתם משתמשים. כלומר, אם אתם משתמשים בגרסה 1.34.100-gke.93 של bmctl, אתם יכולים לשדרג אשכול רק לגרסה 1.34.100-gke.93.
שדרוגים של גרסאות תיקון
בגרסה משנית נתונה, אפשר לשדרג לכל גרסה גבוהה יותר עם תיקון. כלומר, אפשר לשדרג אשכול בגרסה 1.34.X לגרסה 1.34.Y כל עוד Y גדול מ-X. לדוגמה, אפשר לשדרג מ-1.33.0 ל-1.33.100 ומ-1.33.100 ל-1.33.300. כדי לוודא שהאשכולות כוללים את תיקוני האבטחה העדכניים ביותר, מומלץ לשדרג לגרסת התיקון המומלצת העדכנית ביותר בכל הזדמנות.
לתיקונים המומלצים האחרונים, אפשר לעיין במאמר בנושא תמיכה בגרסאות ובשדרוגים.
שדרוגים של גרסאות משניות
כשמשדרגים אשכול לגרסה משנית חדשה, מקבלים תכונות ויכולות חדשות, בנוסף לתיקונים ולשיפורים. הכללים לשדרוג גרסאות משניות תלויים בגרסה:
1.33 ומעלה
אפשר לשדרג אשכולות מגרסה משנית אחת לגרסה המשנית הבאה, בלי קשר לגרסת התיקון. כלומר, אפשר לשדרג מ-1.N.X ל-1.N+1.Y, כאשר 1.N.X היא גרסת האשכול ו-N+1 היא הגרסה המשנית הזמינה הבאה. גרסאות התיקון, X ו-Y, לא משפיעות על לוגיקת השדרוג במקרה הזה. לדוגמה, אפשר לשדרג מ-1.33.500-gke.63 ל-1.34.100-gke.93.
החל מגרסה 1.33, Google Distributed Cloud תומך בדילוג על שדרוגים (שדרוג של שתי גרסאות משניות בפעולה אחת). כלומר, אפשר לשדרג אשכול מגרסה 1.N.X, כאשר N הוא 31 ומעלה, ישירות לגרסה 1.N+2.Z בפעולה אחת.
אפשר לדלג על שדרוגים בגרסת Preview לגרסת היעד 1.33. בזמן שהיכולת הזו נמצאת בתצוגה מקדימה, אנחנו לא ממליצים לבצע שדרוגים מדלגים מגרסה 1.31 לגרסה 1.33 עם אשכולות ייצור. האפשרות לדלג על שדרוגים זמינה בגרסאות יעד 1.34 ואילך.
1.32 ומטה
אפשר לשדרג אשכולות מגרסה משנית אחת לגרסה המשנית הבאה, בלי קשר לגרסת התיקון. כלומר, אפשר לשדרג מ-1.N.X ל-1.N+1.Y, כאשר 1.N.X היא גרסת האשכול ו-N+1 היא הגרסה המשנית הזמינה הבאה. גרסאות התיקון, X ו-Y, לא משפיעות על לוגיקת השדרוג במקרה הזה. לדוגמה, אפשר לשדרג מ-1.33.500-gke.63 ל-1.34.100-gke.93.
לפני גרסה 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, אבל בחרתם להשאיר מאגר צמתים של עובדים בגרסה 1.16.5, לא תוכלו לשדרג את מאגר הצמתים של העובדים לגרסה 1.16.6 בזמן שהאשכול נמצא בגרסה 1.28.100-gke.146.
1.28
גרסת האשכול צריכה להיות גדולה מגרסת מאגר צומתי העובדים או שווה לה.
(1.28 Preview) סטיית הגרסה המקסימלית בין מאגר של צמתי Worker לבין האשכול היא שתי גרסאות משניות, כאשר התכונה n-2 version skew 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, אבל בחרתם להשאיר מאגר צמתים של עובדים בגרסה 1.16.5, לא תוכלו לשדרג את מאגר הצמתים של העובדים לגרסה 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, אבל בחרתם להשאיר מאגר צמתים של עובדים בגרסה 1.16.5, לא תוכלו לשדרג את מאגר הצמתים של העובדים לגרסה 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-aggregatorgke-connect-agent |
| מאזן עומסים של מישור הבקרה | מריצים את HAProxy ו-Keepalived שמשרתים תנועה אל kube-apiserver, ומריצים רכיבי MetalLB כדי לתבוע כתובות IP וירטואליות |
Pods סטטיים של מאזן עומסים במישור הבקרה (HAProxy, Keepalived)
רמקולים של MetalLB |
מה צפוי בזמן ההשבתה
בטבלה הבאה מפורטים זמני ההשבתה הצפויים וההשפעה הפוטנציאלית כשמשדרגים אשכולות. הטבלה הזו מניחה שיש לכם כמה צמתי אשכול ומישור בקרה עם זמינות גבוהה (HA). אם אתם מפעילים אשכול עצמאי או שאין לכם מישור בקרה של זמינות גבוהה, צפוי זמן השבתה נוסף. אלא אם צוין אחרת, זמן ההשבתה הזה חל על שדרוגים של אדמינים ושל אשכולות משתמשים:
| רכיבים | ציפיות לגבי זמן השבתה | מתי מתרחשת השבתה |
|---|---|---|
שרת ה-API של מישור הבקרה של Kubernetes (kube-apiserver), etcd והמתזמן |
ללא זמן השבתה | לא רלוונטי |
בקרי מחזור חיים וansible-runner משימות (באשכולות של אדמין בלבד) |
ללא זמן השבתה | לא רלוונטי |
מישור הבקרה של Kubernetes loadbalancer-haproxy ו-
keepalived |
השבתה זמנית (פחות מדקה עד 2 דקות) כשמאזן העומסים מפנה את התנועה. | תחילת תהליך השדרוג. |
ניראות (observability) pipeline-stackdriver וגם metrics-server |
הספק רוקן ושודרג. זמן ההשבתה צריך להיות פחות מ-5 דקות.
ערכות DaemonSet ממשיכות לפעול ללא השבתה. |
אחרי שהשדרוג של צמתי מישור הבקרה מסתיים. |
| ממשק רשת של קונטיינר (CNI) | אין זמן השבתה למסלולי רשת קיימים. DaemonSet נפרס בזוגות ללא זמן השבתה. המפעיל מרוקן ומשודרג. זמן ההשבתה קצר מ-5 דקות. |
אחרי שהשדרוג של צמתי מישור הבקרה מסתיים. |
| MetalLB (אשכול משתמש בלבד) | הספק רוקן ושודרג. זמן ההשבתה הוא פחות מ-5 דקות.
שירות קיים חווה השבתה זמנית (פחות מדקה) כשמאזן העומסים מפנה את התנועה. |
אחרי שהשדרוג של צמתי מישור הבקרה מסתיים. |
| CoreDNS ומידרוג אוטומטי של DNS (באשכול משתמשים בלבד) | ל-CoreDNS יש כמה עותקים עם קנה מידה אוטומטי. בדרך כלל אין השבתה. | אחרי שהשדרוג של צמתי מישור הבקרה מסתיים. |
| מנהל הקצאות נפח מקומי | אין זמן השבתה לנפחי אחסון מתמידים (PV) קיימים שהוקצו.
יכול להיות שיהיה זמן השבתה של 5 דקות אצל הספק. |
אחרי שהשדרוג של צמתי מישור הבקרה מסתיים. |
| Istio / ingress | ה-operator של Istio מרוקן ומשודרג. בערך 5 דקות של
השבתה. הגדרות קיימות של כניסה ממשיכות לפעול. |
אחרי שהשדרוג של צמתי מישור הבקרה מסתיים. |
| מפעילים אחרים של מערכות | זמן השבתה של 5 דקות כשמרוקנים את הסוללה ומשדרגים. | אחרי שהשדרוג של צמתי מישור הבקרה מסתיים. |
| עומסי עבודה של משתמשים | תלוי בהגדרה, למשל אם יש זמינות גבוהה. כדאי לבדוק את הפריסות של עומסי העבודה שלכם כדי להבין את ההשפעה הפוטנציאלית. |
כשמשדרגים את צומתי העובדים. |
פרטי השדרוג של אשכול משתמשים
בקטע הזה מפורט סדר השדרוגים של הרכיבים ומידע על הסטטוס של שדרוג אשכול משתמשים. בקטע הבא מפורטים חריגות מהתהליך הזה לשדרוגים של אדמין, היברידי או אשכול עצמאי.
בתרשים הבא מוצג תהליך בדיקת ההתאמה לשדרוג של אשכול משתמשים:
בתרשים שלמעלה מפורטים השלבים שמתרחשים במהלך שדרוג:
- הפקודה
bmctl upgrade clusterיוצרת משאב מותאם אישיתPreflightCheck. - בדיקת הטרום-טיסה הזו מריצה בדיקות נוספות, כמו בדיקות שדרוג של אשכולות, בדיקות תקינות של רשתות ובדיקות תקינות של צמתים.
- התוצאות של הבדיקות הנוספות האלה משולבות בדוח שמתייחס ליכולת של האשכול לשדרג בהצלחה לגרסת היעד.
אם הבדיקות המקדימות מסתיימות בהצלחה ואין בעיות שמונעות את השדרוג, הרכיבים באשכול משודרגים בסדר מסוים, כמו שמוצג בתרשים הבא:
בתרשים שלמעלה, הרכיבים משודרגים לפי הסדר הבא:
השדרוג מתחיל בעדכון השדה
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 (PDBs). אפשר להשתמש ב-PDB כדי לוודא שמספר מוגדר של רפליקות תמיד פועל באשכול בתנאי הפעלה רגילים.
מדיניות PDB מאפשרת להגביל את השיבוש בעומס עבודה כשצריך לתזמן מחדש את הפודים שלו. הוצאת צמתים משימוש על סמך פינוי זמינה כ-GA בגרסה 1.29.
בגרסאות 1.28 ומטה, מערכת Google Distributed Cloud לא מכבדת PDBs כשמתבצע ניקוי של הצמתים במהלך שדרוג. במקום זאת, תהליך ניקוי הצמתים מתבצע על בסיס האפשרות הטובה ביותר. יכול להיות שחלק מה-Pods ייתקעו במצב Terminating ולא יפנו את המקום בצומת. השדרוג ממשיך, גם אם יש Pods תקועים, כשתהליך הניקוי של הצומת נמשך יותר מ-20 דקות.
מידע נוסף מופיע במאמר העברת צמתים למצב תחזוקה.
המאמרים הבאים
- כדאי לעיין בשיטות המומלצות לשדרוגים של Google Distributed Cloud
- שדרוג Google Distributed Cloud
- פתרון בעיות בשדרוג אשכול