מידע על שירותי LoadBalancer

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

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

לפני שקוראים את הדף הזה, חשוב להכיר את המושגים של רשתות GKE.

סקירה כללית

כשיוצרים LoadBalancer Service,‏ GKE מגדיר Google Cloud מאזן עומסים מסוג pass-through שהמאפיינים שלו תלויים בפרמטרים של מניפסט השירות.

התאמה אישית של שירות LoadBalancer

כשבוחרים באיזו הגדרה של LoadBalancer Service להשתמש, כדאי להביא בחשבון את ההיבטים הבאים:

• סוג מאזן העומסים – פנימי או חיצוני
• מדיניות תנועה חיצונית
• איזון עומסים משוקלל
• תחום עניין משותף אזורי

איור: עץ החלטות לבחירת שירות LoadBalancer

סוג מאזן העומסים – פנימי או חיצוני

כשיוצרים שירות LoadBalancer ב-GKE, מציינים אם למאזן העומסים יש כתובת פנימית או חיצונית:

• שירותי LoadBalancer חיצוניים מיושמים באמצעות מאזני עומסים אזוריים חיצוניים להעברת סיגנל ללא שינוי. לקוחות שנמצאים מחוץ לרשת ה-VPC ו Google Cloud מכונות וירטואליות עם גישה לאינטרנט יכולים לגשת לשירות LoadBalancer חיצוני.

  כדי ליצור שירות LoadBalancer חיצוני, משתמשים באחת מהשיטות הבאות:

  • באשכולות שמריצים GKE 1.33.1-gke.1779000 ואילך, מוסיפים spec.loadBalancerClass: "networking.gke.io/l4-regional-external" למניפסט של השירות לפני ששולחים את המניפסט לאשכול. מומלץ להשתמש בשדה הזה כי הוא תמיד יוצר מאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות לקצה העורפי עם קצוות עורפיים של GCE_VM_IP NEG. השדה spec.loadBalancerClass הוא קבוע ואי אפשר לשנות אותו אחרי שיוצרים את השירות.

  • באשכולות שמופעלת בהם גרסה נתמכת של GKE, אפשר להוסיף את ההערה cloud.google.com/l4-rbs: "enabled" למניפסט של השירות לפני ששולחים את המניפסט לאשכול. ההערה הזו יוצרת גם מאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות קצה עורפי. מאזן העומסים משתמש בGCE_VM_IP קצה עורפי של NEG אם המניפסט נשלח לאשכול שמריץ GKE 1.32.2-gke.1652000 ואילך. אחרת, מאזן העומסים משתמש בשרתי קצה עורפיים של קבוצת מופעי מכונה. ‫GKE מעריך את ההערה הזו רק כשמחילים את מניפסט השירות על האשכול בפעם הראשונה.

• שירותים מסוג Internal LoadBalancer מיושמים באמצעות מאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי. לקוחות שנמצאים באותה רשת VPC או ברשת שמחוברת לרשת ה-VPC של האשכול יכולים לגשת לשירות LoadBalancer פנימי.

  כשיטה מומלצת, לפני שיוצרים שירות LoadBalancer פנימי, חשוב לוודא שחלוקת המשנה של GKE מופעלת. התכונה 'חלוקת משנה' ב-GKE מופעלת אוטומטית אם האשכול שלכם מריץ GKE 1.36 ואילך. בגרסאות קודמות של GKE, צריך להפעיל במפורש את תכונת החלוקה לקבוצות משנה ב-GKE.

  כדי ליצור שירות LoadBalancer פנימי, משתמשים באחת מהשיטות הבאות:

  • באשכולות שמריצים GKE 1.33.1-gke.1779000 ואילך עם הפעלת GKE subsetting, מוסיפים spec.loadBalancerClass: "networking.gke.io/l4-regional-internal" למניפסט של השירות לפני ששולחים את המניפסט לאשכול. מומלץ להשתמש בשדה הזה כי הוא תמיד יוצר מאזן עומסי רשת פנימי מסוג Network Load Balancer עם GCE_VM_IP קצה עורפי של NEG. אי אפשר לשנות את השדה spec.loadBalancerClass אחרי שיוצרים את השירות.

  • באשכולות שמופעלת בהם גרסה נתמכת של GKE, אפשר להוסיף את ההערה networking.gke.io/load-balancer-type: "Internal" למניפסט של Service לפני שליחת המניפסט לאשכול. הפעולה הזו גם יוצרת מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי. מאזן העומסים משתמש בבק-אנד של GCE_VM_IP NEG אם המניפסט נשלח לאשכול שבו מופעלת חלוקת המשנה של GKE. אחרת, מאזן העומסים משתמש בבקאנד של קבוצת מופעי מכונה.

מניפסטים של LoadBalancer Service שלא כוללים את spec.loadBalancerClass ושלא כוללים את ההערות cloud.google.com/l4-rbs: "enabled" או networking.gke.io/load-balancer-type: "Internal" יוצרים מאזן עומסים אזורי חיצוני של רשתות להעברת סיגנל ללא שינוי שמבוסס על מאגר יעדים. אנחנו לא ממליצים להשתמש במאזני עומסי רשת חיצוניים אזוריים להעברת סיגנל ללא שינוי שמבוססים על מאגר יעד.

