מידע על שירותי 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.37 ואילך, GKE יוצר באופן אוטומטי מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי שמבוסס על שירות לקצה העורפי עם קצוות עורפיים של GCE_VM_IP NEG. אין צורך להוסיף הערות או שדות למניפסט של השירות. כדי ליצור באופן מפורש מאזן עומסים מדור קודם שמבוסס על מאגר יעדים, מוסיפים את צמד השדה והערך spec.loadBalancerClass: "networking.gke.io/l4-regional-external-legacy".

  • באשכולות שבהם פועלת גרסת GKE ‏1.33.1-gke.1779000 עד 1.36, צריך להוסיף את 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, מוסיפים את spec.loadBalancerClass: "networking.gke.io/l4-regional-internal" למניפסט של השירות לפני ששולחים את המניפסט לאשכול. מומלץ להשתמש בשדה הזה כי הוא תמיד יוצר מאזן עומסי רשת פנימי מסוג passthrough עם קצה עורפי של GCE_VM_IP NEG. אי אפשר לשנות את השדה spec.loadBalancerClass אחרי שיוצרים את השירות.

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

באשכולות שבהם פועלות גרסאות GKE שקודמות ל-1.37, מניפסטים של שירות LoadBalancer שאין להם 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 כדי לוודא שחבילות מועברות רק לצומת עם לפחות פוד אחד שמוכן להצגה ולא מסתיים, תוך שמירה על כתובת ה-IP המקורית של המקור של הלקוח. האפשרות הזו מתאימה במיוחד לעומסי עבודה עם מספר קבוע יחסית של צמתים עם Pods להצגת מודעות, גם אם המספר הכולל של הצמתים באשכול משתנה. האפשרות הזו נדרשת כדי לתמוך באיזון עומסים משוקלל.

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

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

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

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

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

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

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

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

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

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

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

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

  • באשכולות שמריצים GKE 1.33.1-gke.1779000 עד 1.36, מוסיפים את 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 Service צריך להשתמש ב-externalTrafficPolicy: Local. ב-GKE אפשר להשתמש ב-externalTrafficPolicy: Cluster, אבל externalTrafficPolicy: Cluster משבית בפועל את חלוקת העומסים המשוקללת, כי יכול להיות שהחבילה תנותב לצומת אחר אחרי מאזן העומסים.

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

זיקה לאזור

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

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

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

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

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

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

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

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

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

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

GKE subsetting

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

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

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

באשכולות שפועלים בגרסאות שקודמות ל-1.36, אפשר להפעיל באופן ידני את GKE subsetting כשיוצרים אשכול או מעדכנים אשכול קיים. אחרי שמפעילים את הגדרת קבוצת המשנה ב-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 NEG backends.

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

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

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

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

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

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

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

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

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

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

קיבוץ צמתים

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

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

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

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

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

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

חברות של צומת ב-GCE_VM_IP NEG backends

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

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

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

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

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

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

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

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

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

externalTrafficPolicy	מספר הצמתים באשכול	חברות במועדון של נקודת קצה
Cluster	‫1 עד 250 צמתים	‫GKE משתמש בכל הצמתים באשכול כנקודות קצה של קבוצות נקודות הקצה של השירות, גם אם הצומת לא מכיל 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 לא יכול ליצור ולנהל מאזני עומסי רשת פנימיים להעברת נתונים, מאזני עומסי רשת חיצוניים אזוריים שמבוססים על שירות לקצה העורפי ומאזני עומסים של אפליקציות (ALB) חיצוניים שנוצרו בשביל משאבי Ingress של GKE, אם מתקיים אחד מהתנאים הבאים:true

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

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

• יוצרים שירותי LoadBalancer שמשתמשים בקבוצות GCE_VM_IP של נקודות קצה ברשת. למידע נוסף, קראו את המאמר קיבוץ צמתים.
• הגדרת משאבי 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 מקצה את היציאה של בדיקת התקינות מטווח היציאות של הצומת, אלא אם מציינים יציאה מותאמת אישית לבדיקת התקינות.

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

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

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

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

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

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

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

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

