GKE Ingress למאזני עומסים של אפליקציות (ALB)

בדף הזה מופיעה סקירה כללית על Ingress ב-Google Kubernetes Engine (GKE) למאזני עומסים של אפליקציות, ומוסבר איך בקר ה-Ingress מקצה מאזני עומסים של אפליקציות כדי לחשוף אפליקציות לתעבורת נתונים מסוג HTTP(S) מתוך רשת ה-VPC או מחוצה לה.

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

כדי להבין את המידע שבדף הזה, אתם צריכים להכיר את הנושאים הבאים:

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

סקירה כללית

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

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

כדי להשתמש ב-Ingress, צריך להפעיל את התוסף לאיזון עומסי HTTP. התוסף הזה מופעל כברירת מחדל באשכולות GKE, ואסור להשבית אותו.

ההבדל בין שירות Kubernetes לבין שירות לקצה העורפי של Google Cloud

האובייקט של שירות Kubernetes והאובייקט של Google Cloud שירות לקצה העורפי משמשים למטרות דומות אבל שונות. למרות שיש קשר הדוק בין השניים, הוא לא תמיד קשר של אחד לאחד.

בקר ה-Ingress של GKE פועל כמתרגם בין שני המושגים האלה. כשיוצרים משאב Ingress, הבקר מקצהGoogle Cloud מאזן עומסים. לאחר מכן, הבקר יוצרGoogle Cloud שירות לקצה העורפי ייעודי לכל שילוב ייחודי של (service.name, service.port) שמופיע במניפסט של Ingress.

לדוגמה, למניפסט של Ingress יכול להיות אותו שם של שירות Kubernetes, אבל הוא יכול להפנות ל-service.port אחר בשני כללים נפרדים של host או path. במקרה כזה, בקר ה-Ingress של GKE יוצר שני שירותי קצה עורפי נפרדים. לכן, אובייקט אחד של שירות Kubernetes יכול להיות קשור לכמה שירותים לקצה העורפי של Google Cloud .

‫Ingress לתנועה חיצונית ופנימית

יש שני סוגים של משאבי GKE Ingress:

סביבת הרשת הנדרשת למאזני עומסים חיצוניים של אפליקציות (ALB)

מאזן העומסים החיצוני של אפליקציות (ALB) הוא מערכת מנוהלת שפרוסה ברחבי העולם ומשתמשת בשרתי proxy של ממשק הקצה של Google‏ (GFE) שפרוסים ברשת הקצה של Google. שרתי ה-proxy האלה לא נמצאים ברשת ה-VPC שלכם. כשלקוח שולח בקשה לכתובת ה-IP החיצונית של מאזן העומסים, הבקשה מנותבת באמצעות רשת ה-anycast של Google ל-GFE הקרוב ביותר. ה-GFE מסיים את תעבורת הנתונים של המשתמש (כולל TLS, אם הוגדר) ואז מעביר את תעבורת הנתונים לפודים של הקצה העורפי באשכול GKE.

כדי שהתהליך הזה יפעל, בקר ה-Ingress של GKE יוצר באופן אוטומטי כללי חומת אש שמאפשרים לתנועה מה-GFE וממערכות בדיקת התקינות שלGoogle Cloudלהגיע לפודים. הכללים האלה מאפשרים תעבורת נתונים מטווחים ידועים של כתובות IP של Google (130.211.0.0/22 ו-35.191.0.0/16).

כך פועל מאזן העומסים החיצוני של אפליקציות (ALB):

  1. הלקוח שולח בקשה לכתובת ה-IP וליציאה של כלל ההעברה של מאזן העומסים.
  2. הבקשה מנותבת לשרת proxy של ממשק הקצה של Google‏ (GFE) ברשת הגלובלית של Google. שרת ה-proxy הזה מסיים את החיבור לרשת של הלקוח.
  3. שרת ה-proxy של GFE מעביר את הבקשה לנקודת הקצה המתאימה של Pod לקצה העורפי באשכול GKE, כפי שנקבע על ידי מפת URL ושירותי הקצה העורפי של מאזן העומסים.

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

סביבת הרשת הנדרשת למאזני עומסים פנימיים של אפליקציות (ALB)