דרישות מוקדמות ל-HttpLoadBalancing

כדי ליצור שירותי LoadBalancer שמבוססים על מאזני עומסים אזוריים חיצוניים של רשתות להעברת סיגנל ללא שינוי או על מאזני עומסים פנימיים של רשתות להעברת סיגנל ללא שינוי, צריך לוודא שהתוסף HttpLoadBalancing מופעל אם האשכול פועל בגרסת GKE לפני 1.36. HttpLoadBalancing התוסף מופעל כברירת מחדל.

שירותי LoadBalancer ב-GKE גרסה 1.36 ואילך לא תלויים בתוסף HttpLoadBalancing.

השפעה של externalTrafficPolicy

הפרמטר externalTrafficPolicy שולט בפעולות הבאות:

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

הערך של externalTrafficPolicy יכול להיות Local או Cluster:

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

הערה: שימוש במדיניות Local כדי לשמור על כתובות IP של מקור לא יפעל אם ip-masq-agent פועל באשכול שלכם וטווח כתובות ה-IP של ה-Pod לא מוחרג מהסוואת כתובות ה-IP. הוראות להחרגת טווחי כתובות IP מהסוואה מפורטות במאמר custom nonMasqueradeCIDRs list in the ip-masq-agent configMap.

• כדאי להשתמש ב-externalTrafficPolicy: Cluster במצבים שבהם המספר הכולל של הצמתים באשכול יחסית קבוע, אבל מספר הצמתים עם ה-Pods של השרת משתנה. האפשרות הזו לא שומרת את כתובות ה-IP המקוריות של הלקוח, ויכולה להוסיף חביון כי יכול להיות שהמנות ינותבו ל-Pod של שרת בצומת אחר אחרי שהן יועברו לצומת ממאזן העומסים. האפשרות הזו לא תואמת לאיזון עומסים משוקלל.

מידע נוסף על ההשפעה של externalTrafficPolicy על ניתוב מנות בתוך הצמתים מופיע במאמר עיבוד מנות.

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

איזון עומסים משוקלל

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

איור: חלוקת תנועה של איזון עומסים משוקלל

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

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

• באשכול GKE צריך להשתמש בגרסה 1.31.0-gke.1506000 ואילך.

• צריך ליצור שירות LoadBalancer חיצוני שיוביל למאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות לקצה העורפי. אפשר להשתמש באחת מהשיטות הבאות:

  • באשכולות שמריצים GKE 1.33.1-gke.1779000 ואילך, מוסיפים spec.loadBalancerClass: "networking.gke.io/l4-regional-external" למניפסט של Service לפני ששולחים את המניפסט לאשכול. זו השיטה המועדפת.

  • באשכולות שמופעלת בהם גרסה נתמכת של GKE, מוסיפים את ההערה cloud.google.com/l4-rbs: "enabled" למניפסט של Service לפני ששולחים את המניפסט לאשכול.

• כדי להפעיל את התכונה 'איזון עומסים משוקלל', צריך לכלול את ההערה networking.gke.io/weighted-load-balancing: pods-per-node במניפסט השירות.

• המניפסט של שירות LoadBalancer חייב להשתמש ב-externalTrafficPolicy: Local. ‫GKE לא מונע מכם להשתמש ב-externalTrafficPolicy: Cluster, אבל externalTrafficPolicy: Cluster משבית למעשה את איזון העומסים המשוקלל, כי יכול להיות שהמערכת תנתב את המנות, אחרי מאזן העומסים, לצומת אחר.

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

תחום עניין משותף

שירותי Internal LoadBalancer תומכים בהעדפה אזורית, שיכולה להפנות חיבורים חדשים לצמתים עם Pods שמספקים שירותים באותו אזור כמו הלקוח. אם אין פודים תקינים באזור, GKE מעביר את התעבורה לאזור אחר. השארת התנועה באזור מסוים יכולה לצמצם את התנועה בין אזורים שונים, וכך להפחית את העלות ואת זמן האחזור. כדי להפעיל את התכונה 'זיקה לאזור' באשכול GKE, צריך להפעיל את התכונה 'חלוקת משנה של GKE'.

כשמגדירים זיקה אזורית לשירות LoadBalancer פנימי,‏ GKE מגדיר את מאזן העומסים הפנימי המתאים להעברת סיגנל ללא שינוי עם האפשרות ZONAL_AFFINITY_SPILL_CROSS_ZONE ויחס העברה לאזורים אחרים של אפס (0.0). ההגדרה הזו עוזרת לוודא שהתעבורה נשארת באזור ולא מועברת לאזורים אחרים. מאזן העומסים מצמצם את קבוצת השרתים העורפיים המקוריים של הצמתים שעומדים בדרישות רק לשרתים עורפיים של צמתים שעומדים בדרישות שנמצאים באותו אזור כמו הלקוח, אם כל התנאים הבאים מתקיימים:

• הלקוח תואם לזיקה אזורית.

• יש לפחות קצה עורפי אחד תקין ומתאים של צומת באזור של הלקוח.

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

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

שיקולים לגבי שינוי קנה מידה עם זיקה לאזור

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

שיקולים מיוחדים לגבי שירותי LoadBalancer פנימיים

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

GKE subsetting

החל מגרסה 1.36 של GKE,‏ חלוקת משנה של GKE לשירותי איזון עומסים פנימיים מופעלת כברירת מחדל באשכולות GKE. בגרסאות האלה, חלוקת המשנה של GKE נשארת פעילה גם אם הדגל --enable-l4-ilb-subsetting ברמת האשכול מוגדר ל-false בהגדרת האשכול או בכלי תשתית כקוד (IaC) כמו Terraform.

אפשרות ההגדרה הזו ברמת האשכול משפרת את יכולת ההתאמה של מאזני עומסים פנימיים מסוג Network Load Balancer, כי היא מאפשרת לקבץ את נקודות הקצה של הצמתים בצורה יעילה יותר לGCE_VM_IPקבוצות של נקודות קצה ברשת (NEGs). קבוצות ה-NEG משמשות כקצה העורפי של מאזן העומסים.

בתרשים הבא מוצגים שני שירותים באשכול אזורי עם שלושה צמתים. האשכול כולל הפעלה של חלוקת משנה של GKE. לכל שירות יש שני Pods. ‫GKE יוצר GCE_VM_IP NEG אחד לכל Service. נקודות הקצה (Endpoints) בכל NEG הן הצמתים עם ה-Pods שמשרתים את השירות המתאים.

במקרים של אשכולות שמופעלות בהם גרסאות קודמות לגרסה 1.36, אפשר להפעיל ידנית את התכונה 'חלוקת משנה של GKE' כשיוצרים אשכול או מעדכנים אשכול קיים. אחרי שמפעילים את התכונה 'חלוקת משנה של GKE', אי אפשר להשבית אותה.

כדי להשתמש בתכונה 'חלוקה לתתי-קבוצות' ב-GKE, צריך:

• גרסה ‎1.18.19-gke.1400 ואילך של GKE, וגם
• אם האשכול שלכם הוא מגרסה קודמת ל-1.36, צריך להפעיל את התוסף HttpLoadBalancing. התוסף הזה מופעל כברירת מחדל. היא מאפשרת לאשכול לנהל מאזני עומסים שמשתמשים בשירותים לקצה העורפי. אם האשכול שלכם הוא בגרסה 1.36 ומעלה, התוסף HttpLoadBalancing לא נדרש לחלוקת משנה של GKE.

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

מספר הצמתים

אם ההגדרה של חלוקת משנה ב-GKE מושבתת באשכול, יכולות להיות בעיות בשירותים פנימיים של LoadBalancer אם באשכול יש יותר מ-250 צמתים בסך הכול (בכל מאגרי הצמתים). הסיבה לכך היא שמאזני עומסים פנימיים להעברת סיגנל ללא שינוי שנוצרו על ידי GKE יכולים להפיץ חבילות רק ל-250 מכונות וירטואליות או פחות של צמתי בק-אנד. המגבלה הזו קיימת בגלל שתי הסיבות הבאות:

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

אשכול עם חלוקת משנה של GKE תומך בשירותי LoadBalancer פנימיים באשכולות עם יותר מ-250 צמתים בסך הכול.

מספר הצמתים שנתמכים בחלוקת משנה של GKE תלוי בערך של השדה externalTrafficPolicy בשירות הפנימי LoadBalancer:

• ‫externalTrafficPolicy: Local: תומך בעד 250 צמתים עם פודים של שרתים לשירות נתון.

• ‫externalTrafficPolicy: Cluster: לא מגביל את מספר הצמתים עם Pods להצגת מודעות. הסיבה לכך היא ש-GKE מגדיר לכל שירות עד 25 נקודות קצה של צמתים ב-GCE_VM_IP NEGs. מידע נוסף זמין במאמר בנושא חברות של צמתים ב-GCE_VM_IP backends של NEG.

ביזור תעבורת נתונים

כברירת מחדל, שירותי LoadBalancer פנימיים וחיצוניים יוצרים מאזני עומסי רשת להעברת סיגנל ללא שינוי עם זיקה לסשן שמוגדרת לערך NONE. מאזני עומסים מסוג Passthrough Network משתמשים בהעדפה של סשנים, במידע על תקינות ובפרטים כמו משקל (בנסיבות מסוימות) כדי לזהות ולבחור קצה עורפי של צומת שעומד בדרישות לחיבור חדש.

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

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

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

השפעה של איזון עומסים משוקלל

