מודרניזציה של מישור הבקרה המנוהל

כדי להמשיך לקבל תמיכה, צריך להעביר את צי Cloud Service Mesh ממימוש שיצא משימוש של מישור הבקרה ISTIOD למימוש TRAFFIC_DIRECTOR לפני המועד האחרון לסיום התמיכה. אתם יכולים להתחיל את המודרניזציה לפי לוח הזמנים שלכם, או לאפשר ל-Google לתזמן אותה באופן אוטומטי ברגע שהארגון שלכם יהיה תואם.

יש שתי דרכים לעדכן את המערכת, ואפשר גם לשלב ביניהן:

  • מודרניזציה בהפעלה על ידי הלקוח (שירות עצמי): אתם מפעילים את המודרניזציה של צי המחשבים וקובעים את התזמון המדויק שלה באמצעות Google Cloud CLI, ללא תלות בלוחות זמנים שנקבעו על ידי Google.
  • מודרניזציה בניהול Google (ברירת מחדל): Google מעריכה את התאימות של צי המכשירים ומתזמנת באופן אוטומטי את המודרניזציה בארגון שלכם בהתאם לחלונות הזמן לתחזוקה ולהודעות מראש. ‫Google מחכה שכל המכשירים בארגון יהיו תואמים, ולכן מכשיר אחד לא תואם יחסום את המודרניזציה.

לא משנה באיזו דרך תבחרו, תצטרכו לבצע את השלבים הבסיסיים הבאים כדי לעדכן את מישור הבקרה:

  1. בדיקת התאימות: הפעלת בדיקות תאימות והבנת התאימות של צי המכשירים שלכם למודרניזציה.
  2. תכנון והגדרה של המודרניזציה: בוחרים את המסלול, מגדירים את סדר ההשקה של האשכולות וה-Fleet או דוחים את ההשקה של Fleet ספציפי.
  3. תיקון פערים בתאימות: לפני שמתחילים בתהליך המודרניזציה, חשוב לוודא שהציוד עומד בכל דרישות התאימות.
  4. התחלת המודרניזציה: הפעלת מודרניזציה שמופעלת על ידי הלקוח לפי לוח הזמנים שלכם, או המתנה לתזמון שמופעל על ידי Google.
  5. מודרניזציה של קלאסטר פעיל: במהלך חלונות תחזוקה מוגדרים, שני מישורי בקרה פועלים זה לצד זה, ופריסות (עומסי עבודה ושערי גישה) עוברות אוטומטית למישור הבקרה החדש. תצטרכו להפעיל מחדש באופן ידני את עומסי העבודה של StatefulSet ו-DaemonSet.
  6. מעקב אחרי הסטטוס, תקופת ההרצה והסיום: עוקבים אחרי התקדמות התנאים, פותרים בעיות שגורמות לעיכובים, בודקים את עומסי העבודה במהלך תקופת ההרצה (לפחות 6 ימי עסקים), עם תמיכה מלאה בהחזרה למצב הקודם לפני סיום ההגדרה ברמת הצי.

בדיקת התאימות של צי הרכבים וטיפול בפערים

לפני שמתחילים בתהליך מודרניזציה של צי מכשירים – בין אם מדובר במודרניזציה שמופעלת על ידי הלקוח או על ידי Google – צריך לוודא שהצי תואם. כדי לבדוק תנאים פוטנציאליים לחסימה ולפתור בעיות בהגדרות, צריך להפעיל את הדיווח על תאימות. לפרטים נוספים, ראו הסבר על התאימות של Cloud Service Mesh.

  • במסגרת מודרניזציה מבוססת-Google: Google תתזמן רק ארגונים שבהם כל צי הרכבים שלא נדחה תואם.
  • במקרה של מודרניזציה שמופעלת על ידי הלקוח: לפני שמתחילים את המודרניזציה, צריך לוודא שדוחות צי המחשבים היעד MODERNIZATION_COMPATIBLE.

