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 ✔

ניהול שירותים

השירותים ב-mesh שמוגדרים על ידי Cloud Service Mesh נהנים מהיתרונות הבאים:

  • זיהוי שירותים. כשאפליקציה ברשת רוצה להגיע לאפליקציה אחרת, היא יכולה לקרוא לשירות הזה לפי שם.

  • התאמה אוטומטית של ה-Backend לעומס. המופעים שמריצים את קוד האפליקציה מתרחבים או מצטמצמים באופן דינמי בהתאם לצרכים שלכם.

  • רישום אוטומטי של נקודות קצה. כשמוסיפים או מסירים מופעים חדשים, הם משויכים לשירות באופן אוטומטי.

תכונה נתמך
פריסה אוטומטית של פרוקסי מסוג sidecar למכונות וירטואליות ב-Compute Engine ✔
הזרקה אוטומטית של פרוקסי מסוג sidecar ל-Pods של GKE ✔
זיהוי שירותים על סמך שם המארח ✔
שינוי גודל אוטומטי של מכונה על סמך ניצול יחידת העיבוד המרכזית (CPU) ✔
התאמה אוטומטית של מופעים לעומס על סמך עומס התנועה או קיבולת ההגשה
(מכונות וירטואליות ב-Compute Engine בקבוצות של מופעי מכונה מנוהלים, או MIG, בלבד)		 ✔
תיקון אוטומטי של מופעים על סמך בדיקות תקינות שניתנות להגדרה ✔
רישום אוטומטי של נקודות קצה למכונות וירטואליות ב-Compute Engine ✔
רישום אוטומטי של נקודות קצה עבור מקרים של קונטיינרים או פודים ב-GKE ✔
‫API להוספה או להסרה של נקודות קצה באופן פרוגרמטי ✔

נקודות קצה לתנועת הגולשים במישור הנתונים

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

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

תכונה נתמך
אפליקציות מבוססות מכונות וירטואליות ברשת ✔
אפליקציות מבוססות קונטיינרים ברשת ✔
אפליקציות מבוססות מכונות וירטואליות מחוץ לרשת ✔
אפליקציות מבוססות קונטיינרים מחוץ לרשת ✔
אפליקציות שפועלות במרכזי נתונים מקומיים ✔
אפליקציות בסביבות מרובות עננים ✔

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

במודל של 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 ✔
צומת ✔

פרוטוקולים של בקשות

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

תכונה נתמך
HTTP ✔
HTTPS ✔
HTTP/2 ✔
TCP ✔
gRPC ✔

אבטחת השירות

‫Cloud Service Mesh תומך באבטחת שירותים באמצעות ההגדרות הבאות.

תכונה Envoy gRPC
TLS with GKE Pods ✔ ✔
mTLS with GKE Pods ✔ ✔
בקרת גישה והרשאה ✔ ✔
הגבלת קצב של יצירת בקשות באמצעות Google Cloud Armor ✔

ניתוב וניהול תנועה

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

חלק מהתכונות המתקדמות לניהול תעבורת נתונים לא זמינות בשירותי gRPC בלי שרת Proxy, ואף אחת מהתכונות המתקדמות לניהול תעבורת נתונים לא זמינה במשאב של פרוקסי TCP של היעד.

התכונות הבאות לא נתמכות כש-Cloud Service Mesh מטפל בתנועת TCP (לא HTTP(S)).

תכונה נתמך בשרת Proxy של Envoy שהוגדר לטיפול בתנועת HTTP(S) או gRPC תמיכה ב-gRPC ללא שרת proxy
ניתוב בקשות HTTP/שכבה 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) ✔ ✔

בחירת ה-Backend על סמך מדיניות איזון עומסים שניתנת להגדרה.

