באינטרנט חבורה מאמרים о רשת שירות (רשת שירות), והנה עוד אחת. הידד! אבל למה? לאחר מכן, אני רוצה להביע את דעתי שעדיף היה לו יופיעו רשתות שירות לפני 10 שנים, לפני הופעתן של פלטפורמות מכולות כמו Docker ו-Kubernetes. אני לא אומר שנקודת המבט שלי טובה או גרועה מאחרות, אבל מכיוון שרשתות שירות הן חיות מורכבות למדי, נקודות מבט מרובות יעזרו להבין אותן טוב יותר.

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

היסטוריה של dotCloud

כתבתי על ההיסטוריה של dotCloud ועל אפשרויות הארכיטקטורה עבור הפלטפורמה הזו, אבל לא דיברתי הרבה על שכבת הרשת. אם אתה לא רוצה לצלול לקריאה מאמר אחרון לגבי dotCloud, הנה התמצית בקצרה: זוהי פלטפורמת PaaS-כשירות המאפשרת ללקוחות להפעיל מגוון רחב של יישומים (Java, PHP, Python...), עם תמיכה במגוון רחב של נתונים שירותים (MongoDB, MySQL, Redis...) וזרימת עבודה כמו Heroku: אתה מעלה את הקוד שלך לפלטפורמה, היא בונה תמונות קונטיינר ופורסת אותן.

אני אגיד לך איך התנועה הופנתה לפלטפורמת dotCloud. לא בגלל שזה היה מגניב במיוחד (למרות שהמערכת עבדה טוב לתקופתה!), אלא בעיקר בגלל שבאמצעות כלים מודרניים עיצוב כזה יכול להיות מיושם בקלות תוך זמן קצר על ידי צוות צנוע אם הם צריכים דרך לנתב תנועה בין חבורה של מיקרו-שירותים או שלל יישומים. כך תוכלו להשוות בין האפשרויות: מה קורה אם מפתחים הכל בעצמכם או משתמשים ברשת שירות קיימת. הבחירה הסטנדרטית היא להכין את זה בעצמך או לקנות את זה.

ניתוב תנועה עבור יישומים מתארחים

אפליקציות ב-dotCloud יכולות לחשוף נקודות קצה של HTTP ו-TCP.

נקודות קצה HTTP נוסף באופן דינמי לתצורת אשכול מאזן העומס היפאצ'י. זה דומה למה שעושים משאבים היום Ingress ב-Kubernetes ומאזן עומסים כמו טראפיק.

לקוחות מתחברים לנקודות קצה HTTP דרך דומיינים מתאימים, בתנאי ששם הדומיין מצביע על מאזני עומסים של dotCloud. שום דבר מיוחד.

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

לקוחות יכולים להתחבר לנקודות קצה של TCP באמצעות שם המארח המתאים (משהו כמו gateway-X.dotcloud.com) ומספר היציאה.

שם מארח זה הופך לאשכול השרתים "nats" (לא קשור ל NATS), שינתב חיבורי TCP נכנסים לקונטיינר הנכון (או, במקרה של שירותים מאוזנים עומסים, לקונטיינרים הנכונים).

אם אתה מכיר את Kubernetes, זה כנראה יזכיר לך את השירותים NodePort.

לא היו שירותים מקבילים בפלטפורמת dotCloud אשכול IP: לשם הפשטות, הגישה לשירותים הייתה באותו אופן הן מתוך הפלטפורמה והן מחוצה לה.

הכל היה מאורגן בצורה פשוטה למדי: ההטמעות הראשוניות של רשתות ניתוב HTTP ו-TCP היו כנראה רק כמה מאות שורות של Python כל אחת. אלגוריתמים פשוטים (הייתי אומר תמימים) ששוכללו ככל שהפלטפורמה גדלה והופיעו דרישות נוספות.

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

במה זה שונה מרשת שירות מודרנית?