בדיקות התאימות מעריכות את הגדרות ה-CRD של Istio, את ההערות של ה-Pod, את התלות בתשתית (כמו Workload Identity) ואת פרמטרים של קנה מידה.

טיפול בתכונות שלא נתמכות

במסגרת ISTIODהוצאה משימוש של רמת הבקרה,אנחנו מפסיקים את התמיכה בתכונות שלא תואמות להטמעה של TRAFFIC_DIRECTORרמת הבקרה. Google Cloud פרטים נוספים זמינים במאמר בנושא תמיכה ב-API.

אם אתם משתמשים בתכונות שלא נתמכות, אתם צריכים לבצע אחת מהפעולות הבאות לפני סיום התמיכה (ראו הוצאה משימוש):

  • שינוי מבנה ההגדרה (מומלץ): מסירים את השדות שלא נתמכים או מחליפים אותם בחלופות נתמכות של Cloud Service Mesh כדי שהדוחות של צי הרכבים MODERNIZATION_COMPATIBLE יפעלו, ואז מבצעים מודרניזציה להטמעה של מישור הבקרה TRAFFIC_DIRECTOR.
  • מעבר ל-Istio בקוד פתוח (OSS): אם עומסי העבודה שלכם דורשים תכונות ש-Cloud Service Mesh מנוהל עם TRAFFIC_DIRECTOR לא תומך בהן, לא תוכלו לבצע מודרניזציה של האשכולות האלה ל-TRAFFIC_DIRECTOR. צריך להעביר את עומסי העבודה האלה ל-Istio בקוד פתוח בניהול עצמי.
  • הסרת Cloud Service Mesh: אפשר להסיר את Cloud Service Mesh המנוהל.

תכנון והגדרה של המודרניזציה

כדאי לתכנן איך לחדש את הצי שלכם. אם לא תעשו את זה, המודרניזציה מבוססת-Google תופעל באופן שמוגדר כברירת מחדל. צריך לפעול כדי לוודא שציים שאינם בסביבת ייצור יעברו מודרניזציה קודם, וציים קריטיים יעברו מודרניזציה אחרונים. בנוסף, Google לא תתזמן את המודרניזציה של הארגון שלכם עד ש-100% מהמכשירים שלא נדחו בכל הארגון יהיו תואמים, ולכן יכול להיות שהמודרניזציה תיחסם בגלל בעיות תאימות מקומיות.

לפני שמתחילים בתהליך המודרניזציה, כדאי לבדוק את האפשרויות הזמינות ולהגדיר את הגדרות ההשקה בכל צי הרכבים והאשכולות בארגון.

תוכניות לימודים זמינות

גישה תיאור מתאים במיוחד ל היקף דרישות מוקדמות הודעה מראש יכולת החזרה למצב הקודם
מודרניזציה בהפעלה של לקוח אתם מתחילים את המודרניזציה של הצי לפי לוח הזמנים שלכם. שליטה מדויקת בתזמון של מודרניזציה של צי המכשירים (אתם מחליטים מתי להתחיל ומתי לבטל את השינויים ברמת צי המכשירים). להשתמש במעקב הקיים של האפליקציה כדי לקבל התראה אם צריך לבצע חזרה לגרסה קודמת. לפי צי (FLEET_PROJECT_ID). צי היעד חייב להיות תואם למודרניזציה. לא רלוונטית. ביצוע שחזור מיידי בשירות עצמי באמצעות Google Cloud CLI.
מודרניזציה מבוססת-Google (ברירת מחדל) ‫Google מתזמנת אוטומטית את המודרניזציה בארגון. מודרניזציה אוטומטית אחרי שכל ציוד הקצה בארגון יהיה תואם. כל Google Cloud הארגון (כל צי הרכבים שלא נדחה). כל צי הרכבים בארגון שלא נדחה חייב להיות תואם למודרניזציה. התראה על Fleet של מכונות שנשלחת 14 ימים או יותר לפני ההפעלה + התראה על אשכול שנשלחת 24 שעות או יותר לפני ההפעלה. אם המעקב המתוקנן יציג שגיאה, Google תבטל את השינוי. אם מופיעה שגיאה בנתוני המעקב של האפליקציה, צריך לפנות אל Cloud Customer Care.

