מידע על Gateway API

בדף הזה מתואר היישום של Google Kubernetes Engine‏ (GKE) של Kubernetes Gateway API באמצעות GKE Gateway controller.

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

‫Gateway API הוא תקן קוד פתוח לרשתות שירותים. ‫Gateway API הוא משאב Ingress משופר, והוא משפר אותו בדרכים הבאות:

  • מבוסס על תפקידים: Gateway API מורכב ממשאבי API שמתאימים לתפקידים הארגוניים של מפעיל האשכול, המפתח וספק התשתית. כך מפעילים של אשכולות יכולים להגדיר איך צוותי פיתוח שונים שלא מתואמים ביניהם יכולים להשתמש בתשתית משותפת.

  • נייד: Gateway API הוא תקן קוד פתוח עם הטמעות רבות, שמאפשר שהמושגים ומשאבי הליבה יהיו עקביים בין הטמעות וסביבות שונות, וכך מצמצם את המורכבות ומגביר את ההיכרות של המשתמשים. העיצוב שלו מבוסס על מושג הגמישות, באמצעות API ליבה נייד מאוד (כמו Ingress) שעדיין מאפשר גמישות והרחבה כדי לתמוך ביכולות המקוריות של הסביבה וההטמעה.

  • מפורט: משאבי Gateway API מספקים יכולות מובנות להתאמה מבוססת-כותרות, שקלול תנועה ויכולות אחרות שאפשר להשתמש בהן רק ב-Ingress באמצעות הערות מותאמות אישית.

משאבים של Gateway API

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

‫GKE מספק מחלקות Gateway. מפעילים של אשכולות יוצרים משאבי Gateway על סמך המחלקות האלה. מפתחי אפליקציות יוצרים משאבי HTTPRoute שמשויכים למשאבי Gateway.
איור: סקירה כללית של Gateway API

‫Gateway API מכיל את סוגי המשאבים הבאים:

  • ‫GatewayClass: מגדיר משאב בהיקף אשכול שהוא תבנית ליצירת איזוני עומסים באשכול. ‫GKE מספק GatewayClasses שאפשר להשתמש בהם באשכולות GKE.
  • שער: מגדיר איפה ואיך מאזני העומסים מאזינים לתעבורת נתונים. מפעילים של אשכולות יוצרים שערים באשכולות שלהם על סמך GatewayClass. ‫GKE יוצר מאזני עומסים שמיישמים את ההגדרה שמוגדרת במשאב Gateway.
  • ‫HTTPRoute: הגדרה של כללים ספציפיים לפרוטוקול לניתוב בקשות מ-Gateway לשירותי Kubernetes. ‫GKE תומך ב-HTTPRoutes לניתוב תעבורת נתונים מבוסס-HTTP(S). מפתחי אפליקציות יוצרים HTTPRoutes כדי לחשוף את אפליקציות ה-HTTP שלהם באמצעות Gateways.
  • ‫Policy: מגדיר קבוצה של מאפיינים ספציפיים להטמעה של משאב Gateway. אפשר לצרף מדיניות ל-Gateway, ל-Route או ל-Kubernetes Service.
  • ‫ReferenceGrant: מאפשר הפניות בין מרחבי שמות ב-Gateway API. כדי להתייחס לאובייקט מחוץ למרחב השמות שלו, צריך ליצור משאב ReferenceGrant.

GatewayClass

‫GatewayClass הוא משאב שמגדיר תבנית למאזני עומסים מסוג HTTP(S) (שכבה 7) באשכול Kubernetes. ‫GKE מספק GatewayClasses כמשאבים בהיקף האשכול. מפעילים של אשכולות מציינים GatewayClass כשיוצרים שערים באשכולות שלהם.

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

חלק מה-GatewayClasses תומכים באיזון עומסים בין כמה אשכולות.

בטבלה הבאה מפורטים ה-GatewayClasses שזמינים באשכולות GKE וסוג איזון העומסים הבסיסי שלהם. פרטים מלאים על GatewayClasses זמינים במאמר יכולות ומפרטים של GatewayClass.