עיבוד מנות

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

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

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

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

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

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

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

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

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

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

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

externalTrafficPolicy	ניתוב מנות עם איזון עומסים	ניתוב מנות של תשובות
Cluster	זוהי התנהגות הבסיס לניתוב מנות מאוזנות עומסים: אם לצומת שקיבל חבילות עם איזון עומסים אין Pod פעיל, מוכן ולא מסתיים, הצומת הזה מנתב את החבילות לצומת אחר שיש לו Pod פעיל, מוכן ולא מסתיים. אם בצומת שקיבל חבילות עם איזון עומסים יש Pod שמוכן להפעלה, לא מסתיים ומוכן להגשה, הצומת עשוי לנתב את החבילות לאחת מהאפשרויות הבאות: פוד מקומי. צומת אחר עם Pod מוכן, לא מסתיים ופעיל. באשכולות אזוריים, אם הצומת שקיבל מנות מאוזנות עומסים מעביר מנות לצומת אחר, ההשפעה של הקרבה לאזור היא כדלקמן: אם לא מפעילים את הזיקה לאזור, הצומת האחר יכול להיות בכל אזור. אם האפשרות 'זיקה אזורית' מופעלת, הצומת שקיבל חבילות עם איזון עומסים מנסה לנתב אותן לצומת אחר באותו אזור. אם זה לא אפשרי, יכול להיות שהצומת השונה נמצא באזור כלשהו. אם אין פודים פעילים, מוכנים ולא מסתיימים של השירות בכל הצמתים באשכול, קורה הדבר הבא: אם מופעלת האפשרות Proxy Terminating Endpoints^1, הצומת שקיבל חבילות עם איזון עומסים מנתב אותן לפוד שמספק שירות אבל מסתיים, אם אפשר. אם האפשרות Proxy Terminating Endpoints מושבתת, או אם אין פודים באשכול כולו, הצומת שקיבל מנות מאוזנות עומס סוגר את החיבור באמצעות איפוס TCP.	חבילות התגובה תמיד נשלחות מצומת באמצעות Direct Server Return (החזרה ישירה של השרת): אם הצומת עם ה-Pod שמשרת את הבקשה הוא לא הצומת שקיבל את חבילות מאזן העומסים התואמות, הצומת שמשרת את הבקשה שולח את חבילות התגובה בחזרה לצומת המקבל. לאחר מכן, הצומת המקבל שולח את מנות התגובה באמצעות החזרת נתונים ישירה מהשרת. אם הצומת עם ה-Pod שמספק את השירות הוא הצומת שקיבל את החבילות שחולקו, הצומת הזה שולח את חבילות התגובה באמצעות Direct Server Return.
Local	ההתנהגות הבסיסית של ניתוב חבילות עם איזון עומסים היא כזו: בדרך כלל, לצומת שקיבלה חבילות עם איזון עומסים יש Pod מוכן, לא מסתיים ופעיל (כי נדרש Pod כזה כדי לעבור את בדיקת התקינות של מאזן העומסים). הצומת מנתב חבילות עם איזון עומסים ל-Pod מקומי. באשכולות אזוריים, שיוך לאזור לא משנה את התנהגות ברירת המחדל של ניתוב חבילות עם איזון עומסים. כמוצא אחרון, אם אין פודים פעילים, מוכנים ולא מסיימים את הפעולה בשביל השירות בצומת שקיבל מנות מאוזנות עומס, מתרחש הדבר הבא: אם האפשרות 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 ואילך

תמחור ומכסות

התמחור של הרשת חל על מנות נתונים (packets) שעוברות עיבוד על ידי מאזן עומסים. מידע נוסף זמין במאמר בנושא תמחור של Cloud Load Balancing וכללי העברה. אפשר גם להשתמש ב Google Cloud מחשבון התמחור כדי להעריך את החיובים.

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

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

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

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