ניהול כמה צי רכבים בארגון

אם Google Cloud הארגון שלכם מנהל כמה צי רכבים, אתם לא צריכים לבחור גישה אחת לכולם. אפשר לשלב בין שיטות בידינג, למשל:

  • דחיית עדכונים של צי רכבים מורכב או קריטי: אפשר להצמיד צי רכבים ספציפי להטמעה מדור קודם באמצעות --modernization-strategy deferred כדי שהוא לא ייכלל בתזמון מבוסס-Google, בזמן שאתם מטפלים בתלות או מתכננים הפעלה שמופעלת על ידי לקוח.
  • מתחילים עם מודרניזציה שמופעלת על ידי הלקוח בציים נבחרים: מודרניזציה של ציים לבדיקה, לפיתוח או להערכה כדי לאמת את ההתנהגות בציר הזמן שלכם.
  • לאפשר ל-Google לחדש את שאר צי הרכבים: כל צי רכבים תואם שלא נדחה יישאר בהסכמה לתזמון מבוסס-Google.

דחיית המודרניזציה של ה-Fleet (ביטול הסכמה)

כדי להחריג צי ספציפי מהמודרניזציה שמבוססת על Google, צריך להגדיר את האסטרטגיה שלו ל-DEFERRED:

gcloud alpha container fleet mesh update \
  --modernization-strategy deferred \
  --project FLEET_PROJECT_ID

מחליפים את FLEET_PROJECT_ID במזהה של פרויקט המארח של Fleet.

ההגדרה --modernization-strategy deferred היא הדרך המומלצת לבצע את הפעולות הבאות:

  • להחריג צי ספציפי מתזמון מבוסס-Google כי אתם מתכוונים לבצע מודרניזציה של הצי הזה בעצמכם, לפי לוח הזמנים שלכם, באמצעות מודרניזציה שמופעלת על ידי הלקוח.
  • אפשר להשהות באופן זמני את המודרניזציה של ציוד מורכב או קריטי בזמן שאתם מטפלים בתלות, וכך לאפשר לציוד תואם אחר בארגון להמשיך בתזמון מבוסס-Google.

שימו לב: התווית הקודמת של הפרויקט mesh-modernization-mode=manual עדיין תקפה, אבל מומלץ להשתמש בתווית --modernization-strategy deferred. ציים אחרים בארגון שלא נדחו עדיין יכולים להשתמש בתזמון מבוסס-Google אחרי שכל המכשירים יהיו תואמים.

הגדרת סדר ההשקה

אתם יכולים לשלוט בסדר ההשקה העוקב בכל האשכולות והציים באמצעות התווית mesh-modernization-order (מוקדם, ברירת מחדל או מאוחר).

סדר הפריסה של האשכול (רלוונטי לשני המסלולים)

אם צי מכיל כמה אשכולות, אפשר לשלוט בסדר שבו האשכולות עוברים מודרניזציה על ידי החלת התווית mesh-modernization-order על כל אשכול. כשאתם או Google מפעילים מודרניזציה של צי, כל קבוצת אשכולות עוברת מודרניזציה ברצף. המערכת מחכה לסיום שלבי המודרניזציה האוטומטיים בקבוצה הנוכחית לפני שהיא מתחילה את הקבוצה הבאה:

gcloud container clusters update CLUSTER_NAME \
  --location LOCATION \
  --update-labels="mesh-modernization-order=VALUE"

