מישור בקרה מנוהל ללקוחות קיימים

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

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

סקירה כללית של מישור הבקרה

ב-service mesh, מישור הבקרה מספק ניהול תנועה, ניהול פרוקסי כשמשתמשים בפרוקסי Envoy ויכולות אחרות של רשת.

ב-Anthos Service Mesh היו שתי רמות בקרה: רמת בקרה מנוהלת ורמת בקרה בתוך האשכול. רק פרוקסי Envoy משמשים כמישור הנתונים.

מישור בקרה מנוהל חדש

מישור הבקרה המנוהל החדש נקרא Traffic Director (TD). מה המשמעות של מישור הבקרה החדש מבחינתכם?

אחד השינויים המשמעותיים ביותר בין המוצר Anthos Service Mesh לבין Cloud Service Mesh הוא המעבר למישור בקרה גלובלי עם ריבוי דיירים.

מישור הבקרה המנוהל שמשמש ב-Anthos Service Mesh מוקדש לאשכול יחיד. למרות שממשקי ה-API (Istio CRDs) שמשמשים ל-GKE זהים, וההגדרה של xDS שנשלחת ל-sidecars תואמת ללא הבדלים בהתנהגות, ההבדלים במישור הבקרה מובילים לכמה מאפיינים שגלויים לכם, משתמשי הקצה.

• זמן התגובה לשינוי בהגדרה. פריסות של שירותים חדשים או שינויים במדיניות השירותים נמשכים קצת יותר זמן עם מישור הבקרה החדש.
  • צינור ההגדרות מבצע אישור הגדרות בשני שלבים כדי להבטיח אמינות. במעבר הראשון מתבצעים אימותים כדי לבדוק אם ההגדרה תקינה. בשלב הבא, ההגדרה מופצת באופן גלובלי לפריסות של השירות. כדי לאפשר שימוש בשירותים של Google Cloud , כמו איזון עומסים גלובלי בין אזורים או בין אזורים שונים, בדיקות תקינות מרכזיות, התאמה אוטומטית לעומס לפי תנועה והגבלת קצב של יצירת בקשות מנוהלת, התצורה מועברת למערכות האלה ומאומתת באופן עצמאי כדי לוודא שהיא נכונה. ההגדרה מאוחסנת גם באופן פנימי שמאפשר לצוות Site Reliability Engineering (SRE) של Google לבצע פעולות במוצר בצורה מהימנה ויעילה במהלך מקרי חירום בייצור.
  • הפעולות האלה מספקות אמינות טובה יותר, אבל הן גורמות לדחיפת הגדרות (config push) איטית יותר מהחביון שנצפה אצל משתמשים נוכחיים ב-Anthos Service Mesh.
  • החביון של כל Pod חדש לאחזור הגדרה קיימת נמדד כטוב יותר מעט עם רמת הבקרה החדשה. ההפצה האיטית של ההגדרות מתבצעת בפעם הראשונה שמופץ שירות חדש שנוצר או מדיניות חדשה שמופצת לשירות. השהיות בהפצה של נקודות קצה דומות מבחינה פונקציונלית.
• מהירות ההרחבה של אירועים ושינויים אחרים בנקודות הקצה. הטיפול בהם מהיר לפחות כמו במישור הבקרה החדש. האירועים האלה כוללים הפעלה או הפסקה של Podים חדשים בגלל התאמה אופקית של קבוצות Pod לעומס, והפעלה מחדש של Podים עם כתובות IP חדשות כי הם הועברו לצומת אחר באשכול.
• שינוי מספר נקודות הקצה. במישור הבקרה הגלובלי החדש, נקודות הקצה של הרשת נשלחות ישירות מכל אשכול למישור הבקרה מכל האשכולות ברשת. זו גישה פשוטה, מהירה וניתנת להרחבה יותר מאשר הגישה שבה נעשה שימוש במישור הבקרה המנוהל הקודם. במודל הישן יותר של מישור בקרה מנוהל (מישור בקרה ייעודי), כל Istiod צריך לתקשר עם כל אשכול אחר ברשת כדי לקבוע את נקודות הקצה שזמינות בכל אשכול אחר. במישור הבקרה הגלובלי, נקודות הקצה מועברות ישירות למישור הבקרה הגלובלי. כך משפרים את האמינות והביצועים ברשתות עם מספר גדול של נקודות קצה, ומאפשרים לרשתות להתרחב למספר גדול יותר של נקודות קצה.

