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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בתרשים:

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

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

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

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

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

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

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

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

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

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

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

בתרשים:

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

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

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

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

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

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

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

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

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

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

קיבולת שירות שמוגדרת כברירת מחדל

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

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

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

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

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

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

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

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

בתרשים:

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

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

בתרשים הבא מוצג אופן הפעולה של שינוי גודל אוטומטי על סמך תנועה באפליקציה שמקבלת 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 תומך בכל סוגי הזיקה לסשן שזמינים במופעים שלCloud de Confiance by S3NS מאזן עומסים של אפליקציות באמצעות המשאב GCPTrafficDistributionPolicy: ‏ STRONG_COOKIE_AFFINITY (התמדה של סשנים עם שמירת מצב), HTTP_COOKIE,‏ GENERATED_COOKIE,‏ HEADER_FIELD ו-CLIENT_IP.

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

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

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