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

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

רשימת התכונות הנתמכות של Cloud Service Mesh למישור בקרה בתוך האשכול מופיעה במאמר שימוש בממשקי Istio API (מישור בקרה 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 בתוך האשכול נתמכות רק באמצעות האסטרטגיה של העברת אשכולות קנרית.
• העברות ושדרוגים נתמכים רק מגרסאות של 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 לא נתמכים:

  • EnvoyFilter 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 רק באמצעות Envoys, אלא אם הצי מכיל אשכולות אחרים שההתנהגות הזו לא מופעלת בהם. האפשרות הזו זהה לאפשרות 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).

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

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

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

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

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

אפשר לעיין בדף המגבלות על יכולת ההתאמה

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

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

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

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

Notes on terminology

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

תמונות בסיסיות

תכונה	מנוהל (TD)	מנוהל (istiod)
תמונת proxy ללא הפצה	†

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

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

אבטחה

VPC Service Controls

תכונה	מנוהל (TD)	מנוהל (istiod)
VPC Service Controls

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

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

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

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

תכונות אבטחה

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

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

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

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

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

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

בקשת אימות

תכונה	מנוהל (TD)	מנוהל (istiod)
אימות JWT^(הערה 1)
ניתוב על סמך הצהרת 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)	מנוהל (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 שמשמשת להגדרת יומני גישה ומעקב. מישור הבקרה TRAFFIC_DIRECTOR לא תומך בהגדרת קצב הדגימה של העקבות.

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

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

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

סקיצה

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

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

Networking

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

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

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

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

תכונה	מנוהל (TD)	מנוהל (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)	מנוהל (istiod)
Sidecars
שער תעבורת נתונים נכנסת (Ingress)
יציאה ישירה מ-sidecars
תעבורת נתונים יוצאת (egress) באמצעות שערים לתעבורת נתונים יוצאת	*	*

תמיכה ב-CRD

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

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

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

שער ענן של Service mesh

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

Kubernetes Gateway API

תכונה	מנוהל (TD)	מנוהל (istiod)
Kubernetes Gateway API

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

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

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

תכונה	מנוהל (TD)	מנוהל (istiod)
RATE
UTILIZATION
CUSTOM_METRICS
במהלך הטיסה (תצוגה מקדימה)

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

כניסה לשירות

תכונה	מנוהל (TD)	מנוהל (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)	מנוהל (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)	מנוהל (istiod)
Sidecar v1beta1	*

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

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

DNS proxy

תכונה	מנוהל (TD)	מנוהל (istiod)
רזולוציית שם של Service באשכולות	*
פתרון שמות של ServiceEntry באשכול	*
רזולוציית שם של Headless Service
הקצאה אוטומטית של כתובות

‫† נדרשת גרסה 1.21.5-asm.39 ואילך של Sidecar.

MeshConfig

תכונה	מנוהל (TD)	מנוהל (istiod)
DiscoverySelectors
clusterLocal
LocalityLB	§
ExtensionProviders	§
CACert
ImageType - distroless	§
OutboundTrafficPolicy	§
defaultProviders.accessLogging
defaultProviders.tracing
defaultConfig.tracing.stackdriver	§
accessLogFile	§

ProxyConfig

תכונה	מנוהל (TD)	מנוהל (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)	מנוהל (istiod)
לוחות בקרה של Cloud Service Mesh במסוף Google Cloud
Cloud Monitoring
Cloud Logging

כלים

תכונה	מנוהל (TD)	מנוהל (istiod)
הכלי gcloud beta container fleet mesh debug