streamalism.org

1. סקירה כללית

במדריך זה נבין את הצורך הבסיסי במערכת תזמור מכולות.

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

2. תזמור מיכלים

לפני שנתחיל להשוות בין Mesos ו- Kubernetes, בואו נבזבז זמן בהבנה מה הם מכולות ולמה בכל זאת אנחנו זקוקים לתזמור מכולות.

2.1. מיכלים

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

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

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

זה די טריוויאלי ליצור תמונות docker, כל מה שאנחנו צריכים זה קובץ Docker:

FRA openjdk: 8-jdk-alpine VOLUME / tmp COPY target / hello-world-0.0.1-SNAPSHOT.jar app.jar ENTRYPOINT ["java", "- jar", "/ app.jar"] EXPOSE 9001

לכן, שורות מעטות אלו מספיק טובות כדי ליצור תמונת Docker של יישום Spring Boot באמצעות ה- Docker CLI:

docker build -t hello_world.

2.2. תזמור מיכלים

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

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

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

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

3. סקירה קצרה של מסוס

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

3.1. ארכיטקטורה

ארכיטקטורת Mesos מורכבת ממסוס Master, סוכן Mesos ומסגרות יישומים:

בואו נבין את מרכיבי האדריכלות כאן:

• מסגרות: אלו הם היישומים בפועל שדורשים ביצוע מבוזר של משימות או עומס עבודה. דוגמאות אופייניות הן Hadoop או Storm. המסגרות במסוס מורכבות משני מרכיבים עיקריים:
  • מתזמן: זה אחראי על הרישום ב- Master Node כאלה שהמאסטר יכול להתחיל להציע משאבים
  • מוציא להורג: זה התהליך שמתחיל בצמתים של הסוכנים להפעיל את משימות המסגרת
• סוכני מסוס: אלו הם אחראי להפעלת המשימות בפועל. כל סוכן מפרסם בפני המאסטר את המשאבים הזמינים שלו כמו מעבד וזיכרון. בקבלת משימות מהמאסטר, הם מקצים משאבים נדרשים למבצע המסגרת.
• מאסטר מסוס: זה אחראי על תזמון משימות שהתקבלו מהמסגרות באחד מצומת הסוכנים הזמינים. מאסטר מציע הצעות משאבים למסגרות. המתזמן של Framework יכול לבחור להפעיל משימות על המשאבים הזמינים הללו.

3.2. מָרָתוֹן

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

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

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

3.3. דוגמא

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

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

# hello-marathon.json {"id": "marathon-demo-application", "cpus": 1, "mem": 128, "disk": 0, "instances": 1, "container": {"type ":" DOCKER "," docker ": {" image ":" hello_world: latest "," portMappings ": [{" containerPort ": 9001," hostPort ": 0}]}}," רשתות ": [{" mode ":" host "}]}

בואו נבין מה בדיוק קורה כאן:

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

אנו יכולים להפעיל יישום זה באמצעות ממשקי ה- API של REST המסופקים על ידי מרתון:

תלתל -X POST \ // localhost: 8080 / v2 / apps \ -d @ hello-marathon.json \ -H "סוג תוכן: יישום / json"

4. סקירה קצרה של קוברנטס

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

4.1. ארכיטקטורה

אדריכלות קוברנטס מורכבת ממאסטר קוברנט וצמתים של קוברנטס:

בואו נעבור על החלקים העיקריים בארכיטקטורה ברמה גבוהה זו:

• מאסטר קוברנטס: ה המאסטר אחראי על שמירת המצב הרצוי של האשכול. הוא מנהל את כל הצמתים באשכול. כפי שאנו רואים, המאסטר הוא אוסף של שלושה תהליכים:
  • kube-apiserver: זה השירות שמנהל את כל האשכול, כולל עיבוד פעולות REST, אימות ועדכון אובייקטים של Kubernetes, ביצוע אימות והרשאה
  • מנהל קוביית הבקר: זה הדמון הטבוע את לולאת בקרת הליבה נשלח עם Kubernetes, תוך ביצוע השינויים הדרושים כדי להתאים את המצב הנוכחי למצב הרצוי של האשכול
  • מתזמן קוביות: שירות זה שומר על תרמילים לא מתוזמנים וקושר אותם לצמתים בהתאם למשאבים המבוקשים ולאילוצים אחרים
• צמתים של קוברנטס: הצמתים באשכול Kubernetes הם המכונות המפעילות את המכולות שלנו. כל צומת מכיל את השירותים הדרושים להפעלת המכולות:
  • קובלט: זה סוכן הצומת הראשי אשר מבטיח כי המכולות המתוארות ב- PodSpecs מסופקות על ידי kube-apiserver רצים ובריאים
  • קוביית פרוקסי: זה שרת ה- proxy ברשת פועל על כל צומת ומבצע העברת זרמים פשוטים של TCP, UDP, SCTP או העברת סיבוב סביב קבוצה של backends
  • זמן ריצה של מכולה: זה זמן הריצה שבו מריצים מיכל בתוך התרמילים, ישנם מספר זמן אפשרי של מכולות עבור Kubernetes, כולל זמן הריצה Docker הנפוץ ביותר

4.2. אובייקטים קוברנטיים

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

