תכונות נתמכות באמצעות ממשקי Istio API (מישור בקרה מנוהל)

חשוב לדעת: השימוש ב-Managed Cloud Service Mesh באמצעות ההטמעה של ISTIOD control plane יצא משימוש. צריך לשדרג את כל צי המכשירים המנוהלים של ISTIOD להטמעה של מישור הבקרה של TRAFFIC_DIRECTOR.

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

רשימת התכונות שנתמכות ב-Cloud Service Mesh למישור בקרה באשכול מופיעה במאמר שימוש בממשקי API של Istio (מישור בקרה באשכול של istiod). אם אתם לא בטוחים באיזה מישור בקרה של Cloud Service Mesh אתם משתמשים, אתם יכולים לבדוק את ההטמעה של מישור הבקרה לפי ההוראות במאמר זיהוי ההטמעה של מישור הבקרה.

מגבלות

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

ההגבלות הבאות חלות:

• אשכולות GKE צריכים להיות באחד מהאזורים הנתמכים.
• גרסת GKE חייבת להיות גרסה נתמכת.
• יש תמיכה רק בפלטפורמות שמפורטות בקטע סביבות.
• אין תמיכה בפודים שפועלים עם hostNetwork: true.
• אסור לפרוס את Managed Cloud Service Mesh באשכול שיש בו גם פריסה באשכול של OSS Istio או מישור בקרה באשכול Cloud Service Mesh.
• אי אפשר לשנות ערוצי הפצה.
• לא ניתן לבצע מיגרציות מ-managed Cloud Service Mesh עם asmcli אל Cloud Service Mesh עם fleet API. באופן דומה, אי אפשר להקצות את הגרסה המנוהלת של Cloud Service Mesh באמצעות Fleet API מ---management manual ל---management automatic.
• העברות מ-Cloud Service Mesh בתוך אשכול נתמכות רק באמצעות האסטרטגיה של העברת אשכול Canary.
• העברות ושדרוגים נתמכים רק מגרסאות של Cloud Service Mesh בתוך האשכול שנמצאות בטבלה Supported versions (גרסאות נתמכות) ושימוש ב-Mesh CA או ב-Certificate Authority Service (שירות רשות האישורים). במקרים של התקנות עם Istio CA (שנקרא בעבר Citadel), צריך קודם להעביר את הנתונים אל Mesh CA.
• המגבלות על היקף השימוש מפורטות במדריך הזה
• אפשר להשתמש רק באפשרות הפריסה multi-primary עבור multi-cluster: אי אפשר להשתמש באפשרות הפריסה primary-remote עבור multi-cluster.
• אין תמיכה ב-istioctl ps. במקום זאת, אפשר להשתמש בפקודות gcloud beta container fleet mesh debug כמו שמתואר בקטע פתרון בעיות.

• ממשקי API לא נתמכים:

  • WasmPlugin API

  • IstioOperator API

  • Kubernetes Ingress API

  הערה: אתם עדיין יכולים להפעיל תכונות אופציונליות בלי להשתמש ב-IstioOperator API, כמו שמוסבר במאמר הפעלת תכונות אופציונליות ב-Cloud Service Mesh מנוהל.

• רשימה של שדות API שלא נתמכים מופיעה במאמר ממשקי Istio API שלא נתמכים ב-Managed Cloud Service Mesh.

• אתם יכולים להשתמש במישור הבקרה המנוהל בלי מינוי ל-GKE Enterprise, אבל רכיבים מסוימים בממשק המשתמש ותכונות מסוימות במסוף Google Cloud זמינים רק למנויי GKE Enterprise. במאמר ההבדלים בממשק המשתמש של GKE Enterprise ו-Cloud Service Mesh מוסבר מה זמין למנויים ומה לא.

• במהלך תהליך ההקצאה של מישור בקרה מנוהל, ה-CRD של Istio שתואמים לערוץ שנבחר מותקנים באשכול שצוין. אם יש באשכול הגדרות CRD קיימות של Istio, הן יוחלפו.

• ב-Managed Cloud Service Mesh יש תמיכה רק בדומיין ברירת המחדל של DNS,‏ .cluster.local.

