כשמשדרגים את 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 תצוגה מקדימה) גרסאות של אשכולות משתמשים יכולות להיות עד שתי גרסאות משניות מתחת לגרסה של האשכול המנהל. לדוגמה, אשכול אדמין בגרסה 1.29 יכול לנהל אשכול משתמש בגרסה 1.16. הניהול של הטיית הגרסאות n-2 זמין כגרסת תצוגה מקדימה לניהול אשכולות בגרסה 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.600-gke.141 ל-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.600-gke.141 ל-1.36.100-gke.144.
בגרסאות שקדמו ל-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 התוספים של הפלטפורמה | 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 speakers כדי לתבוע כתובות IP וירטואליות |
מאזני עומסים של מישור הבקרה, תרמילי Pod סטטיים (HAProxy, Keepalived)
רמקולים של MetalLB |
הציפייה לגבי זמן השבתה
בטבלה הבאה מפורט זמן ההשבתה הצפוי וההשפעה הפוטנציאלית כשמשדרגים אשכולות. הטבלה הזו מניחה שיש לכם כמה צמתי אשכול ומישור בקרה עם זמינות גבוהה. אם אתם מפעילים אשכול עצמאי או שאין לכם מישור בקרה של זמינות גבוהה, צפוי זמן השבתה נוסף. אלא אם צוין אחרת, זמן ההשבתה הזה חל גם על שדרוגים של אשכולות אדמין וגם על שדרוגים של אשכולות משתמשים:
| רכיבים | ציפיות לגבי זמן ההשבתה | מתי מתרחשת השבתה |
|---|---|---|
שרת ה-API של מישור הבקרה של Kubernetes (kube-apiserver), etcd ומתזמן |
ללא זמן השבתה | לא רלוונטי |
בקרים של מחזור חיים ומשימת ansible-runner (אשכול אדמין בלבד) |
ללא זמן השבתה | לא רלוונטי |
מישור הבקרה של Kubernetes loadbalancer-haproxy ו-
keepalived |
זמן השבתה זמני (פחות מדקה או שתיים) כשמאזן העומסים מפנה את התנועה. | תחילת תהליך השדרוג. |
ניראות (observability) pipeline-stackdriver וגם
metrics-server |
ה-Operator רוקן ושודרג. זמן ההשבתה אמור להיות פחות מ-5 דקות.
DaemonSets ממשיכים לפעול ללא זמן השבתה. |
אחרי שהשדרוג של צומתי מישור הבקרה מסתיים. |
| ממשק רשת של קונטיינרים (CNI) | אין זמן השבתה של מסלולי הרשת הקיימים. DaemonSet נפרס בזוגות ללא זמן השבתה. המפעיל מרוקן ומשודרג. זמן השבתה של פחות מ-5 דקות. |
אחרי ששדרוג הצמתים במישור הבקרה מסתיים. |
| MetalLB (אשכול משתמשים בלבד) | האופרטור נוקז ושודרג. זמן ההשבתה הוא פחות מ-5 דקות.
השירות הקיים מושבת לזמן קצר (פחות מדקה) כשמאזן העומסים מפנה את התנועה. |
אחרי שהשדרוג של צומתי מישור הבקרה מסתיים. |
| CoreDNS ו-DNS autoscaler (אשכול משתמשים בלבד) | ל-CoreDNS יש כמה רפליקות עם התאמה אוטומטית לעומס. בדרך כלל אין השבתה. | אחרי שהשדרוג של צומתי מישור הבקרה מסתיים. |
| הקצאת נפח אחסון מקומי | אין זמן השבתה לנפחי אחסון קיימים שמוקצים באופן קבוע (PV).
יכול להיות שהמפעיל לא יהיה זמין למשך 5 דקות. |
אחרי שהשדרוג של צומתי מישור הבקרה מסתיים. |
| Istio / תעבורת נתונים נכנסת (Ingress) | ה-operator של Istio מנוקז ומשודרג. כ-5 דקות של השבתה. הגדרות קיימות של תעבורת נכנסת ימשיכו לפעול. |
אחרי שהשדרוג של צומתי מישור הבקרה מסתיים. |
| מפעילי מערכות אחרים | 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.
שדרוג באמצעות אשכול bootstrap
התהליך לשדרוג אשכול אדמין, אשכול היברידי או אשכול עצמאי דומה לתהליך לשדרוג אשכול משתמש שמוסבר בקטע הקודם.
ההבדל העיקרי הוא שהפקודה bmctl upgrade cluster מתחילה תהליך ליצירת אשכול אתחול. אשכול האתחול הוא אשכול זמני שמנהל את האשכול ההיברידי, האדמיניסטרטיבי או העצמאי במהלך השדרוג.
התהליך של העברת הבעלות על הניהול של האשכול לאשכול האתחול נקרא pivot. שאר תהליך השדרוג זהה לתהליך השדרוג של אשכול המשתמש.
במהלך תהליך השדרוג, המשאבים באשכול היעד נשארים לא מעודכנים. התקדמות השדרוג משתקפת רק במשאבים של אשכול האתחול.
במקרה הצורך, אתם יכולים לגשת לאשכול ה-bootstrap כדי לעקוב אחרי תהליך השדרוג ולנפות בו באגים. אפשר לגשת לאשכול ה-bootstrap דרך bmctl-workspace/.kindkubeconfig.
כדי להעביר בחזרה את הבעלות על ניהול האשכול אחרי השדרוג, האשכול מעביר את המשאבים מאשכול ה-bootstrap לאשכול המשודרג. אין שלבים ידניים שצריך לבצע כדי להעביר את האשכול במהלך תהליך השדרוג. אשכול האתחול נמחק אחרי ששדרוג האשכול מסתיים בהצלחה.
ניקוז צמתים
שדרוגים של אשכולות ב-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 ולא יפנו את המקום בצומת. השדרוג ממשיך, גם עם Pods תקועים, כשניקוז הצומת נמשך יותר מ-20 דקות.
מידע נוסף מופיע במאמר בנושא העברת צמתים למצב תחזוקה.
המאמרים הבאים
- שיטות מומלצות לשדרוגים של Google Distributed Cloud
- שדרוג של Google Distributed Cloud
- פתרון בעיות בשדרוג אשכולות