סקירה כללית על ממשקי 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 להתחבר לרשתות שונות באמצעות קישור בין רשתות שכנות (peering) של VPC.

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

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

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

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

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

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

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

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

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

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

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

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

יירוט תנועה

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

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

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

משאב Mesh

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

Mesh

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

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

• ‫Envoy פועל לצד האפליקציה כשרתי proxy של קובץ עזר חיצוני
• לקוחות 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, לבין משאב שירות לקצה העורפי וה-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 שנפרסו כשירות Ingress והוגדרו על ידי המשאב Gateway. בדוגמה הזו, שרתי ה-proxy של Envoy מוגדרים להאזין ביציאה 80 לחיבורים נכנסים מלקוחות.

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

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

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

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

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

• חובה לציין את פרמטר ההיקף Gateway. צריך לציין את ההיקף במשאב Gateway וגם בהגדרת ה-bootstrap של שרתי ה-proxy של Envoy, גם אם קיים רק Gateway אחד.
• יצירת משאב Gateway לא פורסת שירות עם שרת proxy של Envoy. פריסת ה-Envoy proxy היא שלב נפרד.
• למשאב Gateway יש type שמייצג את סוג הפריסה של Ingress. השדה הזה שמור לשימוש בעתיד. הערך הנתמך היחיד כרגע הוא 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. בעלי הפרויקט לניהול הרשת מאשרים למשאבי Route מפרויקטים אחרים להפנות למשאב Mesh, וכך מאפשרים להגדרות הניתוב מפרויקטים אחרים להיות חלק מהרשת. מישור נתונים של רשת Mesh, בין אם מדובר ב-Envoy או ב-gRPC, שולח בקשה להגדרה מפרויקט הניהול ומקבל איחוד של כל המסלולים שמצורפים ל-Mesh. ב-Gateway, המסלולים מאוחדים גם בכל Gateways שמשתמשים באותו היקף.

פרויקט הניהול Mesh יכול להיות כל פרויקט שתבחרו, וההגדרה תפעל כל עוד יש קישוריות לרשת VPC בפרויקטים הבסיסיים, באמצעות VPC משותף או קישור בין רשתות 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 של ניתוב השירות.
• משתמשים ב-xDS API גרסה 3 ואילך.
  • גרסת Envoy מינימלית של 1.20.0 (כי ממשקי ה-API של ניתוב השירות נתמכים רק בגרסה 3 של xDS)
  • הגרסה המינימלית של מחולל האתחול של 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. אם שתי כתובות ה-IP מחוברות לאותו משאב Mesh, התעבורה שמנותבת על ידי משאב HTTPRoute לא יכולה להשתמש ביציאה 8000, גם אם כתובות ה-IP הבסיסיות שונות. ההגבלה הזו נובעת מההטמעה של Envoy proxy, שקודם מקצה עדיפות לנתיב שתואם ליציאה.
• המשאב Gateway לא מקצה מאזן עומסים מנוהל ולא יוצר באופן דינמי שירות Envoy.
• ל-Envoys שנפרסו אוטומטית ומשמשים כשערי כניסה לא יכול להיות הארגומנט serving_ports לדגל --service-proxy.
• פריסת Envoy באופן אוטומטי לא תומכת באספקת מספר פרויקט ששונה מהפרויקט של מכונת ה-VM.

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

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