מידע על Gateway API

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

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

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

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

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

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

משאבי Gateway API

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

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

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

GatewayClass

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

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

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

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

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

שער

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

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

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

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

HTTPRoute

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

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

מדיניות

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

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

בקר השער של GKE תומך בכללי המדיניות הבאים:

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

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.

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

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

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

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

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

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

בתרשים הבא, מנהל הפלטפורמה פרס Gateway לגישה בלעדית לכל Namespace. לדוגמה, שער 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 בין מרחבי שמות, אשכולות ואזורים. ארגונים גדולים עם אפליקציות שמפוזרות גיאוגרפית יכולים להפיק תועלת משערים מרובי-אשכולות, כי הם יכולים לשלוט בתנועה הגלובלית ברמת פירוט גבוהה, וגם להעביר את הבעלות על הניתוב. בדומה לדוגמאות הקודמות, אדמין פלטפורמה מנהל את שער הגישה ומקצה הרשאות ניתוב. התוספת העיקרית לתרחיש השימוש הזה היא שהמסלולים מפנים לשירותים בכמה אשכולות, שנפרסים על פני אשכולות. ניתן לנתב את התעבורה באופן מפורש, כך שהתעבורה אל store.example.com/us תנותב אל ה-Pods של gke-us, או באופן מרומז, כך שהתעבורה אל example.com/* תנותב אל האשכול הקרוב ביותר ללקוח. הגמישות הזו מאפשרת לבעלי שירותים להגדיר את אסטרטגיית הניתוב האופטימלית לאפליקציה שלהם.

GKE Gateway controller

בקר GKE Gateway הוא ההטמעה של 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 של השער שנפרס.

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

Service Extensions

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

בקר השער של GKE תומך בסוגי התוספים הבאים:

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

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

Ingress ו-Gateway

‫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 עם רשתות שירות (service mesh)

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

תמחור

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

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

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