שם GatewayClass תיאור
gke-l7-global-external-managed מאזני עומסים גלובליים חיצוניים של אפליקציות(ALB) שמבוססים על מאזן עומסים גלובלי חיצוני של אפליקציות
gke-l7-regional-external-managed מאזני עומסים חיצוניים אזוריים של אפליקציות(ALB) שמבוססים על מאזן עומסים חיצוני אזורי של אפליקציות
gke-l7-rilb מאזני עומסים פנימיים של אפליקציות(ALB) שמבוססים על מאזן עומסים פנימי של אפליקציות
gke-l7-gxlb מאזני עומסים גלובליים חיצוניים של אפליקציות(ALB) שמבוססים על מאזן עומסים קלאסי של אפליקציות
gke-l7-cross-regional-internal-managed-mc מאזני עומסים פנימיים של אפליקציות (ALB) בכמה אשכולות ובכמה אזורים, שמבוססים על מאזן עומסים פנימי של אפליקציות (ALB) בכמה אזורים
gke-l7-global-external-managed-mc מאזני עומסים גלובליים חיצוניים של אפליקציות(ALB) מרובי-אשכולות שמבוססים על מאזן עומסים גלובלי חיצוני של אפליקציות
gke-l7-regional-external-managed-mc מאזני עומסים אזוריים חיצוניים של אפליקציות(ALB) שמבוססים על מאזן עומסים אזורי חיצוני של אפליקציות
gke-l7-rilb-mc מאזני עומסים פנימיים של אפליקציות(ALB) מרובי-אשכולות שמבוססים על מאזן עומסים פנימי של אפליקציות
gke-l7-gxlb-mc מאזני עומסים גלובליים חיצוניים של אפליקציות(ALB) מרובי-אשכולות שמבוססים על מאזן עומסים קלאסי של אפליקציות
gke-td ‫Cloud Service Mesh עם כמה אשכולות
asm-l7-gxlb מאזני עומסים גלובליים חיצוניים של אפליקציות(ALB) שמבוססים על Cloud Service Mesh

כל GatewayClass כפוף למגבלות של מאזן העומסים הבסיסי.

שער

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

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

דוגמה לפריסת שער מופיעה במאמר פריסת שערים.

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

HTTPRoute

‫HTTPRoute מגדיר איך בקשות HTTP ו-HTTPS שמתקבלות על ידי Gateway מופנות לשירותים. מפתחי אפליקציות יוצרים HTTPRoutes כדי לחשוף את האפליקציות שלהם דרך Gateways.

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

מדיניות

מדיניות מגדירה מאפיינים של משאב Gateway, בדרך כלל ספציפיים להטמעה, שאופרטורים של אשכולות יכולים לצרף ל-Gateway, ל-Route או לשירות Kubernetes. מדיניות מגדירה איך התשתית הבסיסיתGoogle Cloud אמורה לפעול.

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

ב-GKE Gateway Controller יש תמיכה במדיניות הבאה:

  • ‫HealthCheckPolicy: מגדיר את הפרמטרים ואת אופן הפעולה של בדיקת התקינות שמשמשת לבדיקת סטטוס התקינות של ה-Pods בעורף השרת.
  • ‫GCPGatewayPolicy: הגדרה של פרמטרים ספציפיים של הקצה הקדמי שלGoogle Cloud מאזן העומסים. המדיניות הזו דומה לFrontendConfig של משאב Ingress.
  • ‫GCPBackendPolicy: הגדרה של האופן שבו שירותי הקצה העורפי של מאזן העומסים צריכים לפזר את התעבורה לנקודות הקצה. המדיניות הזו דומה למדיניות BackendConfig עבור משאב Ingress.
  • ‫GCPBackendPolicy: מגדיר איך שירותי הקצה העורפי של מאזן העומסים מפזרים את התעבורה לקצוות העורפיים. המדיניות GCPBackendPolicy תומכת במצב איזון CUSTOM_METRICS, שמאפשר קבלת החלטות ניתוב על סמך מדדי אפליקציה שהוגדרו על ידי המשתמש ומדווחים באמצעות דוחות העומס של ORCA.
  • ‫GCPTrafficDistributionPolicy: מגדיר איך התנועה מתפלגת בין נקודות קצה ב-backend. המדיניות הזו דומה לאופן שבו מגדירים אלגוריתמים ספציפיים לאיזון תנועה בשירות לקצה העורפי שאליו מתייחס משאב Ingress.

