עיצוב אשכולות Kubernetes: כמה צריכים להיות?

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

TL; DR: ניתן להפעיל את אותה קבוצה של עומסי עבודה על מספר אשכולות גדולים (לכל אשכול יהיה מספר רב של עומסי עבודה) או על רבים קטנים (עם מספר קטן של עומסים בכל אשכול).

להלן טבלה שמעריכה את היתרונות והחסרונות של כל גישה:

כאשר משתמשים ב-Kubernetes כפלטפורמה להפעלת יישומים, עולות לעתים קרובות מספר שאלות בסיסיות לגבי המורכבויות של הקמת אשכולות:

• בכמה אשכולות עלי להשתמש?
• כמה גדול אני צריך לעשות אותם?
• מה צריך לכלול כל אשכול?

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

הצהרת שאלה

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

בנוסף, סביר להניח שהרבה מופעים של יישומים אלה יפעלו בסביבות שונות - למשל, אלה עשויים להיות dev, מבחן и לְדַרבֵּן.

התוצאה היא מטריצה ​​שלמה של יישומים וסביבות:

יישומים וסביבות

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

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

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

כתוצאה מכך, למשתמשי Kubernetes יש מספר שאלות:

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

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

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

• אשכול משותף אחד גדול;
• הרבה אשכולות קטנים מאוד מיוחדים;
• אשכול אחד לכל יישום;
• אשכול אחד לכל סביבה.

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

מכמה אשכולות גדולים (משמאל) לרבים קטנים (מימין)

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

ובכן, בואו נתחיל!

1. אשכול משותף אחד גדול

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

אשכול אחד גדול

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

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

בואו נסתכל על היתרונות והחסרונות של גישה זו.

+ שימוש יעיל במשאבים

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

לדוגמה, זה נכון עבור צמתים מאסטר. בדרך כלל, לכל אשכול Kubernetes יש 3 צמתים מאסטר, כך שלאשכול בודד אחד ישאר מספרם כך (לשם השוואה, 10 אשכולות יצטרכו 30 צמתים מאסטר).

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

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

+ זול

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

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

חלק משירותי Kubernetes מנוהלים, כגון Google Kubernetes Engine (GKE) או שירות Azure Kubernetes (AKS), ספק את שכבת הבקרה בחינם. במקרה זה, נושא העלות הוא פחות חריף.

ישנם גם שירותים מנוהלים שגובים תשלום קבוע עבור תפעול כל אשכול Kubernetes (לדוגמה, Amazon Elastic Kubernetes Service, EKS).

+ ניהול יעיל

ניהול אשכול אחד קל יותר מאשר ניהול של כמה.

הניהול עשוי לכלול את המשימות הבאות:

• עדכון גרסת Kubernetes;
• הקמת צינור CI/CD;
• התקנת תוסף CNI;
• הגדרת מערכת אימות משתמש;
• התקנה של בקר גישה;

ורבים אחרים…

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

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

ועכשיו כמה מילים על החסרונות.

- נקודת כשל בודדת

במקרה של סירוב היחיד האשכול יפסיק לעבוד באופן מיידי כל עומסי עבודה!

ישנן דרכים רבות שבהן דברים יכולים להשתבש:

• עדכון Kubernetes מוביל לתופעות לוואי בלתי צפויות;
• רכיב רחב אשכול (לדוגמה, תוסף CNI) מתחיל לא לעבוד כמצופה;
• אחד ממרכיבי האשכול אינו מוגדר כהלכה;
• כשל בתשתית הבסיסית.

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

- אין בידוד קשיח

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

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

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

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

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

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

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

חשוב לזכור תמיד ש-Kubernetes תוכנן במקור עבור שיתוף, לא בשביל בידוד ובטיחות.

− היעדר ריבוי שכירות קפדנית

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

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

Kubernetes מספקת מנגנונים שונים לשלוט בהתנהגות זו, כגון בקשות משאבים ומגבלות (ראה גם את המאמר " מגבלות מעבד ומצערת אגרסיבית ב-Kubernetes " - משוער. תרגום), משאבים מכסות и LimitRanges. עם זאת, כמו במקרה של אבטחה, התצורה שלהם היא די לא טריוויאלית והם אינם מסוגלים למנוע לחלוטין את כל תופעות הלוואי הבלתי צפויות.