• התקנות חדשות של Cloud Service Mesh מנוהל מאחזרות JWKS רק באמצעות Envoy, אלא אם הצי מכיל אשכולות אחרים שההתנהגות הזו לא מופעלת בהם. האפשרות הזו מקבילה לאפשרות PILOT_JWT_ENABLE_REMOTE_JWKS=envoy ב-Istio. יכול להיות שתצטרכו לבצע הגדרה נוספת להגדרות ServiceEntry ו-DestinationRule בהשוואה להגדרות שאין בהן תנאי VPCSC_GA_SUPPORTED (ראו בהמשך). לדוגמה, ראו requestauthn-with-se.yaml.tmpl. כדי לקבוע אם מצב הפעולה הנוכחי שווה ערך ל-PILOT_JWT_ENABLE_REMOTE_JWKS=envoy, צריך לבדוק אם VPC Service Controls נתמכים במישור הבקרה (כלומר, התנאי VPCSC_GA_SUPPORTED מוצג).

• מישור נתונים מנוהל נתמך רק בעומסי עבודה בלי שרתי proxy נוספים מסוג sidecar (מלבד ה-sidecar של Cloud Service Mesh).

הבדלים במישור הבקרה

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

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

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

מה קובע את ההטמעה של מישור הבקרה

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

בכל ה-fleet החדשים שמצטרפים ל-Cloud Service Mesh מנוהל, מישור הבקרה מיושם באמצעות TRAFFIC_DIRECTOR, למעט במקרים הבאים:

• אם אתם משתמשים קיימים ב-Cloud Service Mesh מנוהל, תקבלו את הטמעת מישור הבקרה של ISTIOD כשאתם מפעילים צי חדש באותו Google Cloud ארגון ב-Cloud Service Mesh מנוהל, לפחות עד 30 ביוני 2024. אם אתם נמנים עם המשתמשים האלה, אתם יכולים לפנות לתמיכה כדי לשנות את ההתנהגות הזו. משתמשים שהשימוש הקיים שלהם לא תואם להטמעה של TRAFFIC_DIRECTOR ללא שינויים, ימשיכו לקבל את ההטמעה של ISTIOD עד 8 בספטמבר 2024. (המשתמשים האלה קיבלו הודעה חשובה בנוגע לשירות).
• אם באשכול GKE on Google Cloud ב-fleet יש מישור בקרה של Cloud Service Mesh בתוך האשכול כשמקצים את Cloud Service Mesh המנוהל, מקבלים את ההטמעה של מישור הבקרה ISTIOD.
• אם אחד מהאשכולות ב-fleet משתמש ב-GKE Sandbox, כשמקצים את Cloud Service Mesh המנוהל מקבלים את ההטמעה של מישור הבקרה ISTIOD.

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

התקנה, שדרוג והחזרה לגרסה קודמת

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
התקנה באשכולות GKE באמצעות API של תכונת fleet
שדרוגים מגרסאות ASM 1.9 שמשתמשות ב-Mesh CA
שדרוגים ישירים (דילוג על רמות) מגרסאות של Cloud Service Mesh שקודמות ל-1.9 (ראו הערות לגבי שדרוגים עקיפים)
שדרוגים ישירים (דילוג על רמות) מ-Istio OSS (ראו הערות לגבי שדרוגים עקיפים)
שדרוגים ישירים (דילוג על רמות) מהתוסף Istio-on-GKE (ראו הערות לגבי שדרוגים עקיפים)
הפעלת תכונות אופציונליות

הערה: אפשר לבצע שדרוגים והעברות באופן עקיף. כלומר, אתם יכולים לפעול לפי נתיבי השדרוג הרגילים של Cloud Service Mesh בכל גרסה עד שתגיעו לגרסה 1.29 של Cloud Service Mesh עם מישור בקרה בתוך האשכול, ואז להעביר למישור הבקרה המנוהל. העברות ושדרוגים ישירים נתמכים רק מגרסאות Cloud Service Mesh 1.9 ואילך שהותקנו באמצעות Mesh CA. אם אתם משתמשים ב-Istio CA, קודם תצטרכו לעבור ל-Mesh CA.

סביבות

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
גרסאות GKE שזמינות כרגע בערוצי הפצה, באחד האזורים הנתמכים
גרסאות GKE שזמינות כרגע בערוצי הפצה, באחד האזורים הנתמכים, אשכולות GKE Autopilot
סביבות מחוץ ל- Google Cloud (GKE Enterprise מקומי, GKE Enterprise בעננים ציבוריים אחרים, Amazon EKS,‏ Microsoft AKS או אשכולות Kubernetes אחרים)

להתכונן להתרחבות

דף מגבלות המדרגיות

סביבת הפלטפורמה

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
רשת אחת
רשתות מרובות
פרויקט יחיד
שימוש ב-VPC משותף בכמה פרויקטים

