WEBVTT

00:00:00.000 --> 00:00:04.660
היום נדבר על משהו שכמעט כולם שמעו עליו אבל לא יודעים להסביר קוברנטיס, קוברנטיז.

00:00:04.840 --> 00:00:08.240
זה מבלבל כי הוא פותר בעיה שרוב האנשים לא רואים עד שהם נתקלים בה.

00:00:08.360 --> 00:00:11.720
כולם יודעים שזה חשוב, אבל תשאלו מה זה עושה ותקבלו מבט מבולבל.

00:00:11.880 --> 00:00:16.020
זה לא תחליף לדוקר ולא מערכת הפעלה לענן, למרות שאנשים לעיתים קרובות מנחשים כך.

00:00:16.160 --> 00:00:20.520
הבלבול הגיוני כי קוברנטיס פותר בעיה שאתם לא יודעים שהיא קיימת עד שאתם פוגשים אותה.

00:00:20.520 --> 00:00:24.740
זה כלי שהופך לחיוני ברגע שיש לכם יותר ממספר קטן של קונטיינרים לנהל.

00:00:24.880 --> 00:00:34.180
בסוף הפרק הזה תבינו מה זה באמת קוברנטיס, איך הוא משתלב עם קונטיינרים ולמה שירות Azure קוברנטיז הופך אותו למעשי עבור צוותים שלא רוצים לבנות הכל מאפס.

00:00:34.340 --> 00:00:36.600
קחו את הקפה שלכם ובואו נצלול פנימה.

00:00:36.700 --> 00:00:38.200
הבעיה לפני הקונטיינרים

00:00:38.200 --> 00:00:39.440
בואו נחזור לבעיה.

00:00:39.580 --> 00:00:41.840
תארו לעצמכם חברת תוכנה לפני עשר שנים.

00:00:41.840 --> 00:00:46.580
יש לכם כמה אפליקציות להריץ, אז אתם קונים שרתים, מתקינים מערכות הפעלה ומטמיעים הכל ידנית.

00:00:46.740 --> 00:00:50.040
כל אפליקציה מקבלת מכונה משלה ולא ניתן לחלוק משאבים ביניהן.

00:00:50.160 --> 00:00:54.960
אם אפליקציה אחת צריכה הרבה זיכרון ואחרת בקושי צריכה משהו, כל אחת מקבלת שרת משלה בכל מקרה.

00:00:55.100 --> 00:00:56.280
הביזבוז היה עצום.

00:00:56.480 --> 00:01:02.440
שרתים עבדו בית מינוס 20% תפוקה בערך, אבל אי אפשר היה לאחד אותם כי האפליקציות היו רבות על תלויות.

00:01:02.440 --> 00:01:09.100
סיימתם עם חדר מלא בשרתים, כל אחד בקושי עושה עבודה, כל אחד צורך חשמל וקירור, וכולם דורשים תחזוקה מתמדת.

00:01:09.200 --> 00:01:12.540
אפליקציה אחת צריכה פייטן 3.7, אחרת צריכה פייטן 3.8.

00:01:12.720 --> 00:01:15.040
אחת צריכה ספרייה ישנה, אחרת צריכה את הכי חדשה.

00:01:15.040 --> 00:01:20.340
אי אפשר להריץ אותן על אותה מכונה בלי לשבור משהו, אז אתם קונים עוד שרתים ומשלמים על חומרה שבעיקר עומדת ללא שימוש.

00:01:20.340 --> 00:01:33.940
מכונות וירטואליות עזרו מעט בכך שאפשרו לפצל שרת פיזי לחתיכות קטנות יותר, כשכל אחת מריצה מערכת הפעלה משלה, אבל כל VM היא כבדה עם מערכת הפעלה מלאה שתופסת שטח דיסק וזיכרון ולוקח לדקות לעלות, והאיתם צריכים להגדיר כל אחת בנפרד שזו הייתה המון עבודה.

00:01:33.940 --> 00:01:38.540
אתם עדיין מנהלים את כל מערכות ההפעלה האלה, מתקנים, מעדכנים ומאבטחים אותן.

00:01:38.540 --> 00:01:48.120
צוותים היו צריכים משהו קל ונייד יותר, דרך להירוז אפליקציה עם כל מה שהיא צריכה כדי לרוץ ללא התקורה של מכונה וירטואלית מלאה ושאפשר להעביר בקלות בין מכונות.

