פענוח של שמות DNS

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

במאמר הזה מוסבר הקשר בין כתובת ה-IP הווירטואלית של כלל העברה לבין האופן שבו כלל ההעברה משויך לשירות. בנוסף, במאמר מוסבר איך לתכנן ולהגדיר DNS לתקשורת בין שירותים ברשת שירותים של Cloud Service Mesh.

לדוגמה, נניח שיש שלושה שירותים, service-a, service-b ו-service-c, שמתקשרים ביניהם. מפתחים משתמשים לעיתים קרובות בשמות דומיין מלאים בקוד שלהם לצורך תקשורת בין שירותים. אם שם הדומיין הוא example.com, יכול להיות שהשלושה שירותים ייוצגו כך:

• service-a.example.com
• service-b.example.com
• service-c.example.com

כשמגדירים משאבים של Cloud Service Mesh כדי ליצור רשת שירותים, מגדירים כלל העברה לכל אחד מהשירותים. כלל העברה מייצג את הצמד IP:Port של שירות היעד. כדי שתעבורת נתונים יוצאת (egress) תייורט על ידי פרוקסי קובץ עזר חיצוני Envoy, כתובת ה-IP של היעד צריכה להיות זהה לכתובת ה-IP שמשויכת לכלל ההעברה. לכן, צריך להקצות כתובת IP לכל שירות. לדוגמה:

• ל-service-a.example.com יש כתובת IP‏ 10.0.0.100
• ל-service-b.example.com יש כתובת IP‏ 10.0.0.101
• ל-service-c.example.com יש כתובת IP‏ 10.0.0.102

ההגדרה התואמת של Cloud Service Mesh כוללת שלושה כללי העברה, FR1,‏ FR2 ו-FR3, שכל אחד מהם משתמש ביציאה 80:

• ל-FR1 יש כתובת IP‏ 10.0.0.100:80 שמשויכת ל-service-a.example.com.
• ל-FR2 יש כתובת IP‏ 10.0.0.101:80 שמשויכת ל-service-b.example.com.
• ל-FR3 יש כתובת IP‏ 10.0.0.102:80 שמשויכת ל-service-c.example.com.

כש-service-a מפעיל את service-b באמצעות שם הדומיין שמוגדר במלואו (FQDN) service-b.example.com, קורים שלושה דברים:

1. ‫service-a מבצע קודם חיפוש DNS עבור service-b.example.com כדי לזהות את כתובת ה-IP של service-b.
2. הדומיין מפוענח ל-10.0.0.101 כדי שיתאים לכתובת ה-IP המוגדרת של כלל ההעברה של service-b.
3. שרת ה-proxy של Envoy יכול עכשיו ליירט תנועה ולנתב אותה לשירות הקצה העורפי שיש לו קצה עורפי של service-b, בין אם אלה NEGs או MIGs.

אתם יכולים להגדיר תחום פרטי מנוהל ב-Cloud DNS כדי לארח את רשומות המשאבים של השירותים שלכם.