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

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

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

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

מגבלות

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

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

• אשכולות GKE צריכים להיות באחד מהאזורים הנתמכים.
• גרסת GKE חייבת להיות גרסה נתמכת.
• יש תמיכה רק בפלטפורמות שמפורטות בקטע סביבות.
• אין תמיכה ב-Pods שפועלים עם hostNetwork: true.
• אסור לפרוס את 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).

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

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

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

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

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

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

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

ציים חדשים שמצטרפים ל-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 בצי שלכם מישור בקרה של Cloud Service Mesh בתוך האשכול כשאתם מקצים Cloud Service Mesh מנוהל, תקבלו את הטמעת מישור הבקרה של ISTIOD.
• אם באחד מהאשכולות בארגון נעשה שימוש ב-GKE Sandbox, תקבלו את ההטמעה של מישור הבקרה ISTIOD כשאתם מקצים Cloud Service Mesh מנוהל.

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

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

התכונה	מנוהל (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.28 עם מישור בקרה בתוך האשכול, ואז אפשר להעביר למישור הבקרה המנוהל. העברות ושדרוגים ישירים נתמכים רק מגרסאות 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)
רשת אחת
Multi-network
פרויקט יחיד
שימוש ב-VPC משותף בכמה פרויקטים

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

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

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

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

תמונות בסיס

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

‫† Cloud Service Mesh עם מישור בקרה מנוהל (TD) תומך רק בסוג התמונה distroless. אי אפשר לשנות אותו.

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

אבטחה

VPC Service Controls

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

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

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

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

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

אמצעי אבטחה

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

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

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

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

אימות בחיבור ישיר

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

בקשת אימות

התכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
אימות JWT^(הערה 1)
ניתוב על סמך טענות JWT
העתקת הצהרת JWT לכותרות

הערות:

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 dual-stack נתמכות רק ב-gRPC בגרסה 1.66.1 ואילך ב-C++‎ וב-Python, ב-gRPC Go v1.71 או ב-gRPC Node.js v1.12. אם מנסים להגדיר תכונות של dual-stack עם גרסה של gRPC שלא תומכת ב-dual-stack, הלקוחות ישתמשו רק בכתובת הראשונה שנשלחה על ידי Traffic Director.

פריסות של Envoy

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

תמיכה ב-CRD

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

מאזן עומסים ל-Istio ingress gateway

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

שער ענן של Service mesh

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

Kubernetes Gateway API

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

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

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

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

התכונה	מנוהל (TD)	הוצאה משימוש של Managed (istiod)
דירוג
שימוש
CUSTOM_METRICS
במהלך ההעברה (תצוגה מקדימה)

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

Service entry

התכונה	מנוהל (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 control plane מחייבת שכלל היעד שמגדיר קבוצות משנה יהיה באותו מרחב שמות ובאותו אשכול עם שירות 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 באשכולות	†
תרגום שם (Name resolution) של ServiceEntry באשכול	†
תרגום שם (Name resolution) של Headless Service
הקצאה אוטומטית של כתובות

‫† נדרשת גרסה 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)

‫† Distroless image משמש להחדרה.

אזורים

אשכולות 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 )