00:01:48.160 --> 00:01:49.900
כאן נכנסו לתמונה הקונטיינרים.

00:01:50.140 --> 00:01:51.400
מה הם קונטיינרים באמת?

00:01:51.400 --> 00:01:56.020
קונטיינר הוא חבילה קטנה שכוללת את האפליקציה שלכם ואת כל מה שהיא צריכה כדי לרוץ.

00:01:56.180 --> 00:02:00.960
זה אומר שהקוד, הרנטיימפ, הספריות וקבצי ההגדרות ערוזים כולם יחד ביחידה אחת.

00:02:00.960 --> 00:02:03.260
תחשבו על זה כמו מקולת משלוח לתוכנה.

00:02:03.420 --> 00:02:08.280
מקולת משלוח יכולה לעלות על מסעית, רכבת או נהיה, והמכולה עצמה נשארת בדיוק אותו הדבר.

00:02:08.460 --> 00:02:10.840
מקולת התוכנה שלך עובדת בדיוק באותה הדרך.

00:02:10.840 --> 00:02:15.640
אתה בונה אותה פעם אחת, והיא פועלת אותו הדבר על המחשב הנייד, שרת הבדיקות וסביבת הייצור שלך.

00:02:15.760 --> 00:02:19.300
ההבדל המרכזי בין מקולות למכונות וירטואליות הוא רמת היעילות שלהן.

00:02:19.440 --> 00:02:24.960
מכונה וירטואלית מריצה מערכת הפעלה מלאה משלה, לכן לכל VM יש קרנל משלה, קבצי מערכת וכל השאר.

00:02:25.080 --> 00:02:27.460
מחולה חולקת את מערכת ההפעלה של המערך.

00:02:27.680 --> 00:02:30.320
זהו רק תהליך עם תצוגה מבודדת משלו על העולם.

00:02:30.320 --> 00:02:33.080
זה אומר שמכולות עולות בשניות לא בדקות.

00:02:33.200 --> 00:02:36.800
הן צורכות פחות זיכרון, וניתן לדחוס יותר מהן על מכונה בודדת.

00:02:36.880 --> 00:02:42.060
דוקר הפכם הקולות לפופולריות, בכך שנתנה למפתחים דרך פשוטה לבנות ולהריץ אותן בפקודה אחת.

00:02:42.060 --> 00:02:45.440
פתאום, הבעיה של אצלי זה עובד התחילה להיעלם.

00:02:45.580 --> 00:02:49.660
אם היישום שלך הרץ במחולה על המחשב הנייד, הוא ירוץ בדיוק כך גם על השרת.

00:02:49.800 --> 00:02:54.400
הסביבה נשארת עקבית בכל מקום, אבל מכולות פותרות בעיה אחת ויוצרות אחרת.

00:02:54.400 --> 00:02:57.040
אם קומץ מכולות, ניהול ידני עובד מצוין.

00:02:57.200 --> 00:03:00.180
אתה יכול להפעיל אותן, לעצור אותן ולעקוב אחריהן בעצמך.

00:03:00.320 --> 00:03:01.920
אבל מה קורה כשיש לחמאות מהן?

00:03:01.920 --> 00:03:07.860
עליך להחליט איזה שרת יריץ איזה מחולה להפעיל מחדש קושלות, לחבר ביניהן ולהגדיל את המשאבים באומסי תעבורה.

00:03:08.060 --> 00:03:11.360
זהו אתגר חדש, וזה בדיוק המקום שבו קוברנטיס נכנסת לתמונה.

00:03:11.540 --> 00:03:12.700
בעיית האורקסטרציה

00:03:12.700 --> 00:03:17.240
אז, המחולות עובדות, הרזת את היישום, הוא רץ בעקביות בכל מקום והחיים טובים.

00:03:17.360 --> 00:03:18.500
אבל, רק לזמן מה?

00:03:18.620 --> 00:03:21.420
אם עשר או עשרים מקולות, אפשר לנהל את הדברים ידנית.

00:03:21.420 --> 00:03:26.680
אתה יודע איזה שרת מריץ איזו מחולה, אפשר להפעיל מחדש עם משהו קורס, ולעדכן פה ושם.