ReferenceGrant

המשאב ReferenceGrant מאפשר למשאבים כמו HTTPRoute או Gateway להפנות לשירותי קצה עורפי או לסודות שנמצאים במרחבי שמות שונים באמצעות הפניה בין מרחבי שמות. האובייקט ReferenceGrant משמש כספק הרשאות, ומציין לאילו משאבים (from) מותר להפנות למשאבים אחרים (to). כדי להפעיל הפניות בין מרחבי שמות, צריך ReferenceGrant במרחב השמות של המשאב שאליו מתבצעת ההפניה.

בדוגמה הבאה, ה-HTTPRoute במרחב השמות frontend צריך להפנות תנועה לשירות במרחב השמות backend. יוצרים ReferenceGrant במרחב השמות backend, כאשר:

  • בשדה from מפורטים מרחב השמות של המקור וסוג המשאב שיכולים ליצור הפניות, כלומר HTTPRoute במרחב השמות frontend.
  • השדה to מציין את סוג משאב היעד שאפשר להפנות אליו, כלומר שירותים במרחב השמות backend.
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-frontend-to-access-backend
  namespace: backend
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: frontend
  to:
  - group: ""
    kind: Service

אם מופיעה הודעת השגיאה 'לא נמצאה הענקת הרשאה תקפה' בסטטוס של השער, צריך לוודא שהערכים group, kind, namespace ו-name שהוגדרו בקטעים from ו-to תקפים.

בעלות על שערים ודפוסי שימוש

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

שער בניהול עצמי

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

בעלים יחיד יכול לקבל שליטה מלאה גם בשער וגם במסלול

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

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

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

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

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

שער לכל מרחב שמות מספק גישה בלעדית של שער למרחב השמות הזה.

שער משותף לכל אשכול

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

בתרשים הבא, מנהל הפלטפורמה פרס שני שערים במרחב השמות infra. שער external מאפשר לנתבים ממרחבי השמות web ו-mobile להתחבר לשער. מסלולים ממרחב השמות accounts לא יכולים להשתמש בשער external כי מרחב השמות accounts מיועד רק לשירותים פנימיים. שער internal מאפשר ללקוחות פנימיים לתקשר באופן פרטי בתוך ה-VPC באמצעות כתובות IP פרטיות.

שער לכל אשכול מאפשר למרחבי שמות שונים בתוך אשכול לשתף שער יחיד

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

שער משותף לכל צי

