צמתי עובד של Kubernetes: רבים קטנים או כמה גדולים?

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

התשובות לשאלות אלו נמצאות במאמר. דניאל ווייבל, מהנדס תוכנה ומורה לפרויקט החינוכי Learnk8S בתרגום הפקודה Kubernetes aaS מ-Mail.ru.

קיבולת אשכול

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

ישנן מספר דרכים להשיג את יעד קיבולת האשכול הרצוי. לדוגמה, אנו זקוקים לאשכול בעל קיבולת כוללת של 8 ליבות מעבד ו-32 ג'יגה-בייט של זיכרון RAM מכיוון שמערכת יישומים דורשת כל כך הרבה משאבים. לאחר מכן תוכל להתקין שני צמתים עם זיכרון של 16 ג'יגה-בייט או ארבעה צמתים עם זיכרון של 8 ג'יגה-בייט, שני מעבדים מרובע ליבות או ארבעה מעבדים דו-ליבים.

הנה רק שתי דרכים אפשריות ליצור אשכול:

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

איזו אפשרות עדיפה?

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

מספר צמתים גדולים

צמתים קטנים רבים

ניהול אשכולות קל יותר (אם הוא מקומי)

שיוך אוטומטי חלק

זול יותר (אם במקום)

המחיר מעט שונה (בענן)

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

שכפול מלא

נעשה שימוש יעיל יותר במשאבים (פחות תקורה בדמונים של המערכת
סובלנות גבוהה יותר לתקלות מקבץ

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

אז בואו נדון בכל נקודה מהטבלה ביתר פירוט.

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

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

Pros

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

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

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

ניתוב תנועה וחלוקת עומסים בין פודים בענן מבוצע באופן אוטומטי: תנועה המגיעה מהאינטרנט נשלחת למאזן העומס הראשי, המעביר את התעבורה ליציאת אחד הצמתים (שירות Nodeport מגדיר את היציאה בטווח 30000-32767 בכל צומת אשכול). הכללים שנקבעו על ידי תנועה מחדש של Kube-Proxy מהצומת לתרמיל. הנה איך זה נראה עבור עשרה תרמילים בשני צמתים:

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

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

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

Pro #3: אתה יכול להריץ יישומים אינטנסיביים למשאבים
יישומים מסוימים דורשים שרתים חזקים באשכול. לדוגמה, אם מערכת למידת מכונה דורשת זיכרון של 8 ג'יגה -בייט, לא תוכל להריץ אותה על צמתים של 1 ג'יגה -בייט, אלא רק עם צומת עובד גדול אחד לפחות.

חסרונות

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

זו יכולה להיות בעיה.

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

לדוגמה, קובלט בודק באופן קבוע את כל המכולות על צומת לשרידות - ככל שיותר מכולות, כך קובלט צריך לעשות יותר.

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

אם מספר המודולים גדל, הוא יכול להאט את המערכת ואף לערער את אמינותה.

במאגר Kubernetes כמה התלונןשצמתים קופצים בין סטטוסים Ready/NotReady מכיוון שבדיקות kubelet רגילות של כל הקונטיינרים בצומת נמשכות יותר מדי זמן.
מסיבה זו Kubernetes ממליץ להציב לא יותר מ-110 תרמילים לכל צומת. בהתאם לביצועים של הצומת, אתה יכול להפעיל יותר פודים לכל צומת, אבל קשה לחזות אם יהיו בעיות או שהכל יעבוד כשורה. כדאי לבדוק את העבודה מראש.

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

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

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

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

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

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

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

החיסרון מספר 4: עוד צעדים אוטומטיים
ל-Kubernetes מערכת קנה מידה אוטומטי של אשכולות עבור תשתית ענן, המאפשרת לך להוסיף או להסיר צמתים באופן אוטומטי בהתאם לצרכים הנוכחיים שלך. עם צמתים גדולים יותר, קנה המידה האוטומטי הופך פתאומי ומסורבל יותר. לדוגמה, בשני צמתים, הוספת צומת נוסף תגדיל מיד את קיבולת האשכול ב-50%. ואתה תצטרך לשלם עבור המשאבים האלה, גם אם אתה לא צריך אותם.

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

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

אפשרות שנייה: צמתים קטנים רבים

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

Pros

Pro #1: פחות השפעה של כישלון
ככל שיותר צמתים, כך פחות תרמילים בכל צומת. לדוגמה, אם יש לך מאה מודולים לכל עשרה צמתים, אז לכל צומת יהיו בממוצע עשרה מודולים.

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

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

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

חסרונות

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

בקר הצומת ב-Kubernetes Controller Manager עובר באופן קבוע בכל הצמתים באשכול כדי לבדוק את תקינותו - ככל שיותר צמתים, העומס על הבקר עולה.

גם העומס על מסד הנתונים של etcd גדל - כל kubelet ו-kube-proxy מתקשרים צוֹפֶה עבור etcd (דרך ה-API), שאליו על etcd לשדר עדכוני אובייקט.

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

Kubernetes תומך רשמית באשכולות עם מספר צמתים עד 5000. עם זאת, בפועל יש כבר 500 צמתים יכול לגרום לבעיות לא טריוויאליות.

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

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

החיסרון מספר 2: עלויות תקורה נוספות.
בכל צומת עובד, Kubernetes מריץ קבוצה של דמוני מערכת - אלה כוללים את זמן הריצה של מיכל (כגון Docker), kube-proxy ו-kubelet, כולל cAdvisor. יחד הם צורכים כמות קבועה מסוימת של משאבים.

אם יש לך צמתים קטנים רבים, הפרופורציה של תקורה זו בכל צומת גדולה יותר. לדוגמה, דמיינו שכל דמוני המערכת בצומת בודד משתמשים יחד ב-0,1 ליבות מעבד ו-0,1 GB של זיכרון. אם יש לך צומת עשר ליבות אחד עם 10 ג'יגה-בייט של זיכרון, אז הדמונים צורכים 1% מקיבולת האשכול. מצד שני, בעשרה צמתים ליבה אחת עם זיכרון של 1 ג'יגה-בייט, הדמונים יקחו 10% מקיבולת האשכול.

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

חסרון מס' 3. שימוש לא יעיל במשאבים
בצמתים קטנים, ייתכן שחלקי המשאבים הנותרים קטנים מכדי להקצות להם עומס עבודה כלשהו, ​​ולכן הם נותרים ללא שימוש.

לדוגמה, כל פוד דורש 0,75 GB של זיכרון. אם יש לך עשרה צמתים, כל אחד עם 1GB של זיכרון, אתה יכול להפעיל עשרה פודים, ולהשאיר לכל צומת 0,25GB של זיכרון לא בשימוש.

המשמעות היא ש -25% מזיכרון האשכול כולו מבוזבזים.

בצומת גדול עם זיכרון של 10 ג'יגה-בייט, אתה יכול להריץ 13 מהמודולים האלה - ויהיה רק ​​קטע אחד שאינו בשימוש של 0,25 ג'יגה-בייט.

במקרה זה, רק 2,5% מהזיכרון מתבזבז.

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

מספר צמתים גדולים או רבים קטנים?

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

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

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

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

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

תרגום שהוכן על ידי צוות פלטפורמת הענן פתרונות ענן של Mail.ru.

עוד על Kubernetes: 25 כלים שימושיים לניהול ופריסה של אשכולות.

מקור: www.habr.com