Kubernetes: קוד פתוח לעומת ספק ספציפי

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

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

ניהול מספר רב של מכולות

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

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

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

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

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

איור 1. ייצוג סכמטי של אופן הפעולה של Kubernetes

אוטומציה מלאה

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

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

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

יתרונות, יתרונות, יתרונות

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

• ניהול ריפליקות מרובות. הדבר החשוב ביותר הוא ניהול קונטיינרים על פני מספר מארחים. חשוב מכך, נהל עותקים רבים של יישומים במכולות כישות אחת. הודות לכך, המהנדסים לא צריכים לדאוג לגבי כל מכולה בנפרד. אם אחד מהמכולות קורס, Kubernetes יראה את זה ויפעיל אותו מחדש.
• רשת אשכולות. ל-Kubernetes יש גם מה שנקרא רשת אשכולות עם מרחב כתובות משלה. הודות לכך, לכל פוד יש כתובת משלו. Subpod מובנה כיחידה מבנית מינימלית של אשכול שבו מכולות משוגרות ישירות. בנוסף, ל-Kubernetes פונקציונליות המשלבת איזון עומסים ו-Service Discovery. זה מאפשר לך להיפטר מניהול כתובות IP ידני ולהאציל משימה זו ל-Kubernetes. ובדיקות תקינות אוטומטיות יעזרו לזהות בעיות ולהפנות תעבורה לתרמילים עובדים.
• ניהול תצורה. בעת ניהול מספר רב של יישומים, קשה לנהל את תצורת האפליקציות. למטרה זו, ל-Kubernetes משאבי ConfigMap מיוחדים. הם מאפשרים לך לאחסן באופן מרכזי תצורות ולחשוף אותן לתרמילים בעת הפעלת יישומים. מנגנון זה מאפשר לנו להבטיח את העקביות של התצורה לפחות בעשרה או מאה העתקים של יישומים.
• כרכים מתמשכים. מיכלים מטבעם בלתי ניתנים לשינוי וכאשר המיכל יופסק, כל הנתונים שנכתבו למערכת הקבצים יושמדו. אבל יישומים מסוימים מאחסנים נתונים ישירות בדיסק. כדי לפתור בעיה זו, ל-Kubernetes יש פונקציונליות לניהול אחסון דיסק - Persistent Volumes. מנגנון זה משתמש באחסון חיצוני עבור נתונים ויכול להעביר אחסון מתמשך, בלוק או קובץ, לתוך קונטיינרים. פתרון זה מאפשר לך לאחסן נתונים בנפרד מהעובדים, מה שחוסך אותם אם אותם עובדים מתקלקלים.
• מאזן עומסים. למרות שב-Kubernetes אנו מנהלים ישויות מופשטות כמו Deployment, StatefulSet וכו', בסופו של דבר קונטיינרים פועלים על מכונות וירטואליות רגילות או שרתי חומרה. הם אינם מושלמים ויכולים ליפול בכל עת. Kubernetes יראה זאת ותפנה תעבורה פנימית לעתקים אחרים. אבל מה לעשות עם תנועה שמגיעה מבחוץ? אם פשוט תפנה תנועה לאחד העובדים, אם הוא קורס, השירות יהפוך ללא זמין. כדי לפתור בעיה זו, ל-Kubernetes יש שירותים כמו Load Balancer. הם מתוכננים להגדיר באופן אוטומטי מאזן ענן חיצוני עבור כל העובדים באשכול. מאזן חיצוני זה מפנה תנועה חיצונית לעובדים ומנטר את מצבם בעצמו. אם עובד אחד או יותר אינם זמינים, התנועה מועברת לאחרים. זה מאפשר לך ליצור שירותים זמינים ביותר באמצעות Kubernetes.

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

קוד פתוח Kubernetes

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

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

איור 2. ארכיטקטורת k8s

Kubernetes מהספק

אינטגרציה עם ספק ענן מספקת שתי אפשרויות:

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

איך זה קורה כאן. המהנדס שמתחיל את האשכול מפרט כמה עובדים הוא צריך ועם אילו פרמטרים (לדוגמה, 5 עובדים, כל אחד עם 10 מעבדים, 16 ג'יגה זיכרון RAM ולמשל 100 ג'יגה דיסק). לאחר מכן הוא מקבל גישה לאשכול שכבר נוצר. במקרה זה, העובדים עליהם מופעל העומס מועברים לחלוטין ללקוח, אך כל מישור הניהול נשאר באחריות הספק (אם השירות ניתן לפי מודל השירות המנוהל).

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

איור 3. דוגמה לאשכול Kubernetes מספק ענן

מה לבחור: קוד פתוח או ספק

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

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

המאמר הוכן על ידי דמיטרי קרסנוב, אדריכל מוביל של שירות Containerum של ספק #CloudMTS

מקור: www.habr.com