מהקצה ל-Service mesh: חשיפת אפליקציות של Service mesh דרך GKE Gateway

Last reviewed 2023-10-24 UTC

ארכיטקטורת העזר הזו מראה איך לשלב בין Cloud Service Mesh לבין Cloud Load Balancing כדי לחשוף אפליקציות ב-Service Mesh ללקוחות באינטרנט.

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

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

שער כניסה לרשת Mesh

ב-Istio 0.8 הוצג שער הכניסה לרשת. השער מספק קבוצה ייעודית של שרתי proxy שהיציאות שלהם חשופות לתנועה שמגיעה מחוץ ל-Service mesh. פרוקסי ה-Ingress של הרשת הזו מאפשרים לכם לשלוט בהתנהגות החשיפה של הרשת בנפרד מהתנהגות הניתוב של האפליקציה.

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

כדי לנהל את התעבורה החיצונית הזו, צריך מאזן עומסים חיצוני לרשת. ארכיטקטורת העזר הזו משתמשת ב-Cloud Load Balancing של Google Cloud, שמוקצה באמצעות משאבי GKE Gateway, כדי להפוך את הפריסה לאוטומטית.

במקרה של Google Cloud, הדוגמה הקנונית להגדרה הזו היא שירות חיצוני לאיזון עומסים שמפעיל מאזן עומסי רשת ציבורי (L4). מאזן העומסים הזה מצביע על NodePorts של אשכול GKE. ה-NodePort האלה חושפים את ה-Pods של שער הכניסה של Istio, שמנתבים תנועה לשרתי proxy של downstream mesh sidecar.

ארכיטקטורה

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

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

בתרשים הקודם אפשר לראות ששימוש באיזון עומסים שקוף ברמה 4 עם שער כניסה לרשת מסוג mesh מציע את היתרונות הבאים:

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

GKE Gateway and Services

יש הרבה דרכים לספק גישה לאפליקציות ללקוחות שנמצאים מחוץ לאשכול. ‫GKE Gateway הוא הטמעה של Kubernetes Gateway API. ‫GKE Gateway מפתח ומשפר את משאב ה-Ingress.

כשפורסים משאבי GKE Gateway באשכול GKE, בקר ה-Gateway עוקב אחרי משאבי Gateway API ומבצע התאמה בין משאבי Cloud Load Balancing כדי ליישם את התנהגות הרשת שצוינה במשאבי GKE Gateway.

כשמשתמשים ב-GKE Gateway, סוג מאזן העומסים שבו משתמשים כדי לחשוף אפליקציות ללקוחות תלוי בעיקר בגורמים הבאים:

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

ב-GKE Gateway, ההתנהגות הזו נשלטת על ידי ציון GatewayClass מתאים.

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

תעבורת נתונים נכנסת (ingress) בענן ותעבורת נתונים נכנסת (ingress) ברשת Mesh

פריסת איזון עומסים חיצוני ברמה 7 מחוץ לרשת, יחד עם שכבת כניסה לרשת, מציעה יתרונות משמעותיים, במיוחד לתעבורת נתונים באינטרנט. למרות ש-Cloud Service Mesh ושערי הכניסה של Istio מספקים ניתוב מתקדם וניהול תעבורה ברשת, יש פונקציות שעדיף להשתמש בהן בקצה הרשת. השימוש ברשתות קצה באינטרנט באמצעות מאזן עומסים חיצוני של אפליקציות (ALB) שלGoogle Cloudעשוי לספק יתרונות משמעותיים בביצועים, באמינות או באבטחה בהשוואה לכניסה מבוססת-רשת. ההטבות האלה כוללות:

שכבת מאזן העומסים החיצונית הזו ברמה 7 נקראת cloud ingress כי היא מבוססת על מאזני עומסים שמנוהלים בענן, ולא על שרתי proxy באירוח עצמי שמשמשים ל-mesh ingress. השילוב של כניסה לענן וכניסה לרשת משתמש ביכולות משלימות של התשתית Google Cloud והרשת. בתרשים הבא מוצג שילוב של תעבורת נתונים נכנסת בענן (דרך שער GKE) ותעבורת נתונים נכנסת ברשת, שמשמשות כשתי שכבות של איזון עומסים לתעבורת נתונים.

תעבורת נתונים נכנסת ל-Cloud משמשת כשער לתעבורת נתונים חיצונית לרשת דרך רשת ה-VPC.

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

