לפני כשנה כתבתי פוסט שעסק ב- COFs) Container Orchestration Frameworks) והשווה בין מזוס, ECS, קוברנטיס, Swarm ו- Nomad ובאותה עת נראה היה שהתחרות בין כמה מהכלים האלו עדיין פתוחה.
כשאני מסתכל על ההתרחשויות של השנה האחרונה - כפי שזה נראה, Kubernetes היא שתכתיב את הטון בעתיד הנראה לעין.
:קצת רקע
• קוברנטיס (לעתים נכתב בקיצור K8s) היא פריימוורק ששוחררה כפרויקט קוד פתוח ע״י גוגל באמצע שנת 2014 לניהול Orchestrations של Containers. בסה"כ בת ארבע שנים.
• לגוגל היה ניסיון קודם בפרויקטים פנימיים דומים: הראשון בשם Borg והמחליף שלו Omega, להרצת קונטיינרים. הם לא הריצו Docker או Rkt - אלא קונטיינרים פרי פיתוח מוקדם של גוגל. הניסיון הזה הוכיח את עצמו.
• קוברנטיס (בדומה ל- COFs אחרים) מספקת יכולות Load Balancing, Discovery וAuto-Scaling ובעצם מהווה סוג של ״מיני-ענן״ בו יחידת ה- compute היא Container. האיום הזה לא נחבא מעיניהם של ספקי-הענן הגדולים, והם ניסו לפתח COFs מקבילים שישמרו את ה- Lock-In לענן שלהם.
• אמזון יצאה עם ECS, ומיקרוסופט עם ACS (שתי החברות שאולי היה להן הכי הרבה להפסיד) - פתרון הרצת ו Orchestrations של Containers שתפור לענן שלהן. והן הטילו את כובד משקלן בכדי לשכנע שזו אלטרנטיבה ראויה (וטובה יותר) לקוברנטיס - אלטרנטיבה שרק צריכה עוד זמן להבשיל.
• השוק לא הגיב יפה להצעות הללו - ופנה ל- manual installation של קוברנטיס על גבי EC2.
• מיקרוסופט הוציאה את AKS (קרי Azure Kubernetes Service) ואמזון את EKS (קרי Elastic Kubernetes Service) כ- Kubernetes מנוהל. בהתחלה נראה היה ש- EKS ו- AKS הולכים להיות offering משני על מנת לשמר לקוחות ולא להישאר יותר מדי מאחור, אבל מהר מאוד התברר שהשירותים הללו תופסים את תשומת לב הלקוחות, ומשם השתנו הדברים והם התחילו לקבל גם את מירב ההשקעה מצד ספקי הענן. ECS/ACS הופכים להיות פתרונות נישה, בעיקר עבור לקוחות שכבר נרתמו לחזון שהוצג ב- 2015, והשקיעו בו, או אולי יצליחו לשלב אותם גם בעולם של קוברנטיס (עבור ה- worker nodes - על זה בהמשך).
• גם פתרונות ענן כגון Pivotal Container Service ו- Cloud Foundary הגיעו למסקנה דומה, ופנו לכיוון קוברנטיס.
• אפילו החברה מאחורי Docker שניסתה להציג חזון משלה בדמות Swarm (לאחר שהבינה שב- COFs יש פוטנציאל עסקי גדול יותר מתמיכה ב- Docker בלבד) כאשר הכריזה לפני כשנה על תמיכה ״גם״ בקוברנטיס - מה שבפועל ״הוציא את העוקץ״ מ- Swarm שמותג כ"פתרון הרשמי של דוקר".
• Mesosphere DC/OS - הגרסה המסחרית של Mesos, מציעה גם היא תמיכה בקוברנטיס.
בקיצור: מלחמת ה COFs הסתיימה וה- Kubernetes ניצח.
חשוב לציין שלמרות שקוברנטיס הוא ה- COF שהפך לברירת-המחדל, יש עדיין תהליכים שלא ברור כיצד יסתיימו:
• מיקרוסופט שחררה את ACI (קרי Azure Container Instances) ואמזון את AWS Fargate כשירותים בהם ניתן להריץcontainer on-demand ולשלם ע״פ השימוש הנקודתי. השירותים מזכירים מאוד את AWS Lambda או Azure functions כאשר הרזולוציה היא Container ולא פונקציה, על אף שמנסים לשווק אותם כ"תחליף ל- EC2".
• השימוש העיקרי הוא בהפעלה של containers המבצעים batch של עבודה - ולא בהרכבה של containers מסוגים שונים המתקשרים זה עם זה. האלמנט של Orchestration לא ממש קיים בשירותים הללו.
• גם קוברנטיס תומכת בהפעלת containers באופן on-demand, מה שעשוי לרמז שהלקוחות העיקריים של ACI ו- Fargate הם לקוחות שלא מריצים קובנרטיס או כאלו שיש להם Workload מאסיבי שאינם רוצים להפעיל על ה- Kubernetes cluster הרגיל שלהם (למשל: משימות AI כבדות).
• קוברנטיס עצמה נפתחה לספקי הענן, למשל: החל מגרסה 1.9 היא תומכת באופן טבעי ב- AWS NLB (קרי Network Load Balancer). מיותר לציין שיש הרבה Kubernetes-plugins שמסייעים לבצע את החיבורים לעננים ספציפיים בצורה טבעית יותר.
• ישנה השקעה בהרצה של Kubernetes בכדי להפעיל VMs ולא רק Containers. המוטיבציה היא לשלב גם שרתים שאינם לינוקס (למשל Windows או אפליקציות Unikernel) ו/או בידוד גבוה יותר - בעיקר משיקולי אבטחה.
• קוברנטיס מאפשרת יכולות ניהול משאבים טובות ברמת התשתית, אבל ניהול של מאות מיקרו-שירותים הוא עדיין דבר קשה מאוד לביצוע. יש פרויקטים (למשל: lstio הנתמך ע״י Lyft, IBM וגוגל) המנסים לספק שכבת ניהול ברמה יותר ״אפליקטיבית״ שתקל על ניהול שכזה. פרויקטים כאלו יכולים להשתלב עם קוברנטיס כ- plug-in ו/או להחליף כמה מיכולות הליבה שלה (למשל: Service Discovery או Load Balancing).
Managed Kubernetes
כמה שאנו אוהבים לשמוע כמה אוטומטית ו״חכמה״ היא קוברנטיס בניהול ה- Containers Cluster, הפעלה של קוברנטיס היא עדיין משימה מורכבת מכמה סיבות:
• יש שורה של בחירות שיש לבצע בהתקנה של קוברנטיס. האם אתם מעדיפים א או ב, ג או ד? דוגמה טובה היא תקשורת בין Containers: האם Kubenet (ברירת-המחדל) מספיק לכם? אולי אתם צריכים scale, ביצועים, ו/או יכולות שליטה מתקדמות יותר ברמת הרשת וכדאי להשתמש ב Weave? אולי בעצם ב Calico? ואם אתם בוחרים ב Calico - אתם מעדיפים אותו עם Flannel (כלומר: Canal) או בלעדיו?
• קוברנטיס מטפל בשורה של מקרי-קצה מורכבים להבנה, שללא ניסיון ניכר קשה להבין אותם ולוודא שהם עובדים בצורה תקינה.
• High Availability - איך להבטיח ש pods ימשיכו לתפקד ככל האפשר. לדוגמה: האם ה- masters הם באמת highly available? האם אתם יכולים ליצור master חדש עם קונפיגורציה שלמה בצורה אוטומטית?
• אבטחה - האם אתם מודעים כיצד להקשיח התקנה של קוברנטיס, ויש לכם את המנגנון להתקין עדכונים בכל השכבות?
• חיבור של קוברנטיס לספק הענן הספציפי היא עוד משוכה שיש לעבור. למשל: על EC2 לא תוכלו ליצור cluster גדול מ- 50 nodes ללא החלפה של ה- CNI Network plugin. כנראה שתרצו כמה מה- nodes שירוצו על spots. כדאי מאוד להתחבר ל- IAM בצורה נכונה, לקנפג את Route53 כך שה- master ימצא את כל הרכיבים שלו ואם יש כמה clusters - הם יהיו זקוקים ל- subdomains, וכו׳.
הפתרון הטבעי, בדומה מאוד לבחירה בספק ענן (ולא הפעלה של Data Center של החברה) - הוא שימוש ב Managed Kubernetes. זו הבחירה הטבעית עבור רוב משתמשי Kubernetes, בייחוד אלו שלא הולכים להריץ אלפי שרתים ב- Cluster של קוברנטיס (ולכן סביר יותר שיהיה לכם את האינטרס והמשאבים לעבוד עם קונפיגורציה מאוד ספציפית ("לא מקובלת") לצרכים שלכם).
בחלק הבא נציג כלים נפוצים נסקור את הפתרונות האפשריים של Managed Kubernetes ונבצע השוואה ביניהם.
Gett בחברת (Chief Architect) מאת: ליאור בר און, ארכיטקט ראשי
http://www.softwarearchiblog.com
לפני כשנה כתבתי פוסט שעסק ב- COFs) Container Orchestration Frameworks) והשווה בין מזוס, ECS, קוברנטיס, Swarm ו- Nomad ובאותה עת נראה היה שהתחרות בין כמה מהכלים האלו עדיין פתוחה.
כשאני מסתכל על ההתרחשויות של השנה האחרונה - כפי שזה נראה, Kubernetes היא שתכתיב את הטון בעתיד הנראה לעין.
:קצת רקע
• קוברנטיס (לעתים נכתב בקיצור K8s) היא פריימוורק ששוחררה כפרויקט קוד פתוח ע״י גוגל באמצע שנת 2014 לניהול Orchestrations של Containers. בסה"כ בת ארבע שנים.
• לגוגל היה ניסיון קודם בפרויקטים פנימיים דומים: הראשון בשם Borg והמחליף שלו Omega, להרצת קונטיינרים. הם לא הריצו Docker או Rkt - אלא קונטיינרים פרי פיתוח מוקדם של גוגל. הניסיון הזה הוכיח את עצמו.
• קוברנטיס (בדומה ל- COFs אחרים) מספקת יכולות Load Balancing, Discovery וAuto-Scaling ובעצם מהווה סוג של ״מיני-ענן״ בו יחידת ה- compute היא Container. האיום הזה לא נחבא מעיניהם של ספקי-הענן הגדולים, והם ניסו לפתח COFs מקבילים שישמרו את ה- Lock-In לענן שלהם.
• אמזון יצאה עם ECS, ומיקרוסופט עם ACS (שתי החברות שאולי היה להן הכי הרבה להפסיד) - פתרון הרצת ו Orchestrations של Containers שתפור לענן שלהן. והן הטילו את כובד משקלן בכדי לשכנע שזו אלטרנטיבה ראויה (וטובה יותר) לקוברנטיס - אלטרנטיבה שרק צריכה עוד זמן להבשיל.
• השוק לא הגיב יפה להצעות הללו - ופנה ל- manual installation של קוברנטיס על גבי EC2.
• מיקרוסופט הוציאה את AKS (קרי Azure Kubernetes Service) ואמזון את EKS (קרי Elastic Kubernetes Service) כ- Kubernetes מנוהל. בהתחלה נראה היה ש- EKS ו- AKS הולכים להיות offering משני על מנת לשמר לקוחות ולא להישאר יותר מדי מאחור, אבל מהר מאוד התברר שהשירותים הללו תופסים את תשומת לב הלקוחות, ומשם השתנו הדברים והם התחילו לקבל גם את מירב ההשקעה מצד ספקי הענן. ECS/ACS הופכים להיות פתרונות נישה, בעיקר עבור לקוחות שכבר נרתמו לחזון שהוצג ב- 2015, והשקיעו בו, או אולי יצליחו לשלב אותם גם בעולם של קוברנטיס (עבור ה- worker nodes - על זה בהמשך).
• גם פתרונות ענן כגון Pivotal Container Service ו- Cloud Foundary הגיעו למסקנה דומה, ופנו לכיוון קוברנטיס.
• אפילו החברה מאחורי Docker שניסתה להציג חזון משלה בדמות Swarm (לאחר שהבינה שב- COFs יש פוטנציאל עסקי גדול יותר מתמיכה ב- Docker בלבד) כאשר הכריזה לפני כשנה על תמיכה ״גם״ בקוברנטיס - מה שבפועל ״הוציא את העוקץ״ מ- Swarm שמותג כ"פתרון הרשמי של דוקר".
• Mesosphere DC/OS - הגרסה המסחרית של Mesos, מציעה גם היא תמיכה בקוברנטיס.
בקיצור: מלחמת ה COFs הסתיימה וה- Kubernetes ניצח.
חשוב לציין שלמרות שקוברנטיס הוא ה- COF שהפך לברירת-המחדל, יש עדיין תהליכים שלא ברור כיצד יסתיימו:
• מיקרוסופט שחררה את ACI (קרי Azure Container Instances) ואמזון את AWS Fargate כשירותים בהם ניתן להריץcontainer on-demand ולשלם ע״פ השימוש הנקודתי. השירותים מזכירים מאוד את AWS Lambda או Azure functions כאשר הרזולוציה היא Container ולא פונקציה, על אף שמנסים לשווק אותם כ"תחליף ל- EC2".
• השימוש העיקרי הוא בהפעלה של containers המבצעים batch של עבודה - ולא בהרכבה של containers מסוגים שונים המתקשרים זה עם זה. האלמנט של Orchestration לא ממש קיים בשירותים הללו.
• גם קוברנטיס תומכת בהפעלת containers באופן on-demand, מה שעשוי לרמז שהלקוחות העיקריים של ACI ו- Fargate הם לקוחות שלא מריצים קובנרטיס או כאלו שיש להם Workload מאסיבי שאינם רוצים להפעיל על ה- Kubernetes cluster הרגיל שלהם (למשל: משימות AI כבדות).
• קוברנטיס עצמה נפתחה לספקי הענן, למשל: החל מגרסה 1.9 היא תומכת באופן טבעי ב- AWS NLB (קרי Network Load Balancer). מיותר לציין שיש הרבה Kubernetes-plugins שמסייעים לבצע את החיבורים לעננים ספציפיים בצורה טבעית יותר.
• ישנה השקעה בהרצה של Kubernetes בכדי להפעיל VMs ולא רק Containers. המוטיבציה היא לשלב גם שרתים שאינם לינוקס (למשל Windows או אפליקציות Unikernel) ו/או בידוד גבוה יותר - בעיקר משיקולי אבטחה.
• קוברנטיס מאפשרת יכולות ניהול משאבים טובות ברמת התשתית, אבל ניהול של מאות מיקרו-שירותים הוא עדיין דבר קשה מאוד לביצוע. יש פרויקטים (למשל: lstio הנתמך ע״י Lyft, IBM וגוגל) המנסים לספק שכבת ניהול ברמה יותר ״אפליקטיבית״ שתקל על ניהול שכזה. פרויקטים כאלו יכולים להשתלב עם קוברנטיס כ- plug-in ו/או להחליף כמה מיכולות הליבה שלה (למשל: Service Discovery או Load Balancing).
Managed Kubernetes
כמה שאנו אוהבים לשמוע כמה אוטומטית ו״חכמה״ היא קוברנטיס בניהול ה- Containers Cluster, הפעלה של קוברנטיס היא עדיין משימה מורכבת מכמה סיבות:
• יש שורה של בחירות שיש לבצע בהתקנה של קוברנטיס. האם אתם מעדיפים א או ב, ג או ד? דוגמה טובה היא תקשורת בין Containers: האם Kubenet (ברירת-המחדל) מספיק לכם? אולי אתם צריכים scale, ביצועים, ו/או יכולות שליטה מתקדמות יותר ברמת הרשת וכדאי להשתמש ב Weave? אולי בעצם ב Calico? ואם אתם בוחרים ב Calico - אתם מעדיפים אותו עם Flannel (כלומר: Canal) או בלעדיו?
• קוברנטיס מטפל בשורה של מקרי-קצה מורכבים להבנה, שללא ניסיון ניכר קשה להבין אותם ולוודא שהם עובדים בצורה תקינה.
• High Availability - איך להבטיח ש pods ימשיכו לתפקד ככל האפשר. לדוגמה: האם ה- masters הם באמת highly available? האם אתם יכולים ליצור master חדש עם קונפיגורציה שלמה בצורה אוטומטית?
• אבטחה - האם אתם מודעים כיצד להקשיח התקנה של קוברנטיס, ויש לכם את המנגנון להתקין עדכונים בכל השכבות?
• חיבור של קוברנטיס לספק הענן הספציפי היא עוד משוכה שיש לעבור. למשל: על EC2 לא תוכלו ליצור cluster גדול מ- 50 nodes ללא החלפה של ה- CNI Network plugin. כנראה שתרצו כמה מה- nodes שירוצו על spots. כדאי מאוד להתחבר ל- IAM בצורה נכונה, לקנפג את Route53 כך שה- master ימצא את כל הרכיבים שלו ואם יש כמה clusters - הם יהיו זקוקים ל- subdomains, וכו׳.
הפתרון הטבעי, בדומה מאוד לבחירה בספק ענן (ולא הפעלה של Data Center של החברה) - הוא שימוש ב Managed Kubernetes. זו הבחירה הטבעית עבור רוב משתמשי Kubernetes, בייחוד אלו שלא הולכים להריץ אלפי שרתים ב- Cluster של קוברנטיס (ולכן סביר יותר שיהיה לכם את האינטרס והמשאבים לעבוד עם קונפיגורציה מאוד ספציפית ("לא מקובלת") לצרכים שלכם).
בחלק הבא נציג כלים נפוצים נסקור את הפתרונות האפשריים של Managed Kubernetes ונבצע השוואה ביניהם.
Gett בחברת (Chief Architect) מאת: ליאור בר און, ארכיטקט ראשי
http://www.softwarearchiblog.com
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר