ניהול תנועה בשער

בדף הזה נסביר איך פועל ניהול התנועה בשער.

הדף הזה מיועד למפתחים, לאופרטורים ולמומחי רשת שרוצים לפרוס תנועה ולנהל אותה באמצעות Gateway API.

סקירה כללית

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

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

ניהול תנועה

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

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

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

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

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

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

תרשים של איזון עומסים, התאמה לעומס (autoscaling) וניהול קיבולת

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

מידע נוסף על האופן שבו Cloud Load Balancing מטפל בניהול תנועה זמין במאמר בנושא ניהול קיבולת גלובלי.

יכולות ניהול תעבורת נתונים ו-Service Extensions

משאבי Gateway,‏ HTTPRoute,‏ Service ו-Policy מספקים את האמצעים לניהול התנועה ב-GKE. GKE Gateway controller הוא מישור הבקרה שעוקב אחרי המשאבים האלה.

תוספי GKE Gateway Service מאפשרים להתאים אישית את ניהול התנועה ב-GKE ולהרחיב אותו. תוספים מחדירים לוגיקה מותאמת אישית לניהול מתקדם של תעבורת נתונים.

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

  • קיבולת השירות: ציון נפח התנועה שהשירות יכול לקבל לפני שה-Pods עוברים שינוי גודל אוטומטי או שהתנועה גולשת לאשכולות זמינים אחרים
  • שינוי גודל אוטומטי של קבוצות Pod על סמך תנועה: שינוי גודל אוטומטי של קבוצות Pod בשירות על סמך בקשות HTTP שמתקבלות בשנייה
  • איזון עומסים בין כמה אשכולות: איזון עומסים בשירותים שמארחים בכמה אשכולות GKE או בכמה אזורים
  • חלוקת התנועה: חלוקת תנועה מפורשת לפי משקל בין שרתי קצה עורפיים
  • שיתוף משאבים בין מקורות (CORS): מאפשר ומסייע באבטחת בקשות ממקורות שונים
  • שמירה במטמון קצה: שמירת תוכן במטמון באמצעות Cloud CDN כדי לשפר את זמן האחזור של משתמשי הקצה ולהפחית את עומס המקור באפליקציות שמארחות ב-GKE
  • ניהול תעבורת נתונים בהתאמה אישית באמצעות Service Extensions: הרחבת ניהול תעבורת הנתונים על ידי הוספת לוגיקה מותאמת אישית לשליטה מתקדמת, למשל:
    • שינוי כותרות ומטענים ייעודיים (payloads) של בקשות ותגובות HTTP
    • הטמעה של לוגיקת ניתוב בהתאמה אישית כדי לשלוט בזרימת התנועה
    • שילוב עם שירותים חיצוניים לפונקציות כמו הרשאה
  • העדפה מתקדמת של סשנים: הצמדת סשנים באמצעות קובצי Cookie או כותרות מתמשכים כדי לבצע אופטימיזציה של ביצועי אפליקציה עם שמירת מצב

תמיכה בניהול תנועה

היכולות הזמינות לניהול התנועה תלויות ב-GatewayClass שפורס. רשימה מלאה של תכונות נתמכות מופיעה במאמר בנושא יכולות של GatewayClass. בטבלה הבאה מפורט סיכום של התמיכה ב-GatewayClass לניהול תנועה:

GatewayClass קיבולת השירות התאמה אוטומטית לעומס (autoscaling) של תנועת גולשים איזון עומסים בין כמה אשכולות חלוקת התנועה1 CORS העדפה מתקדמת של סשנים שמירה במטמון קצה
gke-l7-global-external-managed
gke-l7-regional-external-managed
gke-l7-rilb
gke-l7-gxlb
gke-l7-global-external-managed-mc
gke-l7-regional-external-managed-mc
gke-l7-cross-regional-internal-managed-mc
gke-l7-rilb-mc
gke-l7-gxlb-mc
‫1 חלוקת התנועה נתמכת באמצעות שערים של אשכול יחיד ב-GA.

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

