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 השירות לקצה העורפי משרתים מטרות דומות אך שונות. הם קשורים מאוד זה לזה, אבל הקשר הוא לא תמיד אחד לאחד.

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

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

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

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

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

חשוב: בכל פעם ש-GKE יוצר מאזן עומסים של אפליקציות חיצוני או מאזן עומסים של אפליקציות פנימי באמצעות אובייקט Ingress, מומלץ להימנע משינוי ההגדרה של מאזן העומסים באמצעות שיטות מחוץ ל-GKE. ההתאמות האישיות שלכם בהגדרות של האובייקטים של מאזן העומסים – כללי העברה, שרתי proxy ביעד, מיפוי של כתובות URL, שירותים לקצה העורפי ובדיקות תקינות – יימחקו כשמחילים שינויים חדשים במשאבים, במהלך סנכרונים תקופתיים או במהלך שדרוגים של אשכולות. אם אתם צריכים לנהל מאזן עומסים חיצוני של אפליקציות (ALB) או מאזן עומסים פנימי של אפליקציות (ALB) מחוץ ל-GKE, אתם יכולים להשתמש במקום זאת באיזון עומסים מובנה בקונטיינרים עבור קבוצות עצמאיות של נקודות קצה ברשת (NEGs).

סביבת הרשת הנדרשת למאזני עומסים חיצוניים של אפליקציות (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):

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

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

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

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

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

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

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

תמונה

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

לקוח יוצר חיבור לכתובת ה-IP ולפורט של כלל ההעברה של מאזן העומסים.
שרת proxy מקבל את החיבור לרשת של הלקוח ומסיים אותו.
הפרוקסי יוצר חיבור לנקודת הקצה (Pod) המתאימה ב-NEG, כפי שנקבע על ידי מפת 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 ויוצרים מאזן עומסים פנימי של אפליקציות.
הערך שמוגדר הוא לא `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 או משרתי Envoy proxy.
שרת 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 הווירטואלית, כללי ההעברה, בדיקות תקינות וכללי חומת האש.

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

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

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

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

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

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

יתרונות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יכול להיות שאובייקטים ישנים יותר של Ingress חיצוני שנוצרו באשכולות המותאמים ל-VPC משתמשים בקצה עורפי של קבוצות מופעים בשירותי הקצה העורפי של כל מאזן עומסים של אפליקציות (ALB) חיצוני שהם יוצרים. המידע הזה לא רלוונטי ל-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 דקות עד שהשינוי בשער יתעדכן. ההשפעה הזו משמעותית במיוחד באשכולות אזוריים, כי נדרש מספר גדול יותר של קבוצות שליליות.
חלים מכסות למיפוי כתובות URL.
מכסות למשאבי Compute Engine.
אם אתם לא משתמשים ב-NEGs עם בקר ה-Ingress של GKE, אז יש הגבלה של 1,000 צמתים באשכולות GKE. כשפורסים שירותים עם קבוצות NEG, אין הגבלה על מספר הצמתים ב-GKE. שירותים שאינם NEG שנחשפים דרך Ingress לא פועלים בצורה תקינה באשכולות שיש בהם יותר מ-1,000 צמתים.
כדי שבקר GKE Ingress ישתמש ב-readinessProbes כבדיקות תקינות, הפודים של Ingress צריכים להתקיים בזמן יצירת Ingress. אם העותקים המשוכפלים שלכם מוקטנים ל-0, בדיקת בריאות ברירת המחדל חלה. מידע נוסף זמין בתגובה הזו ב-GitHub בנושא בדיקות תקינות.
שינויים ב-readinessProbe של Pod לא משפיעים על ה-Ingress אחרי שהוא נוצר.
מאזן עומסים חיצוני של אפליקציות (ALB) מסיים את ה-TLS במיקומים שמפוזרים באופן גלובלי, כדי לצמצם את זמן האחזור בין הלקוחות לבין מאזן העומסים. אם אתם צריכים שליטה גיאוגרפית במיקום שבו מסתיים ה-TLS, אתם צריכים להשתמש בבקר Ingress בהתאמה אישית שנחשף דרך שירות GKE מסוג LoadBalancer, ולהפסיק את ה-TLS בשרתי קצה שנמצאים באזורים שמתאימים לצרכים שלכם.
אין תמיכה בשילוב של כמה משאבי Ingress למאזן עומסים אחד של Google Cloud .
צריך להשבית את ה-TLS ההדדי באפליקציה כי הוא לא נתמך במאזני עומסים חיצוניים של אפליקציות.
Ingress יכול לחשוף רק את יציאות ה-HTTP‏ 80 ו-443 בחלק הקדמי שלו.