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

המסמך הזה מיועד ללקוחות קיימים של 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.

העברה של מישור הבקרה לרשתות קיימות ולציים קיימים

החל מ-22 ביולי 2024,‏ Google תעדכן בהדרגה את האשכולות הקיימים כדי להשתמש במישור הבקרה המנוהל עם הטמעה של TD. נודיע לכם לפני שנעדכן את הרשתות.

אפשר לעיין ביכולות של מישורי הבקרה Istiod ו-Traffic Director בדף שבו מתוארות התכונות הנתמכות באמצעות ממשקי Istio API (מישור בקרה מנוהל).

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

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

gcloud container hub mesh describe --project=[PROJECT_ID]

התוצאות אמורות להיראות כך:

membershipStates:
  projects/656460026795/locations/us-central1/memberships/cluster:
    servicemesh:
      conditions:
      - code: MODERNIZATION_SCHEDULED
        details: This cluster has been scheduled for modernization on or after (date ~ at least 2 weeks).
        documentationLink: 
        severity: INFO

כל אשכולות מישור הבקרה המנוהל מדור קודם שצורפו באמצעות meshconfig.googleapis.com API יירשמו אוטומטית לצי בפרויקט של האשכול באמצעות gkehub.googleapis.com Membership API. אם יש לכם אוטומציה שמבטלת את הרישום של אשכול, אתם צריכים להסיר אותה לפני ההעברה, אחרת יהיו בעיות בהעברה. כדי שהמוצר המנוהל יפעל בצורה תקינה, הוא צריך להיות רשום לצי עם התכונה 'רשת' מופעלת.

אם אתם צריכים להתאים אישית את המיגרציה או אם יש לכם שאלות לגבי שימוש בתכונות שלא נתמכות, אתם יכולים לפנות לתמיכה.

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

• כדי להפעיל בדיקות תקינות, מערכת snk daemonset נוצרת במרחב השמות kube-system של האשכול, ונוצר כלל חומת אש לכל אשכול.
• כדי להפעיל הטמעה של קבוצה של נקודות קצה ברשת (NEG), מוסיפים את ההערה cloud.google.com/neg לכל השירותים של Kubernetes.
• נוצרים באשכול Google Cloud משאבים חדשים, כמו Mesh, ‏ Routes, שירותי קצה עורפי ובדיקות תקינות.
• הפעלות של Pods שמנוהלות על ידי פריסות של Kubernetes מופעלות מחדש כדי להתחבר למישור הבקרה של Traffic Director.

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

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

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

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

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

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

אם מוסיפים צי חדש ל-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 .