איזון עומסים ושינוי קנה מידה של חיבורים ארוכים ב-Kubernetes

מאמר זה יעזור לך להבין כיצד איזון עומסים עובד ב-Kubernetes, מה קורה בעת שינוי קנה מידה של חיבורים ארוכי חיים ומדוע עליך לשקול איזון בצד הלקוח אם אתה משתמש ב-HTTP/2, gRPC, RSockets, AMQP או פרוטוקולים ארוכים אחרים . 

קצת על אופן הפצה מחדש של התעבורה ב-Kubernetes 

Kubernetes מספקת שתי הפשטות נוחות לפריסת יישומים: שירותים ופריסות.

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

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

בוא נראה איך זה נראה.

1. בתרשים שלהלן ניתן לראות שלושה מופעים של אותו יישום ומאזן עומסים:

   

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

   

3. תרחיש הפריסה קובע את מספר המופעים של היישום. כמעט לעולם לא תצטרך להרחיב ישירות תחת:

   

4. לכל פוד מוקצית כתובת IP משלו:

   

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

זה נראה כמו זה.

1. פניית תלתל 10.96.45.152 מתקבלת לשירות:

   

2. השירות בוחר באחת משלוש כתובות הפוד כיעד שלו:

   

3. התנועה מנותבת לתרמיל ספציפי:

   

אם האפליקציה שלך מורכבת מ-front-end ו-backend, אז יהיה לך גם שירות וגם פריסה לכל אחד.

כאשר ה-frontend שולח בקשה ל-backend, הוא לא צריך לדעת בדיוק כמה פודים ה-backend משרת: יכול להיות אחד, עשרה או מאה.

כמו כן, ה-frontend אינו יודע דבר על הכתובות של הפודים המשרתים את ה-backend.

כאשר ה-frontend מגיש בקשה ל-backend, הוא משתמש בכתובת ה-IP של שירות ה-backend, שאינה משתנה.

ככה זה נראה.

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

   

2. השירות בוחר באחד מהפודים האחוריים ככתובת היעד:

   

3. התנועה עוברת מ-Pod 1 ל-Pod 5, שנבחר על ידי השירות:

   

4. מתחת ל-1 לא יודע בדיוק כמה תרמילים כמו מתחת ל-5 מסתתרים מאחורי השירות:

   

אבל איך בדיוק השירות מפיץ בקשות? זה נראה כאילו נעשה שימוש באיזון עגול? בואו נבין את זה. 

איזון בשירותי Kubernetes

שירותי Kubernetes אינם קיימים. אין תהליך עבור השירות שמוקצים לו כתובת IP ויציאה.

אתה יכול לאמת זאת על ידי כניסה לכל צומת באשכול והפעלת הפקודה netstat -ntlp.

אפילו לא תוכל למצוא את כתובת ה-IP שהוקצתה לשירות.

כתובת ה-IP של השירות ממוקמת בשכבת הבקרה, בבקר, ונרשמת במסד הנתונים - וכו'. אותה כתובת משמשת רכיב אחר - kube-proxy.
Kube-proxy מקבל רשימה של כתובות IP עבור כל השירותים ומייצר קבוצה של חוקי iptables בכל צומת באשכול.

הכללים האלה אומרים: "אם אנו רואים את כתובת ה-IP של השירות, עלינו לשנות את כתובת היעד של הבקשה ולשלוח אותה לאחד הפודים."

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

בואו נסתכל על זה. 

1. שקול אשכול של שלושה צמתים. לכל צומת יש תרמילים:

   

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

   

3. הפוד הראשון מבקש שירות ועליו לעבור לאחד מהפודים המשויכים:

   

4. אבל השירות לא קיים, התהליך לא קיים. איך זה עובד?

   

5. לפני שהבקשה עוזבת את הצומת, היא עוברת על כללי iptables:

   

6. כללי iptables יודעים שהשירות לא קיים ומחליפים את כתובת ה-IP שלו באחת מכתובות ה-IP של הפודים המשויכים לאותו שירות:

   

7. הבקשה מקבלת כתובת IP חוקית ככתובת היעד ומעובדת כרגיל:

   

8. בהתאם לטופולוגיית הרשת, הבקשה מגיעה בסופו של דבר לתרמיל:

   

האם iptables יכול לטעון איזון?

לא, iptables משמשים לסינון ולא נועדו לאיזון.

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

וזה בדיוק מה שמיושם ב-Kubernetes.

אם יש לך שלושה פודים, kube-proxy יכתוב את הכללים הבאים:

1. בחר את המשנה הראשונה עם הסתברות של 33%, אחרת עבור לכלל הבא.
2. בחר את השני עם הסתברות של 50%, אחרת עבור לכלל הבא.
3. בחר את השלישי מתחת.

מערכת זו מביאה לכך שכל תרמיל נבחר בהסתברות של 33%.

ואין ערובה שפוד 2 ייבחר הבא אחרי פוד 1.

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

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

חיבורים ארוכים ב- Kubernetes אינם מותאמים כברירת מחדל

כל בקשת HTTP מה-frontend ל-backend מוגשת על ידי חיבור TCP נפרד, שנפתח ונסגר.

אם ה-frontend שולח 100 בקשות בשנייה ל-backend, אז 100 חיבורי TCP שונים נפתחים ונסגרים.

אתה יכול להפחית את זמן עיבוד הבקשות ואת הטעינה על ידי פתיחת חיבור TCP אחד ושימוש בו עבור כל בקשות ה-HTTP הבאות.

לפרוטוקול HTTP יש תכונה הנקראת HTTP keep-alive, או שימוש חוזר בחיבור. במקרה זה, נעשה שימוש בחיבור TCP יחיד כדי לשלוח ולקבל מספר בקשות ותגובות HTTP:

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

ההגדרה עצמה פשוטה ונגישה עבור רוב שפות התכנות והסביבות.

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

• Keep-alive ב-Node.js
• שמור בחיים במגף אביב
• שמור בחיים בפייתון
• Keep-alive ב-.NET

מה קורה אם אנו משתמשים ב-Kee-alive בשירות Kubernetes?
הבה נניח שגם הקצה הקדמי וגם הקצה האחורי תומכים ב- Keep-alive.

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

בניגוד למצב הרגיל שבו חיבור ה-TCP נסגר לאחר קבלת תגובה, כעת הוא נשמר פתוח לבקשות HTTP נוספות.

מה קורה אם ה-frontend שולח יותר בקשות ל-backend?

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

האם iptables לא אמורים לחלק מחדש את התעבורה?

לא במקרה הזה.

כאשר נוצר חיבור TCP, הוא עובר דרך כללי iptables, אשר בוחרים קצה אחורי ספציפי אליו תעבור התעבורה.

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

בוא נראה איך זה נראה.

1. הפוד הראשון שולח בקשה לשירות:

   

2. אתה כבר יודע מה יקרה אחר כך. השירות אינו קיים, אך ישנם כללי iptables שיעבדו את הבקשה:

   

3. אחד מהפודים האחוריים ייבחר ככתובת היעד:

   

4. הבקשה מגיעה לתרמיל. בשלב זה, ייווצר חיבור TCP מתמשך בין שני הפודים:

   

5. כל בקשה הבאה מהפוד הראשון תעבור דרך החיבור שכבר נוצר:

   

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

גם אם יש לך שני פודים ב-backend, עם חיבור קבוע, התנועה תמיד תעבור לאחד מהם.

האם ניתן לתקן זאת?

מכיוון ש-Kubernetes לא יודע לאזן קשרים מתמשכים, המשימה הזו מוטלת עליך.

שירותים הם אוסף של כתובות IP ויציאות הנקראות נקודות קצה.

האפליקציה שלך יכולה לקבל רשימה של נקודות קצה מהשירות ולהחליט כיצד להפיץ בקשות ביניהן. אתה יכול לפתוח חיבור מתמשך לכל פוד ובקשות לאזן בין החיבורים האלה באמצעות round-robin.

או להחיל יותר אלגוריתמי איזון מורכבים.

הקוד בצד הלקוח שאחראי לאיזון צריך לפעול לפי ההיגיון הזה:

1. קבל רשימה של נקודות קצה מהשירות.
2. פתח חיבור קבוע עבור כל נקודת קצה.
3. כאשר יש צורך להגיש בקשה, השתמש באחד מהחיבורים הפתוחים.
4. עדכן באופן קבוע את רשימת נקודות הקצה, צור נקודות קצה חדשות או סגור חיבורים קבועים ישנים אם הרשימה משתנה.

כך זה ייראה.

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

   

2. עליך לכתוב קוד ששואל אילו פודים הם חלק מהשירות:

   

3. ברגע שיש לך את הרשימה, שמור אותה בצד הלקוח והשתמש בה כדי להתחבר לתרמילים:

   

4. אתה אחראי על אלגוריתם איזון העומס:

   

כעת נשאלת השאלה: האם בעיה זו חלה רק על HTTP Keep-alive?

איזון עומסים בצד הלקוח

