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

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

הדף הזה מיועד למפתחים, לאופרטורים ולמומחי רשת שרוצים לפרוס תנועה ולנהל אותה באמצעות 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 או בכמה אזורים
  • חלוקת התנועה: חלוקת תנועה מפורשת לפי משקל בין שרתי קצה עורפיים
  • זיקה לסשן (GCPTrafficDistributionPolicy): הצמדת סשנים באמצעות קובצי Cookie, כותרות או כתובות IP של לקוחות כדי לבצע אופטימיזציה של ביצועי אפליקציות עם שמירת מצב
  • שיתוף משאבים בין מקורות (CORS): מאפשר ומסייע באבטחת בקשות בין מקורות
  • שמירה במטמון קצה: שמירת תוכן במטמון באמצעות Cloud CDN כדי לשפר את זמן האחזור של משתמשי הקצה ולהפחית את עומס המקור של אפליקציות שמתארחות ב-GKE
  • ניהול תעבורת נתונים בהתאמה אישית באמצעות Service Extensions: הרחבת ניהול תעבורת הנתונים על ידי הוספת לוגיקה מותאמת אישית לשליטה מתקדמת, למשל:
    • שינוי כותרות ומטענים ייעודיים (payloads) של בקשות ותגובות HTTP
    • הטמעה של לוגיקת ניתוב בהתאמה אישית כדי לשלוט בזרימת התנועה
    • שילוב עם שירותים חיצוניים לפונקציות כמו הרשאה

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

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

GatewayClass קיבולת השירות התאמה אוטומטית לעומס (autoscaling) של תנועת גולשים איזון עומסים בין כמה אשכולות חלוקת התנועה1 זיקה לסשן (GCPTrafficDistributionPolicy) 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 מחלקים את התנועה על סמך מדדים מותאמים אישית. המדדים האלה יכולים לכלול את עומס השימוש במעבד הגרפי או אותות שימוש אחרים שספציפיים לאפליקציה. מדדים בהתאמה אישית מספקים תמונה מדויקת יותר של ביצועי עומס העבודה. האפליקציה שלכם מדווחת על המדדים האלה באמצעות התקן Open Request Cost Aggregation (ORCA). מידע נוסף זמין במאמר בנושא מדדים מותאמים אישית עבור Application Load Balancer.

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

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

  • ‫GCPTrafficDistributionPolicy: מגדיר זיקה לסשנים ואלגוריתמים לאיזון עומסים לבחירת נקודות קצה בתוך קצה עורפי לניתוב ברמת נקודת הקצה. אפשר להגדיר שמירה על סשן (STRONG_COOKIE_AFFINITY, HTTP_COOKIE, GENERATED_COOKIE, HEADER_FIELD, CLIENT_IP) ואלגוריתמים יציבים לאיזון עומסים כמו RING_HASH. כשבוחרים באפשרות 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 בקשות לשנייה. לשרתי הקצה העורפיים ב-us-west1 יש קיבולת עודפת, ולכן 10 בקשות לשנייה עוברות ל-us-west1, כך שהוא מקבל 16 בקשות לשנייה בסך הכול ומפיץ 8 בקשות לשנייה לכל פוד.

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

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

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

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

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

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

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

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

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

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

תנועה שמפוזרת באזור מסוים

בתרשים:

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

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

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

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

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

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

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

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

דרישות

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

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

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

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

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

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

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

מגדירים את האובייקט GCPBackendPolicy באמצעות השדה maxRatePerEndpoint עם ערך מקסימלי של RPS. משתמשים במניפסט הבא כדי להגדיר את האובייקט 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)

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

  • הגדרת יעדי רמת השירות (SLO) של הביצועים עבור האפליקציה. הן יכולות להיות אחת או יותר מהאפשרויות הבאות, בהתאם למה שאתם מגדירים כביצועים 'גרועים' או 'לא יציבים'. אפשר לאסוף את כל הנתונים הבאים ממדדי איזון העומסים ב-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 (ניתוב בין אשכולות בשיטת blue-green עם שער) מוצג פיצול של תנועה בין אשכולות.

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

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

משקל

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

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

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

קיבולת

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

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

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

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

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

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

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

GKE Gateway תומך בכל סוגי הזיקה לסשן שזמינים במופעים שלGoogle Cloud מאזן עומסים של אפליקציות באמצעות המשאב GCPTrafficDistributionPolicy: ‏ STRONG_COOKIE_AFFINITY (התמדה של סשנים עם שמירת מצב), HTTP_COOKIE,‏ GENERATED_COOKIE,‏ HEADER_FIELD ו-CLIENT_IP.

כדי להגדיר זיקה לסשן (session affinity), מומלץ להשתמש ב-GCPTrafficDistributionPolicy, שהיא שיטת ברירת המחדל. עם זאת, אפשר להשתמש ב-GCPBackendPolicy בהגדרות קיימות של סוגי השיוך לסשן CLIENT_IP ו-GENERATED_COOKIE. אם שתי המדיניות מכוונות לאותו שירות, המדיניות GCPTrafficDistributionPolicy מקבלת עדיפות. אפשר גם להגדיר אלגוריתמים יציבים לאיזון עומסים, כמו RING_HASH, באמצעות GCPTrafficDistributionPolicy.

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