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

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

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

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

‫Cloud Service Mesh באמצעות ממשקי Istio API באשכולות GKE מספק הטמעה נתמכת באופן מלא של ממשקי Istio API. ממשקי ה-API מיושמים ונתמכים על ידי מישור הבקרה TRAFFIC_DIRECTOR המנוהל באופן מלא ומשולב עם Cloud Networking. בעבר, היו שתי הטמעות נוספות של מישור הבקרה שנתמכו:

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

מאפיינים תפעוליים של מישור הבקרה TRAFFIC_DIRECTOR

‫Cloud Service Mesh עם מישור הבקרה TRAFFIC_DIRECTOR משתמש בתשתית רשת מנוהלת של Google Cloudבמקום במופעים של מישור בקרה לכל אשכול.

ממשקי ה-API של Istio‏ (CRD) וההגדרה של xDS שנשלחת ל-Envoy sidecars נשארים תואמים, אבל כדאי לצפות למאפייני הפעלה הבאים:

  • הפצה של מדיניות והגדרות שירות: כשיוצרים שירותים חדשים או מעדכנים מדיניות ניתוב ואבטחה, המערכת מאמתת את ההגדרות ומפיצה אותן בין מערכות Google Cloud לפני שהן נכנסות לתוקף ב-sidecar. כתוצאה מכך, ההפצה הראשונית של המדיניות והשירותים אורכת זמן רב יותר מאשר במטוסים של ISTIOD או במטוסים בתוך האשכול. למידע נוסף על אופטימיזציה של תהליכי עבודה של פריסה, אפשר לקרוא את המאמר הפצת הגדרות.
  • שינוי קנה מידה של Pod ועדכוני נקודות קצה: שינויים בנקודות קצה של עומסי עבודה – כמו Pods חדשים שנוצרו על ידי התאמה אופקית של קבוצות Pod לעומס, או הפעלה מחדש של Pods עם כתובות IP חדשות – מועברים ישירות על ידי מישור הבקרה, בלי ההשהיה שקשורה לעדכוני מדיניות. רצפי מודעות קיימים שמאחזרים הגדרות קיימות מתחילים ללא דיחוי.
  • גילוי נקודות קצה בכמה אשכולות: ברשתות של כמה אשכולות, האשכולות משתפים את נקודות הקצה שלהם ישירות דרך Google Cloud במקום לסנכרן אותן מנקודה לנקודה בין כל שילוב של אשכולות. כך אפשר לוודא שהמצב של נקודות הקצה בכל האשכולות מתכנס מהר יותר ובאופן עקבי ככל שהרשת גדלה.

איך זה משפיע עליך?

השלבים הבאים תלויים בהטמעה של מישור הבקרה של Cloud Service Mesh שבה נעשה שימוש באשכולות:

מודרניזציה של מישור הבקרה בשביל Cloud Service Mesh מנוהל עם הטמעה של ISTIOD

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

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

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

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

נספח: ציר זמן להשקה ולהוצאה משימוש של מישור הבקרה

המעבר ממישורי בקרה של ISTIOD להטמעה של מישור בקרה מנוהל של TRAFFIC_DIRECTOR התבצע לפי ציר הזמן הבא:

  • ‫23 במאי 2024: Anthos Service Mesh ו-Traffic Director מוזגו ל-Cloud Service Mesh, והוצגה הטמעה של מישור הבקרה TRAFFIC_DIRECTOR עבור ממשקי Istio API.
  • ‫1 ביולי 2024: צי חדש של מכונות שנוספו ל-Cloud Service Mesh מנוהל התחיל לקבל את ההטמעה של TRAFFIC_DIRECTOR כברירת מחדל.
  • 8 בספטמבר 2024: הפסקנו את הקצאת המשאבים להטמעה של ISTIOD עבור צי רכבים חדש לזמינות לכלל המשתמשים (עם חריגים זמניים לארגונים ספציפיים ברשימת ההיתרים).
  • 28 בספטמבר 2026: הודעה רשמית על הוצאה משימוש של מימוש מישור הבקרה המנוהל ISTIOD ושל מישור הבקרה בתוך האשכול ב-GKE.