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

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

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

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

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

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

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

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

‫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: נתוני הניצול הנוכחיים של כל קבוצת backend, על סמך המדדים המותאמים אישית שהגדרתם.
• ‫/fullness: רמת העומס הנוכחית (עומס או קיבולת) של כל קבוצת קצה עורפי, שמאזני העומסים משתמשים בה כדי לקבל החלטות לגבי ניתוב.
• ‫/rate: בקשות שמתקבלות בכל קבוצת שרתים עורפיים (backend) בכל שנייה.

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

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

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

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

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

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

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

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

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

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

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

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

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

בתרשים:

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

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

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

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

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

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

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

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

דרישות

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

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

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

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

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

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

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

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

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

• כשפורסים מאזני עומסים פנימיים וחיצוניים באופן ידני באמצעות קבוצות עצמאיות של נקודות קצה ברשת (NEGs)
• כשפורסים את Cloud Service Mesh ב-GKE באמצעות NEGs עצמאיים

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

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

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

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

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

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

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

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

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

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

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

בטבלה הבאה מפורטים הקיבולות שמוגדרות כברירת מחדל:

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

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

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

התאמה אוטומטית לעומס על סמך תעבורה מספקת את היתרונות הבאים:

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

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

בתרשים:

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

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

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

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

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

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

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

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

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

• מידע נוסף על פריסת שערים
• סקירה כללית על אבטחת שערים
• מידע על Gateway API
• איך מגדירים משאבי Gateway
• מידע על היכולות של GatewayClass