מחליפים את CLUSTER_NAME בשם האשכול, את LOCATION במיקום האשכול ואת VALUE באחד מהערכים הבאים:

  • ‫early: האשכול עובר מודרניזציה בגל הראשון של המודרניזציה.
  • ‫default: האשכול עובר מודרניזציה בגל השני של המודרניזציה.
  • ‫late: האשכול עובר מודרניזציה בגל השלישי והאחרון של המודרניזציה.

סדר ההשקה של ה-Fleet (רק בניהול של Google)

בארגונים עם כמה קבוצות של מכשירים שעוברות מודרניזציה בהובלת Google, אפשר לשלוט בסדר שבו Google מבצעת מודרניזציה של קבוצות המכשירים על ידי הגדרת התווית ברמת הפרויקט בפרויקט המארח של קבוצת המכשירים:

gcloud alpha projects update FLEET_PROJECT_ID \
  --update-labels="mesh-modernization-order=VALUE"

מחליפים את FLEET_PROJECT_ID במזהה של פרויקט המארח של ה-Fleet ואת VALUE באחד מהערכים הבאים:

  • ‫early: הצי עובר מודרניזציה בגל הראשון של המודרניזציה.
  • ‫default: הצי עובר מודרניזציה בגל השני של המודרניזציה.
  • ‫late: הצי עובר מודרניזציה בגל השלישי והאחרון של המודרניזציה.

‫Google משלים את המודרניזציה של כל רמת צי לפני שהוא מתחיל את הרמה הבאה: קודם כל המוקדמת, אחר כך ברירת המחדל (וללא תווית), ואז המאוחרת. ציים שמסומנים כציים שנדחו לא נכללים בהזמנה הזו.

לדוגמה, אפשר להגדיר את צי הרכבים שאינם בסביבת ייצור ל-early, צי רכבים קריטי במיוחד ל-late, ולהשאיר את השאר בהגדרת ברירת המחדל.

אם אתם לא משתמשים Google Cloud בארגונים ב-Google Cloud, הציים שלכם יתוזמנו ויעברו מודרניזציה באופן עצמאי, ולא תוכלו לשלוט בסדר הפעולות.

מודרניזציה שמופעלת על ידי הלקוח (שירות עצמי)

מודרניזציה שמופעלת על ידי הלקוח מאפשרת לכם שליטה ישירה על מועד תחילת המודרניזציה של צי מסוים.

הפעלת מודרניזציה של ה-Fleet

אחרי שיוצרים את הדוחות של צי היעד MODERNIZATION_COMPATIBLE, מפעילים את המודרניזציה באמצעות הפקודה הבאה:

gcloud alpha container fleet mesh update \
  --modernization-strategy automatic \
  --project FLEET_PROJECT_ID

מחליפים את FLEET_PROJECT_ID במזהה של פרויקט המארח של Fleet.

  • חלונות תחזוקה: Google מכבדת את חלונות התחזוקה וההחרגות של אשכולות שהוגדרו. המודרניזציה של האשכול מתחילה במהלך חלון זמן התחזוקה הפתוח הבא של האשכול.
  • סדר האשכולות: אם הגדרתם תוויות mesh-modernization-order באשכולות, Google תפעל לפי הסדר הזה.

מעקב אחרי ההתקדמות

כדי לעקוב אחרי ההתקדמות של המודרניזציה של Fleet והאשכולות, פועלים לפי ההוראות במאמר בדיקת סטטוס המודרניזציה. כדאי לעקוב אחרי הניטור של האפליקציה כדי להחליט אם צריך לבצע חזרה לגרסה הקודמת, במיוחד כשמופיעים הסטטוסים MODERNIZATION_PREPARING ו-MODERNIZATION_MIGRATING_WORKLOADS.

ביטול שינויים במודרניזציה שהופעלה על ידי לקוח

אם מזהים בעיות במהלך מודרניזציה של אשכול פעיל או במהלך תקופת ההרצה של Fleet (לפני השלמת התהליך ברמת ה-Fleet), אפשר להפעיל רולבק מיידי:

gcloud alpha container fleet mesh update \
  --modernization-strategy deferred \
  --project FLEET_PROJECT_ID

מחליפים את FLEET_PROJECT_ID במזהה של פרויקט המארח של Fleet.

הפעולה הזו תשאיר את כלל המכשירים במצב 'נדחה', כלומר הם לא ייכללו בתהליך המודרניזציה שמבוסס על נתונים מ-Google. כשמוכנים לנסות שוב את המודרניזציה, מריצים מחדש את הפקודה כדי להפעיל מודרניזציה של Fleet.

מודרניזציה מבוססת-Google (ברירת מחדל אוטומטית)

אם לא תפעילו את המודרניזציה בעצמכם, Google תנהל את המודרניזציה בארגון שלכם באופן אוטומטי.

תזמון ברמת הארגון

‫Google עוקבת באופן רציף אחרי צי המכוניות שלכם. אחרי שכל צי הרכבים בארגון שלכם שתומכים ב-Mesh (לא כולל צי רכבים שההעברה שלהם נדחתה) יהיו תואמים למודרניזציה, Google תתזמן את הארגון שלכם למודרניזציה.

התראות מראש ותזמון

‫Google מספקת שני סוגים של הודעות מראש לפני תחילת המודרניזציה:

התראה ברמת הצי

קודם כל, תקבלו הודעה כשהציים שלכם יזוהו כמתאימים למודרניזציה, וייבחרו למודרניזציה מבוססת-Google שתתבצע בעתיד.

  • המודרניזציה של האשכול יכולה להתחיל כבר 14 ימים אחרי יום העסקים הראשון בארה"ב בחודש שאחרי קבלת ההודעה. לדוגמה, אם Google תקבע שהארגון שלכם מוכן ב-10 בינואר 2027, נודיע לכם עד 31 בינואר 2027 שתאריך ההתחלה המוקדם ביותר האפשרי של המודרניזציה הוא 15 בפברואר 2027.

  • תקבלו התראה בו-זמנית על כל צי הרכבים בארגון (לא כולל אלה שדחיתם). ההתראה הזו זמינה בתנאים של סטטוס התכונה ברמת הצי (MODERNIZATION_WILL_BE_SCHEDULED).

התראה ברמת האשכול

תקבלו הודעה ברמת האשכול לגבי תאריך ההתחלה המשוער של המודרניזציה של האשכול הזה על ידי Google, לפחות יום אחד (24 שעות) לפני תחילת המודרניזציה של האשכול.

אחרי ההתראה ברמת הצי, תקבלו תזמון מדויק יותר של מודרניזציה של אשכולות ספציפיים. ההתראה הזו זמינה בתנאים של סטטוס התכונה ברמת האשכול (MODERNIZATION_SCHEDULED).

בקשה להחזרה לגרסה קודמת של מודרניזציה מבוססת-Google

אם מתעוררות בעיות במהלך מודרניזציה פעילה או במהלך תקופת ההרצה של ציוד מודרניזציה שמנוהל על ידי Google, אפשר לפנות אל Cloud Customer Care כדי לבקש חזרה לגרסה הקודמת.

מה קורה במהלך מודרניזציה פעילה

בקטע הזה מתואר מה קורה במהלך מודרניזציה פעילה של ציוד ושל אשכולות.

מודרניזציה של צי הרכב

לכל צי של מכונות שעוברות מודרניזציה (בין אם מדובר במודרניזציה שמונעת על ידי Google או כזו שמופעלת על ידי הלקוח), אנחנו מפעילים את ההטמעה החדשה של רמת הבקרה לכל האשכולות על סמך סדר (מוקדם ← ברירת מחדל ← מאוחר).

אחרי שמפעילים את רמת הבקרה בכל האשכולות, אנחנו מעבירים את התנועה להטמעה החדשה של רמת הבקרה בכל האשכולות על סמך הסדר (מוקדם → ברירת מחדל → מאוחר).

