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

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

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

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

סקירה כללית

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

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

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

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

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

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

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

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

  כשיוצרים שירות LoadBalancer ולא מציינים הגדרות מותאמות אישית, זו ההגדרה שמוגדרת כברירת מחדל.

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

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

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

  כדי ליצור שירות LoadBalancer פנימי:

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

  • כוללים את ההערה networking.gke.io/load-balancer-type: "Internal" במניפסט של השירות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תחום עניין משותף אזורי

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

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

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

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

GKE subsetting

שיטה מומלצת:

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

‫GKE subsetting, שנקרא גם GKE subsetting for Layer 4 internal load balancers, הוא אפשרות הגדרה ברמת האשכול שמשפרת את יכולת ההתאמה של מאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי, על ידי קיבוץ יעיל יותר של נקודות קצה של צמתים ל-GCE_VM_IP קבוצות של נקודות קצה ברשת (NEGs). קבוצות ה-NEG משמשות כקצה העורפי של מאזן העומסים.

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

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

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

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

מספר הצמתים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

השפעה של קרבה אזורית

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

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

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

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

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

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

קיבוץ צמתים

גרסת GKE, הערות במניפסט של השירות, ובשירותים של מאזן עומסים פנימי, האפשרות GKE subsetting קובעות את מאזן העומסים שמתקבל ואת סוגי השרתים העורפיים. Google Cloud סוג מאזן העומסים והבק-אנד קובעים איך הצמתים מקובצים ל-GCE_VM_IP NEGs, לקבוצות של מכונות או למאגרי יעד. בכל הנסיבות, Google Cloud מאזני עומסים מסוג pass-through מזהים את ממשק הרשת (NIC) של צומת GKE, ולא כתובת IP ספציפית של צומת או של Pod.

GKE LoadBalancer Service	מאזן העומסים Google Cloud שנוצר	שיטת קיבוץ הצמתים
שירות Internal LoadBalancer שנוצר באשכול עם הפעלה של חלוקת משנה של GKE^1	מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, שבו שירות הקצה העורפי משתמש בקצה עורפי מסוג GCE_VM_IP קבוצת נקודות קצה ברשת (NEG)	מכונות וירטואליות של Node מקובצות לפי אזורים ב-GCE_VM_IP NEGs על בסיס externalTrafficPolicy של השירות ומספר הצמתים באשכול. externalTrafficPolicy של השירות גם קובע אילו צמתים עוברים את בדיקת התקינות של מאזן העומסים וגם את עיבוד המנות.
שירות Internal LoadBalancer נוצר באשכול עם השבתה של חלוקת המשנה של GKE	מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, שהשירות לקצה העורפי שלו משתמש בקצה עורפי של קבוצת מופעים לא מנוהלת אזורית	כל המכונות הווירטואליות של הצמתים ממוקמות בקבוצות של מכונות לא מנוהלות באזור, ש-GKE משתמש בהן כשרתי קצה (backend) בשביל שירות הקצה של מאזן העומסים הפנימי של הרשת להעברת סיגנל ללא שינוי. ה-externalTrafficPolicy של השירות קובע אילו צמתים עוברים את בדיקת התקינות של איזון העומסים ואת עיבוד החבילות. אותן קבוצות מופעי מכונה לא מנוהלות משמשות לשירותים אחרים לקצה העורפי של מאזן העומסים שנוצרו באשכול, בגלל ההגבלה של קבוצת מופעי מכונה אחת עם איזון עומסים.
שירות External LoadBalancer עם ההערה cloud.google.com/l4-rbs: "enabled"^2 שמוחלת על אשכול שמריץ GKE בגרסה 1.32.2-gke.1652000 ואילך^4	מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות לקצה העורפי, ושבו השירות לקצה העורפי משתמש בGCE_VM_IP קצוות עורפיים של קבוצת נקודות קצה ברשת (NEG)	מכונות וירטואליות של Node מקובצות לפי אזורים ב-GCE_VM_IP NEGs על בסיס externalTrafficPolicy של השירות ומספר הצמתים באשכול. externalTrafficPolicy של השירות גם קובע אילו צמתים עוברים את בדיקת התקינות של מאזן העומסים וגם את עיבוד המנות.
שירות External LoadBalancer עם ההערה cloud.google.com/l4-rbs: "enabled"^2 שמוחלת על אשכול שפועלת בו גרסת GKE מוקדמת יותר מ-1.32.2-gke.1652000^4	מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות לקצה העורפי, והשירות לקצה העורפי שלו משתמש בקצה עורפי של קבוצת מופעים לא מנוהלת אזורית	כל המכונות הווירטואליות של הצמתים ממוקמות בקבוצות של מכונות לא מנוהלות באזור, ש-GKE משתמש בהן כבק-אנד לשירות הבק-אנד של מאזן העומסים החיצוני של הרשת להעברת סיגנל ללא שינוי. ה-externalTrafficPolicy של השירות קובע אילו צמתים עוברים את בדיקת התקינות של איזון העומסים ואת עיבוד החבילות. אותן קבוצות מופעי מכונה לא מנוהלות משמשות לשירותים אחרים לקצה העורפי של מאזן העומסים שנוצרו באשכול, בגלל ההגבלה של קבוצת מופעי מכונה אחת עם איזון עומסים.
שירות LoadBalancer חיצוני ללא ההערה cloud.google.com/l4-rbs: "enabled"^3	מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי שמבוסס על מאגר יעד, שמאגר היעד שלו מכיל את כל הצמתים של האשכול	מאגר היעדים הוא API מדור קודם שלא מסתמך על קבוצות של מופעים. לכל הצמתים יש חברות ישירה במאגר היעד. ה-externalTrafficPolicy של השירות קובע אילו צמתים עוברים את בדיקת התקינות של איזון העומסים ואת עיבוד החבילות.

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

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

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

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

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

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

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

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

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

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

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

• מאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי שנוצרו לשירותים פנימיים של LoadBalancer כשחלוקת המשנה של GKE מושבתת.
• מאזני עומסים חיצוניים של רשת להעברת סיגנל ללא שינוי שמבוססים על שירות לקצה העורפי, שנוצרו עבור שירותים חיצוניים של LoadBalancer עם ההערה cloud.google.com/l4-rbs: "enabled".
• מאזני עומסים חיצוניים של אפליקציות (ALB) שנוצרו למשאבי GKE Ingress חיצוניים, באמצעות בקר GKE Ingress, אבל לא באמצעות איזון עומסים מקורי של קונטיינרים.

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

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

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

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

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

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

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

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

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

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

• אשכולות 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