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

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

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

סקירה כללית

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

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

ניהול תנועה

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

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

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

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

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

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

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

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

  • ניהול תעבורה בהתאמה אישית באמצעות Service Extensions:

    Service Extensions מאפשרים לכם לבצע את הפעולות הבאות:

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

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

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

GatewayClass קיבולת השירות התאמה אוטומטית לעומס (autoscaling) של תנועת גולשים איזון עומסים בין כמה אשכולות חלוקת התנועה1
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 חלוקת התנועה נתמכת בשערי כניסה (Gateways) של אשכול יחיד בזמינות כללית.

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

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

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

  • ‫GCPBackendPolicy for backend selection: the GCPBackendPolicy resource enables precise control over how backend services of a load balancer distribute traffic to their backends. המדיניות הזו כוללת שדות ספציפיים שמאפשרים להגדיר מצבים שונים של איזון עומסים, כמו שימוש במדדים מותאמים אישית. כדי להגדיר בחירת קצה עורפי באמצעות GCPBackendPolicy, אפשר לעיין במאמר הגדרת בחירת קצה עורפי באמצעות GCPBackendPolicy.

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

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

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

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

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

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

כדי לראות את המדדים המותאמים אישית שמדווחים על ידי העורפים של 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 RPS מצטבר. השרתים העורפיים הכי קרובים נמצאים בeurope-west1, אבל הקיבולת שלהם היא רק 20 RPS. לשרתי הקצה העורפיים ב-us-west1 יש קיבולת עודפת, ולכן 10 בקשות לשנייה עוברות ל-us-west1, כך שהוא מקבל 16 בקשות לשנייה בסך הכול ומפיץ 8 בקשות לשנייה לכל פוד.

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

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

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

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

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

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

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

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

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

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

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

בתרשים:

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

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

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

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

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

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

בעזרת קיבולת השירות, אפשר להגדיר ערך של בקשות לשנייה (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 עם ערך מקסימלי של 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

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

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

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

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

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

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

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