‫Google Cloud Application Load Balancers מחלקים את התנועה על סמך מדדים מותאמים אישית. המדדים האלה יכולים לכלול את עומס השימוש ב-GPU או אותות שימוש אחרים שספציפיים לאפליקציה. מדדים מותאמים אישית מספקים תמונה מדויקת יותר של ביצועי עומס העבודה. האפליקציה שלכם מדווחת על המדדים האלה באמצעות התקן Open Request Cost Aggregation (ORCA). מידע נוסף זמין במאמר בנושא מדדים מותאמים אישית עבור Application Load Balancer.

ב-GKE, אפשר לשלב את היכולת המתקדמת הזו לניהול תנועה באמצעות GKE Gateway API. ה-API שימושי לעומסי עבודה עם שימוש משתנה במשאבים, כמו הסקת מסקנות מ-AI גנרטיבי. אתם יכולים להגדיר התנהגות תנועה מותאמת אישית על ידי קביעת ההגדרות של כללי המדיניות הבאים:

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

  • ‫GCPTrafficDistributionPolicy: מגדיר את אלגוריתם איזון העומסים לבחירת נקודת קצה בתוך קצה עורפי לניתוב ברמת נקודת הקצה. כשבוחרים באפשרות WEIGHTED_ROUND_ROBIN, מאזן העומסים משתמש במשקלים שנגזרים ממדדים שדווחו, כולל מדדים מותאמים אישית, כדי להפיץ את התנועה למופעים או לנקודות קצה ספציפיים. כדי להגדיר ניתוב ברמת נקודת הקצה, אפשר לעיין במאמר בנושא הגדרת ניתוב ברמת נקודת הקצה.

מדיניות מבוססת-מיקום

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

מעקב אחרי מדדים מותאמים אישית בשרתי קצה של GKE

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

אפשר להשתמש בתוויות של מדדי GKE כדי לשלוח שאילתות למדדים בהתאמה אישית לפי שירות GKE, אשכול ומרחב שמות.

כדי לראות את המדדים המותאמים אישית שדווחו על ידי ה-backend של GKE, עוברים אל Cloud Monitoring ומציגים את המדדים המותאמים אישית בקטע network.googleapis.com/loadbalancer/backend/ משאב שבמעקב. אתם יכולים להשתמש בתוויות ספציפיות ל-GKE כדי לשלוח שאילתות ולסנן את המדדים האלה.

המדדים שזמינים כוללים:

  • ‫/error_rate: שגיאות שמוצגות על ידי כל קבוצת קצה עורפי לשנייה.
  • ‫/lb_custom_metric: נתוני השימוש הנוכחיים של כל קבוצת שרתים, על סמך המדדים המותאמים אישית שהגדרתם.
  • ‫/fullness: רמת העומס הנוכחית (עומס או קיבולת) של כל קבוצת עורף, שמאזני העומסים משתמשים בה כדי לקבל החלטות לגבי ניתוב.
  • ‫/rate: בקשות שהתקבלו על ידי כל קבוצת עורף לשנייה.

תוויות ספציפיות ל-GKE שמשפרות את המעקב אחרי המדדים האלה כוללות את gke_service_name, gke_namespace ו-gke_cluster. אפשר להשתמש בתוויות האלה כדי לבדוק את נתוני המדדים לפי שירות GKE, מרחב שמות ואשכול. חשוב לדעת שהתוויות האלה של GKE מאוכלסות רק אם הערך של backend_type הוא ZONAL_NETWORK_ENDPOINT_GROUP.

בטבלה הבאה מפורטות תוויות ספציפיות ל-GKE:

תווית סוג תיאור
gke_service_name תווית מדד או תווית מערכת שם השירות של משאב GKE, אם קיים. השדה הזה מאוכלס רק אם הערך של backend_type הוא ZONAL_NETWORK_ENDPOINT_GROUP. לסוגי קצה עורפי אחרים, התווית הזו מכילה ערך null.
gke_namespace תווית מדד או תווית מערכת מרחב השמות של משאב GKE, אם קיים. השדה הזה מאוכלס רק אם הערך של backend_type הוא ZONAL_NETWORK_ENDPOINT_GROUP. לסוגי קצה עורפי אחרים, התווית הזו מכילה ערך null.
gke_cluster תווית מדד או תווית מערכת שם אשכול GKE של המשאב, אם קיים. השדה הזה יאוכלס רק אם הערך של backend_type הוא ZONAL_NETWORK_ENDPOINT_GROUP. לסוגי קצה עורפי אחרים, התווית הזו מכילה ערך null.

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