טופולוגיית כניסה בענן וברשת

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

  • כניסה לענן: כשמשתמשים בשכבת הכניסה לענן בשילוב עם כניסה לרשת, הכי טוב להשתמש בה לאבטחת קצה ולאיזון עומסים גלובלי. שכבת הכניסה לענן משולבת עם הגנה מפני DDoS, חומות אש בענן, אימות ומוצרי הצפנה בקצה הרשת, ולכן היא מצטיינת בהפעלת השירותים האלה מחוץ לרשת. הלוגיקה של הניתוב בדרך כלל פשוטה בשכבה הזו, אבל היא יכולה להיות מורכבת יותר בסביבות מרובות אשכולות ומרובות אזורים. בגלל התפקיד הקריטי של מאזני עומסים שפונים לאינטרנט, סביר להניח ששכבת הכניסה לענן מנוהלת על ידי צוות תשתית שיש לו שליטה בלעדית על האופן שבו האפליקציות נחשפות ומאובטחות באינטרנט. השליטה הזו גם הופכת את השכבה הזו לפחות גמישה ודינמית בהשוואה לתשתית שמבוססת על מפתחים. זהו שיקול שיכול להשפיע על מי מקבל גישת אדמין לשכבה הזו ואיך.
  • Mesh ingress: בשילוב עם cloud ingress, שכבת ה-mesh ingress מספקת ניתוב גמיש שקרוב לאפליקציה. בגלל הגמישות הזו, תעבורת נתונים נכנסת (ingress) של רשת עדיפה על כניסה לענן במקרים של לוגיקת ניתוב מורכבת ושל נראות ברמת האפליקציה. ההפרדה בין שכבות ה-Ingress גם מקלה על בעלי האפליקציות לשלוט בשכבה הזו ישירות, בלי להשפיע על צוותים אחרים. כדי לעזור לאבטח אפליקציות כשחושפים אפליקציות של Service mesh דרך מאזן עומסים L4 במקום מאזן עומסים L7, צריך לסיים את TLS של הלקוח בשכבת הכניסה לרשת בתוך ה-Service mesh.

בדיקת תקינות

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

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

בטופולוגיה שלמעלה צריך להתחשב בנקודות הבאות:

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

אבטחה

הטופולוגיה שלמעלה כוללת גם כמה רכיבי אבטחה. אחד מהאלמנטים החשובים ביותר הוא אופן ההגדרה של ההצפנה והפריסה של האישורים. ‫GKE Gateway משתלב עם אישורים שמנוהלים על ידי Google. אפשר להפנות אל CertificateMapCertificate Manager בהגדרת שער. לקוחות אינטרנט עוברים אימות מול האישורים הציבוריים ומתחברים למאזן העומסים החיצוני כצעד הראשון בענן וירטואלי פרטי (VPC).

הניתוב הבא, שמתבצע בין ממשק הקצה של Google ‏ (GFE) לבין פרוקסי הכניסה לרשת, מוצפן כברירת מחדל. הצפנה ברמת הרשת בין שרתי ה-GFE לבין ה-backend שלהם מופעלת באופן אוטומטי. עם זאת, אם דרישות האבטחה שלכם מחייבות שבעלי הפלטפורמה ישמרו על הבעלות על מפתחות ההצפנה, תוכלו להפעיל HTTP/2 עם הצפנת TLS בין שער האשכול (GFE) לבין הכניסה לרשת (מופע פרוקסי של Envoy). כשמפעילים HTTP/2 עם הצפנת TLS עבור הנתיב הזה, אפשר להשתמש באישור בחתימה עצמית או באישור ציבורי כדי להצפין את התעבורה, כי GFE לא מבצע אימות מולו. שכבת ההצפנה הנוספת הזו מוסברת במדריך הפריסה שקשור אליה. כדי למנוע טיפול לא תקין באישורים, אל תשתמשו באישור הציבורי במאזן העומסים הציבורי במקומות אחרים. במקום זאת, מומלץ להשתמש באישורים נפרדים ב-Service mesh.

אם ב-service mesh נדרש TLS, כל התנועה מוצפנת בין פרוקסי מסוג sidecar לבין הכניסה ל-mesh. בתרשים הבא מוצגת הצפנת HTTPS מהלקוח אל Google Cloud מאזן העומסים, ממאזן העומסים אל שרת ה-proxy של הכניסה לרשת, ומשרת ה-proxy של הכניסה אל שרת ה-proxy של ה-sidecar.

האבטחה מיושמת באמצעות אישורים מנוהלים מחוץ לרשת ואישורים פנימיים בתוך הרשת.

הוזלת עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

פריסה

כדי לפרוס את הארכיטקטורה הזו, אפשר לעיין במאמר מ-edge ל-mesh: פריסת אפליקציות של Service mesh באמצעות GKE Gateway.

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