שילוב של Cloud Service Mesh עם Service Directory

במאמר הזה מוסבר איך להשתמש במרשם השירותים של Service Directory עם Cloud Service Mesh, כדי ש-Cloud Service Mesh יוכל לנתב תעבורה לשירותים שרשומים ב-Service Directory ולהחיל עליהם מדיניות תעבורה. המאמר הזה מיועד למפתחים של Cloud Service Mesh שרוצים לשלב את האפליקציות שלהם בשירותים אחרים ב- Google Cloud.

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

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

כשמשתמשים במרשם השירותים של Service Directory עם Cloud Service Mesh, השילוב מאפשר לאפליקציות ברשת ולשערי הכניסה שהוגדרו על ידי Cloud Service Mesh לגשת לשירותים במרשם השירותים. השילוב של Cloud Service Mesh עם Service Directory נתמך, עם Envoy ועם gRPC ללא proxy, לשילובים של Service Directory עם מאזני עומסים פנימיים של רשתות (NLB) עם העברת נתונים, מאזני עומסים פנימיים של אפליקציות (ALB) ו-Private Service Connect‏ (PSC) בשכבה 4.

כדי לשלב את השירותים, רושמים שירות ב-Service Directory ואז מקשרים את השירות לשירות לקצה העורפי של Cloud Service Mesh. אחרי שנוצרת הצמדה, Cloud Service Mesh שולח שאילתה ל-Service Directory כדי לקבל מידע על השירות הרשום ועל האופן שבו אפשר להגיע לשירות הזה. ב-Cloud Service Mesh אפשר גם לעקוב אחרי שינויים בשירות. השילוב מאפשר ל-Service mesh ולשער בניהול עצמי לשלוח תעבורת נתונים לשירותים האלה. הוא גם מאפשר לאכוף מדיניות – לדוגמה, מדיניות מתקדמת לניהול תעבורת נתונים – שמוגדרת ב-Cloud Service Mesh.

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

כששירות רשום ב-Service Directory, לא צריך להגדיר קבוצות של מופעים או סוגים שונים של קבוצות נקודות קצה ברשת (NEGs) כדי לקבל גישה לשירותים שאתם צריכים. אתם יכולים לרשום באופן אוטומטי את Google Kubernetes Engine, מאזני עומסים פנימיים ו-Private Service Connect ב-Service Directory, וכך לפשט עוד יותר את הגישה של Cloud Service Mesh לשירותים האלה.

משאבים שמשמשים את השילוב

השילוב בין Cloud Service Mesh לבין Service Directory משתמש במשאבים הבאים.

שירותים של Service Directory

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

כבילות שירות

כבילת שירות היא משאב שכולל את שם הדומיין שמוגדר במלואו (FQDN) של שירות Service Directory. לדוגמה, projects/test-proj/locations/us-east1/namespaces/test-namespace/services/test-service הוא FQDN של שירות Service Directory.

שירותים לקצה העורפי

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

שירות קצה עורפי יכול לכלול כמה קישורי שירות. ההגדרה הזו שימושית במצב שבו יש פריסות אזוריות של אותה אפליקציה. יכול להיות שתירשמו כל פריסה אזורית למופע אזורי של ספריית השירותים, כשירות אזורי 1 ושירות אזורי 2. אחר כך אפשר לשייך כל אחד מהשירותים האזוריים של Service Directory לאותו שירות קצה עורפי, באמצעות שני קישורי שירות. כבילת שירות גלובלית 1 תשויך לשירות אזורי 1 באזור א', וכבילת שירות גלובלית 2 תשויך לשירות אזורי 2 באזור ב'.

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

שילוב הפריסה של Cloud Service Mesh עם Service Directory מאפשר תרחישי שימוש חדשים שמועילים כשמסתמכים על שירותים שבבעלות צוותים או ארגונים אחרים או שפורסמו על ידם.

הפיכת שירותים קיימים לזמינים ב-Cloud Service Mesh

‫Service Directory משתלב עם Google Cloud מוצרים כמו GKE, מאזני עומסים פנימיים של רשתות להעברת סיגנל ללא שינוי ומאזני עומסים פנימיים של אפליקציות. כשספקי שירותים יוצרים שירות GKE או מאזן עומסים, הם יכולים לרשום אותו בספריית השירותים.

אחרי שרושמים שירות ב-Service Directory, אפשר להגדיר את Cloud Service Mesh כך שיתקשר עם השירות הזה. לקוחות Cloud Service Mesh יכולים לתקשר עם שירותים שפועלים מאחורי מאזני עומסים פנימיים מסוג Network Load Balancer ומאזני עומסים פנימיים מסוג Application Load Balancer.

שיפור התיאום בין יצרני השירותים לצרכני השירותים

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