כשמגדירים איזון עומסים לפי משקל לשירות מאזן עומסים חיצוני, מערכת GKE מפעילה איזון עומסים לפי משקל במאזן עומסי רשת חיצוני אזורי תואם להעברת סיגנל ללא שינוי. ‫GKE מגדיר את התוכנה kube-proxy או cilium-agent כך שתכלול כותרת תגובה בתשובה לבדיקת תקינות של איזון העומסים. כותרת התגובה הזו מגדירה משקל שפרופורציונלי למספר הפודים (Pods) שמוכנים להצגה, שמוכנים לשימוש ושלא מסיימים את הפעולה בכל צומת.

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

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

• מאזן העומסים מביא בחשבון את המשקל כשהוא בוחר באחד מהקצוות העורפיים של הצמתים שעומדים בדרישות. כשמשתמשים ב-externalTrafficPolicy: Local (נדרש כדי שמאזן העומסים המשוקלל יהיה יעיל), סביר יותר שייבחר בק-אנד של צומת שעומד בדרישות ויש בו יותר פודים שמוכנים להצגה ולא מסיימים את הפעולה, מאשר בק-אנד של צומת שעומד בדרישות ויש בו פחות פודים.

קיבוץ צמתים

גרסת GKE, הערות במניפסט של השירות, ובשירותים של מאזן עומסים פנימי, האפשרות GKE subsetting קובעות את מאזן העומסים שמתקבל Google Cloud ואת סוגי השרתים העורפיים.

בטבלה הבאה מפורטות שיטות הקיבוץ של הצמתים עבור הגדרות שונות של שירות LoadBalancer:

פרטי השירות והאשכול	מאזן העומסים Google Cloud שנוצר	שיטת קיבוץ הצמתים
שירותים פנימיים של מאזן עומסים
גרסה 1.33.1-gke.1779000 של GKE ואילך באשכול עם הפעלה של חלוקת משנה של GKE ^1. מניפסט השירות נשלח לאשכול עם spec.loadBalancerClass: "networking.gke.io/l4-regional-internal".	מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, שהשירות לקצה העורפי שלו משתמש בקצה עורפי מסוג GCE_VM_IP קבוצה של נקודות קצה ברשת (NEG)	המכונות הווירטואליות של הצמתים מקובצות בGCE_VM_IP NEGs אזוריים על בסיס כל שירות, בהתאם לexternalTrafficPolicy של השירות ולמספר הצמתים באשכול. ה-externalTrafficPolicy של השירות גם קובע אילו צמתים עוברים את בדיקת התקינות של מאזן העומסים וגם את עיבוד החבילות.
כל גרסאות GKE הנתמכות באשכול עם הפעלה של חלוקת משנה של GKE^1. מניפסט השירות שנשלח לאשכול עם ההערה networking.gke.io/load-balancer-type: "Internal".
גרסאות GKE לפני 1.36 באשכול שבו מושבת^1 חלוקת המשנה של GKE. מניפסט השירות שנשלח לאשכול עם ההערה networking.gke.io/load-balancer-type: "Internal".	מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, שבו השירות לקצה העורפי משתמש בקצה עורפי של קבוצת מופעים לא מנוהלת אזורית	כל המכונות הווירטואליות של הצמתים ממוקמות בקבוצות של מכונות לא מנוהלות באזור, ש-GKE משתמש בהן כשרתי קצה (backend) לשירות הקצה של מאזן העומסים הפנימי של הרשת להעברת סיגנל ללא שינוי. ה-externalTrafficPolicy של השירות קובע אילו צמתים עוברים את בדיקת התקינות של איזון העומסים וגם את עיבוד החבילות. אותן קבוצות לא מנוהלות של מופעי מכונה משמשות לשירותים אחרים לקצה העורפי של מאזן העומסים שנוצרו באשכול, בגלל ההגבלה של קבוצת מופעי מכונה אחת עם איזון עומסים.
שירותים חיצוניים של מאזן עומסים
‫GKE בגרסה ‎1.33.1-gke.1779000 ואילך. מניפסט של שירות שנשלח לאשכול עם spec.loadBalancerClass: "networking.gke.io/l4-regional-external".	מאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות לקצה העורפי עם קצוות עורפיים של GCE_VM_IP קבוצת נקודות קצה ברשת (NEG)	המכונות הווירטואליות של הצמתים מקובצות בGCE_VM_IP NEGs אזוריים על בסיס כל שירות, בהתאם לexternalTrafficPolicy של השירות ולמספר הצמתים באשכול. ה-externalTrafficPolicy של השירות גם קובע אילו צמתים עוברים את בדיקת התקינות של מאזן העומסים וגם את עיבוד החבילות.
‫GKE בגרסה ‎1.32.2-gke.1652000 ומעלה. מניפסט של שירות שנשלח לאשכול עם ההערה cloud.google.com/l4-rbs: "enabled"^2.
גרסת GKE לפני ‎1.32.2-gke.1652000^3. מניפסט של שירות שנשלח לאשכול עם ההערה cloud.google.com/l4-rbs: "enabled"^2.	מאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות לקצה העורפי עם קצה עורפי של קבוצת מופעים לא מנוהלת אזורית	כל המכונות הווירטואליות של הצמתים ממוקמות בקבוצות של מכונות וירטואליות לא מנוהלות באזורים, ש-GKE משתמש בהן כבק-אנד לשירות הבק-אנד של מאזן עומסי הרשת החיצוניים האזוריים להעברת סיגנל ללא שינוי. הערך externalTrafficPolicy של השירות קובע אילו צמתים עוברים את בדיקת התקינות של מאזן העומסים ואת עיבוד המנות. אותן קבוצות לא מנוהלות של מופעי מכונה משמשות לשירותים אחרים לקצה העורפי של מאזן העומסים שנוצרו באשכול, בגלל ההגבלה של קבוצת מופעי מכונה אחת עם איזון עומסים.
כל הגרסאות הנתמכות של GKE. מניפסט שירות שנשלח לאשכול בלי כל הפריטים הבאים: spec.loadBalancerClass הערה אחת (networking.gke.io/load-balancer-type) הערה אחת (cloud.google.com/l4-rbs)	מאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי שמבוסס על מאגר יעד, שמאגר היעד שלו מכיל את כל הצמתים של האשכול	מאגר היעדים הוא API ישן יותר שלא מסתמך על NEGs או על קבוצות של מכונות וירטואליות. לכל הצמתים יש חברות ישירה במאגר היעד. הערך externalTrafficPolicy של השירות קובע אילו צמתים עוברים את בדיקת התקינות של מאזן העומסים ואת עיבוד המנות.