מוגבל רְאוּת. לא היו לנו מדדים עבור רשת הניתוב של TCP בכלל. בכל הנוגע לניתוב HTTP, גרסאות מאוחרות יותר הציגו מדדי HTTP מפורטים עם קודי שגיאה וזמני תגובה, אך רשתות שירות מודרניות מרחיבות עוד יותר, ומספקות אינטגרציה עם מערכות איסוף מדדים כמו Prometheus, למשל.

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

יעילות ניתוב הוא גם מוגבל. ברשת הניתוב של dotCloud, כל התעבורה הייתה צריכה לעבור דרך אשכול של צמתי ניתוב ייעודיים. משמעות הדבר הייתה חציית גבולות AZ מרובים (Availability Zone) והגדלה משמעותית של זמן האחזור. אני זוכר שקוד איתור בעיות עשה יותר ממאה שאילתות SQL בכל עמוד ופתח חיבור חדש לשרת SQL עבור כל שאילתה. בעת הפעלה מקומית, העמוד נטען באופן מיידי, אך ב-dotCloud זה לוקח כמה שניות לטעון כי כל חיבור TCP (ושאילתת SQL שלאחר מכן) לוקח עשרות אלפיות שניות. במקרה הספציפי הזה, חיבורים מתמשכים פתרו את הבעיה.

רשתות שירות מודרניות טובות יותר בטיפול בבעיות כאלה. קודם כל הם בודקים שהחיבורים מנותבים במקור. הזרימה הלוגית זהה: клиент → меш → сервис, אבל עכשיו הרשת עובדת מקומית ולא על צמתים מרוחקים, אז החיבור клиент → меш הוא מקומי ומהיר מאוד (מיקרו-שניות במקום מילי-שניות).

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

אבטחה גם טוב יותר. רשת הניתוב של dotCloud רצה כולה על EC2 Classic ולא הצפינה תעבורה (בהתבסס על ההנחה שאם מישהו הצליח לשים סניפר על תעבורת רשת EC2, כבר היית בבעיה גדולה). רשתות שירות מודרניות מגנות בשקיפות על כל התעבורה שלנו, למשל, עם אימות TLS הדדי והצפנה שלאחר מכן.

ניתוב תעבורה עבור שירותי פלטפורמה

אוקיי, דיברנו על תעבורה בין אפליקציות, אבל מה לגבי פלטפורמת dotCloud עצמה?

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

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

שירותים קריטיים ברמה נמוכה אלו נפרסו על ידי הפעלת קונטיינרים ישירות על מספר צמתים מרכזיים. במקרה זה, לא נעשה שימוש בשירותי פלטפורמה סטנדרטיים: מקשר, מתזמן ורץ. אם אתה רוצה להשוות לפלטפורמות מכולות מודרניות, זה כמו להפעיל מטוס בקרה עם docker run ישירות על הצמתים, במקום להאציל את המשימה ל- Kubernetes. זה די דומה בקונספט מודולים סטטיים (תרמילים), שבו הוא משתמש kubeadm או bootkube בעת אתחול אשכול עצמאי.

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