איזון עומסים גלובלי, אזורי ושל תחום מוגדר

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

  • גלובלי: התנועה נשלחת לאזור Google Cloud הקרוב ביותר ללקוח, שיש בו שרתי קצה תקינים עם קיבולת. כל עוד יש קיבולת באזור, הוא מקבל את כל התנועה הכי קרובה אליו. אם לאזור מסוים אין קיבולת, תעבורה עודפת מועברת לאזור הקרוב הבא שיש בו קיבולת. מידע נוסף זמין במאמר בנושא איזון עומסים גלובלי.
  • אזורי: תעבורת הנתונים נשלחת על ידי מאזן העומסים לאזור ספציפי. התעבורה מאוזנת בין התחומים (zones) באופן יחסי לקיבולת הזמינה של כל תחום. מידע נוסף זמין במאמר בנושא איזון עומסים אזורי.
  • Zonal: אחרי שנקבעת התנועה לאזור ספציפי, מאזן העומסים מחלק את התנועה באופן שווה בין השרתים העורפיים באותו אזור. ההגדרות הקיימות של חיבורי TCP והתמדה של סשנים נשמרות, כך שבעתיד בקשות יועברו לאותם שרתי קצה עורפיים, כל עוד ה-Pod של שרת הקצה העורפי תקין. מידע נוסף זמין במאמר בנושא איזון עומסים אזורי.

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

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

בתנאים רגילים, התעבורה נשלחת לחלק האחורי הקרוב ביותר ללקוח. תעבורת הנתונים מסתיימת בנקודת ה-PoP של Google שהכי קרובה ללקוח, ואז עוברת דרך הרשת הגלובלית של Google עד שהיא מגיעה לקצה העורפי הכי קרוב, בהתאם לזמן האחזור ברשת. אם לשרתי הבק-אנד באזור מסוים אין קיבולת פנויה, התעבורה מועברת לקלאסטר הבא הכי קרוב עם שרתי בק-אנד תקינים שיש להם קיבולת. אם יותר מ-50% מ-Pods של קצה עורפי בתחום (zone) לא תקינים, התעבורה עוברת בהדרגה לתחומים או לאזורים אחרים, ללא קשר לקיבולת שהוגדרה.

גלישת תנועה מתרחשת רק בתנאים הבאים:

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

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

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

בתרשים:

  • שער מרובה אשכולות מספק איזון עומסים גלובלי באינטרנט עבור שירות store. השירות פרוס בשני אשכולות GKE, אחד ב-us-west1 ואחד ב-europe-west1. כל אשכול מריץ 2 עותקים משוכפלים.
  • כל שירות מוגדר עם max-rate-per-endpoint="10", כלומר לכל שירות יש קיבולת כוללת של 2 רפליקות * 10 בקשות לשנייה = 20 בקשות לשנייה בכל אשכול.
  • נקודות הנוכחות של Google בצפון אמריקה מקבלות 6 בקשות לשנייה. כל תעבורת הנתונים נשלחת אל קצה העורפי הקרוב ביותר שפועל בצורה תקינה ויש לו קיבולת, כלומר אל אשכול GKE ב-us-west1.
  • נקודות הנוכחות באירופה מקבלות 30 בקשות מצטברות לשנייה. השרתים העורפיים הכי קרובים נמצאים בeurope-west1, אבל הקיבולת שלהם היא רק 20 RPS. מכיוון שלשרתי הקצה העורפיים ב-us-west1 יש קיבולת עודפת, 10 בקשות לשנייה עוברות ל-us-west1, כך שהוא מקבל 16 בקשות לשנייה בסך הכול ומפיץ 8 בקשות לשנייה לכל פוד.