כדי לבדוק את הסטטוס הנוכחי, אפשר לעיין במאמר בנושא בדיקת סטטוס המודרניזציה של צי הרכבים.

תקופת ההרצה של ה-Fleet

אחרי שהתנועה מועברת לכל האשכולות, הצי נכנס לתקופת הרצה. הצי נשאר בתקופת ההמתנה (MODERNIZATION_MODERNIZED) למשך לפחות 6 ימי עסקים אחרי שכל האשכולות מסיימים את המודרניזציה, לפני המעבר ל-MODERNIZATION_FINALIZED. היכולת לבצע חזרה מלאה לגרסה הקודמת נשמרת לאורך תקופת ההרצה. אחרי שהמודרניזציה מסתיימת, אי אפשר לבצע חזרה לגרסה הקודמת, ויכול להיות שהרכיבים של ISTIOD יבוטלו.

מודרניזציה של אשכול

במהלך מודרניזציה פעילה של אשכול, שתי ההטמעות של מישור הבקרה מורצות באופן זמני זו לצד זו, ובאופן בטוח ומבוקר, המשימות הבאות מעובדות:

  1. הפעלת ההטמעה החדשה של מישור הבקרה. אם הגדרתם חלונות זמן לתחזוקה לאשכול, השלב הזה יתחיל במהלך חלון זמן לתחזוקה וימשיך עד להשלמתו. חשוב לזכור את הפרטים הבאים:
    • כדי להפעיל בדיקות תקינות, נוצרת קבוצת ה-daemonset‏ snk במרחב השמות kube-system של האשכול, ונוצר כלל חומת אש לכל אשכול.
    • כדי להפעיל את ההטמעה של קבוצה של נקודות קצה ברשת (NEG), מוסיפים את ההערה cloud.google.com/neg לכל שירותי Kubernetes.
    • נוצרים משאבים חדשים Google Cloud כמו mesh,‏ routes,‏ backend services ו-health checks באשכול.
    • חלק מהמשאבים החדשים מוגבלים במכסת השימוש. אתם יכולים לראות את המכסות ולבקש עוד אם צריך.
    • האשכול עובר מעקב במהלך תקופת ההרצה לפני המעבר לשלב הבא.
  2. העברת התנועה להטמעה החדשה של מישור הבקרה. אם הגדרתם חלונות זמן לתחזוקה לאשכול, השלב הזה יתחיל במהלך חלון זמן לתחזוקה וימשיך עד להשלמתו. חשוב לזכור את הפרטים הבאים:
    • תתבצע הפעלה מחדש של פודים שמנוהלים על ידי פריסת Kubernetes שיש להם פרוקסי של Cloud Service Mesh, כדי שהם יתחברו מחדש למישור הבקרה החדש.
    • הפודים מופעלים מחדש בגלים הולכים וגדלים, עם זמן השהיה אחרי כל גל לצורך מעקב.

  3. הפעלה מחדש ידנית של עומסי עבודה שלא קשורים לפריסות (נדרשת פעולה מצד הלקוח).

    • ‫Google מפעילה מחדש באופן אוטומטי עומסי עבודה שמנוהלים על ידי Kubernetes Deployments. צריך להפעיל מחדש באופן ידני עומסי עבודה שמנוהלים על ידי סוגים אחרים של משאבי Kubernetes, כמו StatefulSets ו-DaemonSets.
    • מפעילים מחדש את עומסי העבודה האלה אחרי שהסטטוס של האשכול מדווח על MODERNIZATION_COMPLETED (כלומר, כשהאשכול נמצא בתקופת ההמתנה).
    • צריך להפעיל מחדש את עומסי העבודה האלה לפני שהמודרניזציה של הצי מסתיימת, אחרת הפרוקסי האלה יישארו מחוברים למישור הבקרה מדור קודם של Istiod, שמתוכנן לביטול ההקצאה.
    • מפעילים מחדש עומסי עבודה באמצעות גישות סטנדרטיות של Kubernetes, כמו kubectl rollout restart ...

  4. אחרי שכל עומסי העבודה באשכול עוברים, האשכול ממתין לתקופת ההרצה של fleet.