00:03:26.880 --> 00:03:27.800
זה ניתן לניהול.

00:03:27.940 --> 00:03:29.580
אבל אז היישום שלך גדל.

00:03:29.740 --> 00:03:31.100
אתה עובר למיקרו שירותים.

00:03:31.260 --> 00:03:34.220
אז במקום יישום אחד גדול, יש לך עשרים קטנים יותר.

00:03:34.480 --> 00:03:38.960
כל אחד צריך עותקים מרובים שרצים לאמינות, ועכשיו אתה מסתכל על מתיים הקולות.

00:03:39.160 --> 00:03:40.760
ניהול ידני כבר לא עובד יותר.

00:03:40.760 --> 00:03:46.840
עליך להחליט איזה שרת יריץ כל מיקולה, להפעיל מחדש כשצריך, ולחבר ביניהן כדי שיוכלו לתקשר.

00:03:46.840 --> 00:03:53.120
עליך גם להגדיל משאבים ב-CA תעבורה, אולי במחירה או השקת מוצר, ולהקטין כשהעומס יורד.

00:03:53.300 --> 00:04:00.500
ועליך להפיץ עדכונים ללא השבטה, מה שאומר להחליף מקולות ישנות בחדשות אחת אחת, בזהירות, בלי לשבור כלום.

00:04:00.680 --> 00:04:04.460
אלו בעיות אורקסטרציה, וזה בדיוק מה שקוברנטיס נבנתה לפתור.

00:04:04.460 --> 00:04:09.900
קוברנטיס היא פלטפורמת קוד פתוח המבצעת אוטומציה לפריסה, הרחבה וניהול של יישומים מקולות, קונטיינרים.

00:04:10.080 --> 00:04:12.900
חישבו על זה כעל מערכת ההפעלה של מרכז הנתונים שלכם.

00:04:13.040 --> 00:04:17.820
בדיוק כפי שווינדוס או לינוקס מנהלות משאבים במחשב בודד, כמו מאבד, זיכרון ודיסק,

00:04:18.020 --> 00:04:20.320
קוברנטיס מנהלת משאבים בכל השרתים שלכם.

00:04:20.440 --> 00:04:23.860
היא מתייחסת לכל המכונות שלכם כאל מאגר אחד גדול של כוח מחשוב.

00:04:23.860 --> 00:04:29.080
אתם אומרים למה אתם רוצים להריץ, והיא מבינה איפה למקם את זה, איך לשמור על פעילותו ואיך לחבר אותו לכל השאר.

00:04:29.080 --> 00:04:32.560
מושגי יסוד, פודים, פודס, צמתים, נודס, ואשקולות, קלאסטרס.

00:04:32.700 --> 00:04:34.500
בואו נראה איך קוברנטיס באמת עובדת.

00:04:34.620 --> 00:04:37.200
היחידה הקטנה ביותר בקאברנטס נקראת פוד, פוד.

00:04:37.320 --> 00:04:38.900
פוד עוטף מחולה אחת או יותר.

00:04:39.140 --> 00:04:43.580
מקולות בתוך אוטופוד חולקות איחסון ורשת, כך שהן יכולות לתקשר זו עם זו דרך לוקל הוסט.

00:04:43.580 --> 00:04:46.000
ניתן לחשוב על פוד כי יחידת פריסה בודדת.

00:04:46.120 --> 00:04:48.280
אתם לא פורסים מקולות ישירות בקאברנטס.

00:04:48.400 --> 00:04:49.420
אתם פורסים פודים.

00:04:49.420 --> 00:04:52.140
פודים לא רצים לבדם, הם רצים על צמתים, נודס.

00:04:52.260 --> 00:04:56.100
צומת הוא שרת, פיזי או וירטואלי, שמאווה חלק מאשקול הקאברנטס שלכם.

00:04:56.240 --> 00:04:58.240
כל צומת מריץ את התוכנה הדרושה להפעלת פודים,

00:04:58.380 --> 00:05:00.400
בתוספת כמה דברים אחרים שנגיע עליהם בעוד רגע.

00:05:00.520 --> 00:05:04.260
אשקול, קלאסטר, הוא אוסף של כל הצמתים המנוהלים כמערכת מאוחדת אחת.