מניעת הצפה של תנועה

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

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

אפשר להשתמש בכל אחת מהשיטות הבאות כדי למנוע הצפת תנועה:

  • משתמשים רק בשערי Gateway של אשכול יחיד שיכולים לארח שירותים רק באשכול יחיד.

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

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

איזון עומסים באזור

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

הדיאגרמה הבאה מציגה כיצד תעבורת נתונים מופצת באזור:

תנועה שמפוזרת בתוך אזור

בתרשים:

  • שירות נפרס באשכול GKE אזורי. לשירות יש 4 קבוצות Pod שנפרסות באופן לא אחיד באזורים. ‫3 יחידות Pod נמצאות באזור א',‏ יחידת Pod אחת נמצאת באזור ב', ואף יחידת Pod לא נמצאת באזור ג'.
  • השירות מוגדר עם maxRatePerEndpoint=10. באזור א' יש קיבולת כוללת של 30 RPS, באזור ב' יש קיבולת כוללת של 10 RPS, ובאזור ג' יש קיבולת כוללת של 0 RPS כי אין בו יחידות Pod.
  • השער מקבל נפח תנועה כולל של 16 בקשות לשנייה מלקוחות שונים. התנועה הזו מתחלקת בין האזורים באופן יחסי לקיבולת שנותרה בכל אזור.
  • התנועה מכל מקור או לקוח בודד מאוזנת באופן עקבי בעומס ל-Pod בקצה העורפי בהתאם להגדרות של שמירת נתוני הסשן. התנועה מחולקת בין מקורות תנועה שונים, כך שכל מקור תנועה נשאר שלם. כתוצאה מכך, נדרש סכום מינימלי של מגוון מקורות או לקוחות כדי להפיץ את התנועה בצורה מדויקת בין השרתים העורפיים.

לדוגמה, אם התנועה הנכנסת עולה מ-16 בקשות לשנייה ל-60 בקשות לשנייה, אחד מהתרחישים הבאים יתרחש:

  • אם משתמשים בשערי כניסה (Gateways) של אשכול יחיד, אין אשכולות או אזורים אחרים שאליהם התנועה יכולה לעבור. התנועה ממשיכה להתחלק בהתאם לקיבולות היחסיות של האזורים, גם אם התנועה הנכנסת חורגת מהקיבולת הכוללת. כתוצאה מכך, אזור A מקבל 45 RPS ואזור B מקבל 15 RPS.
  • אם משתמשים בשערים מרובי אשכולות עם שירותים שמפוזרים על פני כמה אשכולות, יכול להיות שיהיה עודף תעבורה לאשכולות אחרים ולאזורים אחרים, כמו שמתואר במאמר איזון עומסים גלובלי ועודף תעבורה. אזור A מקבל 30 בקשות לשנייה, אזור B מקבל 10 בקשות לשנייה, ו-20 בקשות לשנייה עוברות ל клаסטר אחר.

איזון עומסים בתוך אזור

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

למרות שאיזון עומסים רגיל מפזר את התעבורה באופן שווה בין ה-backends, אלגוריתם RING_HASH מספק מיפוי עקבי של בקשות ל-Pods ספציפיים. ‫RING_HASH minimizes request reshuffling when Pods are added or removed, making it a more stable option for stateful workloads sensitive to cache misses. אפשר גם להגדיר את minimumHashRingSize כדי לשנות את גודל טבעת הגיבוב. גודל טבעת גדול יותר יכול לעזור להבטיח פיזור אחיד יותר של בקשות בשרתי קצה עורפיים, במיוחד באשכולות גדולים יותר.

קיבולת השירות

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

דרישות

אלה הדרישות והמגבלות שחלות על קיבולת השירות:

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

הגדרת קיבולת השירות

שערים של אשכול יחיד

מוודאים שגרסת GKE שפועלת באשכול היא 1.31.1-gke.2008000 ואילך. בגרסאות קודמות אפשר להשתמש בהערה networking.gke.io/max-rate-per-endpoint כמו שמתואר בכרטיסייה Multi-cluster Gateways.

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