מידע על כל מדיניות מובנית זמין במאמר localityLbPolicy.

  • משתמשים במדיניות מובנית אחת. בוחרים באחת מהאפשרויות הבאות:

    • סדר סיבובי
    • הבקשה הכי פחות
    • גיבוב מבוסס טבעת (ring hash)
    • אקראי
    • יעד מקורי
    • Maglev

עמידות השירות

‫Cloud Service Mesh תומך ביכולות שעוזרות לשפר את החוסן של השירותים. לדוגמה, אפשר להשתמש ב-Cloud Service Mesh כדי להטמיע תבנית פריסה של blue-green, בדיקת קנרית או ניתוק מעגל (Envoy,‏ gRPC).

תכונה נתמך בשרת proxy של Envoy שהוגדר לטיפול בתנועת HTTP(s),‏ TCP או gRPC תמיכה ב-gRPC ללא שרת proxy
בחירת שירות על סמך פיצול תנועה לפי משקל ✔ ✔
מפסק זרם ✔ ‫✔
רק maxRequests

ניהול הקיבולת של השירות והקצה העורפי

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

תכונה נתמך
מעקב אוטומטי אחרי הקיבולת והניצול של ה-Backend, על סמך מעבד (CPU), עבור מופעי מכונה וירטואלית בקבוצת מופעי מכונה מנוהלים (MIG). ✔
קיבולת ידנית ושינויים זמניים למכונות VM ולמופעי קונטיינרים ב-MIG ובקבוצות של נקודות קצה ברשת (NEGs) על סמך קצב הבקשות. ✔
ריקון ידני של הקיבולת. ✔

מעבר לגיבוי (Failover)

עומסי עבודה של Enterprise מסתמכים בדרך כלל על פריסות של זמינות גבוהה כדי לשפר את זמן הפעולה של השירות. ‫Cloud Service Mesh תומך בסוגי הפריסות האלה על ידי הפעלת יתירות במספר אזורים או במספר מקומות בתוך אותו אזור.

תכונה נתמך
מעבר אוטומטי לגיבוי (failover) לאזור אחר באותו אזור שיש בו קיבולת תקינה בבק-אנד. ✔
מעבר אוטומטי לגיבוי (failover) לאזור הקרוב ביותר עם קיבולת תקינה של השרת העורפי. ✔

בדיקות תקינות

‫Cloud Service Mesh תומך בבדיקות תקינות מרכזיות כדי לקבוע את התקינות של ה-backend.

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

תכונה נתמך
בדיקות תקינות של gRPC ✔
בדיקות תקינות של HTTP ✔
בדיקות תקינות של HTTPS ✔
בדיקות תקינות של HTTP/2 ✔
בדיקות תקינות של TCP ✔

בדיקות תקינות שניתנות להגדרה:

  • יציאה
  • בדיקת מרווחי הזמן
  • חסימות זמניות
  • סף בריא וסף לא בריא
 ✔
נתיב בקשה שניתן להגדרה (HTTP, ‏ HTTPS, ‏ HTTP/2) ✔
מחרוזת או נתיב של בקשה שאפשר להגדיר (TCP או SSL) ✔
מחרוזת צפויה של תגובה שאפשר להגדיר ✔

ניראות (observability)

כלי יכולת תצפית מספקים מידע על ניטור, ניפוי באגים וביצועים, כדי לעזור לכם להבין את Service mesh. היכולות הבאות מסופקות כברירת מחדל או מוגדרות במישור הנתונים. קוד האפליקציה לא צריך לבצע פעולות מיוחדות כדי ליצור את נתוני יכולת הבקרה האלה.

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

תכונה נתמך באמצעות שרתי proxy תמיכה בשירותי gRPC ללא proxy
לוח הבקרה של Service Health ✔ ✔
רישום ב-Data plane ✔ ✔
מעקב במישור הנתונים ✔ ✔

זיקה לסשן (session affinity)

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

תכונה נתמך בשרתי proxy של HTTP(S) נתמך בשרתי TCP Proxy תמיכה בשירותי 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 ✔

המאמרים הבאים