סקירה כללית של מיפוי כללי ניתוב

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

מפת כללי הניתוב מורכבת מהרכיבים הבאים:

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

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

אם כלל העברה מפנה לשרת proxy של יעד gRPC עם השדה validateForProxyless שמוגדר לערך TRUE, כתובת ה-IP שלו צריכה להיות 0.0.0.0. כשמגדירים את validateForProxyless לערך TRUE, המערכת דוחה הגדרות שמציינות כתובת IP שונה מ-0.0.0.0.

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

סוגי פרוקסי יעד נתמכים

‫Cloud Service Mesh תומך בסוגים הבאים של שרתי proxy ליעד:

  • שרת proxy של HTTP ליעד, שמוגדר כשלקוחות ושרתים שולחים או מקבלים תנועת HTTP או HTTP/2.
  • שרת proxy של יעד HTTPS, שמגדירים אותו כשהלקוחות והשרתים שולחים או מקבלים תעבורת נתונים מסוג HTTPS. הפעולה הזו נדרשת כשמגדירים אבטחת שירות באמצעות שרתי proxy של Envoy.
  • שרת proxy של TCP ביעד, שמוגדר כשלקוחות ושרתים שולחים או מקבלים תנועת TCP.
  • Target gRPC proxy, שמוגדר כשלקוחות ושרתים שולחים או מקבלים תנועת gRPC. פרוקסי יעד של gRPC מכילים את השדה validateForProxyless, שמוגדר לערך TRUE כשפורסים שירותי gRPC ללא פרוקסי.

ניתוב תעבורת נתונים באמצעות שרתי proxy מסוג Envoy sidecar

כשמשתמשים ב-Cloud Service Mesh עם שרתי proxy מסוג Envoy sidecar, בקשות של לקוחות מנותבות באופן הבא:

  • מערך הרשת מיירט את הבקשה ומפנה אותה ל-proxy מסוג Envoy קובץ עזר חיצוני.
  • שרת ה-proxy של Envoy sidecar בודק את כתובת ה-IP והיציאה של הבקשה.
  • הזוג של כתובת ה-IP והיציאה נבדק מול כתובת ה-IP והיציאה שצוינו בכל כללי ההעברה שבהם סכמת איזון העומסים מוגדרת ל-INTERNAL_SELF_MANAGED.
  • אם נמצא כלל העברה עם כתובת IP ויציאה תואמות, Envoy בודק את שרת ה-proxy של יעד ה-HTTP או את שרת ה-proxy של יעד ה-gRPC שאליהם כלל ההעברה מפנה.
  • ‫Envoy בודק את מפת ה-URL שאליה מתייחס שרת ה-proxy של היעד.
  • ‫Envoy מנתב את הבקשה בהתאם לכללים שצוינו במפת ה-URL.

מידע על ניתוב תעבורה באמצעות שרת proxy של TCP ליעד זמין במאמר בנושא ניתוב תעבורת TCP באמצעות Cloud Service Mesh.

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

ההתנהגות הזו שונה באפליקציות gRPC ללא שרת proxy. כשמגדירים לקוח gRPC, מציינים את מזהה המשאבים האחיד (URI) של שירות היעד שהלקוח צריך ליצור איתו קשר. מזהה ה-URI הזה משתמש בסכימת פותר השמות xds ובפורמט hostname:port – לדוגמה, xds:///example.hostname:8080.

כשלקוח gRPC בלי שרת Proxy מתחבר ל-Cloud Service Mesh,‏ Cloud Service Mesh שולח לו מידע שמתאים לשירות באופן הבא:

  • ‫Cloud Service Mesh מחפש כללי העברה עם סכמת איזון העומסים שמוגדרת ל-INTERNAL_SELF_MANAGED כדי למצוא כללי העברה שהיציאה שלהם תואמת ליציאה שצוינה ב-URI של היעד.
  • ‫Cloud Service Mesh מוצא את שרת ה-proxy של gRPC או את שרת ה-proxy של HTTP עבור כל אחד מהכללים האלה להעברת תנועה.
  • ‫Cloud Service Mesh מוצא את מיפויי כתובות ה-URL שאליהם מתייחסים פרוקסי היעד של gRPC או פרוקסי היעד של HTTP.
  • ‫Cloud Service Mesh בודק את כללי המארח במפת URL, שגם הם בפורמט hostname[:port], ומחפש התאמה.
  • כשנמצאת התאמה, Cloud Service Mesh מחזיר כללי ניתוב ופרטי שירות ללקוח gRPC.

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

  • אותו שם מארח משמש בכמה מיפויים של כתובות URL.
  • כמה כללי העברה עם תוכנית איזון העומסים INTERNAL_SELF_MANAGED מציינים את אותה יציאה.

לכן, מומלץ לא להשתמש באותו שם מארח בכמה מיפויי כתובות URL שאליהם מפנים כללי העברה שמציינים את אותה יציאה.

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