apiVersion: v1
kind: Service
metadata:
  name: store
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

מגדירים את האובייקט GCPBackendPolicy באמצעות השדה maxRatePerEndpoint עם ערך מקסימלי של בקשות לשנייה. משתמשים במניפסט הבא כדי להגדיר את האובייקט GCPBackendPolicy:

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store
spec:
  default:
    maxRatePerEndpoint: RATE_PER_SECOND
  targetRef:
    group: ""
    kind: Service
    name: store

Multi-cluster Gateways

כדי להשתמש בשערים מרובי אשכולות כדי להגדיר את קיבולת השירות, צריך ליצור Service באמצעות ההערה networking.gke.io/max-rate-per-endpoint. כדי ליצור שירות עם RPS מקסימלי, משתמשים במניפסט הבא:

apiVersion: v1
kind: Service
metadata:
  name: store
  annotations:
    networking.gke.io/max-rate-per-endpoint: "RATE_PER_SECOND"
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

מחליפים את RATE_PER_SECOND במספר המקסימלי של בקשות HTTP/HTTPS לשנייה שכל Pod בשירות הזה אמור לקבל.

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

Total Service capacity = maxRatePerEndpoint * number of replicas

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

קיבולת שירות וקבוצות עצמאיות של נקודות קצה ברשת (NEGs)

אפשר גם להגדיר את קיבולת השירות כשמשתמשים בקבוצות עצמאיות של נקודות קצה ברשת (NEGs), אבל ההגדרה maxRatePerEndpoint לא רלוונטית במקרה הזה. כשמשתמשים ב-NEGs עצמאיים, מגדירים את maxRatePerEndpoint באופן ידני כשמוסיפים את ה-NEG למשאב Backend Service. באמצעות הפקודה gcloud compute backend-services add-backend, הדגל --max-rate-per-endpoint יכול להגדיר את הקיבולת לכל NEG בנפרד.

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

אין הבדל פונקציונלי כשמגדירים את קיבולת השירות באמצעות קבוצות עצמאיות של נקודות קצה ברשת (NEGs). המערכת תומכת בהרחבת קיבולת אוטומטית של תנועה ובמעבר אוטומטי של תנועה.

קביעת הקיבולת של השירות

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

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

  • אפשר להשתמש ב-Cloud Monitoring כדי ליצור קורלציה בין בקשות תנועה לבין היעדים למדידת רמת השירות (SLO) של הביצועים.

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

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

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

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

קיבולת שירות ברירת המחדל

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

בטבלה הבאה מפורטים נפחי ברירת המחדל:

סוג משאב של איזון עומסים ברירת מחדל maxRatePerEndpoint
תעבורת נתונים נכנסת (ingress) (פנימית וחיצונית) ‫1 RPS
שער (כל GatewayClasses) ‫100,000,000 בקשות לשנייה
MultiClusterIngress ‫100,000,000 בקשות לשנייה

התאמה אוטומטית לעומס (autoscaling) על סמך נפח התנועה

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

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

היתרונות של שינוי גודל אוטומטי על סמך תנועת גולשים:

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

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

התאמה אוטומטית לעומס (autoscaling) על סמך נפח התנועה

בתרשים:

  • בעל השירות מגדיר את קיבולת השירות ואת יעד הניצול של הפריסה.
  • השער מקבל תנועה מלקוחות שפונים לשירות store. השער שולח טלמטריה של ניצול למנגנון לשינוי גודל ה-Pod ב-GKE. הניצול שווה לתנועה בפועל שהתקבלה על ידי כל Pod חלקי הקיבולת שהוגדרה של ה-Pod.
  • הכלי GKE Pod Autoscaler משנה את גודל ה-Pods בהתאם לניצול היעד שהוגדר.

התנהגות עם התאמה אוטומטית לעומס

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

התאמה אוטומטית לעומס על סמך תנועה עם 10 בקשות לשנייה

