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

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

טייס אוטומטי רגילה

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

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

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

‫Kubernetes
Ingress

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

סקירה כללית

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

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

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

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

אובייקט השירות של Kubernetes ואובייקט Cloud de Confiance השירות לקצה העורפי משרתים מטרות דומות אך שונות. הם קשורים מאוד זה לזה, אבל הקשר ביניהם הוא לא תמיד אחד לאחד.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תמונה

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

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

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

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

האם בקר 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

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

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

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

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

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

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

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

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

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

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

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

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

יתרונות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מידע על פתרון בעיות שגיאה מסוג 502 ב-Ingress חיצוני זמין במאמר Ingress חיצוני יוצר שגיאות HTTP 502.

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

‫GKE Ingress לא תומך באישורים שמנוהלים על ידי Certificate Manager. כדי להשתמש באישורים שמנוהלים על ידי Certificate Manager, צריך להשתמש ב-Gateway API.
בקטעים שמשתמשים ב-NEGs, יכול להיות שמספר הכניסות ישפיע על זמן ההתאמה של הכניסה. לדוגמה, באשכול עם 20 שערים (ingress), שכל אחד מהם מכיל 20 קצוות עורפיים שונים של NEG, יכול להיות שזמן האחזור של שינוי בשער יהיה יותר מ-30 דקות. ההשפעה הזו משמעותית במיוחד באשכולות אזוריים, כי נדרש מספר גדול יותר של NEGs.
המכסות למפות URL חלות.
המכסות של משאבי Compute Engine חלות.
אם אתם לא משתמשים ב-NEG עם בקר ה-Ingress של GKE, באשכולות GKE יש מגבלה של 1,000 צמתים. כשפורסים שירותים עם קבוצות NEG, אין הגבלה על מספר הצמתים ב-GKE. שירותים שאינם שירותי NEG שנחשפים דרך Ingress לא פועלים בצורה תקינה באשכולות שיש בהם יותר מ-1,000 צמתים.
כדי שבקר GKE Ingress ישתמש ב-readinessProbes כבדיקות תקינות, הפודים של Ingress צריכים להתקיים בזמן יצירת Ingress. אם העותקים המשוכפלים שלכם מוגדלים ל-0, בדיקת בריאות ברירת המחדל חלה. מידע נוסף זמין בתגובה הזו ב-GitHub בנושא בדיקות תקינות.
שינויים ב-readinessProbe של Pod לא משפיעים על ה-Ingress אחרי שהוא נוצר.
מאזן עומסים חיצוני של אפליקציות (ALB) מסיים את ה-TLS במיקומים שמפוזרים ברחבי העולם, כדי למזער את זמן האחזור בין הלקוחות לבין מאזן העומסים. אם אתם צריכים שליטה גיאוגרפית על המיקום שבו מסתיים ה-TLS, אתם צריכים להשתמש בבקר כניסה בהתאמה אישית שנחשף דרך שירות GKE מסוג LoadBalancer, ולסיים את ה-TLS בקצוות עורפיים שנמצאים באזורים שמתאימים לצרכים שלכם.
אין תמיכה בשילוב של כמה משאבי Ingress למאזן עומסים אחד של Cloud de Confiance by S3NS .
צריך להשבית את ה-Mutual TLS (mTLS) באפליקציה כי הוא לא נתמך במאזני עומסים חיצוניים של אפליקציות (ALB).
Ingress יכול לחשוף רק את יציאות ה-HTTP‏ 80 ו-443 בחלק הקדמי שלו.