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

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

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

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

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

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

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

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

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

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

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

במקום לבזבז זמן על תחזוקת אשקולות, הצוות שלכם יכול להתמקד במה שבאמת חשוב, האפליקציות שאתם בונים. עבור רוב הצוותים, במיוחד אלו שרק מתחילים, קוברנטיז מנוהל הוא הבחירה הנכונה. אתם מקבלים את כל העוצמה של קוברנטיז ללא התקורה התפעולית. AKS, קוברנטיז שהופך לפשות באז'ר. אז מה זה בדיוק AKS? זהו שירות הקוברנטס המנוהל של Azure, המעניק לכם אשקול מלא ללא צורך לבנות אותו מאפס. מישור הבקרה הוא בחינם, כפי שציינו, כך שאתם משלמים רק על המכונות הווירטואליות שמריצות את עומסי העבודה שלכם. זה אומר שניתן להתחיל בקטן, לשלם מעט מאוד, ולהתרחב ככל שהצרכים שלכם גדלים. Azure מטפלת בכל העבודה הקשה, שדרוגים, תיקונים וניתור תקינות עבור מישור הבקרה כולם מטופלים. אתם לא צריכים צוות יהודי של מומחי קוברנטיז רק כדי לשמור על המערכת פעילה. ומכיוון ש-AKS הוא חלק מהעקוס סיסטם של Azure, הוא משתלב עם כלים שאתם כנראה כבר משתמשים בהם. Azure Active Directory לאימות, Azure Monitor לרישום ומדדים, ו-Azure Policy למשילות. כולם עובדים יחד מחוץ לקופסה, ללא צורך בחיבור חלקים נפרדים.

הקמת צינורות C, CD עם GitHub Actions או Azure DevOps לוקחת דקות ספורות בלבד. דחפו שינוי למאגר שלכם, והמערכת בונה אוטומטית תמונת קונטיינר חדשה, דוחפת אותה ל-Azure Container Registry ומעדכנת את הפריסה ב-AKS. ללא שלבים ידניים, ללא צורך בחיבור SSH לשרתים. הכל מבוצע באופן אוטומטי. למתחילים, קיים מצב AKS אוטומטי, המיועד לצוותים שלא רוצים לקבל כל החלטה בנוגע להגדרות האשכול. הוא מספק הגדרות ברירת מחדל מוכנות לשימוש עבור קנה מידה, רשת, אבטחה ושדרוגים. אתם לא חייבים להפוך למומחי קוברנטיז כדי להתחיל. פשוט תארו את האפליקציה שלכם ו-AKS יטפל בכל השאר. פקודה אחת נותנת לכם אשכול, קובץ מניפסט אחד מריץ את האפליקציה שלכם. הקישורים שאתם לומדים ב-AKS עוברים לכל סביבת קוברנטיז, כי מתחת למכסה המנוע מדובר בקאברנט סטנדרטי. אתם לא לומדים מערכת קניינית, אתם לומדים את הדבר האמיתי, כש-Azure מטפלת במורכבות התפעולי. אז עכשיו יש לכם את התמונה המלאה. קונטיינרים אורזים את האפליקציות שלכם כך שירוצו בעקביות בכל מקום, וקאברנטס מתזמר את הקונטיינרים הללו בקנה מידה רחב, תוך טיפול אוטומטי בפריסה, קנה מידה ושחזור.

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