תעבורת נתונים נכנסת (ingress) לרשת ה-mesh

Service mesh מאפשרת תקשורת בין השירותים שפועלים ב-Service mesh. איך מושכים תנועה לרשת ה-Mesh? אפשר להשתמש בשער כדי להפנות תנועה מחוץ לרשת אל הרשת דרך נקודת כניסה.

במאמר הזה מוסבר איך להשתמש ב-Cloud Load Balancing כשער להעברת תנועה לרשת שלכם, והוא כולל את הנושאים הבאים:

  • שיקולים ברמה גבוהה לגבי השער.
  • סקירה כללית של האפשרויות כשבוחרים שער לרשת ה-Mesh.
  • המלצות לגבי הארכיטקטורה שאפשר ליישם בטופולוגיית השער.

במסמך הזה, שער מתייחס לפתרון או לתבנית לטיפול בתנועה שמיועדת לשירות ברשת שלכם. ‫Ingress Gateway של Istio הוא הטמעה אחת של התבנית הזו. במסמך הזה, המונח gateway הוא מונח כללי שמתייחס לתבנית הכללית, ולא להטמעה של Istio.

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

כשמעצבים את Service mesh, כדאי לקחת בחשבון את התנועה שמגיעה מהמקורות הבאים:

  • תנועה שמקורה בתוך הרשת
  • תנועה שמקורה מחוץ לרשת

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

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

  1. שירות א' שולח בקשה לשירות ב' לפי שם.
  2. הבקשה הזו נחסמת ומופנית מחדש לשרת ה-proxy של קובץ העזר החיצוני של Service A.
  3. לאחר מכן, ה-proxy של ה-sidecar שולח את הבקשה לנקודת קצה שמשויכת ל-Service B.
מישור הנתונים של ה-mesh מטפל בתעבורה פנימית ב-service mesh.
מישור הנתונים של ה-Service mesh מטפל בתנועה פנימית ב-Service mesh (לחצו כדי להגדיל)


בדוגמה הבאה, התעבורה מגיעה מחוץ ל-Service mesh ולא עוברת לאורך מישור הנתונים של ה-Service mesh.

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

בדוגמה הזו, הלקוח נמצא מחוץ ל-Service mesh. מכיוון שהלקוח לא משתתף ישירות ברשת, הוא לא יודע אילו נקודות קצה שייכות לשירותים בתוך הרשת. במילים אחרות, מכיוון שהלקוח לא משתמש בשרת proxy שהוגדר ב-Cloud Service Mesh כדי לשלוח בקשות יוצאות, הוא לא יודע באילו זוגות של כתובות IP ויציאות להשתמש כשהוא שולח תנועה לשירות א' או לשירות ב'. בלי המידע הזה, הלקוח לא יכול לגשת לשירותים בתוך רשת ה-mesh.

שיקולים לגבי השער

בקטע הזה מפורטות בעיות שכדאי לקחת בחשבון כשבוחרים שער, כולל:

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

איך מאפשרים ללקוחות להגיע לשער של רשת ה-mesh

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

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

  • האם הלקוחות שלי נמצאים באינטרנט הציבורי, בסביבה מקומית או שהם חלק מרשת הענן הווירטואלי הפרטי (VPC) שלי?
  • באילו פרוטוקולי תקשורת הלקוחות שלי משתמשים?

בקטע בחירת שער לרשת מופיע סקירה כללית של אפשרויות Cloud Load Balancing, בהתאם למיקום הלקוח ולפרוטוקול התקשורת.

טיפול בתנועה בשער

השער נמצא בקצה של רשת ה-mesh – בין לקוחות שנמצאים מחוץ לרשת ה-mesh לבין שירותים שנמצאים בתוך רשת ה-mesh. לכן, השער הוא מקום טבעי להחלת מדיניות כשנכנסת תעבורה לרשת ה-mesh. כללי המדיניות האלה כוללים את:

  • ניהול תנועה – לדוגמה, ניתוב, הפניות מותנות ושינוי בקשות
  • אבטחה – לדוגמה, סיום TLS והגנה מפני התקפות מניעת שירות מבוזרות (DDoS) של Google Cloud Armor
  • שמירה במטמון ב-Cloud CDN

בקטע Choose a gateway for your mesh מודגשות מדיניות שרלוונטית בקצה של הרשת.

שליחת תנועה משער הכניסה לשירות ברשת

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

בקטע Choose a gateway for your mesh מפורטים השרתים העורפיים שאליהם שער יכול לשלוח תנועה.

בחירת שער לרשת ה-Mesh

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

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

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

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

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

שער מיקום הלקוח פרוטוקולים מדיניות שרתי קצה עורפיים/נקודות קצה
מאזן עומסים פנימי של אפליקציות (ALB)

לקוחות מבוססי-Google Cloudבאותו אזור כמו מאזן העומסים.

