מידע על Gateway API

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

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

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

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

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

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

משאבי Gateway API

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

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

• ‫GatewayClass: מגדיר משאב בהיקף אשכול שהוא תבנית ליצירת איזוני עומסים באשכול. ‫GKE מספק GatewayClasses שאפשר להשתמש בהם באשכולות GKE.
• ‫Gateway: מגדיר איפה ואיך מאזני העומסים מאזינים לתעבורת הנתונים. מפעילים של אשכולות יוצרים שערים באשכולות שלהם על סמך 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 מתאים לCloud de Confiance מאזן עומסים אחר. כשיוצרים שער על סמך GatewayClass, נוצר מאזן עומסים תואם כדי ליישם את ההגדרה שצוינה.

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

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

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

שער

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

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

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

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

HTTPRoute

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

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

מדיניות

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

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

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

• ‫HealthCheckPolicy: מגדיר את הפרמטרים וההתנהגות של בדיקת התקינות שמשמשת לבדיקת סטטוס התקינות של ה-Pods של ה-Backend.
• ‫GCPGatewayPolicy: הגדרה של פרמטרים ספציפיים של הקצה הקדמי שלCloud de Confiance by S3NS מאזן העומסים. המדיניות הזו דומה לFrontendConfig של משאב Ingress.
• ‫GCPBackendPolicy: מגדיר איך שירותי הקצה העורפי של מאזן העומסים מחלקים את התעבורה לנקודות הקצה (קצה עורפי). המדיניות הזו דומה לBackendConfig עבור משאב Ingress, והיא תומכת בתכונות כמו מצב איזון 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 תומך בשימוש במאזן עומסים על ידי כמה דיירים, שמשותף למרחבי שמות, לאשכולות ולאזורים. אם נדרשת בעלות מבוזרת יותר, אין צורך לשתף את השערים. אלה כמה מהדפוסים הנפוצים ביותר לשימוש ב-Gateways ב-GKE.

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

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

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

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

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

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

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

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

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

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

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

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

באמצעות multi-cluster Gateways, אפשר לשתף Gateway בין מרחבי שמות, אשכולות ואזורים. ארגונים גדולים עם אפליקציות שמפוזרות גיאוגרפית יכולים להפיק תועלת משערים מרובי-אשכולות, כי הם יכולים לשלוט בתנועה הגלובלית בצורה מדויקת וגם להקצות בעלות על ניתוב. בדומה לדוגמאות הקודמות, אדמין של הפלטפורמה מנהל את שער הגישה ומקצה את הניתוב. התוספת העיקרית לתרחיש השימוש הזה היא שההפניות של Routes הן לשירותים מרובי-אשכולות, שנפרסים באשכולות. ניתן לנתב את התעבורה באופן מפורש, כך שהתעבורה אל 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 אחד או יותר.

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

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

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

Service Extensions

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

ב-GKE Gateway Controller יש תמיכה בשני סוגים של תוספים:

• ‫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 בנפרד, גם על ידי משתמשים שונים. לשערי רשת יכולים להיות הרבה נתיבים, ונתיב יכול להיות מחובר ליותר משער רשת אחד. הקשרים בין שערים לבין מסלולים מוסברים במאמר דפוסי שימוש בשערים.

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.

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

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