כשמשדרגים את 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 זמינה לכולם לניהול אשכולות בגרסה 1.30.
באשכול ניהול נתון בגרסה 1.30 ואילך, לאשכולות המשתמשים לא חייבת להיות אותה גרסה משנית. לדוגמה, אשכול אדמין בגרסה 1.30 יכול לנהל אשכולות משתמשים בגרסאות 1.30, 1.29 ו-1.28.
היכולת לנהל כמה מק"טים מאפשרת לכם לתכנן את שדרוגי הצי בצורה גמישה יותר. לדוגמה, אתם לא צריכים לשדרג את כל אשכולות המשתמשים מגרסה 1.28 לגרסה 1.29 לפני שאתם משדרגים את אשכול הניהול לגרסה 1.30.
1.29
הכללים הבאים חלים על אשכולות של משתמשים שמנוהלים על ידי אשכול אדמין או אשכול היברידי בגרסה 1.29:
הגרסאות של אשכולות המשתמשים לא יכולות להיות גבוהות יותר מהגרסה של האשכול המנהל (אדמין או היברידי).
(1.29 גרסת טרום-השקה (Preview)) אשכולות המשתמשים יכולים להיות עד שתי גרסאות משניות מתחת לגרסת האשכול המנהל. לדוגמה, אשכול אדמין בגרסה 1.29 יכול לנהל אשכול משתמש בגרסה 1.16. הניהול של הטיית הגרסאות n-2 זמין כגרסת תצוגה מקדימה לניהול אשכולות בגרסה 1.29.
(גרסת טרום-השקה 1.29) באשכול ניהול נתון, לאשכולות המשתמשים לא חייבת להיות אותה גרסה משנית. לדוגמה, אשכול אדמין בגרסה 1.29 יכול לנהל אשכולות משתמשים בגרסאות 1.29, 1.28 ו-1.16. הניהול של גרסאות שונות זמין כגרסת טרום-השקה (Preview) לניהול אשכולות בגרסה 1.29.
היכולת לנהל כמה מק"טים בגרסת טרום-השקה (Preview) מאפשרת לכם לתכנן את שדרוגי הצי בצורה גמישה יותר. לדוגמה, אתם לא צריכים לשדרג את כל אשכולות המשתמשים מגרסה 1.16 לגרסה 1.28 לפני שתוכלו לשדרג את אשכול הניהול לגרסה 1.29.
1.28 ומטה
הכללים הבאים חלים על אשכולות של משתמשים שמנוהלים על ידי אשכול אדמין או אשכול היברידי בגרסה 1.28 או גרסה קודמת:
הגרסאות של אשכולות המשתמשים לא יכולות להיות גבוהות יותר מהגרסה של האשכול המנהל (אדמין או היברידי).
אשכולות המשתמשים יכולים להיות עד גרסה משנית אחת מתחת לגרסת האשכול המנהל. לדוגמה, אשכול אדמין בגרסה 1.28 לא יכול לנהל אשכול משתמש בגרסה 1.15.
באשכול ניהול נתון, כל אשכולות המשתמשים המנוהלים חייבים להיות באותה גרסה משנית.
למידע על כללי הטיה של גרסאות למאגרי צמתים, ראו כללי ניהול גרסאות של מאגרי צמתים.
כללי גרסאות
כשמורידים ומתקינים גרסה חדשה של bmctl, אפשר לשדרג את אשכולות הניהול, האשכולות ההיברידיים, האשכולות העצמאיים ואשכולות המשתמשים שנוצרו או שודרגו באמצעות גרסה קודמת של bmctl. אי אפשר לשדרג לאחור אשכולות לגרסה נמוכה יותר.
אפשר לשדרג אשכול רק לגרסה שתואמת לגרסת bmctl שבה אתם משתמשים. כלומר, אם אתם משתמשים בגרסה 1.36.200-gke.118 של bmctl, אתם יכולים לשדרג את האשכול רק לגרסה 1.36.200-gke.118.
שדרוגים של גרסאות תיקון
בגרסה משנית נתונה, אתם יכולים לשדרג לכל גרסת תיקון גבוהה יותר. כלומר, אפשר לשדרג אשכול בגרסה 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.600-gke.141 ל-1.36.200-gke.118.
החל מגרסה 1.33, Google Distributed Cloud תומך בדילוג על שדרוגים (שדרוג שתי גרסאות משניות בפעולה אחת). כלומר, אפשר לשדרג אשכול מגרסה 1.N.X, כאשר N היא 31 או גרסה גבוהה יותר, ישירות לגרסה 1.N+2.Z בפעולה אחת.
אפשר לדלג על שדרוגים בגרסת טרום-השקה (Preview) לגרסת היעד 1.33. בזמן שהיכולת הזו נמצאת בגרסת טרום-השקה (Preview), אנחנו לא ממליצים לדלג על שדרוגים מגרסה 1.31 ל-1.33 באשכולות בסביבת הייצור. האפשרות לדלג על שדרוגים זמינה לכולם בגרסאות יעד 1.34 ואילך.
1.32 ומטה
אתם יכולים לשדרג אשכולות מגרסה משנית אחת לגרסה המשנית הבאה, בלי קשר לגרסת התיקון. כלומר, אפשר לשדרג מ-1.N.X ל-1.N+1.Y, כאשר 1.N.X היא גרסת האשכול ו-N+1 היא הגרסה המשנית הבאה שזמינה. גרסאות התיקון, X ו-Y, לא משפיעות על הלוגיקה של השדרוג במקרה הזה. לדוגמה, אפשר לשדרג מ-1.35.600-gke.141 ל-1.36.200-gke.118.
בגרסאות שקדמו ל-1.33, אי אפשר לדלג על גרסאות משניות כשמשדרגים אשכולות. אם תנסו לשדרג לגרסה משנית שגבוהה בשתי גרסאות משניות או יותר מהגרסה הנוכחית של האשכול, bmctl יציג שגיאה. לדוגמה, אי אפשר לשדרג אשכול מגרסה 1.30.0 לגרסה 1.32.0 בשלב אחד.
כמו שצוין קודם, אשכול אדמין יכול לנהל אשכולות משתמשים באותה גרסה או בגרסה נמוכה יותר. ההבדל בגרסאות בין אשכולות המשתמשים לבין האשכול שמנהל אותם (לפעמים נקרא הטיית גרסה) משתנה בהתאם לגרסת האשכול. לפני שמשדרגים אשכול ניהול לגרסה משנית חדשה, צריך לוודא שהגרסאות של אשכולות המשתמשים המנוהלים ימשיכו לעמוד בכללי ההטיה של גרסאות האשכולות לגרסת השדרוג הרצויה.
כללים לניהול גרסאות של מאגרי צמתים
כשמשדרגים מאגרי צמתים באופן סלקטיבי, חלים כללי הגרסאות הבאים:
1.30 ומעלה
גרסת האשכול צריכה להיות גדולה מגרסת מאגר הצמתים העובדים או שווה לה.
ההפרש המקסימלי בין גרסת מאגר הצמתים של ה-worker לבין גרסת האשכול הוא שתי גרסאות משניות.
מאגרי צומתי העובדים יכולים להיות בכל גרסת תיקון של גרסה משנית תואמת.
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)) ההפרש המקסימלי בין גרסת מאגר צומתי העובדים לבין גרסת האשכול הוא שתי גרסאות משניות, כשמופעלת התכונה Preview של הפרש הגרסאות n-2. אם לא תפעילו את היכולת הזו, ההפרש המקסימלי בין הגרסאות של מאגר צומתי העובדים והאשכול הוא גרסה משנית אחת.
מאגרי צומתי העובדים לא יכולים להיות בגרסה שפורסמה כרונולוגית אחרי גרסת האשכול. הגרסה המוקדמת יותר לא כוללת את הפרטים המלאים של הגרסה המאוחרת יותר, שנדרשים לצורך תאימות.
לדוגמה, גרסה 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
| גרסת האשכול (מישור הבקרה) | גרסאות נתמכות של מאגרי צומתי עובדים (הגרסאות שנוספו מודגשות) | |||
|---|---|---|---|---|
| 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
| גרסת האשכול (מישור הבקרה) | גרסאות נתמכות של מאגרי צומתי עובדים (הגרסאות שנוספו מודגשות) | |||
|---|---|---|---|---|
| 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
| גרסת האשכול (מישור הבקרה) | גרסאות נתמכות של מאגרי צומתי עובדים (הגרסאות שנוספו מודגשות) | |||
|---|---|---|---|---|
| 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 התוספים של הפלטפורמה | Pod סטטיים של מישור הבקרה של 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 speakers כדי לתבוע כתובות IP וירטואליות |
פודים סטטיים של מאזן העומסים של מישור הבקרה (HAProxy, Keepalived)
רמקולים של MetalLB |
זמן השבתה צפוי
בטבלה הבאה מפורטים זמני ההשבתה הצפויים וההשפעה האפשרית של שדרוג אשכולות. ההנחה בטבלה הזו היא שיש לכם כמה צומתי אשכולות ומישור בקרה עם זמינות גבוהה. אם אתם מפעילים אשכול עצמאי או שאין לכם מישור בקרה עם זמינות גבוהה, צפו לזמן השבתה נוסף. אלא אם צוין אחרת, זמן ההשבתה הזה חל גם על שדרוגים של אשכולות אדמין וגם על שדרוגים של אשכולות משתמשים:
| רכיבים | ציפיות לגבי זמן ההשבתה | מתי מתרחשת השבתה |
|---|---|---|
שרת ה-API של מישור הבקרה של Kubernetes (kube-apiserver), etcd ומתזמן |
ללא זמן השבתה | לא רלוונטי |
בקרים של מחזור חיים ומשימת ansible-runner (אשכול אדמין בלבד) |
ללא זמן השבתה | לא רלוונטי |
מישור הבקרה של Kubernetes loadbalancer-haproxy ו-keepalived |
זמן השבתה זמני (פחות מדקה או שתיים) כשמאזן העומסים מפנה את התנועה. | תחילת תהליך השדרוג. |
ניראות (observability) pipeline-stackdriver וגם
metrics-server |
האופרטור נוקז ושודרג. זמן ההשבתה אמור להיות פחות מ-5 דקות.
DaemonSets ממשיכים לפעול ללא זמן השבתה. |
אחרי שהשדרוג של צומתי מישור הבקרה מסתיים. |
| ממשק רשת של קונטיינרים (CNI) | אין זמן השבתה של מסלולי הרשת הקיימים. DaemonSet נפרס בזוגות ללא זמן השבתה. המפעיל מרוקן ומשודרג. זמן השבתה של פחות מ-5 דקות. |
אחרי שהשדרוג של צומתי מישור הבקרה מסתיים. |
| MetalLB (אשכול משתמשים בלבד) | האופרטור נוקז ושודרג. זמן ההשבתה הוא פחות מ-5 דקות.
השירות הקיים מושבת לזמן קצר (פחות מדקה) כשמאזן העומסים מפנה את התנועה. |
אחרי שהשדרוג של צומתי מישור הבקרה מסתיים. |
| CoreDNS ו-DNS autoscaler (אשכול משתמשים בלבד) | ל-CoreDNS יש כמה רפליקות עם התאמה אוטומטית לעומס. בדרך כלל אין זמן השבתה. | אחרי שהשדרוג של צומתי מישור הבקרה מסתיים. |
| הקצאת נפח אחסון מקומי | אין זמן השבתה של אמצעי אחסון מתמידים (PV) קיימים שהוקצו.
יכול להיות שהמפעיל לא יהיה זמין למשך 5 דקות. |
אחרי שהשדרוג של צומתי מישור הבקרה מסתיים. |
| Istio / תעבורת נתונים נכנסת (Ingress) | האופרטור של Istio מרוקן ומשודרג. כ-5 דקות של זמן השבתה. הגדרות Ingress קיימות ממשיכות לפעול. |
אחרי שהשדרוג של צומתי מישור הבקרה מסתיים. |
| מפעילי מערכות אחרים | זמן השבתה של 5 דקות בזמן הניקוז והשדרוג. | אחרי שהשדרוג של צומתי מישור הבקרה מסתיים. |
| עומסי עבודה של משתמשים | תלוי בהגדרה, למשל אם יש זמינות גבוהה. כדאי לבדוק את פריסות עומסי העבודה שלכם כדי להבין את ההשפעה הפוטנציאלית. |
כשצומתי העובדים משודרגים. |
פרטי השדרוג של אשכול המשתמשים
בקטע הזה מפורטים סדר השדרוגים של הרכיבים ופרטי הסטטוס של שדרוג אשכול משתמש. בקטע הבא מפורטות חריגות מהתהליך הזה בשדרוגים של אשכולות אדמין, אשכולות היברידיים או אשכולות נפרדים.
בתרשים הבא מוצג תהליך הבדיקה המקדימה לשדרוג של אשכול משתמש:
בתרשים שלמעלה מפורטים השלבים שמתרחשים במהלך השדרוג:
- הפקודה
bmctl upgrade clusterיוצרת משאב בהתאמה אישית שלPreflightCheck. - בדיקת ההכנה הזו מריצה בדיקות נוספות, כמו בדיקות של שדרוג האשכול, בדיקות תקינות של הרשת ובדיקות תקינות של הצמתים.
- התוצאות של הבדיקות הנוספות האלה משולבות כדי לדווח על היכולת של האשכול לשדרג בהצלחה לגרסת היעד.
אם הבדיקות המקדימות מסתיימות בהצלחה ואין בעיות שחוסמות את השדרוג, הרכיבים באשכול משודרגים בסדר מסוים, כמו שמוצג בתרשים הבא:
בתרשים שלמעלה, הרכיבים משודרגים לפי הסדר הבא:
השדרוג מתחיל בעדכון השדה
spec.anthosBareMetalVersion.מערכות איזון העומסים של מישור הבקרה משודרגות.
מאגר הצמתים של מישור הבקרה משודרג.
אחרי שמאגר הצמתים של מישור הבקרה משודרג, הרכיבים הבאים משודרגים במקביל:
- חיבור נציג
- תוספים לאשכולות
- מאגר צמתים של מאזן עומסים
אחרי שמאגר הצמתים של מאזן העומסים משודרג, מאגרי הצמתים של העובדים משודרגים.
אחרי שכל הרכיבים שודרגו, מתבצעות בדיקות תקינות של האשכול.
בדיקות התקינות ממשיכות לפעול עד שכל הבדיקות עוברות בהצלחה.
כשהבדיקות של תקינות המערכת עוברות, השדרוג מסתיים.
לכל רכיב יש שדה סטטוס משלו בתוך המשאב המותאם אישית של האשכול. כדי להבין את התקדמות השדרוג, אפשר לבדוק את הסטטוס בשדות הבאים:
| רצף | שם השדה | משמעות |
|---|---|---|
| 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 לשדרוג, האפשרות הזו עדיין זמינה. כדי להשתמש באשכול אתחול כשמשדרגים, מריצים את הפקודה 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.
שדרוג באמצעות אשכול אתחול
תהליך השדרוג של אשכול אדמין, אשכול היברידי או אשכול עצמאי דומה לתהליך השדרוג של אשכול משתמש שמתואר בקטע הקודם.
ההבדל העיקרי הוא שהפקודה bmctl upgrade cluster מתחילה תהליך ליצירת אשכול אתחול. אשכול ה-bootstrap הזה הוא אשכול זמני שמנהל את האשכול ההיברידי, אשכול הניהול או האשכול העצמאי במהלך השדרוג.
התהליך של העברת הבעלות על ניהול האשכול לאשכול ה-bootstrap נקרא pivot. שאר תהליך השדרוג זהה לתהליך השדרוג של אשכול המשתמש.
במהלך תהליך השדרוג, המשאבים באשכול היעד נשארים לא מעודכנים. ההתקדמות של השדרוג משתקפת רק במשאבים של אשכול ה-bootstrap.
במקרה הצורך, אתם יכולים לגשת לאשכול ה-bootstrap כדי לעקוב אחרי תהליך השדרוג ולנפות בו באגים. אפשר לגשת לאשכול ה-bootstrap דרך bmctl-workspace/.kindkubeconfig.
כדי להעביר בחזרה את הבעלות על ניהול האשכול אחרי השדרוג, האשכול מעביר את המשאבים מאשכול ה-bootstrap לאשכול המשודרג. אין שלבים ידניים שצריך לבצע כדי להעביר את האשכול במהלך תהליך השדרוג. אשכול ה-bootstrap נמחק אחרי שהשדרוג של האשכול מסתיים.
ניקוז צמתים
שדרוגים של אשכולות ב-Google Distributed Cloud עלולים לגרום לשיבושים באפליקציה בזמן ניקוז הצמתים. תהליך הניקוז הזה גורם לכל ה-Pods שפועלים בצומת להיכבות ולהתחיל מחדש בצמתים שנותרו באשכול.
אפשר להשתמש בפריסות כדי להתמודד עם שיבושים כאלה. בפריסה אפשר לציין שצריך להריץ כמה רפליקות של אפליקציה או שירות. באפליקציה עם כמה רפליקות, לא אמורים להיות שיבושים במהלך השדרוגים.
PodDisruptionBudgets (PDBs)
כשמשדרגים אשכול, Google Distributed Cloud משתמש בתהליך של מצב תחזוקה כדי לרוקן צמתים.
החל מגרסה 1.29, הצמתים מרוקנים באמצעות Eviction API, שמכבד את PodDisruptionBudgets (PDBs). אפשר להשתמש ב-PDB כדי להבטיח שמספר מוגדר של רפליקות תמיד יפעל באשכול בתנאי הפעלה רגילים.
תקציבי PDB מאפשרים להגביל את השיבוש בעומס העבודה כשצריך לתזמן מחדש את ה-Pods שלו. פינוי צמתים שמבוסס על פינוי זמין כ-GA בגרסה 1.29.
בגרסאות 1.28 ומטה, Google Distributed Cloud לא מכבד את ה-PDB כשצמתים מתרוקנים במהלך שדרוג. במקום זאת, תהליך פינוי הצומת מתבצע כמיטב היכולת. יכול להיות שחלק מה-Pods ייתקעו במצב Terminating ולא יתפנו מהצומת. השדרוג ממשיך, גם עם Pods תקועים, כשניקוז הצומת נמשך יותר מ-20 דקות.
מידע נוסף זמין במאמר העברת צמתים למצב תחזוקה.
המאמרים הבאים
- שיטות מומלצות לשדרוגים של Google Distributed Cloud
- שדרוג של Google Distributed Cloud
- פתרון בעיות בשדרוג אשכולות