Cloud Service Mesh עם קבוצות של נקודות קצה ברשת לקישוריות היברידית

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

אתם מגדירים את Cloud Service Mesh כך שרשת השירות תוכל לשלוח תנועה לנקודות קצה שנמצאות מחוץ ל- Google Cloud. נקודות הקצה האלה כוללות את:

  • מאזני עומסים מקומיים.
  • אפליקציות שרת במכונה וירטואלית (VM) בענן אחר.
  • כל יעד אחר שאפשר להגיע אליו באמצעות קישוריות היברידית, ואפשר להגיע אליו באמצעות כתובת IP ויציאה.

מוסיפים את כתובת ה-IP והיציאה של כל נקודת קצה לקבוצת נקודות קצה (NEG) של רשת קישוריות היברידית. קבוצות NEG עם קישוריות היברידית הן מסוג NON_GCP_PRIVATE_IP_PORT.

התמיכה של Cloud Service Mesh בשירותים מקומיים ובשירותי מולטי-קלאוד מאפשרת לכם:

  • ניתוב תעבורה באופן גלובלי, כולל לנקודות הקצה של שירותים מקומיים ושירותי מולטי-קלאוד.
  • ליהנות מהיתרונות של Cloud Service Mesh ו-service mesh – כולל יכולות כמו גילוי שירותים וניהול מתקדם של תעבורת נתונים – בשירותים שפועלים בתשתית הקיימת שלכם מחוץ ל- Google Cloud.
  • אפשר לשלב את היכולות של Cloud Service Mesh עם Cloud Load Balancing כדי להביא שירותי רשת לסביבות מרובות. Google Cloud

אין תמיכה ב-NEGs של קישוריות היברידית (NON_GCP_PRIVATE_IP_PORT NEGs) בלקוחות gRPC ללא proxy.

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

בעזרת Cloud Service Mesh אפשר להגדיר רישות בין שירותים מבוססי מכונות וירטואליות לבין שירותים מבוססי קונטיינרים בסביבות שונות, כולל:

  • Google Cloud
  • מרכזי נתונים מקומיים
  • עננים ציבוריים אחרים

העברת תעבורה של רשתות וירטואליות למיקום מקומי או לענן אחר

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

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

בתרשים שלמעלה, כשהאפליקציה שולחת בקשה לשירות on-prem, הלקוח של Cloud Service Mesh בודק את הבקשה היוצאת ומעדכן את היעד שלה. יעד הבקשה מוגדר לנקודת קצה שמשויכת לשירות on-prem (במקרה הזה, 10.2.0.1). לאחר מכן הבקשה עוברת דרך Cloud VPN או Cloud Interconnect ליעד המיועד שלה.

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

העברה של שירות מקומי קיים אל Google Cloud

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

מעבר ממיקום מקומי אל Google Cloud.
מעבר ממיקום מקומי אל Google Cloud (לחצו כדי להגדיל)

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

פיצול התנועה מאפשר לכם להתחיל בשליחת 0% מהתנועה לשירות cloud ו-100% לשירות on-prem. לאחר מכן, אפשר להגדיל בהדרגה את שיעור התנועה שנשלחת לשירות cloud. בסופו של דבר, אתם שולחים 100% מהתנועה לשירות cloud, ואז אפשר להוציא את שירות on-prem משימוש.

Google Cloud שירותי קצה רשת לפריסות מקומיות ולפריסות מרובות עננים (multi-cloud)

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

פריסות שמתפרסות על פני כמה סביבות.
פריסות שמתפרסות על פני כמה סביבות (לחצו כדי להגדיל)

בתרשים שלמעלה, תעבורת נתונים מלקוחות באינטרנט הציבורי נכנסת לרשת שלGoogle Cloudממאזן עומסים של Google Cloud , כמו מאזן עומסים של אפליקציות (ALB) גלובלי חיצוני שלנו. כשהתנועה מגיעה למאזן העומסים, אפשר להחיל שירותים בקצה הרשת, כמו הגנה מפני DDoS ב-Cloud Armor או אימות משתמשים באמצעות שרת proxy לאימות זהויות (IAP). מידע נוסף זמין במאמר בנושא שירותי קצה רשת לפריסות מרובות סביבות.

אחרי שמחילים את השירותים האלה, התנועה עוצרת לרגע ב-Google Cloud, שם אפליקציה או שרת proxy עצמאי (שהוגדר על ידי Cloud Service Mesh) מעבירים את התנועה דרך Cloud VPN או Cloud Interconnect לשירות המקומי.

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

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

בתרשים הבא מוצגים המשאבים שמאפשרים תמיכה בשירותים מקומיים ובשירותי מרובה עננים (multi-cloud) ב-Cloud Service Mesh. Google Cloud משאב המפתח הוא ה-NEG ונקודות הקצה ברשת שלו. המשאבים האחרים הם המשאבים שאתם מגדירים כחלק מההגדרה הרגילה של Cloud Service Mesh. לצורך פשטות, בדיאגרמה לא מוצגות אפשרויות כמו כמה שירותי קצה עורפי גלובליים.

משאבי Compute Engine לשירותים מקומיים ולשירותים מרובי עננים.
משאבי Compute Engine לשירותים מקומיים ולשירותי מולטי-ענן (לחצו כדי להגדיל)

כשמגדירים את Cloud Service Mesh, משתמשים במשאב של global backend services API כדי ליצור שירותים. שירות הוא מבנה לוגי שמשלב את הרכיבים הבאים:

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

שירותים מקומיים ושירותים מרובי עננים הם כמו כל שירות אחר שמוגדר ב-Cloud Service Mesh. ההבדל העיקרי הוא שמשתמשים ב-NEG עם קישוריות היברידית כדי להגדיר את נקודות הקצה של השירותים האלה. ה-NEGs האלה מוגדרים עם סוג נקודת הקצה ברשת NON_GCP_PRIVATE_IP_PORT. נקודות הקצה שמוסיפים ל-NEGs של קישוריות היברידית צריכות להיות שילובים תקפים של IP:port שאליהם הלקוחות יכולים להגיע – למשל, באמצעות קישוריות היברידית כמו Cloud VPN או Cloud Interconnect.

לכל NEG יש סוג של נקודת קצה ברשת, והוא יכול להכיל רק נקודות קצה ברשת מאותו סוג. הסוג הזה קובע את הפרטים הבאים:

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

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

  • מגדירים את סוג נקודת הקצה ברשת ל-NON_GCP_PRIVATE_IP_PORT. הנתון הזה מייצג כתובת IP שאפשר להגיע אליה. אם כתובת ה-IP הזו היא מקומית או נמצאת אצל ספק שירותי ענן אחר, צריך לוודא שאפשר להגיע אליה מ- Google Cloud באמצעות קישוריות היברידית, כמו הקישוריות שמסופקת על ידי Cloud VPN או Cloud Interconnect.
  • מגדירים Google Cloud אזור שממזער את המרחק הגיאוגרפי בין Google Cloud לבין הסביבה המקומית או סביבת מרובה עננים. לדוגמה, אם אתם מארחים שירות בסביבה מקומית בפרנקפורט, גרמניה, אתם יכולים לציין את אזור europe-west3-a Google Cloud כשאתם יוצרים את ה-NEG.

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

שיקולים לגבי קישוריות ורשת

הלקוחות של Cloud Service Mesh, כמו שרתי proxy של Envoy, צריכים להיות מסוגלים להתחבר ל-Cloud Service Mesh בכתובת trafficdirector.googleapis.com:443. אם החיבור למישור הבקרה של Cloud Service Mesh אבד, יקרו הדברים הבאים:

  • לקוחות קיימים של Cloud Service Mesh לא יכולים לקבל עדכוני הגדרה מ-Cloud Service Mesh. הם ימשיכו לפעול על סמך ההגדרות הנוכחיות שלהם.
  • לקוחות חדשים של Cloud Service Mesh לא יכולים להתחבר ל-Cloud Service Mesh. הם לא יכולים להשתמש ב-service mesh עד שהקישוריות תתחדש.

אם רוצים לשלוח תנועה בין סביבות Google Cloud לבין סביבות מקומיות או סביבות מרובות עננים (multi-cloud), צריך לחבר את הסביבות באמצעות קישוריות היברידית. Google Cloud מומלץ להשתמש בחיבור בזמינות גבוהה שמופעל על ידי Cloud VPN או Cloud Interconnect.

כתובות IP ותחומי כתובות IP של רשתות משנה, של שרתים מקומיים ושל עננים אחרים לא יכולים להיות חופפים. Google Cloud

מגבלות ודברים נוספים שכדאי לזכור

אלה המגבלות של שימוש ב-NEGs של קישוריות היברידית.

הגדרה proxyBind

אפשר להגדיר את הערך של proxyBind רק כשיוצרים targetHttpProxy. אי אפשר לעדכן targetHttpProxy קיים.

קישוריות ושיבושים בקישוריות

פרטים על דרישות הקישוריות והמגבלות מופיעים בקטע שיקולים לגבי קישוריות ורשת.

סוגים שונים של קצה עורפי

שירות לקצה עורפי יכול לכלול קצה עורפי של מכונה וירטואלית או של NEG. אם לשירות לקצה העורפי יש backend של NEG, כל ה-NEGs צריכים להכיל את אותו סוג של נקודת קצה ברשת. אי אפשר להגדיר שירות לקצה העורפי עם כמה קבוצות NEGs, שלכל אחת מהן יש סוגי נקודות קצה שונים.

במפת URL יכולים להיות כללי מארח שמובילים לשירותי קצה עורפיים שונים. יכול להיות שיש לכם שירות לקצה העורפי עם קבוצות NEGs של קישוריות היברידית בלבד (עם נקודות קצה מקומיות) ושירות לקצה העורפי עם קבוצות NEGs עצמאיות (עם נקודות קצה של GKE). מפת ה-URL יכולה להכיל כללים, למשל, פיצול תנועה לפי משקל, שמפצלים את התנועה בין כל אחד משירותי הקצה העורפיים האלה.

שימוש ב-NEG עם נקודות קצה מסוג NON_GCP_PRIVATE_IP_PORT עם Google Cloud backends

אפשר ליצור שירות לקצה העורפי עם NEG קישוריות היברידית שמפנה לבק-אנד ב- Google Cloud. עם זאת, אנחנו לא ממליצים על התבנית הזו כי NEGs עם קישוריות היברידית לא נהנים מבדיקות תקינות מרכזיות. הסבר על בדיקת תקינות מרכזית ובדיקת תקינות מבוזרת מופיע בקטע בדיקת תקינות.

רישום נקודות קצה

כדי להוסיף נקודת קצה ל-NEG, צריך לעדכן את ה-NEG. אפשר לעשות את זה באופן ידני, או להשתמש ב-API ל-REST של Google CloudNEG או ב-Google Cloud CLI כדי להפוך את התהליך לאוטומטי.

כשמופעלת מכונה חדשה של שירות, אפשר להשתמש ב- Google Cloud APIs כדי לרשום את המכונה ב-NEG שהגדרתם. כשמשתמשים בקבוצות של מופעי מכונה מנוהלים (MIG) ב-Compute Engine או ב-GKE (ב- Google Cloud), הבקר של ה-MIG או של ה-NEG מטפל באופן אוטומטי ברישום של נקודות הקצה.

בדיקת תקינות

כשמשתמשים ב-NEGs של קישוריות היברידית, אופן הפעולה של בדיקות התקינות שונה מאופן הפעולה של בדיקות התקינות המרכזיות הרגילות בדרכים הבאות:

  • עבור נקודות קצה ברשת מסוג NON_GCP_PRIVATE_IP_PORT, ‏ Cloud Service Mesh מגדיר את הלקוחות שלו להשתמש במישור הנתונים כדי לטפל בבדיקות תקינות. כדי להימנע משליחת בקשות לקצוות עורפיים לא תקינים, מופעים של Envoy מבצעים בדיקות תקינות משלהם ומשתמשים במנגנונים משלהם.
  • מישור הנתונים מטפל בבדיקות תקינות, ולכן אי אפשר להשתמש במסוףGoogle Cloud , ב-API או ב-Google Cloud CLI כדי לאחזר את סטטוס בדיקת התקינות.

בפועל, שימוש ב-NON_GCP_PRIVATE_IP_PORT אומר את הדברים הבאים:

  • מכיוון שכל אחד מהלקוחות של Cloud Service Mesh מטפל בבדיקות תקינות באופן מבוזר, יכול להיות שתראו עלייה בתעבורת הנתונים ברשת בגלל בדיקות התקינות. הגידול תלוי במספר הלקוחות של Cloud Service Mesh ובמספר נקודות הקצה שכל לקוח צריך לבדוק את תקינותן. לדוגמה:
    • כשמוסיפים עוד נקודת קצה ל-NEG של קישוריות היברידית, יכול להיות שלקוחות קיימים של Cloud Service Mesh יתחילו לבצע בדיקות תקינות של נקודות הקצה ב-NEGs של קישוריות היברידית.
    • כשמוסיפים עוד מופע ל-Service mesh (לדוגמה, מופע של VM שמריץ את קוד האפליקציה וגם לקוח של Cloud Service Mesh), יכול להיות שהמופע החדש יתחיל לבצע בדיקות תקינות של נקודות הקצה ב-NEGs של קישוריות היברידית.
    • תנועת הרשת עקב בדיקות תקינות גדלה בקצב ריבועי (O(n^2)).

רשת VPC

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

חשבון שירות

בתוך Google Cloud, ברירת המחדל של Envoy bootstrap מוגדרת לקריאת פרטי חשבון השירות מ-Compute Engine או מסביבות הפריסה של GKE, או משניהם. כשמריצים מחוץ ל-Google Cloud, צריך לציין באופן מפורש את חשבון השירות, שם הרשת ומספר הפרויקט בקובץ ה-bootstrap של Envoy. לחשבון השירות הזה צריכות להיות הרשאות מספיקות להתחבר ל-Cloud Service Mesh API.

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