‫¹הגדרת חלוקת המשנה של GKE מופעלת אוטומטית ב-GKE מגרסה 1.36 ואילך. אי אפשר להשבית את תכונת חלוקת המשנה ב-GKE אחרי שמפעילים אותה.

‫²ההערה cloud.google.com/l4-rbs: "enabled" מתקבלת רק כשמגישים את מניפסט השירות לאשכול. הוספת ההערה הזו למניפסט של שירות קיים לא ממירה מאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי שמבוסס על מאגר יעד למאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות קצה עורפי.

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

חברות של צומת בקצה העורפי של GCE_VM_IP NEG

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

• ‫GKE יוצר GCE_VM_IP NEG ייחודי בכל אזור לכל LoadBalancer Service. בניגוד לקבוצות של מכונות, צמתים יכולים להיות חברים ב-NEG עם איזון עומסים GCE_VM_IP אחד או יותר.

• הexternalTrafficPolicy של השירות ומספר הצמתים באשכול קובעים אילו צמתים יתווספו כנקודות קצה ל-GCE_VM_IPNEG של השירות.

הערה: GCE_VM_IP NEGs שונים מ-GCE_VM_IP_PORT NEGs. GCE_VM_IP_PORT קבוצות NEG מכילות נקודות קצה של יציאות של קונטיינרים וכתובות IP של Pod, והן משמשות את Gateway ו-Ingress (מקומי לקונטיינר). GCE_VM_IP קבוצות NEGs מזהות ממשקי רשת של מכונות וירטואליות של צמתים באמצעות כתובת ה-IP של הצומת, למרות שלמנות שמתחלקות בין מאזני עומסים יש יעדים שתואמים לכתובת ה-IP של כלל ההעברה של מאזן העומסים ולאחת מהיציאות שהוגדרו לכלל ההעברה.

מישור הבקרה של האשכול מנהל את נקודות הקצה של הצמתים ב-GCE_VM_IP NEGs בהתאם לערך של externalTrafficPolicy של השירות ולמספר הצמתים באשכול, כפי שמסוכם בטבלאות הבאות.

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

externalTrafficPolicy	מספר הצמתים באשכול	חברות במועדון של נקודת קצה
Cluster	‫1 עד 25 צמתים	‫GKE משתמש בכל הצמתים באשכול כנקודות קצה עבור ה-NEG של השירות, גם אם צומת מסוים לא מכיל Pod של שרת עבור השירות.
Cluster	יותר מ-25 צמתים	‫GKE משתמש בקבוצת משנה אקראית של עד 25 צמתים כנקודות קצה עבור קבוצות ה-NEG של השירות, גם אם צומת מסוים לא מכיל Pod של שרת עבור השירות.
Local	כל מספר של צמתים^1	‫GKE משתמש רק בצמתים שיש להם לפחות אחד מה-Pods של השירות כנקודות קצה עבור ה-NEG של השירות.

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

צמתים במאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי

externalTrafficPolicy	מספר הצמתים באשכול	חברות במועדון של נקודת קצה
Cluster	צומת אחד עד 250 צמתים	‫GKE משתמש בכל הצמתים באשכול כנקודות קצה עבור ה-NEG של השירות, גם אם צומת מסוים לא מכיל Pod של שרת עבור השירות.
Cluster	יותר מ-250 צמתים	‫GKE משתמש בקבוצת משנה אקראית של עד 250 צמתים כנקודות קצה עבור ה-NEG של השירות, גם אם צומת לא מכיל Pod של שרת עבור השירות.
Local	כל מספר של צמתים^1	‫GKE משתמש רק בצמתים שיש להם לפחות אחד מה-Pods של השירות כנקודות קצה עבור ה-NEG של השירות.