00:05:04.260 --> 00:05:09.140
במילים פשוטות, פוד הוא היישום שלכם, צומת הוא המקום שבו הוא רץ, והאשקול הוא כל הסביבה.

00:05:09.200 --> 00:05:10.680
פודים הם זמניים, אפמרל.

00:05:10.800 --> 00:05:12.900
ניתן ליצור, להשמיד או להעביר אותם בכל עת.

00:05:13.040 --> 00:05:13.860
זה מתוכנן כך.

00:05:13.980 --> 00:05:16.320
עם צומת קורס, קוברנטיס מעבירה את הפודים לאחר.

00:05:16.440 --> 00:05:18.400
לצורך הרחבה, היא יוצרת פודים חדשים.

00:05:18.580 --> 00:05:20.700
וכשפוד קורס הוא מוחלף באופן אוטומטי.

00:05:20.820 --> 00:05:23.100
המערכת כולה מתייחסת לפודים כאל זמניים.

00:05:23.220 --> 00:05:25.760
אבל עם פודים באים והולכים, אתם צריכים דרך לתקשר איתם.

00:05:25.760 --> 00:05:28.720
במקום לתקשר עם פוד ישירות, אתם מתקשרים עם שירות, סארוויס.

00:05:28.720 --> 00:05:33.220
שירות מספק כתובת רשת יציבה שמנתבת תעבורה לפודים הנכונים, גם כאשר הפודים משתנים.

00:05:33.380 --> 00:05:34.100
דמיינו מלון.

00:05:34.320 --> 00:05:36.040
מספר הטלפון של המלון הוא השירות.

00:05:36.240 --> 00:05:39.160
חדרים מחליפים אורחים כל הזמן, אבל מספר הטלפון נשאר אותו הדבר.

00:05:39.340 --> 00:05:42.100
אתם מתקשרים לקבלה, והם מנתבים את השיחה שלכם לחדר הנכון.

00:05:42.280 --> 00:05:44.160
זה בדיוק מה ששירות עושה בקאברנטס.

00:05:44.160 --> 00:05:48.520
הוא נותן לכם כתובת קבועה שתמיד מצביעה על הפודים שמריצים כרגע את היישום שלכם.

00:05:48.520 --> 00:05:51.460
מישור הבקרה, Control Plane, המוח של האשקול.

00:05:51.640 --> 00:05:53.820
אז יש לכם פודים, צמתים ואשקול.

00:05:53.980 --> 00:05:55.820
השאלה היא, מי מחליט מה רץ איפה?

00:05:56.000 --> 00:05:57.440
זה התפקיד של מישור הבקרה.

00:05:57.600 --> 00:06:00.780
לכל אשקול קוברנטיז יש אחד כזה, והוא המוח של המערכת כולה.

00:06:00.880 --> 00:06:02.220
כאן מתקבלות כל ההחלטות.

00:06:02.380 --> 00:06:04.080
למישור הבקרה יש כמה רכיבים.

00:06:04.080 --> 00:06:07.460
הראשון שבהם הוא שרת ה-API, המשמש כדלת הכניסה לאשקול שלך.

00:06:07.460 --> 00:06:13.620
כל פקודה שאתה שולח לקוברנטס, ביניהם משורת הפקודה, מלוח הבקרה או מסקריפט אוטומטי, עוברת דרך שרת ה-API.

00:06:13.760 --> 00:06:18.720
הוא מאמת את הבקשה שלך, בודק אם מותר לך לבצע את מה שביקשת, ואז מעביר אותה למקום הנכון.

00:06:18.920 --> 00:06:22.400
שום דבר בקוברנטס לא קורה מבלי לעבור קודם דרך שרת ה-API.

00:06:22.400 --> 00:06:26.240
הבא בתור הוא המתזמן, Schedular, שמחליט איזה צומת יריץ כל פוד, פוד.

00:06:26.240 --> 00:06:35.460
כשאתה אומר, אני רוצה שהאפליקציה הזאת ערוץ, המתזמן בוחן את כל עצמתים הזמינים, בודק את המשאבים הפנויים, כמו מאבד, זיכרון ונפח דיסק, ובוחר את המתאים ביותר למשימה.

00:06:35.580 --> 00:06:38.720
זה כמו מנהל מלון שמקצה חדרים בהתאם לצרכים של כל אורח.

