סקירה כללית על ממשקי API של ניתוב שירותים ב-Cloud Service Mesh

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

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

במסמך הזה מתוארים ממשקי API לניתוב שירותים להגדרת Cloud Service Mesh. ממשקי ה-API האלה נועדו לפשט ולשפר את חוויית ההגדרה הכוללת של הרשת.

מודל ניתוב השירות משתמש במשאבי API שנקראים Mesh,‏ Gateway ו-Route. המשאבים האלה מספקים חוויית הגדרה רלוונטית בהקשר כשמגדירים את מישור הבקרה של Service Networking.

במסמך הזה מוצגים המודל והמשאבים הבאים של Service Routing API.

• Meshresource
  • ניהול תעבורת נתונים מאובטח בין שירותים (מזרח-מערב) עבור שרתי proxy מסוג Envoy sidecar ולקוחות gRPC ללא proxy.

• Gatewayמשאב

  • הגדרת אבטחה וניהול תעבורה לשרתי proxy של Envoy שפועלים כשערי כניסה, ומאפשרים ללקוחות חיצוניים להתחבר ל-Service mesh (צפון-דרום).

• Route משאבים מהסוגים הבאים:

  • HTTPRoute
  • GRPCRoute
  • TCPRoute
  • TLSRoute

Google Cloud המסוף לא תומך בממשקי ה-API של ניתוב השירות. אתם צריכים להטמיע את משאבי ה-API האלה באמצעות Google Cloud CLI או ממשקי ה-API ל-REST.

תרחישים לדוגמה ויתרונות

ממשקי ה-API של ניתוב השירותים מאפשרים להגדיר את Cloud Service Mesh גם לפריסות של gRPC בלי שרת Proxy וגם לפריסות של Envoy proxy. מודל ה-API של ניתוב שירותים מאפשר ליהנות מכמה יתרונות מרכזיים.

בתרשים הבא, שני שירותים ב-service mesh מחוברים באמצעות משאב Mesh. שני משאבי HTTPRoute מגדירים את הניתוב. האדמין של הרשת או הפלטפורמה מנהל את המשאב Mesh, ושני בעלי השירותים יוצרים את הגדרות הניתוב של השירותים שלהם.

עיצוב API מבוסס-תפקידים מאפשר הפרדה ברורה של תחומי האחריות

ממשקי ה-API של ניתוב השירות מאפשרים לכם להפריד בין האחריות על הגדרת הרשת לבין התפקידים בארגון:

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

בתרשים הבא, Cloud Load Balancing ומשאב Gateway מספקים שער לתעבורת נתונים נכנסת לרשת, מלקוח שלא נמצא ברשת. האדמין של רשת ה-mesh מגדיר ומנהל את משאב Gateway, בעוד בעלי השירותים מגדירים ומנהלים את השירותים שלהם ואת ניתוב התנועה.

אמינות משופרת עם מודל שירות עצמי

ממשקי ה-API לניתוב שירותים משתמשים במשאבים לכל פרוטוקול ולכל נתיב, שאפשר להגדיר אותם ושהם בבעלות של בעלי שירותים עצמאיים. לגישה הזו יש כמה יתרונות.

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

הפעלה של Service mesh שמשתרעת על פני כמה פרויקטים בסביבות של VPC משותף

מודל ה-API לניתוב שירותים מאפשר לבעלי שירותים להשתתף בתשתית רשת משותפת באמצעות VPC משותף ואמצעי קישוריות אחרים, תוך שמירה על שליטה עצמאית בשירותים שלהם. לדוגמה, בעלי שירותים יכולים להגדיר את משאבי Route בפרויקטים שלהם. אדמינים של הפלטפורמה יכולים להגדיר Mesh בפרויקט מארח שמנוהל באופן מרכזי, ואז להעניק לבעלי שירותים הרשאות IAM לצירוף משאבי Route ל-Mesh או ל-Gateway משותפים. בתרשים הבא מוצגת דוגמה ל-VPC משותף.

ממשקי ה-API של ניתוב השירותים מאפשרים גם ללקוחות של Service mesh להתחבר לרשתות שונות באמצעות קישור בין רשתות VPC שכנות (peering).