איך מישור הבקרה החדש משפיע עליכם?

ההשפעה של רמת הבקרה החדשה עליכם תלויה בממשקי ה-API וברמת הבקרה שבהם אתם משתמשים.

• אם אתם משתמשים ב-Traffic Director, מישור הבקרה שלכם לא משתנה. אין צורך לקרוא את שאר המדריך. המסמכים בנושא הטמעה של Cloud Service Mesh זמינים במאמר הגדרה באמצעותGoogle Cloud API.
• אם אתם משתמשים ב-Anthos Service Mesh, השלבים הבאים למישור הבקרה בפריסה הקיימת תלויים במישור הבקרה המנוהל או במישור הבקרה בתוך האשכול.
  • אם אתם משתמשים במישור בקרה מנוהל, המערכים הקיימים שלכם יועברו למישור הבקרה החדש, שנקרא ב-Cloud Service Mesh מישור בקרה מנוהל (הטמעה של Traffic Director או TD), עם כמה חריגים. קוראים את הקטע הבא, מודרניזציה של מישור הבקרה עבור רשתות וציים קיימים. אם אתם משתמשים בתכונה שלא נתמכת בהטמעה של מישור הבקרה של Traffic Director, תמשיכו להשתמש באופן זמני במישור הבקרה הקודם. כדאי להמשיך לקרוא את המדריך הזה.
  • אם משתמשים במישור הבקרה בתוך האשכול, מישור הבקרה נשאר ללא שינוי. אין צורך לקרוא את שאר המדריך.
  • אם אין לכם Google Cloud ארגון, ואתם משתמשים במישור הבקרה המנוהל בפרויקט ללא ארגון, תקבלו את מישור הבקרה של TD.
• אם אתם לקוחות של Anthos Service Mesh ואתם יוצרים צי חדש, תקבלו את ההטמעה של מישור הבקרה של Traffic Director. כדאי להמשיך לקרוא את המדריך הזה.
  • תקבלו הודעה לגבי התאריך שבו מטוסים חדשים יקבלו את מישור הבקרה של TD.

עדכון מישור הבקרה עבור רשתות וקבוצות קיימות

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

בדיקת התאימות של מישור הבקרה

כדאי לעיין בהבדלים בתכונות הנתמכות בין יישומי מישור בקרה מנוהל כדי לקבוע אם השימוש הנוכחי שלכם ב-Cloud Service Mesh ידרוש שינויים.

מישור הבקרה לרשתות חדשות

החל מ-1 ביולי 2024, רוב המשתמשים הקיימים בהטמעה של מישור הבקרה המנוהל של istiod התחילו לקבל את מישור הבקרה המנוהל המעודכן עם ההטמעה הזמינה של Google ברחבי העולם – מישור הבקרה Traffic Director‏ (TD), בציים חדשים.

משתמשים שהשימוש הקיים שלהם ב-Cloud Service Mesh מנוהל עם הטמעה של istiodמישור הבקרה לא היה תואם להטמעה של Traffic Director בלי שינויים, המשיכו לקבל את ההטמעה של istiodעד 8 בספטמבר 2024.

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

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

המאמרים הבאים

• אם אתם ממשיכים להשתמש ב-Anthos Service Mesh, תוכלו למצוא את המסמכים בתוכן העניינים שבצד ימין, בקטע Configure service mesh with Istio APIs.
• אם אתם ממשיכים להשתמש ב-Traffic Director, תוכלו למצוא את המסמכים הרלוונטיים בקטע הגדרת Service mesh באמצעות ממשקי API של Google Cloud .