מצד אחד, הוא אמין ביותר מכיוון שהוא אינו דורש תמיכה של חנות מפתח/ערך חיצוני כגון Zookeeper (זכור, וכו' או קונסול לא היו קיימים באותה תקופה). מצד שני, זה הקשה על העברת שירותים. בכל פעם שנעשה מהלך, כל הלקוחות יקבלו קובץ YAML מעודכן (ואפשר לאתחל מחדש). לא מאוד נוח!

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

(כמו כן תוכנן להקיף את התעבורה בחיבורי TLS ולהציב שרת פרוקסי נוסף בצד המקבל, וכן לאמת תעודות TLS ללא השתתפות השירות המקבל, שמוגדר לקבל חיבורים רק ב- localhost. עוד על כך בהמשך).

זה מאוד דומה ל SmartStack מ-Airbnb, אבל ההבדל המשמעותי הוא ש-SmartStack מיושם ונפרס לייצור, בעוד שמערכת הניתוב הפנימית של dotCloud נגנזה כאשר dotCloud הפכה ל-Docker.

אני אישית מחשיב את SmartStack כאחד הקודמים למערכות כמו Istio, Linkerd ו-Consul Connect מכיוון שכולן עוקבות אחר אותו דפוס:

• הפעל פרוקסי בכל צומת.
• לקוחות מתחברים ל-proxy.
• מישור הבקרה מעדכן את תצורת ה-proxy כאשר הקצה האחורי משתנים.
• ... רווח!

יישום מודרני של רשת שירות

אם היינו צריכים ליישם רשת דומה היום, נוכל להשתמש בעקרונות דומים. לדוגמה, הגדר אזור DNS פנימי על ידי מיפוי שמות שירות לכתובות במרחב 127.0.0.0/8. לאחר מכן הפעל את HAProxy בכל צומת באשכול, וקבל חיבורים בכל כתובת שירות (בתת-רשת זו 127.0.0.0/8) והפניית/איזון העומס לחלקים האחוריים המתאימים. ניתן לשלוט בתצורת HAProxy confd, המאפשר לך לאחסן מידע עורפי ב-etcd או ב-Consul ולדחוף אוטומטית תצורה מעודכנת ל-HAProxy בעת הצורך.

זה פחות או יותר איך Istio עובד! אבל עם כמה הבדלים:

• שימושים פרוקסי שליח במקום HAProxy.
• מאחסן את תצורת הקצה האחורי באמצעות Kubernetes API במקום etcd או Consul.
• שירותים מוקצים כתובות ברשת המשנה הפנימית (כתובות Kubernetes ClusterIP) במקום 127.0.0.0/8.
• בעל רכיב נוסף (Citadel) להוספת אימות TLS הדדי בין הלקוח לשרתים.
• תומך בתכונות חדשות כגון שבירת מעגל, מעקב מבוזר, פריסת קנרית וכו'.

בואו נסתכל במהירות על כמה מההבדלים.

פרוקסי שליח

Envoy Proxy נכתב על ידי Lyft [המתחרה של אובר בשוק המוניות - כ. נתיב]. זה דומה במובנים רבים ל-proxies אחרים (למשל HAProxy, Nginx, Traefik...), אבל Lyft כתב את שלהם כי הם היו זקוקים לתכונות שחסרות ל-proxies אחרים, ונראה היה חכם יותר ליצור אחד חדש במקום להרחיב את הקיים.

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

אבל Envoy גם מסוגל לעבוד בתור מישור נתונים (מישור נתונים) עבור רשת השירות. המשמעות היא ש-Envoy מוגדר כעת עבור רשת השירות הזו מטוס שליטה (מטוס בקרה).

מטוס בקרה

עבור מישור הבקרה, Istio מסתמך על ה-API של Kubernetes. זה לא שונה מאוד משימוש ב-confd, המסתמך על etcd או Consul כדי להציג את סט המפתחות במאגר הנתונים. Istio משתמש בממשק ה-API של Kubernetes כדי להציג קבוצה של משאבי Kubernetes.

בין זה ואז: אני אישית מצאתי את זה שימושי תיאור ממשק API של Kubernetesשכתוב בו:

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

Istio תוכנן לעבוד עם Kubernetes; ואם אתה רוצה להשתמש בו מחוץ ל-Kubernetes, אז אתה צריך להפעיל מופע של שרת ה-API של Kubernetes (ושירות העזר etcd).

כתובות שירות

Istio מסתמך על כתובות ClusterIP ש-Kubernetes מקצה, כך ששירותי Istio מקבלים כתובת פנימית (לא בטווח 127.0.0.0/8).

תעבורה לכתובת ClusterIP עבור שירות ספציפי באשכול Kubernetes ללא Istio מיירטת על ידי kube-proxy ונשלחת ל-backend של אותו proxy. אם אתה מעוניין בפרטים הטכניים, kube-proxy מגדיר כללי iptables (או מאזני עומס IPVS, תלוי איך זה מוגדר) כדי לשכתב את כתובות ה-IP היעד של חיבורים העוברים לכתובת ClusterIP.

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

בשילוב עם Kubernetes DNS, זה אומר שהקוד שלנו יכול להתחבר לפי שם השירות והכל "פשוט עובד". במילים אחרות, הקוד שלנו מנפיק שאילתות כמו http://api/v1/users/4242אז api לפתור בקשה עבור 10.97.105.48, חוקי iptables יירטו חיבורים מתאריך 10.97.105.48 ויעבירו אותם ל-Proxy המקומי של Envoy, וה-Proxy המקומי הזה יעביר את הבקשה ל-API ממשי. פיו!

סלסולים נוספים

Istio מספקת גם הצפנה ואימות מקצה לקצה באמצעות mTLS (TLS הדדי). רכיב שנקרא מצודה.

יש גם מרכיב מיקסר, אשר השליח יכול לבקש כל בקשה לקבל החלטה מיוחדת לגבי אותה בקשה בהתאם לגורמים שונים כגון כותרות, עומס אחורי וכו'... (אל דאגה: ישנן דרכים רבות לשמור על המיקסר פועל, וגם אם הוא יקרוס, Envoy ימשיך לעבוד בסדר כפרוקסי).

וכמובן, הזכרנו את הנראות: Envoy אוספת כמות עצומה של מדדים תוך מתן מעקב מבוזר. בארכיטקטורת מיקרו-שירותים, אם בקשת API בודדת חייבת לעבור דרך מיקרו-שירותים A, B, C ו-D, אז עם הכניסה, מעקב מבוזר יוסיף מזהה ייחודי לבקשה ויאחסן את המזהה הזה באמצעות בקשות משנה לכל המיקרו-שירותים הללו, מה שמאפשר כל השיחות הקשורות ללכוד. עיכובים וכו'.

לפתח או לקנות

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

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

אבל אם יש לנו דרישות מתקדמות, נראה ש"רכישת" רשת שירות היא אופציה הרבה יותר טובה. (זה לא תמיד "קנייה" מכיוון ש-Istio הוא קוד פתוח, אבל אנחנו עדיין צריכים להשקיע זמן הנדסי כדי להבין, לפרוס ולנהל אותו.)

האם עלי לבחור ב-Istio, Linkerd או Consul Connect?

עד כה דיברנו רק על Istio, אבל זו לא רשת השירות היחידה. אלטרנטיבה פופולרית - לינקרד, ויש עוד קונסול קונקט.

מה לבחור?

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

גישה מבטיחה אחת היא להשתמש בכלי כמו SuperGloo. הוא מיישם שכבת הפשטה כדי לפשט ולאחד את ממשקי ה-API שנחשפים על ידי רשתות שירות. במקום ללמוד את ממשקי ה-API הספציפיים (ולדעתי, המורכבים יחסית) של רשתות שירות שונות, נוכל להשתמש בקונסטרוקציות הפשוטות יותר של SuperGloo - ולעבור בקלות מאחד לשני, כאילו היה לנו פורמט תצורה ביניים המתאר ממשקי HTTP ו-backends מסוגלים של יצירת התצורה בפועל עבור Nginx, HAProxy, Traefik, Apache...

התעסקתי קצת עם Istio ו-SuperGloo, ובמאמר הבא אני רוצה להראות איך מוסיפים את Istio או Linkerd לאשכול קיים באמצעות SuperGloo, ואיך האחרון עושה את העבודה, כלומר מאפשר לך לעבור מ רשת שירות אחת לאחרת ללא החלפת תצורות.

מקור: www.habr.com