כדי לעקוב אחרי סטטוס המודרניזציה הפעיל של האשכולות, אפשר לעיין במאמר בנושא בדיקת סטטוס המודרניזציה.

בדיקת סטטוס המודרניזציה וביצוע פעולה

אפשר לעקוב אחרי התקדמות המודרניזציה של צי הרכבים והאשכולות באמצעות Google Cloud CLI:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

מחליפים את FLEET_PROJECT_ID במזהה של פרויקט המארח של Fleet.

הפלט אמור להיראות כך:

  membershipStates:
    projects/123456789/locations/global/memberships/cluster-1:
      servicemesh:
        conditions:
        - code: MODERNIZATION_MIGRATING_WORKLOADS
          documentationLink: https://cloud.google.com/service-mesh/docs/...
          severity: INFO
  state:
    servicemesh:
      conditions:
      - code: MODERNIZATION_MODERNIZING
        documentationLink: https://cloud.google.com/service-mesh/docs/...
        severity: INFO

סטטוס המודרניזציה מדווח בשדות state.servicemesh.conditions (ברמת הצי) ו-membershipStates.<MEMBERSHIP_NAME>.servicemesh.conditions (ברמת האשכול):

סטטוס של מודרניזציה מוצלחת של צי הרכבים

במודרניזציה מוצלחת של צי הרכבים, הסטטוס של צי הרכבים יהיה MODERNIZATION_MODERNIZING.

כל אשכול יעבור את הסטטוסים הבאים:

  • MODERNIZATION_SCHEDULED
  • MODERNIZATION_PREPARING
  • MODERNIZATION_PREPARED
  • MODERNIZATION_MIGRATING_WORKLOADS
  • MODERNIZATION_COMPLETED

אחרי שכל האשכולות בצי יסיימו את המודרניזציה, הצי יעבור בין הסטטוסים הבאים:

  • MODERNIZATION_MODERNIZED
  • MODERNIZATION_FINALIZED

חזרה למצב קודם

המודרניזציה מבוססת-Google עוקבת אחרי המוכנות והתקינות של הפריסה לאורך תהליך המודרניזציה, ואנחנו נפעיל אוטומטית חזרה לגרסה קודמת אם נזהה בעיות. אם אתם מזהים בעיה, פנו אל Cloud Customer Care כדי לבקש החזרה למצב קודם.

במקרה של מודרניזציה שהופעלה על ידי הלקוח, אפשר להפעיל חזרה לגרסה הקודמת בכל שלב.

במהלך החזרה לגרסה קודמת, הסטטוס של צי המכונות הוא MODERNIZATION_ROLLING_BACK_FLEET והסטטוס של האשכול הוא MODERNIZATION_ROLLING_BACK_CLUSTER.

אחרי שחזור של אשכול, הסטטוס MODERNIZATION_ABORTED מוצג באופן זמני.

טיפול בשגיאות ובהשהיות (מופעל על ידי הלקוח בלבד)

במהלך מודרניזציה שהופעלה על ידי לקוח, אם באשכול מתרחשת בעיה שמונעת התקדמות, המצב שלו משתנה ל-MODERNIZATION_STALLED. ‫Google לא תפעיל חזרה לגרסה קודמת במקרים של מודרניזציה שהופעלה על ידי הלקוח. צריך לבדוק את הבעיה ולהחליט אם לתקן אותה או להפעיל חזרה לגרסה הקודמת.

כשקלאסטר מדווח על MODERNIZATION_STALLED, בודקים את פרטי התנאי. כדי לקבל קישור ישיר לקטע השגיאה הרלוונטי:

שגיאות שדורשות פעולה מהמשתמש

אם נזהה תצורת רשת או אשכול לא תואמת, נעצור את המודרניזציה. חשוב לוודא שהדיווח על התאימות מופעל, ולבדוק את התנאים ברמת הצי וברמת האשכול כדי לזהות פערים, כמו שמתואר במאמר הסבר על התאימות של Cloud Service Mesh.

  • ניסיון חוזר מיידי: ברגע שהבעיה שחוסמת את השדרוג נפתרת, אנחנו מזהים את השינוי וממשיכים בשדרוג באופן מיידי, בלי לחכות לחלון זמן לתחזוקה הבא.

שגיאות פנימיות

מהנדסי Google בודקים בעיות פנימיות בשירותי Google, ויחדשו את המודרניזציה שלכם אם הדבר אפשרי. שימו לב: יכול להיות שהמודרניזציה תתחדש מחוץ לחלון הזמנים לתחזוקה, בדיוק כמו במקרה של שגיאות שדורשות פעולה מצד המשתמש. כדי להימנע מכך, אפשר להפעיל חזרה לגרסה הקודמת.

אם המודרניזציה נתקעת למשך יותר מ-24 שעות, ולא נמצאו פערים בתאימות, אפשר לפנות לצוות התמיכה של Cloud לקבלת פרטים נוספים או להפעיל חזרה לגרסה הקודמת אם עומסי העבודה של הייצור מושפעים.

מידע על תנאים ברמת הצי

תנאי תיאור
MODERNIZATION_COMPATIBLE הצי תואם להטמעה החדשה של מישור הבקרה.
MODERNIZATION_WILL_BE_SCHEDULED מודרניזציה מבוססת-Google: כל ציוד הקצה שלא נדחה בארגון תואם, והוא הוכנס לתור לתזמון.
MODERNIZATION_MODERNIZING תהליך המודרניזציה מתבצע באופן פעיל באחד או יותר מהאשכולות ב-Fleet.
MODERNIZATION_MODERNIZED כל האשכולות סיימו את המודרניזציה הפעילה. הצי נמצא בתקופת ההרצה.
MODERNIZATION_FINALIZED המודרניזציה הושלמה והסתיימה. רכיבי Istiod מדור קודם יוסרו. אי אפשר יותר לבצע חזרה לגרסה הקודמת.
MODERNIZATION_ROLLING_BACK_FLEET מתבצעת חזרה לגרסה קודמת ברמת הצי.

מסמך עזר בנושא תנאים ברמת האשכול

תנאי תיאור
MODERNIZATION_SCHEDULED העדכון של האשכול מתוזמן לתאריך שצוין בתנאי או לתאריך מאוחר יותר. אם הוגדרו חלונות זמן לתחזוקה או החרגות לאשכול, התאריך יציין את חלון הזמן לתחזוקה.
MODERNIZATION_PREPARING הפעלת ההטמעה החדשה של מישור הבקרה.
MODERNIZATION_PREPARED ההטמעה החדשה של מישור הבקרה מופעלת. ההעברה של עומס העבודה עדיין לא התחילה.
MODERNIZATION_MIGRATING_WORKLOADS האשכול מעביר באופן פעיל עומסי עבודה להטמעה החדשה של מישור הבקרה.
MODERNIZATION_COMPLETED המודרניזציה של האשכול הושלמה והוא נמצא בתקופת ההרצה.
MODERNIZATION_STALLED המודרניזציה תקועה בגלל שגיאה (רק אם הלקוח הפעיל אותה). כדי לפתור את הבעיה, אפשר לעיין בפרטים של התנאי.
MODERNIZATION_ROLLING_BACK_CLUSTER מתבצעת נסיגה פעילה של האשכול.
MODERNIZATION_ABORTED האשכול הוחזר למישור הבקרה הקודם. הנתונים מדווחים לזמן קצר.