HTTP אינו הפרוטוקול היחיד שיכול להשתמש בחיבורי TCP מתמשכים.

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

במקום זאת, חיבור TCP מתמשך למסד הנתונים נפתח ומשתמשים בו.

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

העתק של מסד נתונים אחד יהיה טעון יותר מהאחרים. Kube-proxy ו-Kubernetes לא יעזרו באיזון החיבורים. עליך לדאוג לאזן את השאילתות למסד הנתונים שלך.

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

להלן דוגמה לגישה לאשכול מסד נתונים MySQL מ-Node.js:

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

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

• WebSockets ו- WebSockets מאובטחים
• HTTP / 2
• גר"פ
• שקעים
• AMQP

אתה כבר אמור להכיר את רוב הפרוטוקולים האלה.

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

Kube-proxy ו-iptables נועדו לכסות את רוב מקרי השימוש הנפוצים בעת פריסה ל-Kubernetes. זה מטעמי נוחות.

אם אתה משתמש בשירות אינטרנט שחושף REST API, יש לך מזל - במקרה זה, לא נעשה שימוש בחיבורי TCP מתמשכים, אתה יכול להשתמש בכל שירות Kubernetes.

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

עם זאת, בהחלט יש אפשרויות שיכולות לעזור.

איזון קשרים ארוכים ב-Kubernetes

ישנם ארבעה סוגים של שירותים ב-Kubernetes:

1. אשכול IP
2. NodePort
3. LoadBalancer
4. חסר ראש

שלושת השירותים הראשונים פועלים על בסיס כתובת IP וירטואלית, המשמשת את kube-proxy לבניית חוקי iptables. אבל הבסיס הבסיסי של כל השירותים הוא שירות ללא ראש.

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

כל השירותים מבוססים על השירות ללא ראש.

שירות ClusterIP הוא שירות חסר ראש עם כמה תוספות: 

1. שכבת הניהול מקצה לה כתובת IP.
2. Kube-proxy מייצר את כללי iptables הדרושים.

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

אבל איך נוכל להוסיף היגיון דומה לכל היישומים הפרוסים באשכול?

אם היישום שלך כבר פרוס, משימה זו עשויה להיראות בלתי אפשרית. עם זאת, יש אפשרות חלופית.

Service Mesh תעזור לך

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

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

1. מקבל רשימה של כתובות IP מהשירות.
2. פותח ושומר על בריכת חיבור.
3. מעדכן מדי פעם את המאגר על ידי הוספה או הסרה של נקודות קצה.

ברגע שהאפליקציה רוצה להגיש בקשה, היא:

1. בוחר חיבור זמין באמצעות לוגיקה כלשהי (למשל סיבוב סיבובי).
2. מבצע את הבקשה.

שלבים אלה עובדים עבור חיבורי WebSockets, gRPC ו-AMQP.

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

עם זאת, אתה יכול להשתמש ברשתות שירות כמו Istio או Linkerd במקום זאת.

Service Mesh מגדיל את האפליקציה שלך בתהליך ש:

1. מחפש אוטומטית כתובות IP של שירות.
2. בודק חיבורים כגון WebSockets ו-gRPC.
3. מאזן בקשות באמצעות הפרוטוקול הנכון.

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

מה קורה אם מתעלמים מבעיות איזון?

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

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

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

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

מה שיותר בעייתי הוא התרחיש ההפוך.

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

נניח שיש שני לקוחות וחמישה שרתים. במקרה הטוב, יהיו שני חיבורים קבועים לשני שרתים מתוך חמישה.

השרתים הנותרים יהיו פעילים:

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

מסקנה

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

עם זאת, ברגע שאתה מתחיל לעבוד עם פרוטוקולי יישומים המשתמשים בחיבורי TCP מתמשכים, כגון מסדי נתונים, gRPC או WebSockets, השירותים אינם מתאימים יותר. Kubernetes אינו מספק מנגנונים פנימיים לאיזון חיבורי TCP מתמשכים.

המשמעות היא שעליך לכתוב יישומים מתוך מחשבה על איזון בצד הלקוח.

תרגום שהוכן על ידי הצוות Kubernetes aaS מ-Mail.ru.

מה עוד לקרוא בנושא:

1. שלוש רמות של קנה מידה אוטומטי ב-Kubernetes וכיצד להשתמש בהן ביעילות. 
2. Kubernetes ברוח הפיראטיות עם תבנית ליישום.
3. ערוץ הטלגרם שלנו על טרנספורמציה דיגיטלית.

מקור: www.habr.com