00:06:38.720 --> 00:06:43.640
אורח עם הרבה מטען מקבל חדר גדול יותר, בעוד אפליקציה קלה מקבלת צומת קטן יותר אם קיבולת פנויה.

00:06:43.760 --> 00:06:46.040
לאחר מכן יש את מנהל הבקרים, Controller Manager.

00:06:46.040 --> 00:06:49.720
הרכיב הזה עוקב אחרי האשקול ומבדה שהמצב בפועל תואם למה שהצהרת.

00:06:49.880 --> 00:06:52.980
אמרת שאתה רוצה ששלושה עותקים של אפליקציות האינטרנט שלך ירוצו.

00:06:53.100 --> 00:06:55.720
מנהל הבקרים בודק שאכן רצים שלושה עותקים.

00:06:55.880 --> 00:06:58.560
אם אחד קורס, הוא מבחין בכך ומפעיל תחליף.

00:06:58.560 --> 00:07:01.440
אם מי שהוא מוחק בטעות פוד, הוא יוצר אחד חדש.

00:07:01.620 --> 00:07:04.020
זה הרכיב ששומר על האמינות של האשקול שלך.

00:07:04.160 --> 00:07:07.560
ולבסוף, יש את ETCD, שהוא מסד הנתונים של האשקול.

00:07:07.560 --> 00:07:11.200
ומאכסן הכל, כמו מה רץ, איפה זה רץ, ואיך זה מוגדר.

00:07:11.400 --> 00:07:13.400
זהו מקור האמת עבור האשקול כולו.

00:07:13.520 --> 00:07:19.180
אם שרת ה-API הוא דלת הכניסה, אז ETCD הוא ארון הטיוק במשרד האחורי שבו נשמרים כל הרשומות.

00:07:19.180 --> 00:07:23.660
היופי בעיצוב הזה הוא שאתה מתאר מה אתה רוצה, וקאברנטס מבין איך להפוך את זה למציאות.

00:07:23.760 --> 00:07:27.100
אתה לא אומר לו איך לעשות דברים, אתה אומר לו איך התוצאה הסופית צריכה להיראות.

00:07:27.100 --> 00:07:31.380
זהו המודל הדקלרטיבי, וזהו הרעיון המרכזי שעומד מאחורי כל מה שקאברנטס עושה.

00:07:31.500 --> 00:07:34.260
אומסי עבודה, פריסות, שירותים ושינוי קנה מידה.

00:07:34.340 --> 00:07:37.260
אז בואו נדבר על איך באמת מריצים אפליקציות על קוברנטיס.

00:07:37.380 --> 00:07:38.960
אתה לא תיצור פודים באופן ישיר.

00:07:38.960 --> 00:07:42.300
במקום זאת, תשתמש באובייקט ברמה גבוהה יותר שנקרא פריסה, דפלוימנט.

00:07:42.420 --> 00:07:46.260
תחשוב על פריסה כמנהל שאומר לקאברנטס כמה עותקים של הפוד שלך הצריכים לרוץ,

00:07:46.260 --> 00:07:49.600
באיזו תמונת קונטיינר להשתמש, ואיך להדכן אותם כשיוצאת גרסה חדשה.

00:07:49.780 --> 00:07:52.560
זו הדרך הסטנדרטית להריץ אפליקציות חסרות מצב, stateless.

00:07:52.740 --> 00:07:55.700
כשאתה מעדכן פריסה, למשל כשאתה דוחף גרסה חדשה של האפליקציה שלך,

00:07:55.840 --> 00:07:59.120
קוברנטיס מבצע עדכון מתגלגל, rolling update, ומחליף פודים בזה אחר זה,

00:07:59.120 --> 00:08:01.040
ומבדע שלפחות עותק אחד תמיד רץ.

00:08:01.180 --> 00:08:04.360
זה אומר שאין זמן השבטה ואין הפרעה פתאומית למשתמשים שלכם.

00:08:04.360 --> 00:08:08.760
ואם משהו משתבש בגרסה החדשה, אפשר לחזור לגרסה הקודמת בפקודה אחת.

00:08:08.880 --> 00:08:12.480
זו רשת ביטחון עוצמתית, אבל הפודים שלכם עדיין צריכים להיות נגישים.