‫¹מוגבל ל-3,000 צמתים עם Pods להצגת מודעות. יכולים להיות יותר מ-3,000 צמתים באשכול, אבל GKE תומך ביצירה של עד 3,000 נקודות קצה כשיוצרים מאזני עומסים אזוריים חיצוניים של רשתות להעברת סיגנל ללא שינוי שמבוססים על שירותי קצה עורפיים של GCE_VM_IP NEG.

מגבלה על קבוצת מופעי מכונה עם איזון עומסים

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

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

• מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי שנוצר עבור שירות LoadBalancer פנימי, שמניפסט שלו כולל את ההערה networking.gke.io/load-balancer-type: "Internal", ונשלח לאשכול שפועלת בו גרסת GKE לפני 1.36, כשההגדרה GKE subsetting מושבתת.
• מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי שמבוסס על שירות קצה עורפי ונוצר עבור שירות LoadBalancer חיצוני, שהמניפסט שלו כולל את ההערה cloud.google.com/l4-rbs: "enabled", ונשלח לאשכול שמריץ גרסת GKE לפני 1.32.2-gke.1652000.
• מאזן עומסים חיצוני של אפליקציות (ALB) שנוצר עבור GKE Ingress חיצוני, באמצעות בקר GKE Ingress, אבל לא באמצעות איזון עומסים מקורי של קונטיינרים.

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

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

כדי לעקוף את ההגבלה הזו, אפשר להנחות את GKE להשתמש ב-backends של NEG:

• יוצרים שירותים של LoadBalancer שמשתמשים ב-GCE_VM_IP NEGs. מידע נוסף זמין במאמר בנושא קיבוץ צמתים.
• הגדרת משאבי GKE Ingress חיצוניים לשימוש באיזון עומסים מקורי של קונטיינרים. מידע נוסף זמין במאמר בנושא איזון עומסים ב-GKE שמותאם לשימוש בקונטיינרים.

בדיקות תקינות של מאזן עומסים

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

חבילות של בדיקות תקינות של איזון עומסים מקבלות מענה מתוכנת kube-proxy (בקטעים שלא משתמשים ב-GKE Dataplane V2) או מתוכנת cilium-agent (בקטעים עם GKE Dataplane V2) שפועלת בכל צומת. אי אפשר להשיב על בדיקות תקינות של מאזן עומסים לשירותי LoadBalancer באמצעות Pods.

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

externalTrafficPolicy	אילו צמתים עוברים את בדיקת התקינות	באיזו יציאה נעשה שימוש
Cluster	כל הצמתים באשכול עוברים את בדיקת התקינות, כולל צמתים ללא Pods של שרתים. אם קיים לפחות Pod אחד של שרת בצומת, הצומת הזה עובר את בדיקת התקינות של מאזן העומסים, ללא קשר למצב של ה-Pod.	יציאת בדיקת התקינות של מאזן העומסים חייבת להיות יציאת TCP מספר 10256. אי אפשר להתאים אותו אישית.
Local	בבדיקת התקינות של מאזן העומסים, צומת נחשב תקין אם קיים בצומת לפחות Pod אחד מוכן ולא מסתיים, ללא קשר למצב של Pods אחרים. צמתים ללא Pod להצגת תוכן, צמתים שכל ה-Pods להצגת התוכן שלהם נכשלים בבדיקות המוכנות וצמתים שכל ה-Pods להצגת התוכן שלהם נמצאים בתהליך סיום, נכשלים בבדיקת התקינות של מאזן העומסים. במהלך מעברים בין מצבים, הצומת עדיין עובר את בדיקת תקינות של מאזן העומסים עד שמגיעים לסף של בדיקת התקינות של מאזן העומסים. מצב המעבר מתרחש כשכל ה-Pods של שרת בצומת מתחילים להיכשל בבדיקות המוכנות, או כשכל ה-Pods של שרת בצומת מסיימים את הפעולה. אופן העיבוד של המנה במצב הזה תלוי בגרסת GKE. פרטים נוספים זמינים בקטע הבא, עיבוד מנות.	רמת הבקרה של Kubernetes מקצה את יציאת בדיקת התקינות מטווח יציאות הצמתים, אלא אם מציינים יציאה מותאמת אישית לבדיקת התקינות.

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

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

בדיקת תקינות של MIG לעומת NEG

סוג הקצה העורפי שבו משתמשים בשירות LoadBalancer קובע איך Google Cloud מגדיר ומבצע בדיקות תקינות של מאזן העומסים:

• חלוקת משנה של GKE (קצה עורפי של NEG): אם השירות שלכם משתמש בGCE_VM_IP קבוצות של נקודות קצה ברשת (NEGs) – למשל, אם חלוקת המשנה של GKE מופעלת –‏ GKE מגדיר בדיקות תקינות אזוריות. ב-NEGs אזוריים, בקשות לבדיקות תקינות (probes) מכוונות ישירות ליציאה של השירות.
• הגדרות של קבוצות מופעי מכונה (MIG backends): כשבשירות שלכם נעשה שימוש בקבוצות מופעי מכונה לא מנוהלים (MIG) כ-backends, ‏ GKE מגדיר בדיקות תקינות גלובליות. במקרה של קבוצות של מכונות, בדיקות תקינות מכוונות ל-nodePort שהוקצה לשירות.

פתרון בעיות שקשורות לכשלים בבדיקות התקינות

אם השרתים העורפיים של מאזן העומסים מדווחים על מצב לא תקין (לדוגמה, אם הסמל 0/X healthy מוצג במסוף Google Cloud ), כדאי לבדוק את הסיבות הנפוצות הבאות:

• כללי חומת אש חסרים: מאזני עומסים מסוג Google Cloud דורשים כללי חומת אש שמאפשרים תעבורת נתונים נכנסת (ingress) כדי לאפשר לניסויי בדיקת תקינות מטווח כתובות ה-IP של בדיקת התקינות של Google (למשל 130.211.0.0/22 ו-35.191.0.0/16) להגיע לצמתי האשכול. אם כללי חומת האש האלה נמחקים או משתנים, בדיקות תקינות נכשלות.
• אי התאמה ביציאת היעד של הבדיקה: כל כללי אבטחת הרשת המותאמים אישית או הגדרות חומת האש ברמת הצומת צריכים להתייחס ליציאת היעד הנכונה של בדיקת התקינות. במקרים של קצה עורפי של NEG, הבדיקות מכוונות ישירות ליציאה של השירות, אבל במקרים של קצה עורפי של קבוצת מופעי מכונה מנוהלים (MIG), הבדיקות מכוונות ל-nodePort. חוסר התאמה בהגדרת היציאה הצפויה גורם לכך שהבדיקות נכשלות.
• התנהגות של externalTrafficPolicy: Local: אם השירות מוגדר עם ההגדרה externalTrafficPolicy: Local, הצמתים שלא מארחים Pod מוכן שמשרת את השירות הזה נכשלים בכוונה בבדיקת תקינות מאזן העומסים. אם כל ה-Pods בשירות לא מוכנים או נמצאים בתהליך סיום בכל האשכול, כל צמתי ה-Backend מדווחים כלא תקינים (0/X healthy).

עיבוד מנות

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

איזון עומסים מסוג Pass-through

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

• כתובת ה-IP של היעד של החבילה תואמת לכתובת ה-IP של כלל ההעברה של מאזן העומסים.
• הפרוטוקול ויציאת היעד של החבילה תואמים לשני התנאים הבאים:
  • פרוטוקול ויציאה שצוינו ב-spec.ports[] של מניפסט השירות
  • פרוטוקול ויציאה שהוגדרו בכלל ההעברה של מאזן העומסים

תרגום כתובת רשת ביעד בצמתים

אחרי שהצומת מקבל את החבילה, הוא מבצע עיבוד נוסף של החבילה. באשכולות GKE שלא משתמשים ב-GKE Dataplane V2, הצמתים משתמשים ב-iptables כדי לעבד חבילות של איזון עומסים. באשכולות GKE שבהם מופעל GKE Dataplane V2, הצמתים משתמשים ב-eBPF במקום זאת. עיבוד המנות ברמת הצומת תמיד כולל את הפעולות הבאות:

• הצומת מבצע תרגום כתובות רשת של היעד (DNAT) בחבילה, ומגדיר את כתובת ה-IP של היעד לכתובת IP של Pod שמשרת את הבקשה.
• הצומת משנה את יעד היציאה של החבילה ל-targetPort של spec.ports[] התואם של השירות.

תרגום כתובות רשת (NAT) וניתוב בצמתים

בטבלה הבאה מוצג הקשר בין externalTrafficPolicyלבין השאלה אם הצומת שקיבל מנות מאוזנות עומס מבצע תרגום של כתובת רשת המקור (SNAT) לפני שליחת המנות מאוזנות העומס אל Pod:

externalTrafficPolicy	התנהגות SNAT
Cluster	באשכולות GKE שלא משתמשים ב-GKE Dataplane V2, כל צומת שקיבל מנות מאוזנות עומסים תמיד משנה את כתובת ה-IP של המקור של המנות כך שתתאים לכתובת ה-IP של הצומת, בין אם הצומת מנתב את המנות ל-Pod מקומי או ל-Pod בצומת אחר. באשכולות GKE שמשתמשים ב-GKE Dataplane V2, כל צומת שקיבל מנות מאוזנות עומס משנה את כתובת ה-IP של המקור של המנות האלה כך שתתאים לכתובת ה-IP של הצומת רק אם הצומת המקבל מנתב את המנות אל Pod בצומת שונה. אם הצומת שקיבל מנות מאוזנות עומס מעביר את המנות אל Pod מקומי, הצומת לא משנה את כתובת ה-IP של המקור של המנות האלה.
Local	כל צומת שמקבל מנות מאוזנות עומסים מעביר את המנות באופן בלעדי לתא מקומי, והצומת לא משנה את כתובת ה-IP של המקור של המנות האלה.

