מממשק קצה לרשת מרובת אשכולות: אפליקציות מבוזרות גלובלית שנחשפות דרך GKE Gateway ו-Cloud Service Mesh

Last reviewed 2026-06-04 UTC

בארכיטקטורת ההפניה הזו מתוארים היתרונות של חשיפת אפליקציות חיצונית באמצעות שערים של Google Kubernetes Engine ‏ (GKE) שפועלים בכמה אשכולות GKE בתוך Service mesh. המדריך הזה מיועד לאדמינים של הפלטפורמה.

אתם יכולים לשפר את העמידות והיתירות של השירותים שלכם על ידי פריסת אפליקציות באופן עקבי בכמה אשכולות GKE, כשכל אשכול הופך לתחום כשל נוסף. לדוגמה, תשתית מחשוב של שירות עם יעד רמת שירות (SLO) של 99.9% כשפורסים אותה באשכול GKE יחיד, משיגה יעד רמת שירות של 99.9999% כשפורסים אותה בשני אשכולות GKE‏ (1 - (0.001)2). אפשר גם לספק למשתמשים חוויה שבה בקשות נכנסות מופנות אוטומטית לשער הכניסה של רשת ה-mesh עם ההשהיה הכי נמוכה והזמינות הכי גבוהה.

אם אתם רוצים לדעת מה היתרונות של חשיפת אפליקציות שמופעלות ב-service mesh ופועלות באשכול יחיד, כדאי לעיין במאמר From edge to mesh: Expose service mesh applications through GKE Gateway.

ארכיטקטורה

בתרשים הארכיטקטורה הבא מוצג זרימת הנתונים דרך כניסה לענן וכניסה לרשת:

הצפנת TLS מהלקוח, ממאזן העומסים ומ-mesh.

בתרשים שלמעלה מוצגים תרחישים של זרימת נתונים:

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

ארכיטקטורת ההפניה הזו מכילה את שתי שכבות הכניסה הבאות:

  • תעבורת נכנסת ב-Cloud: בארכיטקטורת העזר הזו, משתמשים ב-Kubernetes Gateway API (וב-GKE Gateway controller) כדי לתכנת את שכבת איזון העומסים החיצונית מרובת האשכולות מסוג HTTP(S). מאזן העומסים בודק את שרתי ה-proxy של הכניסה לרשת במספר אזורים, ושולח בקשות לאשכול הקרוב ביותר שפועל בצורה תקינה. הוא גם מטמיע מדיניות אבטחה של Google Cloud Armor.
  • Mesh ingress: ברשת, אתם מבצעים בדיקות תקינות בשרתי הקצה העורפיים ישירות, כדי שתוכלו להפעיל איזון עומסים וניהול תעבורה באופן מקומי.

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

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

תעבורה נכנסת בענן

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

  • הגנה מפני DDoS
  • חומות אש בענן
  • אימות והרשאה
  • הצפנה

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

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

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

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

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

מוצרים ותכונות שהשתמשו בהם

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

  • ‫GKE: שירות מנוהל של Kubernetes שבו אפשר להשתמש כדי לפרוס ולהפעיל אפליקציות בקונטיינרים בהיקף גדול באמצעות התשתית של Google. לצורך ארכיטקטורת ההפניה הזו, כל אשכול GKE שמשרת אפליקציה צריך להיות באותו Fleet.
  • ‫Fleets וmulti-cluster Gateways: שירותים שמשמשים ליצירת אפליקציות מבוססות-קונטיינרים בקנה מידה ארגוני באמצעות התשתית של Google ו-GKE.
  • ‫Google Cloud Armor: שירות שעוזר לכם להגן על האפליקציות והאתרים שלכם מפני התקפות מניעת שירות (DoS) ומתקפות באינטרנט.
  • ‫Cloud Service Mesh: רשת שירותים מנוהלת במלואה שמבוססת על Envoy ו-Istio
  • מאזן עומסים של אפליקציות (ALB): מאזן עומסים מבוסס-פרוקסי ברמה 7 שמאפשר להריץ את השירותים ולהרחיב אותם.
  • ‫Certificate Manager: שירות שמאפשר לקבל ולנהל אישורי TLS לשימוש ב-Cloud Load Balancing.

ציים

כדי לנהל פריסות בכמה אשכולות, GKE ו- Google Cloud משתמשים בציים כדי לקבץ באופן לוגי אשכולות Kubernetes ולנרמל אותם.

שימוש בצי אחד או יותר יכול לעזור לכם לשדרג את הניהול מאשכולות בודדים לקבוצות שלמות של אשכולות. כדי לצמצם את החיכוך בניהול האשכולות, כדאי להשתמש בעיקרון של Fleet: מרחבי שמות זהים. לכל אשכול GKE בצי, צריך לוודא שכל שער הכניסה של ה-mesh מוגדר באותו אופן.

