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

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

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

סקירה כללית

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

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

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

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

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

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

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

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

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

  • באשכולות שמופעלת בהם גרסה נתמכת של GKE, אפשר להוסיף את ההערה cloud.google.com/l4-rbs: "enabled" למניפסט של השירות לפני ששולחים את המניפסט לאשכול. ההערה הזו יוצרת גם מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות backend. מאזן העומסים משתמש ב-GCE_VM_IP NEG backends אם המניפסט נשלח לאשכול שמריץ 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 המקורית של המקור של הלקוח. האפשרות הזו מתאימה לעומסי עבודה עם מספר יחסית קבוע של צמתים עם יחידות Pod של שרתים, גם אם המספר הכולל של הצמתים באשכול משתנה. האפשרות הזו נדרשת כדי לתמוך באיזון עומסים משוקלל.

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

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

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

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

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

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

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

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

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

  • באשכולות שמופעלת בהם גרסה נתמכת של 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'.

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

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

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

GKE subsetting

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

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

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

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

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

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

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

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

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

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

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

קיבוץ צמתים

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

חברות בצומת בבקאנד של GCE_VM_IP NEG

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

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

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

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

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

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

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

externalTrafficPolicy	מספר הצמתים באשכול	חברות במועדון של נקודת קצה
Cluster	צומת אחד עד 250 צמתים	‫GKE משתמש בכל הצמתים באשכול כנקודות קצה עבור ה-NEG של השירות, גם אם צומת מסוים לא מכיל Pod של שרת עבור השירות.
Cluster	יותר מ-250 צמתים	‫GKE משתמש בקבוצת משנה אקראית של עד 250 צמתים כנקודות קצה עבור ה-NEG של השירות, גם אם צומת לא מכיל Pod של שרת עבור השירות.
Local	כל מספר של צמתים1	‫GKE משתמש רק בצמתים שיש להם לפחות אחד מה-Pods של השירות כנקודות קצה עבור ה-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 אחרים. צמתים ללא Pod להצגת תוכן, צמתים שכל ה-Pods להצגת התוכן שלהם נכשלים בבדיקות המוכנות וצמתים שכל ה-Pods להצגת התוכן שלהם נמצאים בתהליך סיום, נכשלים בבדיקת התקינות של מאזן העומסים. במהלך מעברים בין מצבים, צומת עדיין עובר את בדיקת התקינות של מאזן העומסים עד שמגיעים לסף של בדיקת התקינות של מאזן העומסים. מצב המעבר מתרחש כשכל ה-Pods של השרת בצומת מתחילים להיכשל בבדיקות המוכנות, או כשכל ה-Pods של השרת בצומת מסיימים את הפעולה. אופן העיבוד של המנה במצב הזה תלוי בגרסת GKE. פרטים נוספים זמינים בקטע הבא, עיבוד מנות.	רמת הבקרה של Kubernetes מקצה את היציאה של בדיקת התקינות מתוך טווח היציאות של הצומת, אלא אם מציינים יציאה מותאמת אישית לבדיקת התקינות.

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

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

עיבוד מנות

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

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

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

תמחור ומכסות

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

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

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

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

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