הסבר על Azure AKS ACI
/21. אסור שיהיו Subnets חופפים, ולכל Pod ולכל Node צריכה להיות כתובת IP משלו.פרקי ההרצאה: הסבר על Azure AKS ACI
תמלול ההרצאה: הסבר על Azure AKS ACI
הטקסט המלא של הדקות הראשונות בהרצאה «הסבר על Azure AKS ACI» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אג'ור קוברנטי סרוויס AKS ואג'ור קונטיינר אינסטנסס ACI שתי החלופות העיקריות בעולם אג'ור לגלול קונטיינרים. מה ההבדלים ביניהם?
פעם נראה. בהקדמה לקונטיינרים, למדנו שקונטיינרים מנוהלים דרך אורקסטרייטור, אחד כזה שיכול לעצור אותם, להתחיל אותם, לעשות סקייל-אאוט לאפליקציה כשצריך.
יש שתי דרכים לנהל דוקר ומייקרוסופט בייס קונטיינרים באג'ור: אג'ור קונטיינר אינסטנסס ACI ואג'ור קוברנטי סרוויס אג'ור קונטיינר אינסטנסס מציע את הדרך המהירה והפשוטה ביותר להריץ קונטיינרים באג'ור בלי צורך לנהל מכונות וירטואליות או להכיר איזשהם שירותים מיוחדים
זה פלטפורמאז סרוויס פאס אוקיי השירות מוצע כפלטפורמאז סרוויס שמאפשר לנו להעלות את הקונטיינרים שהוא מריץ עבורנו קל מאוד אג'ור קוברנטי Service, AKS. עם נושא של אוטומציה, ניהול ואינטראקציה עם כמות מאוד גדולה של קונטיינרים, כל זה ידוע כאורכסטרציה.
AKS או Azure Kubernetes Service הוא הפתרון המלא לנושא של קונטיינרים, עם נושא של ארכיטקטורה מבוזרת, זה אומר שבעצם אפשר לבזר את זה מספר מקומות בעולם, נושא של שרידות גיאוגרפית וכמות מאוד גדולה של קונטיינרים.
אורכסטרציה, כמו שקצת נגענו במבוא לנושא הקונטיינרים, זו בעצם המשימה של לעשות אוטומציה ולנהל כמות גדולה של קונטיינרים ואיך לתקשר ביניהם.
ניתן עוד כמה מילים על הנושא של AKS במיוחד וגם ACI. AKS בעצם נותן לנו ניהול מלא של קוברנטיס מקצה לקצה. כל נושא של כלי פיתוח CICD שהראינו מקודם, קונטיינרס אינטגריישן, קונטיינרס דבלופמנט, כל נושא של ניטור וגיבוי, הכל מובנה בפנים.
תמיכה בהלם, XML זה רכיב תוכנה שמשמש לטובת קונטנטריזיישן, לארוז בעצם את האפליקציות. טלמטריות, נושא של טלמטריות זה כמו ניטור.
אנחנו מקבלים טלמטריות וניטור מלא. עולמות של DevOps, אם אתם מכירים IT ומכירים פיתוח, יש כבר קרוב לעשר שנים מקצוע חדש שנקרא DevOps, כבר לא כזה חדש, שמשלב את היכולות של IT ופיתוח.
אז יש פרויקטים שלמים שאפשר לבנות על גבי אז'ור DevOps מקצה לקצה גם כן תחת ה-IQS. אבטחה, אבטחה בכמה רמות, גם ברמת הקלאסטר, גם ברמת האימג'ים שאנחנו מעלים, הוא שומר עליהם, וגם ברמת הווירצ'ל נטוורק, ותמיכה ב-Terraform, Terraform של האנשי קורפ.
המשמעות היא שמה ש-Terraform בעצם עושים, הם מאפשרים לכתוב אינפרסטרקצ' של איזה קוד תשתית כשירות לעננים שונים. זאת אומרת, בעברית פשוטה, שאם אני מתחיל ועובד עם AKS באז'ור, זה לא אומר שאני לחוד באז'ור.
אני רוצה לעבור לשירות המקביל ל-AWS Fargate, אין שום בעיה, עם Terraform אני עושה את זה תוך כדי תנועה. כנ"ל לכל שאר פתרונות העננים המנוהלים, כמו שכבר סקרנו אותם בווידאוים הקודמים.
זאת אומרת, אין שום בעיה לעבור מגוגל קלאוד ל-EKS ול-AKS, כל עוד אני עובד עם Terraform, מכיוון ש-Terraform הופך את הכל בעצם לשכבה אחת כמעט אחידה לגמרי.
עיקר היתרונות, אם שואלים אתכם, אם אתם רוצים לדעת מה ההבדל בין אג'ור קוברנטיס סרוויס מנוהל לבין גרסה לא מנוהלת, קודם כל, אג'ור קוברנטיס סרוויס ניתן כשירות מלא, אין עלות נוספת, רק המשאבים שאנחנו צורכים.
בנוסף, הוא מריץ גרסה זהה של קוברנטיס, זוכרים את הקוברנטיס ונילה שהראינו לכם מקודם? זו שבעצם נמצאת בגיטהאב, יש לה תאימות מלאה אחד לשני, אפשר לעבור מקוברנטיס ונילה, בגרסה הבסיסית ל-AKS וחזרה הוא מנוהל תחת ARM תחת ריסורס גרופים כמו יותר רכיבי אז'ור על שדרוג גרסאות שלו אחיד אוטומציה מלאה הוא מאוד מאוד גמיש בנטרוקים
תכף קצת ניגע בזה אני אומר שוב ברמת הרחבה זה לא נדרש כדי לעבור את ההסמכה אבל אני תמיד חושב שכדאי לדעת קצת מעבר תכף נראה איך הנטו באז'ור עם קוברנטיס עובד, ויש לו ברמה עתידית תמיכה בהייבריד קלאסטר בין לינוקס קונטיינרים לווינדוס קונטיינרים.
המשמעות היא שלינוקס קונטיינרים זה הקונטיינר הדפולטיבי שרץ על גבי דוקר, קוברנטיס מנהל. ווינדוס קונטיינר שעדיין לא תופסים כל כך הרבה תאוצה, אלה קונטיינרים שמלוידים על ווינדוס, והכיוון הוא ש-AKS ינהל את שניהם.
ודבר שלדעתי הוא מאוד מאוד חשוב, זה הנושא של לאפשר לאפליקציות Legacy, אפליקציות ישנות, לעבוד בסביבת קונטיינרים וקוברנטיס, כי בעצם מה שווינדוס קונטיינר מביא זה היכולת לקחת אפליקציות ישנות יחסית, כאלה שלא נכתבו במיקרו סרוויס, הן עדיין יחסית מונוליטיות, ולהעביר אותן לסביבת קונטיינרים וקוברנטיס.
מאוד מאוד נוח כל זה, קוברנטיס מנוהל. הגרסה לא מנוהלת, מאפשרת אמנם להריץ קלאסטרים עצמאיים, אבל כל התחזוקה בצד הלקוח, שדרוגי גרסה, תעימות, ל-publish, אז הוא נקרא לעשות publish, לפרסם החוצה את הקונטיינרים ואת הקלאסטרים שלנו, מאוד מאוד לא נוח.
נגיד כמה מילים קצרות, אני מבטיח, על נושא של קישוריות בסביבת קוברנטיס, כי זה באמת מאוד לא סטנדרטי, מאוד לא טריוויאלי.
אז קודם כל יש לנו שתי חלופות. החלופה הראשונה, בתוך Azure, עבור קוברנטיס, עוד מאוד בפירוט בהמשך. כרגע אנחנו רק נותנים פה טיזר להמשך, מכיוון שאנחנו מתעסקים בקוברנטיס.
סגור סוגריים. תצורת רשת בסיסית מאפשרת לנו למעשה לתקשר בין אוהדים ככה בצורה דו-כיוונית מכאן ומכאן, כאשר בתוכם יש פודים.
בכל אחד מהפודים, אתם זוכרים, מחזיק קונטיינר אחד או יותר, יפה, אחרת הייתה לנו כמות קונטיינרים. והתקשורת הזאת היא תצורת רשת בסיסית, שבעצם אנחנו מתקשרים על האז'ור vnet.
אוקיי, אנחנו נבין עוד מעט בדיוק מה זה אומר. אז'ורווינט עם טווח כתובות אחד, רשת אחידה. אוקיי, אנחנו לא יוצאים החוצה לעולם. הלקוח מבחוץ, אין לו גישה לפה, אוקיי? אין גישה לפה, הוא לא יכול לגשת לפה, אלא התקשורת היא ביניהם.
יש כמובן VPN מחוץ לעסק הזה, שאפשר להגיע מבחוץ ולראות אותו. אבל הם לא יוצאים החוצה, בשום צורה. אוקיי, זה לא קיים. יופי.
הגרסה השנייה, שבעיניי כמובן הרבה יותר מעניינת. בצורה הזאת אנחנו מקבלים למעשה משהו שמאוד דומה את הצורה הקודמת שבה הקונטיינרים יכולים להתקשר בינם לבין עצמם בצורה מלאה אבל יש פה דבר חדש שנקרא ברידג' הברידג' הזה מאפשר לנו בעצם להיגשר כשמו כן הוא
בין הפודים על כל אחד מהנודים שהוא נוד אחד ושהוא נוד שתיים להפך או כאחד ושתיים ובצורה הזאת בתוספת רכיב שנקרא Azure CNI כתבתי לכם פה CNI זה אג'ור קונטיינר נטרוקינג אינטרפייס.
בעצם מאפשר native אג'ור נטרוקינג קביליטי בדיפולט. הוא מאפשר לנו לתקשר החוצה. זה מה שזה אומר. ואז, במקום שהפודים והנודים ייתקעו אחד עם השני פה לבד, והקונטיינרים יישארו פה אומללים ומבודדים, פתאום הם מורשים לצאת החוצה ל-customer network, למה שהיה פה, זוכרים?
customer network. אוקיי, גם פה היה customer network, אבל פה לא היה שום קשר ביניהם. ופה יש קשר ביניהם. ולכן, ואז משמשת בעיקר ל-Production.
בצורה הזאת הרבה הרבה יותר נוח לנהל את זה. זה עדיין לא הופך את זה לפשוט, דרך אגב. אבל אם אנחנו מסתכלים על תכנון רשת בסביבת קוברנטיס ברמה הבסיסית ביותר שלו,