בנוסף, צריך לפרוס באופן עקבי שירותי אפליקציות, כך שהשירות balance-reader בחשבון מרחב השמות יהיה קשור לשירות זהה בכל אשכול GKE בצי. העקרונות של זהות ואמון שמונחים בבסיס של Fleet מאפשרים לכם להשתמש בכל התכונות של Fleet ב-GKE וב- Google Cloud.

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

למרות שיש אשכול תצורה יחיד ל-GKE Gateway, מומלץ לסנכרן את התצורות של GKE Gateway בכל אשכולות GKE ב-Fleet.

אם אתם צריכים להגדיר אשכול תצורה חדש, אתם יכולים להשתמש ב-ConfigSync. ‫ConfigSync עוזר לוודא שכל ההגדרות האלה מסונכרנות בכל אשכולות GKE ב-Fleet, וכך להימנע מהתאמה להגדרה לא עדכנית.

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

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

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

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

GKE Gateway ושירותים מרובי אשכולות

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

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

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

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

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

בארכיטקטורת ההפניה הזו מוסבר איך לחשוף שירותי אפליקציה באופן חיצוני באמצעות מאזן עומסים חיצוני של אפליקציות (ALB). עם זאת, כשמשתמשים ב-Gateway, אפשר גם ליצור מאזן עומסים פנימי אזורי של אפליקציות (ALB) עם כמה אשכולות.

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

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

‫Multi Cluster Ingress מסתמך על יצירת משאבי MultiClusterService. התכונה Multi-cluster Gateway (שער מרובה אשכולות) מסתמכת על יצירת משאבי ServiceExport והפניה למשאבי ServiceImport.

כשמשתמשים בשער (Gateway) מרובה-אשכולות, אפשר להפעיל את היכולות הנוספות של מאזן העומסים הבסיסי על ידי יצירת מדיניות. Google Cloud במדריך הפריסה שמשויך לארכיטקטורת העזר הזו מוסבר איך להגדיר מדיניות אבטחה של Google Cloud Armor כדי להגן על שירותי קצה עורפי מפני פרצת אבטחה XSS‏ (cross-site scripting).

משאבי המדיניות האלה מיועדים לשירותי הקצה העורפי ב-Fleet, שנחשפים בכמה אשכולות. בתרחישים של כמה אשכולות, כל המדיניות הזו צריכה להפנות אל משאב ServiceImport וקבוצת ה-API.

בדיקת תקינות

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

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

שיקולים בתכנון

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

אבטחה, פרטיות ותאימות

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

לקוחות באינטרנט עוברים אימות מול אישורים ציבוריים ומתחברים למאזן העומסים החיצוני כצעד הראשון בענן וירטואלי פרטי (VPC). אפשר להפנות אל CertificateMap Certificate Manager בהגדרת השער. הניתוב הבא הוא בין ממשק הקצה של Google‏ (GFE) לבין פרוקסי הכניסה לרשת המשנה. הניתוב הזה מוצפן כברירת מחדל.

הצפנה ברמת הרשת בין שרתי ה-GFE לבין ה-backends שלהם מופעלת באופן אוטומטי. אם דרישות האבטחה שלכם מחייבות שבעלי הפלטפורמה ישמרו על הבעלות על מפתחות ההצפנה, אתם יכולים להפעיל HTTP/2 עם הצפנת TLS בין שער האשכול (GFE) לבין הכניסה לרשת (מופע proxy של Envoy).

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

אם אתם רוצים להשתמש ב-HTTP/2 לחיבור בין GFE לבין רשת ה-mesh, אבל אתם לא צריכים הצפנה משלכם, אתם יכולים להשתמש ב-H2C.

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

כדי ליצור רשומות DNS חיצוניות ואישורי TLS, במדריך הפריסה של ארכיטקטורת העזר הזו נעשה שימוש ב-Cloud Endpoints. השימוש ב-Cloud Endpoints מאפשר לכם ליצור cloud.googתת-דומיין שזמין חיצונית. בתרחישים ברמת הארגון, כדאי להשתמש בשם דומיין מתאים יותר וליצור רשומת A שמפנה לכתובת ה-IP הגלובלית של מאזן העומסים של האפליקציה אצל ספק שירותי ה-DNS.

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

אמינות ועמידות

יתרון מרכזי של התבנית 'קצה לרשת' עם כמה אשכולות ובמספר אזורים הוא שאפשר להשתמש בכל התכונות של Service mesh לאיזון עומסים בין שירותים (תעבורה ממזרח למערב), כמו תעבורת נתונים בין שירותי אפליקציות.

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

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

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

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

פריסה

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

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

שותפים ביצירת התוכן

מחברים:

תורמי תוכן אחרים: