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

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

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

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

רשימת התכונות שנתמכות ב-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 באשכול.
• אי אפשר לשנות את ערוצי ההפצה.
• אי אפשר להעביר מ-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 באשכול שמופיעות בטבלה גרסאות נתמכות, ורק באמצעות Mesh CA או Certificate Authority Service. בהתקנות עם Istio CA (לשעבר Citadel), קודם צריך לעבור ל-Mesh CA.
• מגבלות ההיקף מפורטות במדריך הזה
• יש תמיכה רק באפשרות פריסה של כמה אשכולות עם כמה אשכולות ראשיים, ולא באפשרות פריסה של כמה אשכולות עם אשכול ראשי אחד ואשכולות מרוחקים.
• אין תמיכה ב-istioctl ps. במקום זאת, אתם יכולים להשתמש בפקודות gcloud beta container fleet mesh debug כמו שמתואר בקטע פתרון בעיות.

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

  • WasmPlugin API

  • IstioOperator API

  • Kubernetes Ingress API

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

• במאמר תמיכה ב-Cloud Service Mesh API מפורטות המגבלות והתמיכה ברמת השדה בכל ממשקי ה-API של Istio.

• אתם יכולים להשתמש במישור הבקרה המנוהל בלי מינוי ל-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 רק באמצעות Envoys, אלא אם ה-fleet מכיל אשכולות אחרים שההתנהגות הזו לא מופעלת בהם. האפשרות הזו מקבילה לאפשרות PILOT_JWT_ENABLE_REMOTE_JWKS=envoy ב-Istio. בהשוואה להתקנות שאין בהן את התנאי VPCSC_GA_SUPPORTED (ראו בהמשך), יכול להיות שתצטרכו הגדרות נוספות ל-ServiceEntry ול-DestinationRule. לדוגמה, ראו 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 של התכונות בפלטפורמות השונות.
• ‫* – מציין שהתכונה נתמכת בפלטפורמה ואפשר להפעיל אותה, כמו שמתואר בקטע הפעלת תכונות אופציונליות או במדריך לתכונה שמקושר בטבלת התכונות.
• – מציין שהתכונה לא זמינה או לא נתמכת.

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

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

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

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

סביבות

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

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

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

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

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

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

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

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

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

תמונות בסיס

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
תמונת פרוקסי ללא הפצה	*

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

שימו לב שלתמונות ללא הפצה יש קבצים בינאריים מינימליים, כך שאי אפשר להריץ את הפקודות הרגילות כמו bash או curl כי הן לא קיימות בתמונה ללא הפצה. עם זאת, אתם יכולים להשתמש בקונטיינרים זמניים כדי לצרף Pod של עומס עבודה פעיל, לבדוק אותו ולהריץ פקודות בהתאמה אישית. לדוגמה, ראו איסוף יומנים של 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)‎
Auto-mTLS
מצב mTLS PERMISSIVE
מצב mTLS STRICT	*	*
מצב mTLS DISABLE	†

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

בקשת אימות

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

הערות:

1. כברירת מחדל, JWT של צד שלישי מופעל.
2. מוסיפים את ה-fqdn/שם המארח המלא ב-JWKSURI בזמן שמגדירים את RequestAuthentication API.
3. מישור הבקרה המנוהל אוכף על Envoy לאחזר JWKS כשמציינים URI של JWKS.
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		*
ממשק רשת קונטיינרים (CNI) של Istio
Whitebox sidecar
הגדרת מצב יירוט

‫† מומלץ מאוד להשתמש ב-Container Network Interface‏ (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 byte stream. אם זרם הבייטים של 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
תעבורת נתונים יוצאת באמצעות שערי תעבורת נתונים יוצאת	*	*

תמיכה ב-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)‎
דירוג
ניצול
CUSTOM_METRICS
בטיסה

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

רשומת שירות

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

‫† ההטמעה של מישור הבקרה של TRAFFIC_DIRECTOR תומכת בקבוצת משנה של שדות ServiceEntry. במאמר הזה מפורטת הרשימה המלאה של השדות הנתמכים, השדות שלא נתמכים ומגבלות ההגדרה.

כלל יעד

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

‫† ההטמעה של מישור הבקרה של TRAFFIC_DIRECTOR דורשת שכלל היעד שמגדיר קבוצות משנה יהיה באותו מרחב שמות ואשכול כמו שירות Kubernetes או ServiceEntry. לרשימה המלאה של השדות הנתמכים, השדות שלא נתמכים ומגבלות ההגדרה, ראו תמיכה ב-API: ‏DestinationRule.

Sidecar

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

‫† ההטמעה של מישור הבקרה של TRAFFIC_DIRECTOR תומכת בקבוצת משנה של שדות Sidecar. הרשימה המלאה של השדות הנתמכים, השדות שלא נתמכים ומגבלות ההגדרה מופיעה במאמר תמיכה ב-API: ‏Sidecar.

שרת proxy ל-DNS

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

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

EnvoyFilter

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

‫† בדף Dataplane Extensibility מפורטים השדות הנתמכים והתוספים שאפשר להגדיר

MeshConfig

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

‫† למידע נוסף על התנהגות ההגדרות, ראו תמונת פרוקסי ללא הפצה.
‫† בהגדרת איזון עומסים לפי מיקום מפורטים ההתנהגות והמגבלות של ההגדרות.
‫† במאמר התאמה אישית של הפורמט והקידוד של יומן הגישה של Envoy מפורטים ההתנהגות והמגבלות של ההגדרות האישיות.

ProxyConfig

תכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)‎
תמיכה ב-HTTP/1.0‏ (ISTIO_META_NETWORK)
בחירת תמונה (תמונה ללא הפצה או תמונת בסיס)
קונטיינר sidecar מקורי של Kubernetes ‏(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 )