כשמשתמשים ב-Service Directory, צוות אחד (הבעלים) רושם שירות שהוא רוצה להפוך לזמין לצוותים או לארגונים אחרים (הצרכנים). הבעלים של השירות המנוהל משתף הפניה לשירות הזה עם צרכן. הצרכן יכול להשתמש בהפניה הזו כדי לחפש את השירות של הבעלים בספריית השירותים ולגלות את נקודות הקצה של השירות. לדוגמה, נקודת הקצה יכולה להיות כתובת IP וירטואלית (VIP) שהשירות של היצרן מצפה לקבל אליה תנועה.

השילוב של Cloud Service Mesh עם Service Directory מאפשר לכם להפוך את התהליך לאוטומטי על ידי קישור שירות של Service Directory לשירות קצה עורפי של Cloud Service Mesh. יש לכך את היתרונות הבאים:

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

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

  • מצרפים את השירות, Payments, לפי שם.

  • ‫Cloud Service Mesh משתף מידע על השירות Payments עם הלקוחות שלו.

    • לדוגמה, פרוקסי מסוג sidecar שפועלים ב-Service mesh שלכם יודעים עכשיו את נקודת הקצה (לדוגמה, 10.0.0.1:80) שדרכה אפשר להגיע לשירות.

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

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

גישה לשירותים בתוך גבולות הגזרה באמצעות נקודת כניסה

צוות יכול לקבץ אוסף של שירותים בגבולות גזרה של VPC Service Controls ולחשוף את השירותים האלה דרך נקודת כניסה יחידה. אפשר לרשום את נקודת הכניסה הזו בספריית השירותים ולהפוך אותה לזמינה למשתמשים שרוצים לגשת לשירותים בתוך גבולות הגזרה. מידע נוסף על גבולות גזרה לשירות ב-VPC Service Controls זמין במאמר פרטים והגדרה של גבולות גזרה לשירות.

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

חיבור שירותים בדומיינים שונים

יכול להיות שיש לכם שירותים בדומיינים שונים שאתם צריכים לקשר ביניהם.

קישור שירותים בין ארגונים

יכול להיות שתרצו גישה לשירותים בבעלות של ארגון אחר, כמו Google APIs (לדוגמה, Cloud SQL) או שירותים מנוהלים של צד שלישי.

‫Service Directory תומך ב-Private Service Connect. כשיוצרים נקודת קצה מסוג Private Service Connect ברשת, אפשר לרשום את נקודת הקצה כשירות ב-Service Directory. אחר כך אפשר לצרף את השירות הזה ל-Cloud Service Mesh, כדי שלקוחות mesh, כמו לקוחות Envoy ו-gRPC, ושערים בניהול עצמי, כמו Apigee, יוכלו להפעיל את השירותים האלה.

שימוש ב-Service Directory לגילוי שירותים באמצעות Private Service Connect.
שימוש ב-Service Directory לגילוי שירותים באמצעות Private Service Connect (לחצו כדי להגדיל)

בדוגמה הקודמת, שבה נעשה שימוש ב-Cloud Storage, אפשר לראות איך אפשר להשתמש ב-Private Service Connect כדי לבצע קריאות ל-Google APIs באמצעות נקודת קצה (endpoint) ברשת Virtual Private Cloud.

חיבור שירותים ברשתות VPC

חברות מסוימות משתמשות בכמה רשתות VPC כחלק מהפריסה שלGoogle Cloud . במקרים כאלה, יכול להיות ששירות ברשת VPC אחת יצטרך לגשת לשירות ברשת VPC אחרת. אפשר להגדיר קישור בין רשתות VPC שכנות (peering) כדי לגשת לשירות ברשת VPC אחרת, אבל ההגדרה הזו יוצרת סיבוכים אם יש טווחי כתובות IP חופפים בין הרשתות המקושרות.

‫Private Service Connect מאפשר גישה מאובטחת ופרטית לשירות ברשת VPC אחת משירותים ברשת VPC אחרת, באמצעות נקודת קצה אחת של IP:port.

תצוגה מפורטת של שימוש ב-Service Directory לגילוי שירותים באמצעות Private Service Connect.
תצוגה מפורטת של שימוש ב-Service Directory לגילוי שירותים עם Private Service Connect (לחצו כדי להגדיל)

דוגמאות נוספות בדומיינים שונים

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

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

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

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

דוגמאות:

  • פיצול תעבורה לפי משקל – לדוגמה, בין שני שירותים של Service Directory
  • שיקוף תעבורה – לדוגמה, לשירות ביקורת
בקשות לשירות `users` משוכפלות לשירות `audit`
בקשות לשירות users משוכפלות לשירות audit (לחצו כדי להגדיל)

תמיכה ב-Cloud Service Mesh ובלקוחות קיימים

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

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

מגבלות

ב-Cloud Service Mesh אין תמיכה ב-FQDN NEGs (INTERNET_FQDN_PORT NEGs) בשילוב עם Service Directory.

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