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

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

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

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

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

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

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

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

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

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

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

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

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

  • לארגן את ההגדרות מחדש (מומלץ): מסירים את השדות שלא נתמכים או מחליפים אותם בחלופות שנתמכות ב-Cloud Service Mesh, כדי שה-Fleet ידווח על 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 הארגון (כל הציים שלא נדחו). כל הציים בארגון שלא נדחו חייבים להיות תואמים למודרניזציה. התראה של 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 (מוקדם, ברירת מחדל או מאוחר).

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

אם ב-fleet יש כמה אשכולות, אתם יכולים לשלוט בסדר שבו האשכולות עוברים מודרניזציה על ידי החלת התווית 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 במזהה של הפרויקט המארח של הצי, ואת VALUE באחת מהאפשרויות הבאות:

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

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

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

אם אתם לא משתמשים בארגונים ב- 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 תכבד את הסדר הזה.

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

כדי לעקוב אחרי התקדמות המודרניזציה של הצי והאשכול, פועלים לפי ההוראות במאמר בדיקת סטטוס המודרניזציה. כדאי לעקוב אחרי האפליקציה כדי להחליט אם צריך לחזור לגרסה קודמת, במיוחד בסטטוסים 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. כשתהיו מוכנים לנסות שוב, הריצו מחדש את הפקודה כדי להפעיל את המודרניזציה של הצי.

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

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

קביעת פגישות ברמת הארגון

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תקופת ההרצה של הצי

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

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

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

  1. הפעלת ההטמעה החדשה של מישור הבקרה. אם הגדרתם חלונות זמן לתחזוקה באשכול, השלב הזה יתחיל במהלך חלון זמן לתחזוקה ויימשך עד לסיום. חשוב לזכור:
  2. מעבירים את התנועה להטמעה החדשה של מישור הבקרה. אם הגדרתם חלונות זמן לתחזוקה באשכול, השלב הזה יתחיל במהלך חלון זמן לתחזוקה ויימשך עד לסיום. חשוב לזכור:
    • פודים שמנוהלים על ידי פריסת Kubernetes עם שרתי proxy של Cloud Service Mesh מופעלים מחדש, כדי שהם יתחברו מחדש למישור הבקרה החדש.
    • הפודים מופעלים מחדש בגלים הולכים וגדלים, עם זמן טבילה אחרי כל גל לצורך מעקב.

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

    • ‫Google מפעילה מחדש באופן אוטומטי עומסי עבודה שמנוהלים על ידי פריסות של Kubernetes. עומסי עבודה שמנוהלים על ידי סוגים אחרים של משאבים ב-Kubernetes, כמו StatefulSets ו-DaemonSets, צריך להפעיל מחדש באופן ידני.
    • אחרי שמפעילים מחדש את עומסי העבודה של Deployment, אם לעומסי עבודה כלשהם באשכול עדיין יש שרתי proxy של Cloud Service Mesh שמחוברים אל ISTIOD, האשכול מדווח על MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART לצד MODERNIZATION_MIGRATING_WORKLOADS.
    • מפעילים מחדש באופן ידני את עומסי העבודה שנותרו, כדי ששרתי ה-proxy שלהם יתחברו להטמעה של מישור הבקרה של TRAFFIC_DIRECTOR. ‫Google ממתינה לפחות 60 יום עד שתפעילו מחדש את כל עומסי העבודה, לפני שהיא ממשיכה לאשכולות הבאים (בצי עם כמה אשכולות) או מתחילה את תקופת ההרצה של הצי.
    • כדי לבדוק אילו שרתי proxy עדיין מחוברים ל-ISTIOD, מריצים את הפקודה gcloud beta container fleet mesh debug proxy-status, כמו שמתואר בקטע הצגת הסטטוס של מישור הבקרה. שרתי proxy עם מזהה מכונה של Istiod בעמודה ISTIOD של פלט הפקודה עדיין מתחברים ל-ISTIOD וצריך להפעיל אותם מחדש באופן ידני.
    • אחרי שכל עומסי העבודה של הרשת באשכול מתחברים ל-TRAFFIC_DIRECTOR, הערך של MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART נמחק באופן אוטומטי וסטטוס האשכול משתנה ל-MODERNIZATION_COMPLETED.

  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 (ברמת ה-fleet) ו-membershipStates.<MEMBERSHIP_NAME>.servicemesh.conditions (ברמת האשכול):

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

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

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

  • MODERNIZATION_SCHEDULED
  • MODERNIZATION_PREPARING
  • MODERNIZATION_PREPARED
  • MODERNIZATION_MIGRATING_WORKLOADS
  • (אופציונלי) MODERNIZATION_MIGRATING_WORKLOADS עם MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART
  • MODERNIZATION_COMPLETED

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

  • MODERNIZATION_MODERNIZED
  • MODERNIZATION_FINALIZED

חזרה לגרסאות קודמות

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

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

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

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

טיפול בשגיאות ובעיכובים (רק אם הלקוח הפעיל את הטיפול)

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

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

שגיאות שהמשתמש יכול לפתור

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

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

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

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

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

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

תנאי תיאור
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_AWAITING_MANUAL_WORKLOAD_RESTART העברת עומס העבודה האוטומטית הושלמה. מפעילים מחדש עומסי עבודה של רשתות לא-Deployment, כמו StatefulSets,‏ DaemonSets או Jobs, כדי שהשרתים שלהם יתחברו להטמעה של מישור הבקרה של TRAFFIC_DIRECTOR.
MODERNIZATION_COMPLETED האשכול סיים את תהליך המודרניזציה ונמצא בתקופת ההרצה.
MODERNIZATION_STALLED המודרניזציה נעצרה בגלל שגיאה (רק אם הלקוח הפעיל אותה). כדי לפתור את הבעיה, צריך לעיין בפרטי התנאי.
MODERNIZATION_ROLLING_BACK_CLUSTER האשכול עובר כרגע תהליך של חזרה לגרסה קודמת.
MODERNIZATION_ABORTED האשכול חזר למישור הבקרה הקודם. דווחו לזמן קצר.