בטבלה הבאה מוצגות דרכי הפעולה של externalTrafficPolicy כשמדובר במנות מאוזנות עומס ובמנות תגובה:

externalTrafficPolicy	ניתוב חבילות עם איזון עומסים	ניתוב מנות של תשובות
Cluster	זוהי התנהגות הבסיס לניתוב מנות מאוזנות עומסים: אם לצומת שקיבל מנות מאוזנות עומס אין Pod פעיל, מוכן ולא מסתיים, הצומת הזה מעביר את המנות לצומת אחר שיש לו Pod פעיל, מוכן ולא מסתיים. אם בצומת שקיבל מנות מאוזנות עומסים יש Pod שמוכן להפעלה, לא מסתיים ומוכן להפעלה, הצומת עשוי לנתב את המנות לאחת מהאפשרויות הבאות: פוד מקומי. צומת אחר עם Pod שמוכן להצגה, לא מסתיים ומוכן להצגה. באשכולות אזוריים, אם הצומת שקיבל מנות מאוזנות עומסים מעביר מנות לצומת אחר, ההשפעה של הקרבה לאזור היא כדלקמן: אם לא מפעילים את ההגדרה 'שייכות לאזור', יכול להיות שהצומת השונה יהיה בכל אזור. אם האפשרות 'זיקה אזורית' מופעלת, הצומת שקיבל חבילות מאוזנות עומסים מנסה לנתב אותן לצומת אחר באותו אזור. אם זה לא אפשרי, יכול להיות שהצומת השונה נמצא באזור כלשהו. כמוצא אחרון, אם אין פודים פעילים, מוכנים ולא מסיימים את הפעולה בשביל השירות בכל הצמתים באשכול, יקרה הדבר הבא: אם האפשרות Proxy Terminating Endpoints (נקודות קצה לניתוק פרוקסי) מופעלת^1, הצומת שקיבל חבילות מאוזנות עומסים מעביר אותן ל-Pod שמשרת, אבל מנתק אם אפשר. אם האפשרות Proxy Terminating Endpoints מושבתת, או אם אין פודים באשכול כולו, הצומת שקיבל מנות מאוזנות עומס סוגר את החיבור באמצעות איפוס TCP.	חבילות התגובה תמיד נשלחות מצומת באמצעות Direct Server Return: אם הצומת עם ה-Pod שמשרת את הבקשות הוא לא הצומת שקיבל את חבילות מאוזנות העומסים התואמות, הצומת שמשרת את הבקשות שולח את חבילות התגובה בחזרה לצומת המקבל. לאחר מכן, הצומת המקבל שולח את מנות התגובה באמצעות החזרת נתונים ישירה מהשרת. אם הצומת עם ה-Pod להצגת התוכן הוא הצומת שקיבל את החבילות עם איזון העומסים, הצומת הזה שולח את חבילות התגובה באמצעות החזרה ישירה מהשרת.
Local	ההתנהגות הבסיסית של ניתוב חבילות עם איזון עומסים היא כזו: בדרך כלל, לצומת שקיבלה חבילות עם איזון עומסים יש Pod פעיל, מוכן ולא מסתיים (כי נדרש Pod כזה כדי לעבור את בדיקת תקינות מאזן העומסים). הצמתים מעבירים מנות מאוזנות עומסים ל-Pod מקומי. בקטגוריות אזוריות, קרבה אזורית לא משנה את התנהגות הבסיס של ניתוב מנות מאוזנות עומס. כמוצא אחרון, אם אין פודים של Service במצב serving או ready, או פודים שלא מסיימים את הפעולה שלהם בצומת שקיבל מנות מאוזנות עומס, קורה הדבר הבא: אם האפשרות Proxy Terminating Endpoints מופעלת^1, הצומת שקיבל מנות מאוזנות עומס מעביר אותן ל-Pod מקומי שמשרת את הבקשה, אבל מסיים את הבקשה אם אפשר. אם האפשרות Proxy Terminating Endpoints מושבתת, או אם לצומת שקיבלה מנות מאוזנות עומס אין אף Pod שמוכן להצגת נתונים, הצומת הזו סוגרת את החיבור עם איפוס TCP.	הצומת עם ה-Pod שמציג את המודעות הוא תמיד הצומת שקיבל את החבילות עם איזון העומסים, והצומת הזה שולח את חבילות התגובה באמצעות Direct Server Return (החזרת נתונים ישירות מהשרת).

‫¹ ההגדרה Proxy Terminating Endpoints (נקודות קצה שמסיימות את הפעולה של שרת ה-Proxy) מופעלת בהגדרות הבאות:

• אשכולות GKE שלא משתמשים ב-GKE Dataplane V2: GKE גרסה 1.26 ואילך
• אשכולות GKE שמשתמשים ב-GKE Dataplane V2: GKE גרסה 1.26.4-gke.500 ואילך

מכסות

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

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

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

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