זיהוי שירותים

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

‫Cloud Service Mesh מנטר את השירותים האלה כדי לשתף עם הלקוחות שלו מידע עדכני על בדיקות תקינות. לכן, כשמשתמשים באחד מהלקוחות של Cloud Service Mesh (כמו Envoy sidecar proxy או אפליקציית gRPC ללא proxy) כדי לשלוח בקשה, הלקוח נהנה ממידע עדכני על השירותים.

בהקשר של Cloud Service Mesh, לקוח הוא קוד אפליקציה שפועל במכונה וירטואלית או בקונטיינר, ומנסח בקשות לשליחה לשרת. שרת הוא קוד אפליקציה שמקבל בקשות כאלה. לקוח Cloud Service Mesh הוא לקוח Envoy,‏ gRPC או xDS אחר שמחובר ל-Cloud Service Mesh ושייך למישור הנתונים.

במישור הנתונים, Envoy או gRPC מבצעים את הפעולות הבאות:

  1. הוא בודק בקשה ומתאים אותה לשירות לקצה העורפי, משאב שאתם מגדירים במהלך הפריסה.
  2. אחרי שהבקשה תואמת, Envoy או gRPC מחילים את כל מדיניות התנועה או האבטחה שהוגדרה קודם, בוחרים קצה עורפי או נקודת קצה ומפנים את הבקשה לקצה העורפי או לנקודת הקצה האלה.

זיהוי שירותים

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

לדוגמה:

  • יש לכם מכונה וירטואלית שמריצה את האפליקציה. למכונה הווירטואלית הזו יש שרת proxy מסוג Envoy קובץ עזר חיצוני שמחובר ל-Cloud Service Mesh ומטפל בבקשות יוצאות בשם האפליקציה.
  • הגדרתם שירות קצה עורפי בשם payments. לשירות לקצה העורפי הזה יש שני בק-אנדים של קבוצת נקודות קצה ברשת (NEG) שמפנים למופעי קונטיינר שונים שמריצים את הקוד של שירות payments.
  • הגדרתם משאב Mesh שמגדיר רשת בשם sidecar-mesh.
  • הגדרתם משאב Route שמגדיר את יעדי התנועה לשירות הקצה העורפי payments ולשם המארח helloworld-gce.

בהגדרה הזו, כשהאפליקציה (במכונה הווירטואלית) שולחת בקשת HTTP אל payments.example.com, לקוח Cloud Service Mesh יודע שהבקשה הזו מיועדת לשירות payments.

כשמשתמשים ב-Cloud Service Mesh עם שירותי gRPC ללא proxy, גילוי השירות פועל באופן דומה. עם זאת, ספריית gRPC שפועלת כלקוח של Cloud Service Mesh מקבלת רק מידע על השירותים שציינתם עבורם רכיב xDS resolver. כברירת מחדל, Envoy מקבל מידע על כל השירותים שהוגדרו ברשת של הענן הווירטואלי הפרטי (VPC) שצוינה בקובץ האתחול של Envoy.

גילוי נקודות קצה

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

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

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

מעבר להוספת נקודות קצה לקבוצות של מכונות מנוהלות (MIG) או לקבוצות של נקודות קצה ברשת (NEG) ולהגדרת Cloud Service Mesh, לא נדרשת הגדרה נוספת כדי להפעיל את גילוי השירותים באמצעות Cloud Service Mesh.

יירוט תעבורת נתונים של שרת proxy מסוג Sidecar ב-Cloud Service Mesh

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

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

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