בתרשים, בעלי השירות הגדירו את הקיבולת של שירות החנות ל-10 RPS, מה שאומר שכל Pod יכול לקבל עד 10 RPS. ה-HorizontalPodAutoscaler מוגדר עם averageValue שמוגדר ל-70, כלומר, ניצול היעד הוא 70% מ-10 בקשות לשנייה לכל Pod.

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

replicas = ceiling[ current traffic / ( averageValue * maxRatePerEndpoint) ]

בתרשים, המשוואה הזו מחשבת את:

ceiling[ 10 rps / (0.7 * 10 rps) ] = ceiling[ 1.4 ] = 2 replicas

תעבורה של 10 בקשות לשנייה מובילה ל-2 עותקים. כל רפליקה מקבלת 5 בקשות לשנייה, שזה פחות מניצול היעד של 7 בקשות לשנייה.

חלוקת התנועה

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

בתרשים הבא מתוארת דוגמה להגדרת פיצול תנועה:

הגדרת חלוקת התנועה

בתרשים:

  • בעלי השירות מגדירים שני שירותים לנתיב אחד, עם כלל שמפצל את תעבורת הנתונים כך ש-90% ממנה מועברים אל store-v1 ו-10% אל store-v2.
  • השער מקבל תנועה מלקוחות שעוברים לכתובת ה-URL של אפליקציית החנות, והתנועה מפולחת בהתאם לכלל שהוגדר. ‫90% מהתנועה מגיעה למסלולים אל store-v1 ו-10% מהתנועה מגיעה למסלולים אל store-v2.

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

  • חלוקת תנועה בין שירותים: הגישה הזו משמשת לחלוקת תנועה לצורך השקות של גרסאות אפליקציות. בדוגמה של חלוקת התנועה, יהיו לכם שני פריסות נפרדות, store-v1 ו-store-v2, שלכל אחת מהן יש שירות משלה, store-v1 ו-store-v2. המשקלים מוגדרים בין שני השירותים כדי להעביר את התנועה בהדרגה עד להשקה מלאה של store-v2.

  • פיצול תנועה בין ServiceImports: הגישה הזו משמשת להעברת תנועה לאשכולות ספציפיים או מהם לצורך תחזוקה, העברה או מקרי חירום. ‫ServiceImports מייצג שירותים מרובי אשכולות ומאפשר פיצול תנועה בין שירותים שונים באשכולות שונים. בתרגיל Blue-green, multi-cluster routing with Gateway מודגם פיצול תנועה בין אשכולות.

משקל לעומת קיבולת

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

משקל

המשקל הוא אמצעי מפורש לשליטה בתנועת הנתונים. הוא מגדיר את הפרופורציות המדויקות של התנועה, ללא קשר לתנועה הנכנסת ולניצול של ה-Backend. בדוגמה של פיצול התנועה, אם store-v2 היה מעל הקיבולת, או אם כל העותקים שלו נכשלו, 10% מהתנועה עדיין יוקצו ל-store-v2, מה שעלול לגרום להפסקת התנועה. הסיבה לכך היא שהמשקל לא משנה את שיעור התנועה על סמך השימוש או המצב.

המשקל מתאים במיוחד לתרחישי השימוש הבאים:

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

קיבולת

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

התכונה 'קיבולת' מתאימה במיוחד לתרחישי השימוש הבאים:

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

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

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

זיקה לסשן (session affinity)

זיקה לסשן (session affinity) (נקראת גם 'סשנים דביקים') מבטיחה שבקשות מלקוח ספציפי ינותבו באופן עקבי לאותו Pod של קצה עורפי. זו אופטימיזציה של הביצועים לאפליקציות עם מצב (stateful) שמרוויחות משמירה במטמון מקומי. לדוגמה, עגלות קניות במסחר אלקטרוני או סשנים של משחקים, שבהם חשוב לשמור את נתוני הסשן של המשתמשים בתא ספציפי.

שער GKE תומך בכמה סוגים של זיקה לסשן שזמינים בGoogle Cloud Application Load Balancer instances: ‏ CLIENT_IP,‏ HEADER_FIELD,‏ GENERATED_COOKIE ו-HTTP_COOKIE.

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

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