00:08:12.600 --> 00:08:14.080
כאן נכנסים לתמונה ה-Services.

00:08:14.380 --> 00:08:17.860
Service מספק כתובת רשת יציבה שמנתבת תעבורה לפודים הנכונים.

00:08:17.860 --> 00:08:22.180
הוא גם יכול לחשוף את הפודים האלה לחלקים אחרים באפליקציה או לעולם החיצון.

00:08:22.360 --> 00:08:25.760
Service יכול להיות פנימי, נגיש רק בתוך הקלסטר, או חיצוני,

00:08:25.960 --> 00:08:29.160
עם כתובת IP ציבורית שמשתמשים יכולים להגיע אליה מהאינטרנט.

00:08:29.160 --> 00:08:31.120
עכשיו, הנה העניין לגבי Scaling.

00:08:31.360 --> 00:08:35.220
קוברנטיז יכול להגדיל ולצמצם את האפליקציה שלכם אוטומטית בהתבסס על הביקוש.

00:08:35.360 --> 00:08:38.120
מגדירים יעד נניח 70% ניצול מעבד,

00:08:38.360 --> 00:08:42.160
וקאברנטס מוסיף פודים כשהניצול עובר את הסף ומסיר אותם כשהוא יורד.

00:08:42.280 --> 00:08:46.380
האפליקציה גדלה במהלך זינוק, בתעבורה ומצטמצמת כשדברים נרגעים.

00:08:46.540 --> 00:08:50.120
אין צורך בהתערבות ידנית, אבל כל הכוח הזה מגיע עם מורכבות.

00:08:50.120 --> 00:08:53.560
ניהול קלסטר קוברנטיז עצמאי אומר שאתם אחראים לקונטרול פליין,

00:08:53.740 --> 00:08:55.520
לשדרוגים, לעדכוני הבטחה ולגיבויים.

00:08:55.680 --> 00:08:58.240
נדרשת מומחיות מעמיקה כדי להתמודד עם כשלים בצמתים,

00:08:58.400 --> 00:09:00.320
הגדרות רשת וניהול סקיילינג של הקלסטר.

00:09:00.440 --> 00:09:03.760
צוותים רבים מקדישים יותר זמן לניהול הקלסטר מאשר לבניית אפליקציות,

00:09:03.940 --> 00:09:06.160
וכאן נכנס לתמונה ניהול קוברנטיז מנוהל.

00:09:06.300 --> 00:09:08.320
ניהול עצמי לעומת קוברנטיז מנוהל.

00:09:08.320 --> 00:09:11.480
אז בואו נדבר על המציאות של הרצת קוברנטיז באופן עצמאי.

00:09:11.580 --> 00:09:14.020
כשמקימים קלסטר משלכם, אתם אחראים להכל,

00:09:14.200 --> 00:09:17.520
לקונטרול פליין, לשדרוגים, לעדכוני הבטחה ולגיבויי ETCD.

00:09:17.720 --> 00:09:20.300
אם שרת ה-API קורס, זו הבעיה שלכם.

00:09:20.460 --> 00:09:24.420
אם מתגלה פגיעות הבטחה בגרסה שאתם מריצים, אתם צריכים לתקן אותה.

00:09:24.520 --> 00:09:27.580
אם ה-ETCD משתבש, אתם צריכים לשחזר מגיבוי.

00:09:27.740 --> 00:09:29.320
כל זה דורש מומחיות עמוקה.

00:09:29.320 --> 00:09:32.720
אתם צריכים להבין איך צמתים נכשלים, איך רשת עובדת ברמת הקלסטר,

00:09:32.880 --> 00:09:34.820
ואיך לבצע סקיילינג בלי לשבור שום דבר.

00:09:35.000 --> 00:09:36.800
הנה משהו שמפתיע צמתים רבים.

00:09:37.000 --> 00:09:41.860
ארגונים רבים מבלים יותר זמן בניהול הקלסטר שלהם מאשר בבניית האפליקציות שרצות עליו.

00:09:41.980 --> 00:09:46.260
הם נלחמים כל הזמן בשדרוגים, בפתרון בעיות רשת ובהתמודדות עם קשלים בצמתים.

00:09:46.400 --> 00:09:48.260
הקלסטר הופך לעבודה במשרה מלאה.

