כשמשדרגים את 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.35.300-gke.87 של bmctl, אתם יכולים לשדרג את האשכול רק לגרסה 1.35.300-gke.87.
שדרוגים של גרסאות תיקון
בגרסה משנית נתונה, אפשר לשדרג לכל גרסה גבוהה יותר עם תיקון. כלומר, אפשר לשדרג אשכול בגרסה 1.35.X לגרסה 1.35.Y כל עוד Y גדול מ-X. לדוגמה, אפשר לשדרג מ-1.34.0 ל-1.34.100 ומ-1.34.100 ל-1.34.300. כדי לוודא שהאשכולות כוללים את תיקוני האבטחה העדכניים ביותר, מומלץ לשדרג לגרסת התיקון המומלצת העדכנית ביותר בכל הזדמנות.
במאמר בנושא תמיכה בגרסאות ובשדרוגים מפורטים התיקונים המומלצים האחרונים.
שדרוגים של גרסאות משניות
כשמשדרגים אשכול לגרסה משנית חדשה, מקבלים תכונות ויכולות חדשות, בנוסף לתיקונים ולשיפורים. הכללים לשדרוג גרסאות משניות תלויים בגרסה:
1.33 ומעלה
אפשר לשדרג אשכולות מגרסה משנית אחת לגרסה המשנית הבאה, בלי קשר לגרסת התיקון. כלומר, אפשר לשדרג מ-1.N.X ל-1.N+1.Y, כאשר 1.N.X היא הגרסה של האשכול ו-N+1 היא הגרסה המשנית הזמינה הבאה. גרסאות הפאצ'ים, X ו-Y, לא משפיעות על לוגיקת השדרוג במקרה הזה. לדוגמה, אפשר לשדרג מ-1.34.700-gke.93 ל-1.35.300-gke.87.
החל מגרסה 1.33, Google Distributed Cloud תומך בדילוג על שדרוגים (שדרוג של שתי גרסאות משניות בפעולה אחת). כלומר, אפשר לשדרג אשכול מגרסה 1.N.X, כאשר N הוא 31 ומעלה, ישירות לגרסה 1.N+2.Z בפעולה אחת.
אפשר לדלג על שדרוגים בתצוגה מקדימה לגרסת היעד 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.34.700-gke.93 ל-1.35.300-gke.87.
לפני גרסה 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) סטיית הגרסה המקסימלית בין מאגר של צמתי עובדים לבין האשכול היא שתי גרסאות משניות, כשמופעלת התכונה 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 וירטואליות |
Pods סטטיים של מאזן עומסים במישור הבקרה (HAProxy, Keepalived)
רמקולים של MetalLB |
מה צפוי לקרות בזמן ההשבתה
בטבלה הבאה מפורטים זמני ההשבתה הצפויים וההשפעה הפוטנציאלית כשמשדרגים אשכולות. ההנחה בטבלה הזו היא שיש לכם כמה צמתי אשכול ומישור בקרה עם זמינות גבוהה. אם אתם מפעילים אשכול עצמאי או שאין לכם מישור בקרה של זמינות גבוהה, צפוי זמן השבתה נוסף. אלא אם צוין אחרת, זמן ההשבתה הזה חל על שדרוגים של אשכולות אדמין ושל אשכולות משתמשים:
| רכיבים | ציפיות לגבי זמן השבתה | מתי מתרחשת השבתה |
|---|---|---|
שרת ה-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 ולא יפנו את המקום בצומת. השדרוג ממשיך, גם אם יש פודים תקועים, כשתהליך הניקוי של הצומת נמשך יותר מ-20 דקות.
מידע נוסף מופיע במאמר בנושא העברת צמתים למצב תחזוקה.
המאמרים הבאים
- כדאי לעיין בשיטות המומלצות לשדרוגים של Google Distributed Cloud
- שדרוג של Google Distributed Cloud
- פתרון בעיות בשדרוג אשכולות