לקוחות מקומיים שהבקשות שלהם מגיעות לאותו Google Cloud אזור שבו נמצא מאזן העומסים – לדוגמה, באמצעות Cloud VPN או Cloud Interconnect.

HTTP/1.1

HTTP/2

HTTPS

ניהול מתקדם של תעבורת נתונים

סיום TLS באמצעות אישורים בניהול עצמי

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

  • שרתי קצה עורפיים של מכונות וירטואליות (VM) ב-Compute Engine
  • מכונות קונטיינר ב-Google Kubernetes Engine‏ (GKE) וב-Kubernetes
מאזן עומסים חיצוני של אפליקציות (ALB) לקוחות באינטרנט הציבורי

HTTP/1.1

HTTP/2

HTTPS

ניהול תנועה

‫Cloud CDN (כולל קצה עורפי של קטגוריות Cloud Storage)

סיום TLS באמצעות אישורים בניהול Google או בניהול עצמי

מדיניות SSL

‫Cloud Armor למניעת מתקפות DDoS ומתקפות באינטרנט

תמיכה בשרת proxy לאימות זהויות (IAP) לאימות משתמשים

שרתי קצה עורפיים בכל Google Cloud אזור, שפועלים ב:

  • מכונות וירטואליות ב-Compute Engine
  • מכונות קונטיינר ב-GKE וב-Kubernetes
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי

Google Cloud-based clients in any region; this requires global access if clients are in a different region from the load balancer.

לקוחות מקומיים שהבקשות שלהם מגיעות לכל אזור Google Cloud– לדוגמה, באמצעות Cloud VPN או Cloud Interconnect.

 TCP בק-אנדים באותו אזור Google Cloud שבו נמצא מאזן העומסים, שפועלים במכונות וירטואליות ב-Compute Engine.
מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי לקוחות באינטרנט הציבורי TCP או UDP בק-אנדים באותו אזור Google Cloud שבו נמצא מאזן העומסים, שפועלים במכונות וירטואליות ב-Compute Engine.
מאזן עומסי רשת חיצוני לשרת proxy לקוחות באינטרנט הציבורי SSL או TCP

סיום TLS באמצעות אישורים בניהול Google או בניהול עצמי (פרוקסי SSL בלבד)

מדיניות SSL (שרת proxy ל-SSL בלבד)

שרתי קצה עורפיים בכל Google Cloud אזור, שפועלים ב:

  • מכונות וירטואליות ב-Compute Engine
  • מכונות קונטיינר ב-GKE וב-Kubernetes
Edge proxy
(במכונות וירטואליות או בקונטיינרים) שהוגדר על ידי Cloud Service Mesh		 הלקוחות צריכים להיות במיקום שבו חל אחד מהתנאים הבאים:
  • הם יכולים לשלוח בקשה למאזן עומסים שמנוהל על ידי a Google Cloud, ששולח את הבקשה לפרוקסי הקצה. לפרטים נוספים אפשר לעיין במאמר טיפול בתעבורת נתונים נכנסת (ingress) באמצעות שער ברמה השנייה בקצה של רשת ה-mesh.
  • הם יכולים לשלוח בקשה דרך שרת proxy – לדוגמה, שרת proxy מסוג sidecar – שמוגדר על ידי Cloud Service Mesh.
  • הם יכולים לשלוח בקשה ישירות לכתובת ה-IP ולפורט של מכונה וירטואלית או של מופע של קונטיינר שמריץ את פרוקסי הקצה.

HTTP/1.1

HTTP/2

 ניהול מתקדם של תעבורת נתונים (כולל תמיכה ב-regex)

שרתי קצה עורפיים בכל Google Cloud אזור, שפועלים ב:

  • מכונות וירטואליות ב-Compute Engine
  • מכונות קונטיינר ב-GKE וב-Kubernetes

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

פריסה והגדרה של שערים

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

‫Google Cloud CLI וממשקי Compute Engine API

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

מסוףGoogle Cloud

כדי להגדיר את Cloud Service Mesh ואת מאזני העומסים המנוהלים של Google Cloud, אפשר להשתמש במסוף Google Cloud .

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

GKE ו-Multi Cluster Ingress

בקרי הרשת של GKE ו-GKE Enterprise תומכים גם בפריסה של Cloud Load Balancing לשילוב מובנה עם רשתות קונטיינרים. הם מספקים ממשק הצהרתי בסגנון Kubernetes לפריסה ולהגדרה של שערים. בקרי GKE Ingress ו-Multi-cluster Ingress מנהלים מאזני עומסים פנימיים וחיצוניים לשליחת תעבורה לאשכול יחיד או למספר אשכולות GKE. אפשר גם להגדיר את משאב ה-Ingress כך שיצביע על שירותים שהוגדרו ב-Cloud Service Mesh ונפרסו באשכולות GKE.

דפוסי ארכיטקטורה של שערים

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

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

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

    • השער מחיל את כללי המדיניות.

  2. השער שולח את התנועה לשירות ברשת ה-mesh.