באמצעות multi-cluster Gateways, אפשר לשתף Gateway בין מרחבי שמות, אשכולות ואזורים. ארגונים גדולים עם אפליקציות שמפוזרות גיאוגרפית יכולים להפיק תועלת משימוש בשערי כניסה מרובי-אשכולות, כי הם יכולים לשלוט בתנועה הגלובלית ברמת פירוט גבוהה, וגם להקצות בעלות על ניתוב. בדומה לדוגמאות הקודמות, אדמין פלטפורמה מנהל את שער הכניסה ומקצה ניתוב. התוספת העיקרית לתרחיש השימוש הזה היא שהמסלולים מפנים לשירותים מרובי-אשכולות, שנפרסים על פני אשכולות. ניתן לנתב את התנועה באופן מפורש, כך שהתנועה אל store.example.com/us תנותב אל Pods של gke-us, או באופן מרומז, כך שהתנועה אל example.com/* תנותב אל האשכול הקרוב ביותר ללקוח. הגמישות הזו מאפשרת לבעלי שירותים להגדיר את אסטרטגיית הניתוב האופטימלית לאפליקציה שלהם.

שער לכל צי מספק איזון עומסים במספר אשכולות ובמספר אזורים

GKE Gateway controller

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

יש שתי גרסאות של GKE Gateway Controller:

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

שני בקרי השער הם בקרי אירוח של Google שעוקבים אחרי Kubernetes API באשכולות GKE. בניגוד לבקר GKE Ingress, בקרי Gateway לא מתארחים במישורי בקרה של GKE או בפרויקט המשתמש, ולכן הם יכולים להיות יותר גמישים ויציבים. שני בקרי השער זמינים לכלל המשתמשים (GA).

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

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

שלט רחוק Single-cluster Gateway controller Multi-cluster Gateway controller
מנוהל על ידי Google Cloud Google Cloud
היקף האשכול שערי גישה לאשכול יחיד Multi-cluster Gateways
מיקום הפריסה נפרס באופן אזורי באותו אזור שבו נמצא אשכול ה-GKE. פריסה גלובלית בכמה אזורים Google Cloud .
איך מפעילים מופעל כברירת מחדל ב-GKE. מופעל באמצעות Multi Cluster Ingress API (ממשק API של תעבורת נתונים נכנסת (ingress) של אשכול מרובה) ורישום לצי. מידע נוסף על הפעלת שערים מרובי אשכולות
Supported GatewayClasses
  • ‫gke-l7-global-external-managed GA
  • ‫gke-l7-regional-external-managed GA
  • gke-l7-rilb GA
  • gke-l7-gxlb GA
  • ‫asm-l7-gxlb Preview
  • gke-l7-global-external-managed-mc GA
  • gke-l7-regional-external-managed-mc GA
  • gke-l7-cross-regional-internal-managed-mc GA
  • gke-l7-rilb-mc GA
  • gke-l7-gxlb-mc GA
  • ‫gke-td Preview

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

Service Extensions

בקר GKE Gateway תומך ב-Service Extensions, שמאפשרים להוסיף לוגיקה בהתאמה אישית ל-Cloud Load Balancing.

בקר GKE Gateway תומך בשני סוגים של תוספים:

  • ‫GCPTrafficExtension: התוסף הזה מאפשר להוסיף לוגיקה בהתאמה אישית ל-Cloud Load Balancing. שירות התוסף יכול לשנות את הכותרות ואת נתוני התוכן (payloads) של הבקשות והתשובות בלי להשפיע על הבחירה של שירותי הקצה העורפי או על מדיניות אבטחה אחרת שמשויכת לשירות הקצה העורפי.
  • ‫GCPRoutingExtension: התוסף הזה מאפשר להוסיף לוגיקה מותאמת אישית ל-Cloud Load Balancing כדי לשלוט לאן התנועה מנותבת עבור בקשה נתונה.

מידע נוסף על הגדרת בקרי GKE Gateway זמין במאמר התאמה אישית של תנועת נתונים ב-GKE Gateway באמצעות Service Extensions.

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

‫Ingress ו-Gateway הם שני תקנים של קוד פתוח לניתוב תנועה, אבל יש ביניהם הבדלים חשובים.

השוואה בין Ingress לבין Gateway

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

ב-GKE, אפשר להמיר ישירות את כל משאבי ה-Ingress למשאבי Gateway ו-HTTPRoute. ‫Ingress יחיד תואם גם ל-Gateway (להגדרת קצה קדמי) וגם ל-HTTPRoute (להגדרת ניתוב). בדוגמה הבאה מוצגת תצורת Gateway ו-HTTPRoute תואמת. שימו לב שאפשר ליצור את משאבי Gateway ו-HTTPRoute בנפרד, גם על ידי משתמשים שונים. לשערי רשת יכולים להיות הרבה נתיבים, ונתיב יכול להיות מחובר ליותר משער רשת אחד. הקשרים בין שערים לבין מסלולים מוסברים במאמר דפוסי שימוש בשערים.

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: "gce-internal"
spec:
  rules:
  - host: "example.com"
    http:
      paths:
      - pathType: Prefix
        path: /
        backend:
          service:
            name: site
            port:
              number: 80
      - pathType: Prefix
        path: /shop
        backend:
          service:
            name: store
            port:
              number: 80

שער

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: gke-l7-rilb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute

נתיב

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        value: /
    backendRefs:
    - name: site
      port: 80
  - matches:
    - path:
        value: /shop
    backendRefs:
    - name: store
      port: 80

שילוב של Gateway API עם רשתות שירות

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

תמחור

כל המשאבים של Compute Engine שנפרסים דרך בקרי השער מחויבים על הפרויקט שבו נמצאים אשכולות ה-GKE. במסגרת התמחור של GKE Standard ו-Autopilot, אפשר להשתמש בבקר Gateway של אשכול יחיד ללא תשלום נוסף. התמחור של שערים מרובי-אשכולות מתואר בדף התמחור של שערים מרובי-אשכולות ו-Multi Cluster Ingress.

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