ניתוב תנועה על סמך אינדיקטור של שם השרת

המשאב TLSRoute מאפשר לכם לנתב תנועה מוצפנת באמצעות TLS על סמך Server Name Indication ‏ (SNI) בתהליך הלחיצת יד של TLS. אפשר להגדיר את התנועה ב-TLS כך שתנותב לשירותי הקצה העורפי המתאימים על ידי הגדרת התאמת SNI במשאב TLSRoute. בפריסות האלה, ה-proxy רק מעביר תעבורת נתונים וסשן ה-TLS מסתיים בשרת העורפי של היעד.

המשאב TLSRoute נתמך רק בשרתי Proxy של Envoy שנפרסים כשרתי Proxy מסוג sidecar או כשערים.

משאב TLSRoute שמצורף למשאב TLSRouteMesh

הפריסה שמוצגת בתרשים הבא מעבירה כל תנועה של רשת שירותים שבה לתוסף SNI יש את הערך service1 לשירות העורפי service1. בנוסף, כל התנועה ב-Service mesh שבה לתוסף SNI יש את הערך service2 מנותבת לשירות לקצה העורפי service2. הערך של תוסף SNI ושם השירות לקצה העורפי הם בלתי תלויים זה בזה.

משאב TLSRoute שמצורף למשאב TLSRouteGateway

בפריסה שמוצגת בתרשים הבא, כל תנועה נכנסת מנותבת למשאב Gateway שבו לתוסף SNI יש את הערך serviceA לשירות הקצה העורפי serviceA. בנוסף, כל תנועה נכנסת אל Gateway שבה לתוסף SNI יש את הערך serviceB מנותבת אל שירות ה-Backend‏ serviceB. הערך של תוסף SNI ושם שירות לקצה העורפי לא תלויים זה בזה. גם הערך של תוסף SNI והכותרת בבקשות HTTP הם בלתי תלויים.

המשאב Gateway לא מסיים את חיבור ה-TLS בשרת ה-proxy של Envoy של Gateway. במקום זאת, חיבור ה-TLS מסתיים בשירות לקצה העורפי המתאים. ה-Gateway לא יכול לבדוק מידע שמוצפן בשכבת TLS, מלבד הצגת ClientHello, שמכיל תוסף SNI של טקסט רגיל. במצב הזה, Gateway מבצע העברה של TLS. שימו לב: אין תמיכה בהצפנה של ClientHello.

תמיכה ב-gRPC ליבה

אפשר להגדיר לקוחות gRPC בלי שרת Proxy באמצעות מאפייני ליבה של gRPC, כמו התאמה לפי שיטה.

חלוקת תנועה לתנועת TCP

אפשר להטמיע פיצול תעבורה לפי משקל לתעבורת TCP בכמה שירותי קצה עורפיים. כשמעדכנים את השירות, אפשר להגדיר דפוסים כמו השקה הדרגתית (canary) (כחול-ירוק). פיצול תנועה מאפשר גם להעביר תנועה בצורה מבוקרת ללא השבתה.

יירוט תנועה

כשמשתמשים ב-API של ניתוב שירותים Mesh ובמשאבי Gateway, כל התנועה נחסמת באופן אוטומטי. מידע נוסף זמין במאמר בנושא אפשרויות להגדרת מכונה וירטואלית ב-Compute Engine עם פריסה אוטומטית של Envoy.

ארכיטקטורה ומשאבים

בקטע הזה מתואר מודל ה-API לניתוב שירותים והמשאבים שלו, והוא עוזר להבין איך המשאבים של ה-API לניתוב שירותים פועלים יחד.

משאב Mesh

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

Mesh

המשאב Mesh מופיע כהפניה במשאב Route כדי להוסיף מסלולים לשירותים שמהווים חלק מהרשת.

לקוחות Envoy proxy ו-gRPC בלי שרת Proxy מקבלים הגדרה מ-Cloud Service Mesh על ידי הצטרפות ל-Service mesh שמזוהה לפי שם המשאב Mesh. המשאב Mesh תומך בפריסות הבאות של מישור הנתונים:

• ‫Envoy פועל לצד האפליקציה כשרתי proxy של sidecar
• לקוחות gRPC ללא שרת proxy
• שילוב של Envoy sidecar ולקוחות gRPC ללא proxy

משאב Route

משתמשים במשאב Route כדי להגדיר ניתוב לשירותים. יש ארבעה סוגים שונים של משאבי API‏ Route. הן מגדירות את הפרוטוקול שמשמש להפניית תנועה לשירות קצה עורפי.

• HTTPRoute
• GRPCRoute
• TCPRoute
• TLSRoute

ה-API לא מכיל Route API מילולי. משאבי ה-API היחידים שאפשר להגדיר הם HTTPRoute, GRPCRoute, TCPRoute ו-TLSRoute.

המשאב Route מפנה למשאב אחד או יותר מסוג Mesh ו-Gateway כדי להוסיף את המסלולים שמהווים חלק מההגדרה התואמת של Mesh או Gateway. משאב Route יכול להפנות למשאבים מסוג Gateway וגם למשאבים מסוג Mesh.

משאב Route מפנה גם למשאב אחד או יותר של שירות קצה עורפי. השירותים מוגדרים באמצעות ה-API של שירות הקצה העורפי. יוצרים משאב של שירות קצה עורפי שמפנה לקצה עורפי אחד או יותר של MIG או NEG.

בתרשים הבא מוצגים היחסים בין המשאבים Mesh, Gateway ו-Route, לבין משאב שירות ה-Backend וה-Backends שלו.

אתם מגדירים יכולות אחרות לניהול תנועה, כמו ניתוב, שינויים בכותרות, פסק זמן ופיצול תנועה לפי משקל במשאבי Route. לדוגמה, בתרשים הבא, משאב HTTPRoute מגדיר פיצול תנועה של 70% / 30% בין שני שירותי קצה עורפיים.

כדי לפשט את הניהול של Service mesh, אפשר לראות רשימה של כל המשאבים מסוג Route שמצורפים למשאב מסוג Mesh או Gateway.

משאב TLSRoute

משתמשים במשאב TLSRoute כדי לנתב תעבורת TLS לשירותי קצה עורפיים על סמך שמות מארחים של SNI ושם של משא ומתן על פרוטוקול בשכבת האפליקציה (ALPN). TLSRoute ההגדרה מרמזת על העברת TLS, שבה פרוקסי Envoy לא מסיים את תעבורת ה-TLS.

המשאב TLSRoute מפנה למשאב אחד או יותר מסוג Mesh ו-Gateway כדי להוסיף את המסלולים שמהווים חלק מההגדרה של Mesh או Gateway.

משאב TLSRoute מפנה גם למשאב אחד או יותר של שירות קצה עורפי. השירותים מוגדרים באמצעות משאב ה-API של שירות הקצה העורפי.

משאב Gateway

משתמשים במשאב Gateway כדי לייצג שרתי proxy של Envoy שפועלים כשערי כניסה, ומאפשרים ללקוחות חיצוניים להתחבר ל-Service mesh (תנועה מצפון לדרום). למשאב הזה יש יציאות האזנה יחד עם פרמטר scope. שרת ה-proxy של Envoy שפועל כשער כניסה נקשר ליציאות שצוינו ול-0.0.0.0, שמייצג את כל כתובות ה-IP במכונה הווירטואלית המקומית. בתרשים הבא מוצגים שרתי proxy של Envoy שנפרסו כשירות כניסה והוגדרו על ידי המשאב Gateway. בדוגמה הזו, שרתי proxy של Envoy מוגדרים להאזין ליציאה 80 לחיבורים נכנסים מלקוחות.

משאב ה-API‏ Gateway תומך רק במישור הנתונים של Envoy proxy. היא לא תומכת ב-gRPC ללא proxy. gRPCRoutes נתמכים במשאב Gateway, אבל תנועת ה-gRPC מנותבת על ידי שרת ה-proxy של Envoy, שפועל כשרת proxy באמצע.

מהו Gateway היקף ומהי Gateway הגדרה משולבת?

Gateway מכונה של משאב מייצגת את היציאות וההגדרה שספציפיות לתנועה שמתקבלת ביציאות האלה. למשאב Gateway API יש פרמטר, Gateway, שמשמש לקיבוץ ולמיזוג לוגיים של ההגדרה של שני משאבי Gateway או יותר.scope

לדוגמה, אם רוצים ששרתי ה-proxy של Gateway יאזינו ליציאות 80 ו-443 כדי לקבל תנועת HTTP ו-HTTPS בהתאמה, צריך ליצור שני משאבי Gateway. מגדירים משאב Gateway אחד עם יציאה 80 לתעבורת HTTP, ומשאב אחר עם יציאה 443 לתעבורת HTTPS. נותנים לשדה scope בכל אחת מהן את אותו ערך. שירות Cloud Service Mesh ממזג באופן דינמי את ההגדרות הנפרדות של כל שער שמוגדר באותו היקף. בצד מישור הנתונים, שרתי ה-proxy של Envoy שפועלים במצב שער כניסה חייבים גם להציג את אותו פרמטר היקף ל-Cloud Service Mesh כדי לקבל את התצורה Gateway. שימו לב: מציינים את ההיקף כשיוצרים את משאב Gateway, ומציינים את אותו היקף כפרמטר bootstrap עבור ה-proxies.

אלה שיקולים חשובים לגבי המשאב Gateway:

• חובה לציין את פרמטר ההיקף Gateway. צריך לציין את ההיקף במשאב Gateway ובקובץ ההגדרה של Envoy proxies, גם אם קיים רק Gateway אחד.
• יצירת משאב Gateway לא פורסת שירות עם שרת proxy של Envoy. פריסת ה-Envoy proxy היא שלב נפרד.
• למשאב Gateway יש type שמייצג את סוג הפריסה של הכניסה. השדה הזה שמור לשימוש בעתיד. הערך הנתמך היחיד כרגע הוא OPEN_MESH, שהוא ערך ברירת המחדל ואי אפשר לשנות אותו.

פריסות של רשתות עם פרוטוקולים מעורבים ומישורי נתונים

אפשר להשתמש בפריסת מישור נתונים מעורבת, עם Envoy proxy ו-gRPC ללא proxy באותה רשת. כשיוצרים פריסות כאלה, כדאי לקחת בחשבון את הנקודות הבאות.

• פריסות של Envoy sidecar תומכות בכל המסלולים (HTTPRoute,‏ GRPCRoute,‏ TCPRoute ו-TLSRoute).
• פריסות gRPC ללא proxy תומכות רק ב-GRPCRoute.
• GRPCRoute מוגבלת לתכונות שנתמכות רק בפריסות של gRPC ללא proxy.

טופולוגיות נתמכות בסביבות VPC משותף מרובות פרויקטים

ב-Cloud Service Mesh אפשר להוסיף משאבי Route שמוגדרים בפרויקטים אחרים למשאב Mesh או למשאב Gateway שמוגדר בפרויקט ניהול מרכזי. בעלי שירותים מורשים יכולים להוסיף ישירות את הגדרות ניתוב השירות שלהם אל Mesh או אל Gateway.

בתרחיש טיפוסי של שימוש בכמה פרויקטים, בוחרים פרויקט (פרויקט מארח או פרויקט ניהול מרכזי) כפרויקט הניהול של רשת ה-mesh, שבו יוצרים משאב Mesh. בעלי הפרויקט לניהול הרשת מאשרים למשאבי Route מפרויקטים אחרים להפנות למשאב Mesh, וכך מאפשרים להגדרת הניתוב מפרויקטים אחרים להיות חלק מהרשת. מישור נתונים של רשת Mesh, בין אם מדובר ב-Envoy או ב-gRPC, שולח בקשה להגדרה מפרויקט הניהול ומקבל איחוד של כל המסלולים שמצורפים ל-Mesh. ב-Gateway, המסלולים מאוחדים גם בכל Gateways שמשתמשים באותו היקף.

