Cloud Service Mesh with Google Cloud APIs supported features
במאמר הזה מפורטות התכונות שזמינות ב-Cloud Service Mesh.
רשת שירותים ב-Cloud מורכבת מהאפליקציות שלכם, ממישור נתונים שתואם ל-xDS (פרוקסי Envoy בקוד פתוח או מישור נתונים ללא פרוקסי gRPC) ומ-Cloud Service Mesh כמישור הבקרה.
בטבלאות הבאות, הערך N/A (לא רלוונטי) מציין שלא ניתן לתמוך בתכונה מסוימת כי היא לא תואמת לתצורה הספציפית של Cloud Service Mesh. אם יש רווח ריק בלי סימן וי או לא רלוונטי, המשמעות היא שהתכונה לא אפשרית.
חלק מהתכונות האלה זמינות רק באמצעות ממשקי ה-API של איזון העומסים. מומלץ מאוד להשתמש ב-APIs לניתוב שירותים ולא ליצור פריסות חדשות באמצעות APIs של איזון עומסים.
גרסת xDS נתמכת
Cloud Service Mesh משתמש בממשקי API של מישור הבקרה xDS בקוד פתוח כדי להגדיר את Envoy ואת לקוחות gRPC ללא proxy. הלקוחות האלה פועלים בשם קוד האפליקציה שלכם כדי לספק את יכולות הרשת של האפליקציה ב-Cloud Service Mesh.
יש תמיכה רק ב-xDS v3. אם אתם משתמשים ב-xDS v2, אתם צריכים לעבור ל-xDS v3. מידע על אופן המעבר זמין במאמר מעבר מ-xDS v2 ל-xDS v3.
פלטפורמות להפעלת שירותי רשת
אתם יכולים להריץ אפליקציות בפלטפורמות הבאות ולהוסיף אותן לרשת שירותים גלובלית שמוגדרת על ידי Cloud Service Mesh.
| תכונה | נתמך |
|---|---|
| מכונות וירטואליות (VM) של Compute Engine | ✔ |
| מכונות קונטיינר ב-Google Kubernetes Engine (GKE) | ✔ |
| Kubernetes במכונות קונטיינרים ב-Compute Engine | ✔ |
ניהול שירותים
השירותים ברשת שמוגדרים על ידי Cloud Service Mesh נהנים מהיתרונות הבאים:
זיהוי שירותים. כשאפליקציה ברשת רוצה להגיע לאפליקציה אחרת, היא יכולה לקרוא לשירות הזה לפי שם.
התאמה אוטומטית לעומס של ה-Backend. המופעים שמריצים את קוד האפליקציה מתרחבים או מצטמצמים באופן דינמי בהתאם לצרכים שלכם.
רישום אוטומטי של נקודות קצה. כשמוסיפים או מסירים מופעים חדשים, הם משויכים לשירות באופן אוטומטי.
| תכונה | נתמך |
|---|---|
| פריסה אוטומטית של פרוקסי מסוג sidecar למכונות וירטואליות ב-Compute Engine | ✔ |
| הזרקה אוטומטית של פרוקסי מסוג sidecar ל-Pods של GKE | ✔ |
| זיהוי שירותים על סמך שם המארח | ✔ |
| שינוי גודל אוטומטי של מכונה וירטואלית על סמך ניצול יחידת העיבוד המרכזית (CPU) | ✔ |
| התאמה אוטומטית לעומס של מופעים על סמך עומס התנועה או קיבולת ההגשה (מכונות וירטואליות ב-Compute Engine בקבוצות של מופעי מכונה מנוהלים, או MIG, בלבד) |
✔ |
| תיקון אוטומטי של מופעים על סמך בדיקות תקינות שניתנות להגדרה | ✔ |
| רישום אוטומטי של נקודות קצה למכונות וירטואליות ב-Compute Engine | ✔ |
| רישום אוטומטי של נקודות קצה עבור מקרים של קונטיינרים או Pods ב-GKE | ✔ |
| ממשק API להוספה או להסרה של נקודות קצה באופן פרוגרמטי | ✔ |
נקודות קצה לתנועת הנתונים
מיקרו-שירותים משתמשים במישור הנתונים כדי להגיע לשירותים ברשת שלכם ומחוץ לרשת שלכם. Cloud Service Mesh מאפשר להפריד בין הלוגיקה של האפליקציה לבין הלוגיקה של הרישות, כך שהאפליקציה צריכה רק לשלוח בקשות למישור הנתונים (לדוגמה, קובץ עזר חיצוני שפועל לצד האפליקציה). מישור הנתונים שולח בקשות לנקודת הקצה הנכונה.
בטבלה הבאה, האפליקציות שמתוארות כחלק מהרשת הן אפליקציות שמשתמשות במישור הנתונים שמנוהל על ידי Cloud Service Mesh כדי לתקשר עם שירותים אחרים. האפליקציות האלה יכולות לשלוח תנועה לשירותים ברשת ולשירותים מחוץ לרשת.
| תכונה | נתמך |
|---|---|
| אפליקציות מבוססות-VM ברשת | ✔ |
| אפליקציות מבוססות קונטיינרים ברשת | ✔ |
| אפליקציות מבוססות מכונות וירטואליות מחוץ לרשת | ✔ |
| אפליקציות מבוססות קונטיינרים מחוץ לרשת | ✔ |
| אפליקציות שפועלות במרכזי נתונים מקומיים | ✔ |
| אפליקציות בסביבות מרובות עננים | ✔ |
טופולוגיות של מישור הנתונים
במודל של Service mesh, האפליקציות משתמשות במישור נתונים כדי לתקשר. מישור הנתונים הזה מורכב בדרך כלל משרתי proxy מסוג sidecar שנפרסים לצד האפליקציות שלכם. Cloud Service Mesh הוא גמיש מאוד ותומך בטופולוגיות של מישור הנתונים שמתאימות לצרכים שלכם ברשת השירותים.
| תכונה | נתמך |
|---|---|
| שרתי proxy מסוג Sidecar שפועלים לצד אפליקציות | ✔ |
| אפליקציות gRPC ללא שרת Proxy | ✔ |
| שרתי proxy באמצע בין שתי אפליקציות ברשת | ✔ |
| שרתי proxy של Edge בגבול של רשת ה-mesh | ✔ |
| רשת שמשתרעת על כמה אשכולות GKE או על כמה מכונות וירטואליות ב-Compute Engine בכמה אזורים | ✔ |
הגדרה תוכנתית מבוססת API
כל ההגדרות מוצגות דרך API בארכיטקטורת REST ולוח הבקרה שלנו, כך שאתם יכולים לבצע שינויים אוטומטיים בצוותים גדולים ולנהל שינויים באופן פרוגרמטי. אי אפשר להגדיר חלק מהתכונות באמצעות Google Cloud המסוף.
| תכונה | נתמך |
|---|---|
| ממשקי API ל-REST | ✔ |
| מסוףGoogle Cloud | ✔ |
| Google Cloud CLI | ✔ |
| Cloud Deployment Manager | ✔ |
| תמיכה ב-Terraform | ✔ |
תמיכה בשפות באפליקציות gRPC ללא proxy
אתם יכולים ליצור אפליקציות gRPC ללא proxy שפועלות עם Cloud Service Mesh באמצעות שפות התכנות הבאות. רשימת התכונות של Service mesh שנתמכות בהטמעות ובגרסאות שונות של gRPC מופיעה ב-GitHub.
| שפה | נתמך |
|---|---|
| Java | ✔ |
| Go | ✔ |
| C++ | ✔ |
| Python | ✔ |
| Ruby | ✔ |
| PHP | ✔ |
| Node | ✔ |
פרוטוקולים של בקשות
אפליקציות יכולות להשתמש בפרוטוקולי הבקשות הבאים כשהן משתמשות במישור הנתונים שהוגדר ב-Cloud Service Mesh כדי לתקשר.
| תכונה | נתמך |
|---|---|
| HTTP | ✔ |
| HTTPS | ✔ |
| HTTP/2 | ✔ |
| TCP | ✔ |
| gRPC | ✔ |
אבטחת השירות
Cloud Service Mesh תומך באבטחת שירותים באמצעות ההגדרות הבאות.
| תכונה | Envoy | gRPC |
|---|---|---|
| TLS with GKE Pods | ✔ | ✔ |
| mTLS עם Pods ב-GKE | ✔ | ✔ |
| בקרת גישה והרשאה | ✔ | ✔ |
| הגבלת קצב של יצירת בקשות באמצעות Google Cloud Armor | ✔ |
ניתוב וניהול תנועה
Cloud Service Mesh תומך במדיניות מתקדמת לניהול תנועת גולשים, שבעזרתה אפשר לכוון, לפצל ולעצב את תנועת הגולשים כשהיא עוברת דרך מישור הנתונים.
חלק מהתכונות המתקדמות לניהול תנועה לא זמינות בשירותי gRPC בלי שרת Proxy, ואף אחת מהתכונות המתקדמות לניהול תנועה לא זמינה במשאב של פרוקסי TCP של היעד.
התכונות הבאות לא נתמכות כש-Cloud Service Mesh מטפל בתנועת TCP (לא HTTP(S)).
| תכונה | נתמך בשרת proxy של Envoy שהוגדר לטיפול בתנועת HTTP(S) או gRPC | תמיכה ב-gRPC ללא שרת proxy |
|---|---|---|
| ניתוב בקשות HTTP/Layer 7 על סמך התאמה של סיומת/קידומת/מלאה/ביטוי רגולרי ל: | ||
| • שם המארח | ✔ | ✔ |
| • נתיב | ✔ | ✔ |
| • כותרות | ✔ | ✔ |
| • Method | ✔ | לא רלוונטי |
| • קובצי Cookie | ✔ | ✔ |
| • פרמטרים של בקשות | ✔ | לא רלוונטי |
| הזרקת תקלות | ✔ | ✔ |
| הגדרת פסק זמן | ✔ | לא רלוונטי ראו משך השידור המקסימלי. |
| ניסיונות חוזרים | ✔ | ✔ Except per retry timeout |
| הפניות אוטומטיות | ✔ | |
| שכתוב של URI | ✔ | |
| שינויים בכותרות של בקשות ותגובות | ✔ | |
| חלוקת התנועה | ✔ | ✔ |
| שיקוף תנועה | ✔ | |
| זיהוי חריגות | ✔ | ✔ |
| מפסק זרם | ✔ | ✔ maxRequests בלבד |
| משך שידור מקסימלי | ✔ | ✔ |
איזון עומסים
אתם יכולים להגדיר שיטות ואלגוריתמים מתקדמים לאיזון עומסים כדי לאזן עומסים ברמת השירות, ברמת הקבוצה העורפית (קבוצות של מופעים או קבוצות של נקודות קצה ברשת) וברמה של קצה עורפי או נקודת קצה בודדים. מידע נוסף זמין במאמרים סקירה כללית על שירותי קצה עורפי וסקירה כללית על איזון עומסים מתקדם.
| תכונה | נתמך בשרת proxy של Envoy שהוגדר לטיפול בתנועת HTTP(s), TCP או gRPC | תמיכה ב-gRPC ללא שרת proxy |
|---|---|---|
| בחירת קצה עורפי (קבוצת מופעים או קבוצת נקודות קצה ברשת) על סמך אזור (העדפה לאזור הקרוב ביותר עם קיבולת תקינה של קצה עורפי) | ✔ | ✔ |
| בחירת קצה עורפי באמצעות מצב איזון מבוסס-קצב (בקשות לשנייה). | ✔ לא נתמך בתעבורת TCP (שאינה HTTP(S)). |
✔ |
| בחירת שרת קצה עורפי על סמך מצב איזון מבוסס-ניצול (מכונות וירטואליות רק בקבוצות של מופעים ב-Compute Engine) | ✔ | ✔ |
| קיבולת מקסימלית שאפשר להגדיר לכל קצה עורפי (רק ב-Compute Engine וב-GKE) | ✔ | ✔ |
בחירת קצה עורפי על סמך מדיניות איזון עומסים שניתנת להגדרה. מידע על כל מדיניות מובנית זמין במאמר |
|
|
חוסן השירות
Cloud Service Mesh תומך ביכולות שעוזרות לשפר את העמידות של השירותים. לדוגמה, אפשר להשתמש ב-Cloud Service Mesh כדי להטמיע תבנית פריסה של כחול-ירוק (blue-green deployment), בדיקות קנרית או ניתוק מעגל (Envoy, gRPC).
| תכונה | נתמך בשרת proxy של Envoy שהוגדר לטיפול בתנועת HTTP(s), TCP או gRPC | תמיכה ב-gRPC ללא שרת proxy |
|---|---|---|
| בחירת שירות על סמך פיצול תנועה לפי משקל | ✔ | ✔ |
| מפסק זרם | ✔ | ✔ maxRequests בלבד |
ניהול הקיבולת של השירות והקצה העורפי
Cloud Service Mesh לוקח בחשבון את הקיבולת של השירותים והקצה העורפי כדי לקדם חלוקה אופטימלית של התעבורה בין הקצוות העורפיים של השירותים. Cloud Service Mesh משולב עם Google Cloud התשתית, כך שהוא אוסף נתוני קיבולת באופן אוטומטי. אפשר גם להגדיר את הקיבולת באופן ידני.
| תכונה | נתמך |
|---|---|
| מעקב אוטומטי אחרי הקיבולת והניצול של ה-Backend, על סמך ה-CPU, עבור מופעי VM בקבוצת מופעי מכונה מנוהלים (MIG). | ✔ |
| קיבולת ידנית ושינויים זמניים למכונות וירטואליות ולמופעי קונטיינרים בקבוצות של מופעי מכונה מנוהלים (MIG) ובקבוצות של נקודות קצה ברשת (NEG) על סמך קצב הבקשות. | ✔ |
| ריקון ידני של הקיבולת. | ✔ |
מעבר לגיבוי (Failover)
עומסי עבודה של Enterprise מסתמכים בדרך כלל על פריסות של זמינות גבוהה כדי לשפר את זמן הפעולה של השירות. Cloud Service Mesh תומך בסוגי הפריסות האלה על ידי הפעלת יתירות במספר אזורים או במספר מקומות בתוך אותו אזור.
| תכונה | נתמך |
|---|---|
| מעבר אוטומטי לגיבוי (failover) לאזור אחר באותו אזור שיש בו קיבולת בק-אנד תקינה. | ✔ |
| מעבר אוטומטי לגיבוי (failover) לאזור הקרוב ביותר עם קיבולת תקינה של השרת העורפי. | ✔ |
בדיקות תקינות
Cloud Service Mesh תומך בבדיקות תקינות מרכזיות כדי לקבוע את התקינות של העורף.
מידע נוסף מופיע בסקירה הכללית על בדיקות תקינות.
| תכונה | נתמך |
|---|---|
| בדיקות תקינות של gRPC | ✔ |
| בדיקות תקינות של HTTP | ✔ |
| בדיקות תקינות של HTTPS | ✔ |
| בדיקות תקינות של HTTP/2 | ✔ |
| בדיקות תקינות של TCP | ✔ |
בדיקות תקינות שניתנות להגדרה:
|
✔ |
| נתיב בקשה שניתן להגדרה (HTTP, HTTPS, HTTP/2) | ✔ |
| מחרוזת או נתיב של בקשה שאפשר להגדיר (TCP או SSL) | ✔ |
| מחרוזת תשובה צפויה שניתנת להגדרה | ✔ |
ניראות (observability)
כלי ניראות (observability) מספקים מידע על מעקב, ניפוי באגים וביצועים כדי לעזור לכם להבין את Service mesh. היכולות הבאות מסופקות כברירת מחדל או מוגדרות במישור הנתונים. קוד האפליקציה לא צריך לבצע פעולות מיוחדות כדי ליצור את נתוני יכולת הצפייה האלה.
מרכז הבקרה של תקינות השירות זמין בשירותי gRPC ללא proxy, אבל אי אפשר להגדיר רישום ביומן ומעקב במישור הנתונים. אי אפשר להגדיר ב-Cloud Service Mesh את הרישום ביומן ואת המעקב של אפליקציית gRPC. כדי להפעיל רישום ביומן ומעקב, אפשר לפעול לפי ההוראות שבקטעים לפתרון בעיות או במדריכי gRPC שזמינים באתרים של קוד פתוח. לדוגמה, כדי להפעיל איסוף מדדים ומעקב בשירותי gRPC בלי שרת Proxy, אפשר להשתמש ב-OpenTelemetry.
| תכונה | נתמך באמצעות שרתי Proxy | תמיכה בשירותי gRPC ללא proxy |
|---|---|---|
| לוח הבקרה של תקינות השירות | ✔ | ✔ |
| רישום ב-Data plane | ✔ | ✔ |
| מעקב במישור הנתונים | ✔ | ✔ |
זיקה לסשן (session affinity)
תקשורת בין שרתים ללקוחות כוללת לעיתים קרובות כמה בקשות עוקבות. במקרה כזה, כדאי לנתב בקשות עוקבות של לקוחות לאותו קצה עורפי או שרת. Cloud Service Mesh מספק אפשרויות להגדרה כדי לשלוח בקשות מלקוח מסוים, על בסיס המאמץ הטוב ביותר, לאותו קצה עורפי כל עוד הקצה העורפי תקין ויש לו קיבולת. מידע נוסף זמין במאמר בנושא סקירה כללית על שירותי קצה עורפי.
| תכונה | נתמך בשרתי proxy של HTTP(S) | נתמך בשרתי proxy ל-TCP | תמיכה בשירותי gRPC ללא proxy |
|---|---|---|---|
| כתובת ה-IP של הלקוח | ✔ | ✔ | |
| קובץ Cookie של HTTP | ✔ | לא רלוונטי | |
| כותרת HTTP | ✔ | לא רלוונטי | ✔ |
| קובץ Cookie שנוצר (מגדיר קובץ Cookie של לקוח בבקשה הראשונה) | ✔ | לא רלוונטי |
טופולוגיות של רשתות
Cloud Service Mesh תומך בטופולוגיות נפוצות של רשתות. Google Cloud
| תכונה | נתמך |
|---|---|
| רשת אחת בפרויקט ב- Google Cloud | ✔ |
| מספר רשתות בפרויקט Google Cloud | ✔ |
| כמה שערים בפרויקט ב- Google Cloud | ✔ |
| VPC משותף (רשת אחת שמשותפת בין כמה Google Cloud פרויקטים) | ✔ |
הסבר מפורט על התמיכה ב-VPC משותף ב-Cloud Service Mesh זמין במאמר Limitations.
תאימות
Cloud Service Mesh תואם לתקנים הבאים.
| אישור תאימות | נתמך |
|---|---|
| HIPAA | ✔ |
| ISO 27001, ISO 27017, ISO 27018 | ✔ |
| SOC1, SOC2, SOC3 | ✔ |
| PCI DSS | ✔ |
המאמרים הבאים
- מידע נוסף על Cloud Service Mesh זמין בסקירה הכללית על Cloud Service Mesh.
- כדי למצוא תרחישי שימוש ודפוסי ארכיטקטורה לשירותי gRPC ללא proxy, אפשר לעיין בסקירה הכללית על שירותי gRPC ללא proxy.