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

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

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

בדף הזה אנחנו יוצאים מנקודת הנחה שאתם מכירים את הנושאים הבאים:

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

סקירה כללית

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

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

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

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

אובייקט השירות של Kubernetes ואובייקט Google Cloud שירות ה-Backend משרתים מטרות דומות אך שונות. הם קשורים מאוד זה לזה, אבל הקשר ביניהם הוא לא תמיד אחד לאחד.

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

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

תעבורת נתונים נכנסת (ingress) לתעבורה חיצונית ופנימית

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

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

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

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

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

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

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

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

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

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

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

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

תמונה

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

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

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

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

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

ערך של kubernetes.io/ingress.class ערך של ingressClassName התנהגות של בקר GKE Ingress
לא מוגדר לא מוגדר מעבדים את מניפסט ה-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

בקר GKE Ingress פורס ומנהל משאבי איזון עומסים של 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 Ends או משרתי proxy של Envoy.
  • שרת proxy של HTTP ביעד ושרת proxy של HTTPS ביעד, אם הגדרתם TLS.
  • מפת URL עם כלל מארח יחיד שמפנה למתאם נתיבים יחיד. לכלי להתאמת נתיבים יש שני כללי נתיב, אחד ל-/* ואחד ל-/discounted. כל כלל נתיב ממופה לשירות קצה עורפי ייחודי.
  • קבוצות NEG שמכילות רשימה של כתובות IP של Pod מכל שירות כנקודות קצה. הם נוצרים כתוצאה משירותי my-discounted-products ו-my-products.

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

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

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

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

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

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

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

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

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

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

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

יתרונות

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

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

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

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

תמיכה ב-Cloud Service Mesh: כדי להשתמש ב-Cloud Service Mesh,‏ Google Cloud's fully managed traffic control plane for service mesh, נדרש מודל הנתונים של NEG.

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

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

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

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

תחויבו על מאזן העומסים של האפליקציה שהוקצה על ידי ה-Ingress שיצרתם במדריך הזה. מידע על תמחור מאזני עומסים מופיע במאמר Load balancing and forwarding rules בדף התמחור של Cloud Load Balancing.

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

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

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

תעבורת נתונים נכנסת (ingress) חיצונית ואשכולות מבוססי-נתיבים

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

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

כדי ללמוד איך לפתור שגיאות 502 ב-Ingress חיצוני, אפשר לעיין במאמר External Ingress produces HTTP 502 errors.

המגבלות של GKE Ingress controller

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

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

  • חלים מכסות למיפוי כתובות URL.

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

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

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

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

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

  • אין תמיכה בשילוב של כמה משאבי Ingress למאזן עומסים אחד. Google Cloud

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

  • שער כניסה יכול לחשוף רק את יציאות ה-HTTP‏ 80 ו-443 בחלק הקדמי שלו.

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