בואו נדון בכמה מחפצי Kubernetes הנפוצים:

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

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

4.3. דוגמא

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

לאחר התקנת kubectl ו- Minikube, נוכל לפרוס את המכולה שלנו באשכול Kubernetes בצומת יחיד בתוך Minikube. עלינו להגדיר את אובייקטים בסיסיים של Kubernetes בקובץ YAML:

# hello-kubernetes.yaml api גרסה: אפליקציות / v1 סוג: פריט מטא נתונים: שם: שלום עולם מפרט: העתקים: תבנית אחת: מטא נתונים: תוויות: אפליקציה: שלום עולם מפרט: מכולות: - שם: שלום עולם תמונה: שלום -עולם: יציאות אחרונות: - מיכל נמל: 9001 --- api גרסה: v1 סוג: מטא נתונים של שירות: שם: מפרט שירות שלום-עולם: בורר: אפליקציה: שלום-עולם סוג: יציאות LoadBalancer: - יציאה: 9001 targetport: 9001

ניתוח מפורט של קובץ הגדרה זה אינו אפשרי כאן, אך בוא נעבור על נקודות השיא:

• הגדרנו א פְּרִיסָה עם תוויות בבורר
• אנו מגדירים את מספר ההעתקים הדרושים לפריסה זו
• כמו כן, סיפקנו את פרטי תמונת המכולה כתבנית לפריסה
• הגדרנו גם א שֵׁרוּת עם בורר מתאים
• הגדרנו את אופי השירות כ- LoadBalancer

לבסוף, אנו יכולים לפרוס את המכולה וליצור את כל אובייקטים מוגדרים Kubernetes באמצעות kubectl:

kubectl להחיל -f yaml / hello-kubernetes.yaml

5. מסוס מול קוברנטס

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

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

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

5.1. עומסי עבודה נתמכים

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

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

5.2. תמיכה בהרחבה

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

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

5.3. טיפול בזמינות גבוהה

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

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

5.4. גילוי שירות ואיזון עומסים

Mesos-DNS יכול לספק גילוי שירותים ואיזון עומסים בסיסי ליישומים. Mesos-DNS מייצר רשומת SRV עבור כל משימת Mesos ומתרגם אותם לכתובת ה- IP ולנמל של המכונה שמריצה את המשימה. עבור יישומי מרתון, אנו יכולים גם להשתמש ב- Marathon-lb כדי לספק גילוי מבוסס נמל באמצעות HAProxy.

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

5.5 ביצוע שדרוגים והחזרות

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

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

5.6. רישום ומעקב

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

קוברנטס לפרסם מידע מפורט הקשור לאובייקטים שונים כמדדי משאבים או צינורות מדדים מלאים. נוהג אופייני הוא פריסת כלי חיצוני כמו ELK או Prometheus + Grafana באשכול Kubernetes. כלים כאלה יכולים להכניס מדדי אשכול ולהציג אותם בצורה הרבה יותר ידידותית למשתמש.

5.7. אִחסוּן

למסוס יש אמצעי אחסון מקומיים מתמשכים עבור יישומים סטטיים. אנו יכולים ליצור כרכים מתמשכים רק מהמשאבים השמורים. זה יכול גם לתמוך באחסון חיצוני עם מגבלות מסוימות. ל- Mesos תמיכה ניסיונית בממשק אחסון מכולות (CSI), קבוצה משותפת של ממשקי API בין ספקי אחסון לפלטפורמת תזמור מכולות.

Kubernetes מציע מספר סוגים של נפח מתמשך עבור מכולות סטטיות. זה כולל אחסון כמו iSCSI, NFS. יתר על כן, הוא תומך באחסון חיצוני כמו AWS, GCP גם כן. אובייקט ה- Volume ב- Kubernetes תומך במושג זה ומגיע במגוון סוגים, כולל CSI.

5.8. נטוורקינג

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

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

6. מתי להשתמש במה?

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

ביצועים, לעומת זאת, הם היבט מכריע למדי. מקבץ Kubernetes יכול להשתנות ל -5000 צמתים, ואילו ידוע כי מרתון באשכול Mesos תומך בעד 10,000 סוכנים. ברוב המקרים המעשיים לא נעסוק באשכולות כה גדולים.

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

7. אלטרנטיבות אחרות

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

• נחיל דוקר: נחיל דוקר הוא כלי אשכול ותזמון קוד פתוח למכולות Docker. זה מגיע עם כלי שורת פקודה לניהול אשכול של מארחי דוקר. זה מוגבל למכולות Docker, שלא כמו Kubernetes ו- Mesos.
• נווד: נווד הוא מתזמן עומסי עבודה גמיש מבית HashiCorp לניהול כל יישום מיכל או לא מיכל. Nomad מאפשר תשתית הצהרתית כקוד לפריסת יישומים כמו מיכל Docker.
• OpenShift: OpenShift הוא פלטפורמת מכולה מ- Red Hat, מתוזמר ומנוהל על ידי קוברטס שמתחת. OpenShift מציע תכונות רבות נוסף על מה שקוברנטס מספקות כמו רישום תמונות משולב, בניית מקור לתמונה, פיתרון רשת מקורי, עד כמה שם.

8. מסקנה

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

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