תבנית מתקדמת יותר כוללת שערים בשתי רמות. השערים פועלים באופן הבא:

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

    • השער מחיל את כללי המדיניות.

  2. השער שולח את תעבורת הנתונים לשרת proxy בקצה (או למאגר של שרתי proxy בקצה) שהוגדר על ידי Cloud Service Mesh. שרת ה-proxy הזה פועל כשער ברמה השנייה. ברמה הזו:

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

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

  3. השער ברמה השנייה שולח את התנועה לשירות ברשת שלכם.

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

הפעלת תעבורת נתונים נכנסת מהאינטרנט

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

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

בדפוס הזה, מאזן העומסים שמנוהל על ידי Google Cloudמשמש כשער. השער מטפל בתעבורת נתונים נכנסת (ingress) לפני שהוא מעביר אותה לשירות ברשת.

לדוגמה, אתם יכולים לבחור מאזן עומסים חיצוני של אפליקציות (ALB) בתור השער שלכם כדי להשתמש ב:

  • כתובת IP גלובלית מסוג Anycast שאפשר לנתב באופן ציבורי, שממזערת את זמן האחזור ואת העלויות של מעבר ברשת.
  • ‫Cloud Armor וסיום TLS כדי לאבטח את התנועה ברשת.
  • ‫Cloud CDN להצגת תוכן באינטרנט ובסרטונים.
  • יכולות ניהול תעבורה כמו ניתוב מבוסס-מארח וניתוב מבוסס-נתיב.

למידע נוסף שיעזור לכם לבחור שער מתאים, אפשר לעיין בקטע בחירת שער לרשת Mesh.

הפעלת תעבורת נתונים נכנסת (ingress) מלקוחות ב-VPC וברשתות מקומיות מקושרות

אם הלקוחות שלכם נמצאים ברשת ה-VPC, או אם הם מקומיים ויכולים להגיע לשירותים באמצעות שיטת קישור פרטית (כמו Cloud VPN או Cloud Interconnect), אתם יכולים להשתמש באחד ממאזני העומסים הבאים כשער: Google Cloud

תעבורת נתונים נכנסת מלקוחות ברשת VPC לשירותים ברשת באמצעות מאזן עומסים.
תנועת Ingress מלקוחות ברשת VPC לשירותים ב-mesh באמצעות מאזן עומסים (לחצו כדי להגדיל)

בדפוס הזה, מאזן העומסים שמנוהל על ידי Google Cloudמשמש כשער. השער מטפל בתעבורת נתונים נכנסת (ingress) לפני שהוא מעביר אותה לשירות ברשת.

לדוגמה, אפשר לבחור מאזן עומסים פנימי של אפליקציות (ALB) כשער כדי להשתמש בתכונות האלה:

  • כתובת IP פרטית שאפשר להקצות
  • סיום TLS כדי לאבטח את הרשת
  • יכולות מתקדמות לניהול תעבורת נתונים, כמו פיצול תעבורת נתונים לפי משקל
  • קבוצות של נקודות קצה (NEGs) כקצה עורפי

למידע נוסף שיעזור לכם לבחור שער מתאים, אפשר לעיין בקטע בחירת שער לרשת Mesh.

טיפול בתעבורת נתונים נכנסת (ingress) באמצעות שער ברמה השנייה בקצה הרשת

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

תעבורת Ingress מלקוחות חיצוניים לשירותים בתוך הרשת באמצעות מאזן עומסים ושרת proxy בקצה הרשת.
תנועת Ingress מלקוחות חיצוניים לשירותים ב-mesh באמצעות מאזן עומסים ופרוקסי קצה (לחצו כדי להגדיל)

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

הדפוס הזה מתקדם יותר, אבל הוא מספק יתרונות נוספים:

  • מאזן העומסים שמנוהל על ידי Google Cloudמחיל קבוצה ראשונית של מדיניות – לדוגמה, הגנה של Cloud Armor אם משתמשים במאזן עומסים חיצוני של אפליקציות (ALB).

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

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

  1. צוות אחד יכול להיות אחראי לטיפול בתעבורת נתונים נכנסת (ingress) אלGoogle Cloud , וצוות אחר יכול להיות אחראי לטיפול בתעבורת נתונים נכנסת (ingress) אל הרשת שלו.

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

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

שימוש בממשקי API לניתוב שירותים לתעבורת נתונים נכנסת (ingress)

ממשקי ה-API לניתוב שירותים מספקים את משאב Gateway להגדרת ניהול תעבורה ואבטחה לשרתי proxy של Envoy שפועלים כשערי כניסה, ומאפשרים ללקוחות חיצוניים להתחבר ל-Service mesh (צפון-דרום). מידע נוסף מופיע במאמרים סקירה כללית על ניתוב שירותים והגדרת שער כניסה.

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