פריסה בכמה אשכולות

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
מספר צבעים ראשיים
Primary-remote
חיפוש נקודות קצה בכמה אשכולות באמצעות API הצהרתי
גילוי נקודות קצה בכמה אשכולות באמצעות סודות מרוחקים
גילוי נקודות קצה (endpoint) בכמה אשכולות באמצעות API הצהרתי וטופולוגיה פשוטה

הערות לגבי המונחים

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

תמונות בסיס

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
Distroless proxy image	*

‫† Istio מפרסם תמונות של שרתי proxy‏ default, debug ו-distroless. ב-Cloud Service Mesh עם מישור בקרה מנוהל (TRAFFIC_DIRECTOR): אשכולות שהועברו ישירות משתמשים ב-distroless כברירת מחדל, ואי אפשר לשנות את זה. אשכולות שהועברו משתמשים כברירת מחדל בתמונות default, ויכולים להצטרף ל-distroless באמצעות MeshConfig או הערת pod. אין תמיכה בשינוי של סוגי תמונות אחרים (debug).

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

אבטחה

VPC Service Controls

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
VPC Service Controls

מנגנונים להפצה ולסבב של אישורים

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
ניהול אישורים של עומסי עבודה
ניהול אישורים חיצוניים בשערי כניסה ויציאה.

תמיכה ברשות אישורים (CA)

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
רשות אישורים של Cloud Service Mesh
Certificate Authority Service
Istio CA
שילוב עם רשויות אישורים (CA) בהתאמה אישית

אמצעי אבטחה

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

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
שילוב IAP
אימות של משתמשי קצה
מצב פרימטר לבדיקות
רישום ביומן של דחיות
מדיניות ביקורת (לא נתמכת)

מדיניות ההרשאות

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
מדיניות Authorization v1beta1
מדיניות הרשאה בהתאמה אישית

אימות עמיתים

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
mTLS אוטומטי
מצב mTLS PERMISSIVE
מצב mTLS STRICT	*	*
מצב mTLS DISABLE

הערה: למרות שה-API של PeerAuthentication לא תומך במצב DISABLE להטמעה של מישור הבקרה של TRAFFIC_DIRECTOR, אפשר להשבית את mTLS לעומסי עבודה ספציפיים באמצעות ה-API של DestinationRule כפתרון עקיף. מידע נוסף זמין במאמר השבתת mTLS ב-Managed CSM.

בקשת אימות

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
אימות JWT^(הערה 1)
ניתוב על סמך טענת נכוֹנוּת (claim) של JWT
JWT Copy Claim to Headers

הערות:

1. כברירת מחדל, JWT של צד שלישי מופעל.
2. מוסיפים את ה-FQDN או את שם המארח המלאים ב-JWKSURI כשמגדירים את RequestAuthentication API.
3. מישור הבקרה המנוהל אוכף על Envoy לאחזר JWKS כשמציינים JWKS URI.
4. אסור להשתמש באלגוריתמים של AES CBC‏ (A128CBC-HS256,‏ A192CBC-HS384 ו-A256CBC-HS512) ב-JWKS מוטבע כשמשתמשים בהטמעה של מישור הבקרה של TRAFFIC_DIRECTOR.

Telemetry

מדדים

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
Cloud Monitoring (מדדי HTTP בשרת Proxy)
Cloud Monitoring (מדדים של TCP בשרת proxy)
ייצוא מדדים של Prometheus אל Grafana (מדדים של Envoy בלבד)	*	*
ייצוא מדדי Prometheus ל-Kiali
השירות המנוהל של Google Cloud ל-Prometheus, לא כולל לוח הבקרה של Cloud Service Mesh	*	*
Istio Telemetry API	†
מתאמים או קצה עורפי בהתאמה אישית, בתוך התהליך או מחוצה לו
קצוות עורפיים שרירותיים של טלמטריה ורישום ביומן

‫† מישור הבקרה של TRAFFIC_DIRECTOR תומך בקבוצת משנה של Istio telemetry API שמשמשת להגדרת יומני גישה ומעקב.

הערה: אתם יכולים להגדיר מוצרי טלמטריה של צד שלישי (כמו Grafana ו-Prometheus), אבל אנחנו לא יכולים להבטיח תאימות עתידית, וצוות התמיכה של Cloud לא יכול לעזור לכם לנהל אותם.

רישום בקשות משרת proxy ביומן

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
יומני תעבורת נתונים
יומני גישה	*	*

מעקב

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
Cloud Trace	*	*
מעקב באמצעות Jaeger (מאפשר שימוש ב-Jaeger בניהול הלקוח)		תואם
מעקב באמצעות Zipkin (מאפשר שימוש ב-Zipkin בניהול הלקוח)		תואם

