לאיסטיו ומעבר לו: ממשק רשת השירות של Azure

פיתוח אפליקציות מודרני וראשון בענן, לפחות ב- Azure, הפך כמעט תלוי בקוברנטס. טכנולוגיות כגון קוביות וירטואליות, ה- AKS (Azure Kubernetes Service) ו- Azure Service Fabric Mesh הן המפתח לבניית יישומים מורחבים הניתנים להרחבה ב- Azure, תוך שימוש במיכלים לפריסה ולניהול מיקרו-שירותים.

כשמסתכלים על כלי Kubernetes של Azure, ברור שמיקרוסופט עושה עבודה רבה בקרן Cloud Native Computing Foundation ובסביבתה, ועובדת על כל היבטי מסגרת הקוד הפתוח. אנחנו לא צריכים להיות מופתעים; מיקרוסופט שכרה את אחד ממייסדי פרויקט Kubernetes ואז רכשה את Deis, ספק משמעותי. צוות Deis עומד מאחורי אחת התרומות האחרונות בתכלת למערכת האקולוגית של Kubernetes, ממשק רשת הרשת (SMI).

הכנסת רשתות שירות

עדיף אולי להסביר תחילה מהי רשת שירות ולמה זה חשוב לכל יישום מבוסס Kubernetes.

ארכיטקטורות IT מודרניות כולן הפשטה. עם שירותי ענן אנחנו כבר לא צריכים לחשוב על החומרה הבסיסית. אם אנו משתמשים ב- IaaS אנו מגדירים מכונות וירטואליות לארח את הקוד שלנו. עם PaaS אנו רחוקים עוד יותר מהחומרה, משתמשים בשירותים ובממשקי ה- API שבחרנו, בוחרים רמת ביצועים מתאימה ליישומים ולתקציבים שלנו. עם ארכיטקטורות מבוססות מיכלים כגון Kubernetes, אנו נמצאים בנקודה כלשהי בין השניים: באמצעות שירותים כמו AKS נוכל להגדיר את המכונות הווירטואליות הבסיסיות, אשר מארחות את תרמילי המכולות שלנו ומתרחבות עם שינויים בחישוב ובזיכרון (ו כעת עם KEDA (קנה מידה אוטומטי מבוסס מונע אירועים), עם קבלת אירועים).

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

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

רשת מוגדרת תוכנה למיקרו-שירותים

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

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

יותר מדי רשתות

שילוב של פריסת Kubernetes עם רשת שירות הגיוני מאוד. עם זאת יש עוד בעיה אחת גדולה: באיזו מהן אתה משתמש? שַׁגְרִיר? איסטיו? לינקרד? אספן רשת? אם בחרת באחד, מה ימנע מצוות פיתוח בחלק אחר של העסק שלך לבחור באחר? ואז מה קורה אם החברה שלך מחליטה לתקנן בפלטפורמה ספציפית?

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

SMI: ממשקי API משותפים של רשת רשת

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

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

בין אם תרצו להשתמש ב- Linkerd או ב- Aspen Mesh או ב- NSX Service Mesh של VMware, עם SMI תוכלו לבחור את אחד המועדפים עליכם, ולשפר את ניידות הקוד ולהימנע מנעילה לשירותי ענן ספציפיים. אז יש אפשרות להחליף רשת שירות מבלי להשפיע על הקוד שלך. אם רשת שירות חדשה מציעה ביצועים טובים יותר, כל שעליך לעשות הוא לשנות את צינור הבנייה שלך לשימוש ברשת החדשה ואז לפרוס יישום מעודכן.

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