00:09:48.260 --> 00:09:50.980
זו לא הסיבה שבגללה אימצתם את קוברנטיז מלכתחילה.

00:09:51.060 --> 00:09:53.120
כאן נכנסים שירותי קוברנטיז מנוהלים.

00:09:53.360 --> 00:09:57.620
שירותים כמו Azure Kubernetes Service, או AKS, מטפלים בקונטרול פליין עבורכם.

00:09:57.780 --> 00:10:01.800
Azure מנהלת את שרת ה-API, את האצ'ד, את השדולר ואת הקונטרולר מנגר.

00:10:01.940 --> 00:10:04.600
אתם לא צריכים לדאוג לעדכונים שלהם או לתקינות הפעולה שלהם.

00:10:04.600 --> 00:10:08.420
אתם משלמים רק על צמתי העבודה, המכונות הווירטואליות שמריצות בפועל את עומסי העבודה שלכם.

00:10:08.420 --> 00:10:10.060
מישור הבקרה עצמו הוא בחינם.

00:10:10.240 --> 00:10:12.020
זה משנה את התמונה באופן דרמטי.

00:10:12.140 --> 00:10:16.300
במקום לבזבז זמן על תחזוקת אשקולות, הצוות שלכם יכול להתמקד במה שבאמת חשוב,

00:10:16.500 --> 00:10:17.480
האפליקציות שאתם בונים.

00:10:17.700 --> 00:10:21.640
עבור רוב הצוותים, במיוחד אלו שרק מתחילים, קוברנטיז מנוהל הוא הבחירה הנכונה.

00:10:21.640 --> 00:10:25.060
אתם מקבלים את כל העוצמה של קוברנטיז ללא התקורה התפעולית.

00:10:25.160 --> 00:10:27.680
AKS, קוברנטיז שהופך לפשות באז'ר.

00:10:27.820 --> 00:10:29.260
אז מה זה בדיוק AKS?

00:10:29.260 --> 00:10:31.420
זהו שירות הקוברנטס המנוהל של Azure,

00:10:31.660 --> 00:10:34.140
המעניק לכם אשקול מלא ללא צורך לבנות אותו מאפס.

00:10:34.300 --> 00:10:35.900
מישור הבקרה הוא בחינם, כפי שציינו,

00:10:36.080 --> 00:10:39.180
כך שאתם משלמים רק על המכונות הווירטואליות שמריצות את עומסי העבודה שלכם.

00:10:39.320 --> 00:10:41.580
זה אומר שניתן להתחיל בקטן, לשלם מעט מאוד,

00:10:41.580 --> 00:10:43.540
ולהתרחב ככל שהצרכים שלכם גדלים.

00:10:43.700 --> 00:10:45.660
Azure מטפלת בכל העבודה הקשה,

00:10:45.840 --> 00:10:49.640
שדרוגים, תיקונים וניתור תקינות עבור מישור הבקרה כולם מטופלים.

00:10:49.640 --> 00:10:53.820
אתם לא צריכים צוות יהודי של מומחי קוברנטיז רק כדי לשמור על המערכת פעילה.

00:10:53.920 --> 00:10:56.800
ומכיוון ש-AKS הוא חלק מהעקוס סיסטם של Azure,

00:10:57.080 --> 00:10:59.600
הוא משתלב עם כלים שאתם כנראה כבר משתמשים בהם.

00:10:59.720 --> 00:11:01.580
Azure Active Directory לאימות,

00:11:01.580 --> 00:11:03.680
Azure Monitor לרישום ומדדים,

00:11:03.940 --> 00:11:05.460
ו-Azure Policy למשילות.

00:11:05.640 --> 00:11:07.480
כולם עובדים יחד מחוץ לקופסה,

00:11:07.600 --> 00:11:09.500
ללא צורך בחיבור חלקים נפרדים.

00:11:09.640 --> 00:11:14.160
הקמת צינורות C, CD עם GitHub Actions או Azure DevOps לוקחת דקות ספורות בלבד.

00:11:14.320 --> 00:11:15.660
דחפו שינוי למאגר שלכם,

00:11:15.660 --> 00:11:17.900
והמערכת בונה אוטומטית תמונת קונטיינר חדשה,