הערה: אתם יכולים להגדיר מוצרי טלמטריה של צד שלישי (כמו Jaeger, ‏ Zipkin ו-Grafana), אבל אנחנו לא יכולים להבטיח תאימות עתידית, וצוות התמיכה של Cloud לא יכול לעזור לכם לנהל אותם.

Networking

מנגנונים ליירוט תנועה ולהפניה אוטומטית שלה

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
שימוש ב-iptables באמצעות מאגרי init עם CAP_NET_ADMIN		†
‫Istio Container Network Interface ‏ (CNI)
Whitebox sidecar

‫† מומלץ מאוד להשתמש בממשק רשת של קונטיינרים (CNI) במקום בinit קונטיינרים.

תמיכה בפרוטוקולים

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
IPv4
HTTP/1.1
HTTP/2
זרמי בייטים של TCP (הערה 1)
gRPC
IPv6	†

הערות:

1. למרות ש-TCP הוא פרוטוקול נתמך לרישות ונאספים מדדי TCP, הם לא מדווחים. המדדים מוצגים רק לשירותי HTTP במסוף Google Cloud .
2. אין תמיכה בשירותים שמוגדרים עם יכולות של שכבה 7 לפרוטוקולים הבאים: WebSocket, ‏ MongoDB, ‏ Redis, ‏ MySQL, ‏ Kafka,‏ Cassandra, ‏ RabbitMQ, ‏ Cloud SQL. יכול להיות שתוכלו להשתמש בפרוטוקול באמצעות תמיכה בזרם בייטים של TCP. אם זרם הבייטים של TCP לא תומך בפרוטוקול (לדוגמה, Kafka שולח כתובת להפניה אוטומטית בתשובה ספציפית לפרוטוקול, וההפניה האוטומטית הזו לא תואמת ללוגיקת הניתוב של Cloud Service Mesh), הפרוטוקול לא נתמך. אפשר ליצור יציאות של שערים עם פרוטוקול Mongo, ‏ MySQL ו-Redis, אבל הרשת מתייחסת לתנועה שנוצרת כ-TCP רגיל, בלי טיפול ספציפי לפרוטוקול.
3. ‫† ב-gRPC בלי שרת Proxy, התכונות של IPv6 במצב דואלי נתמכות רק ב-gRPC בגרסה 1.66.1 ואילך ב-C++‎ וב-Python, ב-gRPC Go בגרסה 1.71 וב-gRPC Node.js בגרסה 1.12. אם תנסו להגדיר תכונות של מחסנית כפולה עם גרסה של gRPC שלא תומכת במחסנית כפולה, הלקוחות ישתמשו רק בכתובת הראשונה שנשלחה על ידי Traffic Director.

פריסות של Envoy

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
קבצים נלווים
שער כניסה (Ingress)
תעבורה יוצאת ישירות מ-sidecars
תעבורת נתונים יוצאת (egress) באמצעות שערים לתעבורת נתונים יוצאת	*	*

תמיכה ב-CRD

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
משאב Sidecar
משאב של רשומת שירות
כללי ניתוב של אחוזים, הזרקת תקלות, התאמת נתיבים, הפניות אוטומטיות, ניסיונות חוזרים, כתיבה מחדש, זמן קצוב לתפוגה, ניסיון חוזר, שיקוף, מניפולציה של כותרות ו-CORS
‫`WasmPlugin` API
Istio Operator

מאזן עומסים לשער הכניסה של Istio

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
מאזן עומסים חיצוני של צד שלישי
Google Cloud מאזן עומסים פנימי	*	*

שער ענן של Service mesh

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
שער ענן של Service mesh

Kubernetes Gateway API

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
Kubernetes Gateway API

כללי מדיניות של איזון עומסים

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
סדר סיבובי
הכי פחות חיבורים
אקראי
העברת סיגנל ללא שינוי
גיבוב עקבי (consistent hashing)
רשות מוניציפאלית
GCPTrafficDistributionPolicy
GCPBackendPolicy

מצבי איזון עומסים

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
RATE
ניצול
CUSTOM_METRICS
בטיסה

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

רשומת שירות

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
ServiceEntry v1beta1	†

‫† הטמעה של מישור הבקרה TRAFFIC_DIRECTOR לא תומכת בשדות הבאים ובערכים בשדות:

• השדה workloadSelector
• השדה endpoints[].network
• השדה endpoints[].locality
• endpoints[].weight שדה
• השדה endpoints[].serviceAccount
• הערך DNS_ROUND_ROBIN בשדה resolution
• הערך MESH_INTERNAL בשדה location
• כתובת של שקע דומיין ב-Unix בשדה endpoints[].address
• השדה subjectAltNames
• שני ערכי endpoints[] או יותר אם בשדה resolution יש את הערך DNS

כלל יעד

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
DestinationRule v1beta1	*

‫† הטמעה של מישור הבקרה TRAFFIC_DIRECTOR לא תומכת בשדות הבאים.

• השדה trafficPolicy.loadBalancer.localityLbSetting
• trafficPolicy.tunnel שדה
• השדה trafficPolicy.tls.credentialName
• השדה trafficPolicy.portLevelSettings[].tls.credentialName

בנוסף, בהטמעה של מישור הבקרה של TRAFFIC_DIRECTOR, כלל היעד שמגדיר קבוצות משנה צריך להיות באותו מרחב שמות ובאותו אשכול כמו שירות Kubernetes או ServiceEntry.

Sidecar

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
Sidecar v1beta1	†

‫† הטמעה של מישור הבקרה TRAFFIC_DIRECTOR לא תומכת בשדות הבאים ובערכים בשדות:

• ingress שדה
• השדה egress.port
• השדה egress.bind
• egress.captureMode שדה
• השדה inboundConnectionPool

DNS proxy

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
תרגום שם (Name resolution) של Service באשכולות	*
תרגום שם של ServiceEntry באשכול	†
תרגום שם (Name resolution) של Service ללא GUI
הקצאה אוטומטית של כתובות	*

‫† נדרשת גרסה 1.21.5-asm.39 או גרסה עדכנית יותר של ה-sidecar.

EnvoyFilter

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
EnvoyFilter v1alpha3	†

‫† מידע על שדות נתמכים ותוספים שאפשר להגדיר זמין בדף בנושא הרחבת מישור הנתונים

MeshConfig

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
DiscoverySelectors
clusterLocal
LocalityLB	§
ExtensionProviders
CACert
ImageType – distroless	*
OutboundTrafficPolicy
defaultProviders.accessLogging
defaultProviders.tracing
defaultConfig.tracing.stackdriver
accessLogFile

‫† למידע נוסף על התנהגות ההגדרות, ראו תמונת פרוקסי ללא הפצה.

ProxyConfig

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
תמיכה ב-HTTP/1.0‏ (ISTIO_META_NETWORK)
בחירת תמונה (תמונה ללא הפצה או תמונת בסיס)
Kubernetes native sidecar (ENABLE_NATIVE_SIDECARS)

אזורים

אשכולות GKE צריכים להיות באחד מהאזורים הבאים או בכל אזור בתוך האזורים הבאים.

אזור	מיקום
africa-south1	יוהנסבורג
asia-east1	טייוואן
asia-east2	הונג קונג
asia-northeast1	טוקיו, יפן
asia-northeast2	אוסקה, יפן
asia-northeast3	דרום קוריאה
asia-south1	מומבאי, הודו
asia-south2	דלהי, הודו
asia-southeast1	סינגפור
asia-southeast2	ג'קארטה
australia-southeast1	סידני, אוסטרליה
australia-southeast2	מלבורן, אוסטרליה
europe-central2	פולין
europe-north1	פינלנד
europe-north2	שטוקהולם
europe-southwest1	ספרד
europe-west1	בלגיה
europe-west2	אנגליה
europe-west3	פרנקפורט, גרמניה
europe-west4	הולנד
europe-west6	שווייץ
europe-west8	מילאנו, איטליה
europe-west9	צרפת
europe-west10	ברלין, גרמניה
europe-west12	טורינו, איטליה
me-central1	דוחה
me-central2	דמאם, ערב הסעודית
me-west1	תל אביב
northamerica-northeast1	מונטריאול, קנדה
northamerica-northeast2	טורונטו, קנדה
northamerica-south1	מקסיקו
southamerica-east1	ברזיל
southamerica-west1	צ'ילה
us-central1	איווה
us-east1	דרום קרוליינה
us-east4	צפון וירג'יניה
us-east5	אוהיו
us-south1	דאלאס
us-west1	אורגון
us-west2	לוס-אנג׳לס
us-west3	סולט לייק סיטי
us-west4	לאס וגאס

ממשק משתמש

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
לוחות בקרה של Cloud Service Mesh במסוף Google Cloud
Cloud Monitoring
Cloud Logging

כלים

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
כלי אחד (gcloud beta container fleet mesh debug )