בדף הזה מוסבר על איזון עומסים שמבוסס על ניצול משאבים בשירותי Google Kubernetes Engine (GKE). באיזון עומסים כזה, המערכת בודקת את ניצול המשאבים של הפודים בקצה העורפי ומשתמשת בקיבולת בפועל של עומסי העבודה כדי לאזן מחדש את התנועה בצורה חכמה, וכך לשפר את הזמינות של האפליקציה ולהגמיש את הניתוב.
הדף הזה מיועד לאדריכלי ענן ולמומחי רשתות שמנהלים שירותים ב-GKE ורוצים לבצע אופטימיזציה של חלוקת התנועה על סמך ניצול המשאבים בזמן אמת.
לפני שאתם קוראים את הדף הזה, חשוב שתכירו את המושגים הבאים:
- מושגים של GKE: כולל אשכולות, צמתים ו-Pods של GKE.
- Kubernetes Services: איך האפליקציות נחשפות ב-Kubernetes.
- Cloud Load Balancing: הבנה כללית של Cloud Load Balancing, במיוחד לגבי אופן הפעולה שלGoogle Cloud מאזני עומסים.
- Kubernetes Gateway API: השיטה המומלצת לחשיפת שירותים ולניהול התנועה ב-GKE.
- קבוצות של נקודות קצה ברשת (NEG): איך שירותי GKE משתמשים ב-NEG כדי להשתלב עם Cloud Load Balancing.
- מדדים בסיסיים של ניצול משאבים: לדוגמה, ניצול מעבד (CPU), שהוא המדד הנוכחי שמשמש לאיזון עומסים שמבוסס על ניצול.
סקירה כללית
התשתית של Cloud Load Balancing מנתבת את התעבורה לשירותי GKE על סמך מדדי יכולת הגעה סטנדרטיים, כולל HTTP, HTTPS, HTTP/2 ו-gRPC, שקובעים את התקינות והזמינות של Pods. כברירת מחדל, הוא מעביר את התנועה לכל ה-Pods התקינים בקצה העורפי, תוך התחשבות בזמינות של ה-Pods ובכללי מדיניות אופציונליים להפצת תנועה, כמו GCPTrafficDistributionPolicy.
באפליקציות מודרניות אפשר לעקוב אחרי השימוש ב-CPU כדי להבין את העלויות, לעקוב אחרי הביצועים ולנהל את הקיבולת בצורה יעילה. כדי לענות על הצורך הזה, מאזני העומסים משתמשים בנתוני ניצול המשאבים בזמן אמת כמדד, שמאפשר להם לקבוע את נפח התנועה האופטימלי שכל Pod בקצה העורפי יכול לעבד לצורך חלוקת תנועה חכמה.
באיזון עומסים שמבוסס על ניצול משאבים בשירותי GKE, ניצול המשאבים נמדד כדי לקבוע את היכולת של Pods לקצה העורפי לעבד את תנועת הנתונים של האפליקציה. לאחר מכן, הוא מאזן מחדש את התנועה לקצוות עורפיים אחרים אם נעשה שימוש יתר ב-Pod אחד או יותר.
תכונות ויתרונות
היתרונות של איזון עומסים שמבוסס על ניצול:
זמינות גבוהה יותר של האפליקציה: כשיש עומס על הקצה העורפי, המערכת נותנת עדיפות לתנועה לפודים עם ניצול משאבים נמוך יותר. כך אפשר לשמור על ביצועי האפליקציה, למנוע האטה והפסקות בשירות ולספק חוויית משתמש אמינה.
ניתוב גמיש: מספק קבוצה נוספת של מדדים שמאפשרת להגדיר כללי מדיניות להפצת תנועה שמתאימים בדיוק לתרחישי שימוש עסקיים.
איך פועל איזון עומסים שמבוסס על ניצול משאבים
איזון עומסים שמבוסס על ניצול משאבים בשירותי GKE משפר את ניהול התנועה באפליקציות שפועלות ב-GKE, כי התהליך מגיב מהר יותר לעומס על המשאבים. האפליקציה פועלת ב-GKE באמצעות הרבה מכונות (Pods) במכונות שונות. הוא מקבל תנועה בשתי דרכים עיקריות:
מחוץ לאשכול (תנועה מצפון לדרום): האשכול מקבל תנועה מהאינטרנט או ממקורות חיצוניים אחרים, שנקראת תנועה מצפון לדרום. מאזן עומסים (שער) שמנוהל על ידי GKE מפנה את התנועה הזו מחוץ לאשכול.
מתוך האשכול (תנועה ממזרח למערב): האשכול מקבל תנועה בין חלקים שונים של האפליקציה, משירותים אחרים בתוך אשכול GKE או בין כמה אשכולות. זרימת התנועה הפנימית הזו נקראת תנועה מזרח-מערב.
איזון עומסים מבוסס-ניצול בשירותי GKE כולל תהליך מתמשך, שבו סוכני GKE אוספים מדדי ניצול של Pods שמאפשרים לתשתית של Cloud Load Balancing להפיץ את התנועה בצורה חכמה. בשלבים הבאים מוסבר איך איזון עומסים מבוסס-ניצול בשירותי GKE מנהל את תנועת הנתונים באפליקציה על סמך השימוש במשאבים בזמן אמת:
כשמגדירים את שירות GKE עם מאזן עומסים של אפליקציות (שער), המערכת של GKE יוצרת באופן אוטומטי קבוצות NEG לכל אזור ומקצה את ה-Pods של האפליקציה לקבוצות ה-NEG האלה. בהתחלה, חלוקת התנועה מתבססת על בדיקות תקינות בסיסיות ועל הגדרות ברירת המחדל.
אתם מגדירים את שירות GKE כך שישתמש בניצול המשאבים, כמו מעבד (CPU), כמדד מפתח לאיזון עומסים.
בנוסף למדד ברירת המחדל של ניצול המעבד (CPU), אתם יכולים לחשוף מדדים מותאמים אישית מהאפליקציה שלכם כדי שמאזן העומסים ישתמש בהם. שימוש במדדים מהאפליקציה מאפשר לכם להגדיר אותות משלכם שספציפיים לעומס העבודה. לדוגמה, אתם יכולים להשתמש ב-
gpu_cache_usage_perc metricמעומס עבודה של vLLM כדי לעזור למאזן העומסים לנתב את התנועה לאזור עם יותר משאבים זמינים. במאמר חשיפת מדדים מותאמים אישית למאזני עומסים מוסבר איך חושפים מדדים מותאמים אישית למאזן העומסים.סוכן GKE מיוחד עוקב באופן רציף אחרי השימוש במשאבים של Pods (לדוגמה, מעבד (CPU)) ושולח את הנתונים האלה לתשתית של Cloud Load Balancing באופן קבוע. אם ל-Pod יש כמה קונטיינרים, ה-agent מחשב את הניצול המשולב שלהם.
התשתית של Cloud Load Balancing מנתחת נתוני ניצול בזמן אמת כדי להתאים באופן דינמי את חלוקת התנועה. הוא קובע כמה תנועה לשלוח לכל קבוצת Pods (כל NEG אזורי) על ידי הערכת ניצול המשאבים הממוצע שלהם (כמו עומס ה-CPU) וגורמים אחרים כמו זמן האחזור ברשת. התהליך הזה מעביר באופן אוטומטי את התנועה מ-Pods עם עומס גבוה יותר ל-Pods עם עומס נמוך יותר, וכך מבטיח ניצול יעיל של המשאבים באזור הקרוב ביותר.
בדוגמה הבאה מוסבר איך פועל איזון עומסים שמבוסס על ניצול.
דוגמה: טיפול ב-Pods עם ניצול יתר
כשהשירות מריץ כמה קונטיינרים באותו Pod, סוכן המדדים של GKE מדווח על השימוש במשאבים של כל קונטיינר בנפרד. לאחר מכן, התשתית של Cloud Load Balancing מחשבת ממוצע משוקלל של הניצול שלהם כדי לקבל את הקיבולת הכוללת של ה-Pod.
באיור 1 מוצג איך מערכת Cloud Load Balancing משתמשת במדדי ניצול המעבד (CPU) בזמן אמת מ-GKE כדי לבצע אופטימיזציה של חלוקת התנועה בין פודים שנפרסו בכמה אזורים. בקשת הלקוח מנותבת דרך GKE Gateway לפודים של קצה עורפי שמקובצים ב-NEG בשלושה אזורים.
באזור 1, ה-Pod מדווח על 90% שימוש במעבד. מאזן העומסים מפחית את התנועה ל-Pod הזה כדי למנוע עומס יתר.
באזור 2, ה-Pod מנוצל באופן מתון ב-60% מהמעבד (CPU) וממשיך לקבל תנועה.
באזור 3, ה-Pod מדווח על שימוש נמוך ב-CPU בשיעור של 40%, ויכול להיות שיקבל יותר תנועה. GKE שולח באופן קבוע מטא-נתונים ומדדי ניצול לתשתית של Cloud Load Balancing, שמתאימה בצורה חכמה את ניתוב התנועה כדי לשמור על הביצועים והזמינות של האפליקציה.
נניח שהשירות מוגדר לניצול מקסימלי של 80% מהמעבד (CPU). אם פודים באזור 1 מדווחים על 90% ניצול של המעבד (CPU), שחורג מהסף, קורה הדבר הבא:
- התשתית של Cloud Load Balancing מזהה את ניצול היתר הזה.
- לאחר מכן, הוא מאזן מחדש את התנועה בצורה חכמה ומפחית את כמות התנועה שהוא שולח ל-Pods באזור 1. האיזון מחדש נמשך עד שהניצול הממוצע של המעבד (CPU) בפודים באותו אזור יורד מתחת לסף הניצול של 80%.
- כשה-Pods באזור 1 מדווחים על ניצול נמוך יותר של המעבד (פחות מסף של 80%), התשתית של Cloud Load Balancing מעריכה מחדש את חלוקת התנועה. לאחר מכן, הוא מאזן מחדש בהדרגה את התנועה בין כל ה-Pods שמגבים את השירות, וממשיך להפיץ את התנועה ביעילות על סמך הניצול.