מאזן העומסים הפנימי של האפליקציות מספק מאגר של שרתי proxy לרשת שלכם. שרתי ה-proxy מעריכים לאן כל בקשת HTTP(S)‎ צריכה להגיע על סמך גורמים כמו מפת URL, הזיקה לסשן (session affinity) של BackendService ומצב האיזון של כל קבוצת נקודות קצה לקצה עורפי.

מאזן עומסים פנימי של אפליקציות באזור מסוים משתמש ברשת משנה של שרתי proxy בלבד באותו אזור ברשת ה-VPC, כדי להקצות כתובות IP פנימיות לכל שרת proxy שנוצר על ידי Google Cloud.

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

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

תמונה

כך פועל מאזן העומסים הפנימי של אפליקציות:

  1. הלקוח מתחבר לכתובת ה-IP וליציאה של כלל ההעברה של מאזן העומסים.
  2. שרת proxy מקבל ומסיים את החיבור לרשת של הלקוח.
  3. שרת ה-proxy יוצר חיבור לנקודת הקצה המתאימה (Pod) ב-NEG, כפי שנקבע על ידי מפת URL ושירותי הקצה העורפי של מאזן העומסים.

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

ההתנהגות של בקר ה-Ingress ב-GKE

השאלה אם בקר ה-Ingress של GKE מעבד Ingress תלויה בערך של ההערה kubernetes.io/ingress.class:

ערך של kubernetes.io/ingress.class ערך של ingressClassName ההתנהגות של בקר ה-Ingress ב-GKE
לא מוגדר לא מוגדר מעבדים את המניפסט של Ingress ויוצרים מאזן עומסים חיצוני של אפליקציות (ALB).
לא מוגדר כל ערך לא מבצעת שום פעולה. אם נפרס בקר Ingress של צד שלישי, יכול להיות שהוא יעבד את המניפסט של Ingress.
gce כל ערך. המערכת מתעלמת מהשדה הזה. מעבדים את המניפסט של Ingress ויוצרים מאזן עומסים חיצוני של אפליקציות (ALB).
gce-internal כל ערך. המערכת מתעלמת מהשדה הזה. מעבדים את המניפסט של Ingress ויוצרים מאזן עומסים פנימי של אפליקציות (ALB).
צריך להגדיר ערך שהוא לא gce או gce-internal כל ערך לא מבצעת שום פעולה. אם נפרס בקר Ingress של צד שלישי, יכול להיות שהוא יעבד את המניפסט של Ingress.

הוצאה משימוש של הערה אחת (kubernetes.io/ingress.class)

למרות שההערה kubernetes.io/ingress.class הוצאה משימוש ב-Kubernetes, ב-GKE עדיין משתמשים בהערה הזו. חובה להשתמש בהערה הזו כדי לזהות את מחלקת ה-Ingress.

כשמחילים את ההגדרות, יכול להיות שתופיע אזהרה על הוצאה משימוש. האזהרה הזו מציינת שההערה הוצאה משימוש ומנחה אתכם להשתמש בשדה ingressClassName במקום זאת. אפשר להתעלם מהאזהרה כי GKE Ingress ממשיך להסתמך רק על ההערה kubernetes.io/ingress.class.

מיפויים של משאבי Ingress ל-Compute Engine

בקר ה-Ingress של GKE פורס ומנהל את משאבי איזון העומסים של Compute Engine, על סמך משאבי ה-Ingress שנפרסו באשכול. מיפוי המשאבים של Compute Engine תלוי במבנה של משאב ה-Ingress.

המניפסט הבא מתאר Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

