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

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

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

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

סקירה כללית

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

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

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

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

איור: עץ החלטות לבחירת שירות 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, מוסיפים את 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 שמשרתים באותו אזור כמו הלקוח. אם אין 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 subsetting מופעלת באשכול. לכל שירות יש שני Pods. ‫GKE יוצר GCE_VM_IP NEG אחד לכל Service. נקודות הקצה (Endpoints) בכל NEG הן הצמתים עם ה-Pods שמשרתים את השירות המתאים.

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

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

• ‫GKE גרסה ‎1.18.19-gke.1400 ואילך, ו
• אם האשכול שלכם הוא מגרסה קודמת ל-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 כך שתכלול כותרת תגובה בתשובה לבדיקת תקינות של איזון העומסים. כותרת התגובה הזו מגדירה משקל שפרופורציונלי למספר הפודים שמוכנים להצגה ולא מסיימים את הפעולה בכל צומת.

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

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

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

קיבוץ צמתים

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

בטבלה הבאה מפורטות שיטות הקיבוץ של הצמתים עבור הגדרות שונות של שירות 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 הנתמכות באשכול עם הפעלה של חלוקת משנה של 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_IPבק-אנד של קבוצת נקודות קצה ברשת (NEG).

חברות של צומת בקצה העורפי של 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 (Dataplane מדור קודם) או cilium-agent (GKE Dataplane V2) שפועל בכל צומת. אי אפשר להשיב על בדיקות תקינות של מאזן עומסים לשירותי LoadBalancer באמצעות Pods.

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

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

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

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

עיבוד מנות

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

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

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

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

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

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

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

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

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

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

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

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

‫¹ ההגדרה Proxy Terminating Endpoints מופעלת בהגדרות הבאות:

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

תמחור ומכסות

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

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

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

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

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