- מספר רב של משתמשים

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

בתוך האשכול אתה יכול לשלוט מי יכול לעשות מה באמצעות בקרת גישה מבוססת תפקידים (RBAC) (ראה מאמר " משתמשים והרשאות RBAC ב-Kubernetes " - משוער. תרגום). עם זאת, זה לא ימנע ממשתמשים "לשבור" משהו בתחום האחריות שלהם.

- אשכולות לא יכולים לגדול ללא הגבלת זמן

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

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

יש מגבלה תיאורטית על גודל האשכול. ב-Kubernetes זה בערך 5000 צמתים, 150 אלף פודים ו-300 אלף מיכלים.

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

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

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

אבל בואו נבחן את הגישה ההפוכה: אשכולות קטנים רבים.

2. אשכולות קטנים ומתמחים רבים

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

הרבה אשכולות קטנים

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

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

בואו נסתכל על היתרונות והחסרונות של גישה זו.

+ "רדיוס פיצוץ" מוגבל

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

+ בידוד

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

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

+ מספר קטן של משתמשים

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

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

בואו נסתכל על החסרונות.

- שימוש לא יעיל במשאבים

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

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

- יקר

שימוש לא יעיל במשאבים כרוך אוטומטית בעלויות גבוהות.

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

- קשיים בניהול

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

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

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

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

3. אשכול אחד לכל אפליקציה

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

אשכול לכל אפליקציה

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

בואו נסתכל על היתרונות והחסרונות של גישה זו.

+ ניתן להתאים את האשכול לאפליקציה

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

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

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

- סביבות שונות באשכול אחד

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

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

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

ולבסוף, התרחיש האחרון ברשימה שלנו.

4. אשכול אחד לכל סביבה

תרחיש זה כולל הקצאת אשכול נפרד לכל סביבה:

אשכול אחד לכל סביבה

לדוגמה, ייתכן שיש לך אשכולות dev, מבחן и לְדַרבֵּן, שבו תפעיל את כל המופעים של האפליקציה המיועדת לסביבה ספציפית.

להלן היתרונות והחסרונות של גישה זו.

+ בידוד של סביבת הפרוד

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

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

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

+ ניתן להתאים את האשכול לסביבה

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

• התקנת כלים לפיתוח וניפוי באגים באשכול המפתחים;
• להתקין מסגרות וכלים לבדיקה באשכול מבחן;
• השתמש בחומרה ובערוצי רשת חזקים יותר באשכול לְדַרבֵּן.

זה מאפשר לך להגביר את היעילות של פיתוח אפליקציות וגם של תפעול.

+ הגבלת גישה לאשכול הייצור

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

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

ועכשיו כמה מילים על החסרונות.

- אין בידוד בין יישומים

החיסרון העיקרי של הגישה הוא היעדר בידוד חומרה ומשאבים בין יישומים.

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

כאמור, זה עלול להיות מסוכן.

- חוסר יכולת להתאים את התלות באפליקציות

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

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

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

מסקנה

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

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

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

אז באיזו גישה כדאי לנקוט?

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

עם זאת, הבחירה אינה מוגבלת לדוגמאות לעיל - אתה יכול להשתמש בכל שילוב שלהן!

לדוגמה, אתה יכול לארגן כמה אשכולות לכל צוות: אשכול פיתוח (בו יהיו סביבות dev и מבחן) ואשכול עבור הפקה (היכן תמוקם סביבת הייצור).

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

נ.ב.

קרא גם בבלוג שלנו:

• «מדריך חזותי לפתרון בעיות Kubernetes";
• «יומנים ב-Kubernetes (ולא רק) היום: ציפיות ומציאות";
• «רשת שירות: מה שכל מהנדס תוכנה צריך לדעת על הטכנולוגיה החמה ביותר";
• «ה-ABC של אבטחה ב-Kubernetes: אימות, הרשאה, ביקורת".

מקור: www.habr.com