המניפסט הזה של Ingress מורה ל-GKE ליצור את המשאבים הבאים של Compute Engine:

  • כלל העברה וכתובת IP.
  • כללי חומת האש של Compute Engine שמאפשרים תעבורת נתונים לבדיקות תקינות של מאזן העומסים ותעבורת נתונים של אפליקציות משרתי Google Front End או משרתי Envoy proxy.
  • Proxy ל-HTTP ביעד ו-Proxy ל-HTTPS ביעד, אם הגדרתם TLS.
  • מפת URL עם כלל מארח אחד שמפנה למתאם נתיבים אחד. למאתר הנתיבים יש שני כללי נתיבים, אחד ל-/* ואחד ל-/discounted. כל כלל נתיב ממפה לשירות ייחודי לקצה העורפי.
  • קבוצות NEG שמכילות רשימה של כתובות IP של Pod מכל שירות כנקודות קצה. הם נוצרים כתוצאה מהשירותים my-discounted-products ו-my-products.

שיטות לאיזון עומסים

ב-GKE יש תמיכה באיזון עומסים שמקורם בקונטיינר ובקבוצות של מכונות.

איזון עומסים שמקורם בקונטיינר

איזון עומסים שמקורם בקונטיינר הוא שיטה לאיזון עומסים ישירות לנקודות קצה של Pod ב-GKE. באיזון עומסים מותאם קונטיינרים משתמשים בקבוצות של נקודות קצה ברשת (NEG) מסוג GCE_VM_IP_PORT, שבהן נקודות הקצה הן כתובות ה-IP של הפודים.

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

איזון עומסים שמקורם בקונטיינר תומך בזיקה לסשן (session affinity) שמבוססת על Pod.

‫GKE מפעיל באופן אוטומטי איזון עומסים שמקורם בקונטיינר כשכל התנאים הבאים מתקיימים:

  • האשכול הוא VPC-native.
  • האשכול לא משתמש ברשת VPC משותפת.
  • באשכול לא נעשה שימוש במדיניות רשת ב-Kubernetes ב-GKE.
  • באשכול מופעל תוסף אחד (HttpLoadBalancing). באשכולות GKE, התוסף HttpLoadBalancing מופעל כברירת מחדל. אסור להשבית אותו.

כשמפעילים ב-GKE איזון עומסים מקורי בקונטיינר, השירותים מקבלים באופן אוטומטי את ההערה cloud.google.com/neg: '{"ingress": true}'. ההערה הזו מפעילה את היצירה של NEG שמשקף את כתובות ה-IP של ה-Pods, ומאפשר למאזני העומסים של Compute Engine לתקשר ישירות עם Pods.

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

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

יתרונות

כשמשתמשים ב-NEG, איזון עומסים שמקורם בקונטיינר מאפשר ליצור רשת יציבה יותר עם ביצועים טובים יותר:

ביצועי רשת משופרים: בלי איזון עומסים שמקורם בקונטיינר, התנועה עוברת לקבוצות של מכונות הצומת, ואז מסתמכת על כללי iptables שהוגדרו על ידי kube-proxy כדי לנתב ל-Pod היעד. באיזון עומסים שמקורם בקונטיינר, העומסים של תעבורת הנתונים מאוזנים ישירות ל-Pods, בלי צורך לנתב דרך כתובת ה-IP של ה-VM ורשת kube-proxy בצומת. התהליך הזה מבטל דילוגים נוספים ברשת, ומשפר את זמן האחזור ואת קצב העברת הנתונים.

בדיקות תקינות משופרות: שערי מוכנות של Pod מוטמעים כדי לקבוע את התקינות של Pod מנקודת המבט של מאזן העומסים, במקום להסתמך רק על בדיקות תקינות בתוך האשכול. התכונה החשובה הזו מאפשרת למאזן העומסים לזהות אירועים במחזור החיים של Pod (הפעלה, אובדן וכו'), ומשפרת את היציבות של תעבורת הנתונים. למידע נוסף על השימוש בשערי מוכנות של Pods כדי לקבוע את תקינות ה-Pod, קראו את המאמר מוכנות של Pods.

שיפור החשיפה: איזון עומסים שמקורם בקונטיינר מאפשר לכם לראות את זמן האחזור ממאזן העומסים של האפליקציות ישירות לכל Pod. ההשהיה כבר לא נצברת ברמת ה-IP של הצומת, ולכן קל יותר לפתור בעיות בשירותים ברמת ה-NEG.

תמיכה ב-Cloud Service Mesh: מודל הנתונים של NEG נדרש כדי להשתמש ב-Cloud Service Mesh, מישור הבקרה של Google Cloudלניהול מלא של תעבורת הנתונים ברשת השירות.

המגבלות של מאזני עומסים שמקורם בקונטיינר

למאזני עומסים שמקורם בקונטיינר דרך Ingress ב-GKE יש את המגבלות הבאות:

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

קבוצות של מכונות

כשמשתמשים בקבוצות של מכונות, מאזני העומסים של Compute Engine שולחים תנועה לכתובות ה-IP של המכונות הווירטואליות כרכיבי backend. כשמריצים קונטיינרים במכונות וירטואליות, שבהן הקונטיינרים משתפים את אותו ממשק מארח, יש את המגבלות הבאות:

  • הוא כולל שני דילוגים של איזון עומסים – דילוג אחד ממאזן העומסים למכונה הווירטואלית NodePort ודילוג נוסף דרך ניתוב kube-proxy לכתובות ה-IP של Pod (שעשויות להיות במכונה וירטואלית אחרת).
  • דילוגים נוספים מאריכים את זמן האחזור ומסבכים את נתיב התנועה.
  • למאזן העומסים של Compute Engine אין גישה ישירה ל-Pods, ולכן איזון התנועה לא אופטימלי.
  • אירועים סביבתיים כמו אובדן של VM או Pod, עלולים לגרום לאובדן תנועה לסירוגין בגלל הדילוג הכפול של התנועה.

אשכולות מבוססי-נתיבים ו-Ingress חיצוניים

אם אתם משתמשים באשכולות מבוססי-נתיבים עם Ingress חיצוני, בקר ה-Ingress של GKE לא יכול להשתמש באיזון עומסים מקורי בקונטיינר באמצעות קבוצות של נקודות קצה (NEG) ברשת GCE_VM_IP_PORT. במקום זאת, בקר ה-Ingress משתמש בקצוות עורפיים של קבוצות של מכונות לא מנוהלות, שכוללות את כל הצמתים בכל מאגרי הצמתים. אם קבוצות מופעי המכונה הלא מנוהלות האלה משמשות גם את שירותי LoadBalancer, יכולות להיגרם בעיות שקשורות למגבלה של קבוצת מופעי מכונה אחת עם איזון עומסים.

יכול להיות שחלק מהאובייקטים החיצוניים הישנים של Ingress שנוצרו באשכולות המותאמים ל-VPC משתמשים בקצוות עורפיים של קבוצות מכונות בשירותי הקצה העורפי של כל מאזן עומסים חיצוני של אפליקציות (ALB) שהם יוצרים. ההגדרה הזו לא רלוונטית ל-Ingress פנימי, כי משאבי Ingress פנימיים תמיד משתמשים בקבוצות NEG מסוג GCE_VM_IP_PORT ודורשים אשכולות המותאמים ל-VPC.

במאמר External Ingress produces HTTP 502 errors מוסבר איך לפתור שגיאות 502 עם Ingress חיצוני.

המגבלות של בקר ה-Ingress ב-GKE

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

  • ב-GKE Ingress אין תמיכה באישורים שמנוהלים על ידי Certificate Manager. כדי להשתמש באישורים שמנוהלים על ידי Certificate Manager, צריך להשתמש ב-Gateway API.

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

  • המכסות של מפות URL חלות.

  • המכסות של משאבי Compute Engine חלות.

  • אם אתם לא משתמשים בקבוצות NEG עם בקר ה-Ingress של GKE, באשכולות GKE יש מגבלה של 1,000 צמתים. כשפורסים שירותים עם קבוצות של נקודות קצה ברשת, אין מגבלה על מספר הצמתים ב-GKE. שירותים שאינם NEG שנחשפים דרך Ingress לא פועלים כמו שצריך באשכולות שיש בהם יותר מ-1,000 צמתים.

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

  • שינויים ב-readinessProbe של Pod לא משפיעים על ה-Ingress אחרי שהוא נוצר.

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

  • אי אפשר לשלב כמה משאבי Ingress במאזן עומסים (LB) אחד של Google Cloud .

  • צריך להשבית את ה-mTLS באפליקציה כי אין תמיכה במאזני עומסים חיצוניים של אפליקציות.

  • ‫Ingress יכול לחשוף רק את יציאות ה-HTTP‏ 80 ו-443 בשביל ממשק המשתמש שלו.

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