פרויקט הניהול Mesh יכול להיות כל פרויקט שתבחרו, וההגדרה תפעל כל עוד יש קישוריות לרשת VPC בפרויקטים הבסיסיים, באמצעות VPC משותף או קישור (peering) בין רשתות VPC שכנות.

הרשאות ותפקידים ב-IAM

אלה הרשאות ה-IAM שנדרשות כדי לקבל, ליצור, לעדכן, למחוק, להציג ולהשתמש במשאבים Mesh ו-Route בצורה מאובטחת.

• לאדמינים ב-Mesh צריכות להיות הרשאות networkservices.mesh.*.
• לאדמינים של שערים צריכות להיות הרשאות networkservices.gateways.*.
• לבעלי השירותים צריכות להיות הרשאות networkservices.grpcRoutes.*, networkservices.httpRoutes.* או networkservices.tcpRoutes.*.

מנהלי רשת צריכים להעניק את ההרשאה networkservices.mesh.use לבעלי שירותים כדי שהם יוכלו לצרף את המשאבים Route שלהם למשאב Mesh. אותו מודל חל על משאבי Gateway.

כדי לראות את כל ההרשאות ב-IAM למשאבי Mesh, עוברים אל דף העזר בנושא הרשאות IAM ומחפשים את meshes.

אין צורך בתפקידים מוגדרים מראש נוספים. לתפקיד הקיים והמוגדר מראש אדמין רשת Compute (roles/compute.networkAdmin) יש הרשאות networkservices.* כברירת מחדל. יכול להיות שתצטרכו להוסיף את ההרשאות שתיארנו קודם לתפקידים המותאמים אישית.

הערות ומגבלות

• מסוף Google Cloud לא תומך בממשקי ה-API של ניתוב השירות.
• משתמשים בגרסה 3 של xDS API או בגרסה מתקדמת יותר.
  • גרסת Envoy מינימלית של 1.20.0 (כי ממשקי ה-API של ניתוב השירות נתמכים רק בגרסת xDS‏ 3)
  • הגרסה המינימלית של מחולל האתחול של gRPC היא v0.14.0
• המשאב TLSRoute נתמך רק בשרתי Proxy של Envoy שנפרסים כשרתי Proxy מסוג sidecar או כשערים.
• יש תמיכה רק במכונות וירטואליות של Compute Engine עם פריסה אוטומטית של Envoy וב-Pods של GKE עם הזרקה אוטומטית של Envoy. אי אפשר להשתמש בפריסה ידנית עם ממשקי API לניתוב שירותים.
• ממשקי ה-API לניתוב שירותים לא תואמים לגרסאות קודמות של ממשקי ה-API.
• כשמשאב TCPRoute מצורף למשאב Mesh, אי אפשר להשתמש ביציאה שמשמשת להתאמת תנועת TCP כדי להציג משהו אחר מלבד התנועה שמתוארת בTCPRoute הזה.
  • לדוגמה, יכול להיות שהפריסות שלכם כוללות משאב TCPRoute שתואם ליציאה '8000' ומשאב HttpRoute. אם שני כללי התנועה האלה מצורפים לאותו משאב Mesh, התנועה שמנותבת על ידי משאב HTTPRoute לא יכולה להשתמש ביציאה 8000, גם אם כתובות ה-IP הבסיסיות שונות. המגבלה הזו נובעת מההטמעה של Envoy proxy, שקובעת עדיפות קודם לנתיב שתואם ליציאה.
• המשאב Gateway לא מקצה מאזן עומסים מנוהל ולא יוצר באופן דינמי שירות Envoy.
• ל-Envoys שנפרסו אוטומטית ומשמשים כשערי כניסה לא יכול להיות הארגומנט serving_ports לדגל --service-proxy.
• פריסת Envoy באופן אוטומטי לא תומכת באפשרות לספק מספר פרויקט ששונה מהפרויקט של מכונת ה-VM.

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

• במאמר רשימת משאבי Route מוסבר איך מציגים רשימה של משאבי נתיבים שמשויכים למשאב Mesh או למשאב Gateway.
• מידע על ממשקי ה-API של ניתוב שירותים זמין במסמכי התיעוד של ממשקי ה-API של שירותי רשת.