00:11:18.100 --> 00:11:21.300
דוחפת אותה ל-Azure Container Registry ומעדכנת את הפריסה ב-AKS.

00:11:21.420 --> 00:11:24.240
ללא שלבים ידניים, ללא צורך בחיבור SSH לשרתים.

00:11:24.380 --> 00:11:25.880
הכל מבוצע באופן אוטומטי.

00:11:25.980 --> 00:11:28.040
למתחילים, קיים מצב AKS אוטומטי,

00:11:28.040 --> 00:11:31.340
המיועד לצוותים שלא רוצים לקבל כל החלטה בנוגע להגדרות האשכול.

00:11:31.500 --> 00:11:34.100
הוא מספק הגדרות ברירת מחדל מוכנות לשימוש עבור קנה מידה,

00:11:34.240 --> 00:11:35.500
רשת, אבטחה ושדרוגים.

00:11:35.500 --> 00:11:38.120
אתם לא חייבים להפוך למומחי קוברנטיז כדי להתחיל.

00:11:38.260 --> 00:11:41.160
פשוט תארו את האפליקציה שלכם ו-AKS יטפל בכל השאר.

00:11:41.300 --> 00:11:42.560
פקודה אחת נותנת לכם אשכול,

00:11:42.800 --> 00:11:44.920
קובץ מניפסט אחד מריץ את האפליקציה שלכם.

00:11:45.060 --> 00:11:47.840
הקישורים שאתם לומדים ב-AKS עוברים לכל סביבת קוברנטיז,

00:11:47.840 --> 00:11:50.160
כי מתחת למכסה המנוע מדובר בקאברנט סטנדרטי.

00:11:50.220 --> 00:11:51.880
אתם לא לומדים מערכת קניינית,

00:11:52.100 --> 00:11:53.580
אתם לומדים את הדבר האמיתי,

00:11:53.580 --> 00:11:55.740
כש-Azure מטפלת במורכבות התפעולי.

00:11:55.900 --> 00:11:57.800
אז עכשיו יש לכם את התמונה המלאה.

00:11:57.920 --> 00:12:01.600
קונטיינרים אורזים את האפליקציות שלכם כך שירוצו בעקביות בכל מקום,

00:12:01.780 --> 00:12:04.720
וקאברנטס מתזמר את הקונטיינרים הללו בקנה מידה רחב,

00:12:04.920 --> 00:12:06.240
תוך טיפול אוטומטי בפריסה,

00:12:06.240 --> 00:12:07.260
קנה מידה ושחזור.

00:12:07.420 --> 00:12:11.020
AKS הופך את התזמור הזה לניהולי על ידי טיפול במישור הבקרה

00:12:11.020 --> 00:12:13.260
ושילוב עם כלי Azure שאתם כבר מכירים.

00:12:13.400 --> 00:12:14.520
הנקודה העיקרית היא זו,

00:12:14.520 --> 00:12:18.240
קוברנטיז הוא לא רק עבור חברות טכנולוגיה גדולות עם צוותי הנדסה עצומים.

00:12:18.420 --> 00:12:20.260
עם שירותים מנוהלים כמו AKS,

00:12:20.460 --> 00:12:21.440
הוא נגיש לכל צוות.

00:12:21.580 --> 00:12:23.840
שיעורי הבית שלכם לשבוע הזה פשוטים.

00:12:24.040 --> 00:12:25.520
צרו חשבון Azure בחינם,

00:12:25.760 --> 00:12:27.140
הקימו אשכל AKS,

00:12:27.140 --> 00:12:28.680
ופירסו אפליקציה פשוטה.

00:12:28.820 --> 00:12:29.740
זה לוקח דקות,

00:12:29.880 --> 00:12:31.680
ותראו עד כמה הפלטפורמה התקדמה.

00:12:31.840 --> 00:12:32.980
מוכנים להעמיק יותר?

00:12:33.160 --> 00:12:36.380
הפרק הבא עוסק בבניית תמונת הקונטיינר הראשונה שלכם

00:12:36.380 --> 00:12:38.440
ודחיפתה ל-Azure Container Registry.

00:12:38.440 --> 00:12:43.960
הרשמו בפלטפורמת הפודקסטים המועדפת עליכם ושתפו זאת עם מי שרק מתחיל את דרכו בקאברנטס.