סקירה כללית על Cloud Service Mesh

המאמר הזה מיועד לאדמינים של רשתות ולבעלים של שירותים שרוצים להכיר את Cloud Service Mesh ואת היכולות שלו. זהו מסמך מדור קודם שרלוונטי להגדרות שמשתמשות בממשקי ה-API של איזון העומסים.

‫Cloud Service Mesh הוא מישור בקרה מנוהל לרשתות של אפליקציות. בעזרת Cloud Service Mesh אפשר לספק שירותים גלובליים עם זמינות גבוהה, עם יכולות מתקדמות של רשתות אפליקציות כמו ניהול תעבורה וניראות (observability).

ככל שמספר השירותים והמיקרו-שירותים בפריסה גדל, בדרך כלל מתחילים להיתקל באתגרים נפוצים ברשתות של אפליקציות, כמו:

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

Cloud Service Mesh עוזר לכם לפתור אתגרים מהסוג הזה בפריסה מודרנית שמבוססת על שירותים. ‫Cloud Service Mesh מסתמך על תשתית מנוהלת Google Cloud, כך שלא צריך לנהל תשתית משלכם. אתם מתמקדים בשליחת קוד האפליקציה שפותר את הבעיות העסקיות שלכם, ומאפשרים ל-Cloud Service Mesh לנהל את המורכבויות של רשת האפליקציה.

Cloud Service Mesh

תבנית נפוצה לפתרון בעיות ברשת של אפליקציות היא שימוש ב-service mesh. ‫Cloud Service Mesh תומך ב-service mesh ובדפוסי פריסה אחרים שמתאימים לצרכים שלכם.

ב-Service mesh טיפוסי, התנאים הבאים מתקיימים:

• אתם פורסים את השירותים שלכם באשכול Kubernetes.
• לכל אחד מה-Pods של השירותים יש שרת proxy ייעודי (בדרך כלל Envoy) שפועל כקובץ עזר חיצוני.
• כל שרת proxy מסוג sidecar מתקשר עם תשתית הרשת (מישור בקרה) שמותקנת באשכול. מישור הבקרה מעביר לשרתי ה-proxy מסוג sidecar מידע על שירותים, נקודות קצה ומדיניות ב-Service mesh.
• כש-Pod שולח או מקבל בקשה, הבקשה מועברת לפרוקסי מסוג קובץ עזר חיצוני של ה-Pod. ה-proxy מסוג קובץ עזר חיצוני מטפל בבקשה, למשל, על ידי שליחתה ליעד המיועד.

בתרשימים במסמך הזה ובמסמכים אחרים של Cloud Service Mesh, הסמלים הוורודים בעלי שש הצלעות מייצגים את ה-proxies. מישור הבקרה מחובר לכל שרת proxy ומספק מידע ששרתי ה-proxy צריכים כדי לטפל בבקשות. החיצים בין התיבות מראים את זרימת התנועה. לדוגמה, קוד האפליקציה ב-Service A שולח בקשה. שרת ה-proxy מטפל בבקשה ומעביר אותה אל Service B.

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

מה ההבדל בין Cloud Service Mesh לבין פתרונות אחרים

‫Cloud Service Mesh פועל באופן דומה למודל הזה, אבל יש הבדלים חשובים. הכול מתחיל מהעובדה ש-Cloud Service Mesh הוא שירות מנוהל שלGoogle Cloud. לא צריך להתקין אותו, הוא לא פועל באשכול ולא צריך לתחזק אותו.

בתרשים הבא, Cloud Service Mesh הוא מישור הבקרה. יש ארבעה שירותים באשכול Kubernetes הזה, ולכל אחד מהם יש פרוקסי מסוג sidecar שמחוברים ל-Cloud Service Mesh. ‫Cloud Service Mesh מספק את המידע שדרוש לשרתי ה-proxy כדי לנתב בקשות. לדוגמה, קוד האפליקציה ב-Pod ששייך ל-Service A שולח בקשה. קובץ העזר החיצוני שפועל לצד הפוד הזה מטפל בבקשה ומנתב אותה לפוד ששייך ל-Service B.

מעבר ל-service mesh

‫Cloud Service Mesh תומך ביותר סוגים של פריסות מאשר רשת שירותים רגילה.

‫Kubernetes מרובה אשכולות

עם Cloud Service Mesh, מקבלים רשת אפליקציות שפועלת בכל אשכולות Kubernetes. בתרשים הבא, Cloud Service Mesh מספק את מישור הבקרה לאשכולות Kubernetes ב-us-central1 וב-europe-west1. אפשר לנתב בקשות בין שלושת השירותים ב-us-central1, בין שני השירותים ב-europe-west1 ובין השירותים בשני האשכולות.

רשת Service mesh יכולה להתפרס על פני כמה אשכולות Kubernetes בכמה אזוריGoogle Cloud . שירותים באותו אשכול יכולים לתקשר עם שירותים באשכול אחר. אפשר אפילו להגדיר שירותים שמורכבים מקבוצות Pod בכמה אשכולות.

בעזרת איזון עומסים גלובלי שמבוסס על קרבה ב-Cloud Service Mesh, בקשות שמיועדות ל-Service B מנותבות אל ה-Pod הקרוב ביותר שיכול לטפל בבקשה. בנוסף, מקבלים יתירות כשל חלקה. אם Pod מושבת, הבקשה עוברת אוטומטית ל-Pod אחר שיכול לטפל בבקשה, גם אם ה-Pod הזה נמצא באשכול Kubernetes אחר.

מכונות וירטואליות

‫Kubernetes הופכת לפופולרית יותר ויותר, אבל הרבה עומסי עבודה (workload) נפרסים במכונות וירטואליות (VM). ‫Cloud Service Mesh פותר גם את בעיית הרשת של האפליקציות בעומסי העבודה האלה. עומסי העבודה מבוססי-VM פועלים בשילוב עם עומסי העבודה מבוססי-Kubernetes.

בתרשים הבא, התנועה נכנסת לפריסה דרך מאזן העומסים החיצוני של האפליקציות. הבקשה מנותבת אל Service A באשכול Kubernetes ב-asia-southeast1 ואל Service D במכונה וירטואלית ב-europe-west1.

‫Google מספקת מנגנון חלק להגדרת עומסי עבודה (workload) מבוססי מכונות וירטואליות באמצעות Cloud Service Mesh. אתם רק מוסיפים סימון לתבנית של הגדרות מכונה ב-Compute Engine, ו-Google מטפלת בהגדרת התשתית. ההגדרה הזו כוללת התקנה והגדרה של שרתי ה-proxy שמספקים יכולות של רשתות אפליקציות.

Proxyless gRPC

‫gRPC היא מסגרת RPC בקוד פתוח עם מגוון רחב של תכונות, שבעזרתה אפשר לכתוב מיקרו-שירותים עם ביצועים ברמה גבוהה. עם Cloud Service Mesh, אפשר להוסיף לאפליקציות gRPC יכולות של רשתות אפליקציות (כמו גילוי שירותים, איזון עומסים וניהול תעבורה). מידע נוסף זמין במאמר בנושא Cloud Service Mesh ו-gRPC – שירותים בלי שרת Proxy עבור Service mesh.

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

‫Cloud Service Mesh תומך בשירותי gRPC ללא שרת proxy. השירותים האלה משתמשים בגרסה עדכנית של ספריית gRPC בקוד פתוח שתומכת בממשקי ה-API של xDS. אפליקציות gRPC יכולות להתחבר ל-Cloud Service Mesh באמצעות אותם ממשקי xDS API שבהם משתמש Envoy.

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

תעבורת נתונים נכנסת (ingress) ושערים

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

בתרשים הבא, מאזן עומסים חיצוני של אפליקציות מאפשר Ingress ללקוחות חיצוניים, והתעבורה מנותבת לשירותים באשכול Kubernetes. מאזן עומסים פנימי של אפליקציות (ALB) מעביר תעבורה פנימית לשירות שפועל במכונה הווירטואלית.

‫Cloud Service Mesh פועל עם Cloud Load Balancing כדי לספק חוויית כניסה מנוהלת. מגדירים מאזן עומסים חיצוני או פנימי, ואז מגדירים את מאזן העומסים לשליחת תעבורה למיקרו-שירותים. בתרשים שלמעלה, לקוחות באינטרנט הציבורי מגיעים לשירותים שלכם דרך מאזן עומסים חיצוני של אפליקציות (ALB). לקוחות, כמו מיקרו-שירותים שנמצאים ברשת VPC שלכם, משתמשים במאזן עומסים פנימי של אפליקציות כדי להגיע לשירותים שלכם.

במקרים מסוימים, כדאי להגדיר Cloud Service Mesh כדי להגדיר שער. שער הוא בעצם פרוקסי הפוך, בדרך כלל Envoy שפועל במכונה וירטואלית אחת או יותר, שמקשיב לבקשות נכנסות, מטפל בהן ושולח אותן ליעד. יעד ההעברה יכול להיות בכל Google Cloud אזור או אשכול Google Kubernetes Engine ‏ (GKE). יכול להיות שזה יהיה יעד מחוץ ל-Google Cloud שאפשר להגיע אליו מ- Google Cloud באמצעות קישוריות היברידית. מידע נוסף על מקרים שבהם כדאי להשתמש בשער זמין במאמר בנושא תעבורת נתונים נכנסת (ingress) לרשת.

בתרשים הבא, VM באזור europe-west1 מריצה שרת proxy שפועל כשער לשלושה שירותים שלא מריצים שרתי proxy. התנועה ממאזן עומסים חיצוני של אפליקציות (ALB) וממאזן עומסים פנימי של אפליקציות (ALB) מנותבת אל השער ואז אל שלושת השירותים.

סביבות מרובות

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

בתרשים הבא, Cloud Service Mesh מנתב תעבורה משירותים שפועלים ב- Google Cloud אל Service G, שפועל בענן ציבורי אחר, ואל Service E ו-Service F, שניהם פועלים במרכז נתונים מקומי. ‫Service A,‏ Service B ו-Service C משתמשים ב-Envoy כקובץ עזר חיצוני, ואילו Service D הוא שירות gRPC ללא proxy.

כשמשתמשים ב-Cloud Service Mesh, אפשר לשלוח בקשות ליעדים מחוץ ל-Google Cloud. כך תוכלו להשתמש ב-Cloud Interconnect או ב-Cloud VPN כדי להעביר תנועה באופן פרטי משירותים בתוך Google Cloud לשירותים או לשערי מעבר בסביבות אחרות.

הגדרת Cloud Service Mesh

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

פריסת האפליקציות

קודם פורסים את קוד האפליקציה בקונטיינרים או במכונות וירטואליות. ‫Google מספקת מנגנונים שמאפשרים לכם להוסיף תשתית רשת של אפליקציות (בדרך כלל שרתי proxy של Envoy) למכונות הווירטואליות ול-Pods. התשתית הזו מוגדרת לתקשורת עם Cloud Service Mesh וללמידה על השירותים שלכם.

הגדרת Cloud Service Mesh

בשלב הבא מגדירים את השירותים הגלובליים ומגדירים איך לטפל בתעבורה. כדי להגדיר את Cloud Service Mesh, אפשר להשתמש במסוף Google Cloud (לכמה תכונות והגדרות), ב-Google Cloud CLI, ב-Traffic Director API או בכלי אחרים, כמו Terraform.

אחרי שמבצעים את השלבים האלה, אפשר להשתמש ב-Cloud Service Mesh כדי להגדיר את תשתית הרשת של האפליקציה.

התשתית מטפלת ברשת של האפליקציה

כשאפליקציה שולחת בקשה אל my-service, תשתית הרישות של האפליקציה (לדוגמה, Envoy קובץ עזר חיצוני) מטפלת בבקשה בהתאם למידע שהתקבל מ-Cloud Service Mesh. ההגדרה הזו מאפשרת להפנות בקשה אל my-service בצורה חלקה למופע של אפליקציה שיכול לקבל את הבקשה.

מעקב ועדכונים שוטפים

‫Cloud Service Mesh מנטר את מופעי האפליקציות שמרכיבים את השירותים שלכם. המעקב הזה מאפשר ל-Cloud Service Mesh לגלות אם שירות תקין או אם הקיבולת של שירות השתנתה – למשל, כשנוצר Pod חדש של Kubernetes. על סמך המידע הזה, Cloud Service Mesh מעדכן באופן רציף את תשתית הרשת של האפליקציה.

תכונות

התכונות של Cloud Service Mesh מספקות יכולות של רשתות אפליקציות למיקרו-שירותים. בקטע הזה נסביר על כמה מהנקודות החשובות.

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

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

מבוסס על מוצרים בקוד פתוח

‫Cloud Service Mesh משתמש באותה רמת בקרה (ממשקי xDS API) שבה משתמשים פרויקטים פופולריים בקוד פתוח כמו Envoy ו-Istio. כדי לראות את הגרסאות הנתמכות של ה-API, אפשר לעיין במאמר ממשקי API של מישור הבקרה xDS.

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

להתכונן להתרחבות

מפתרונות חד-פעמיים של רשתות אפליקציות ועד פריסות נרחבות של רשתות שירותים עם אלפי שירותים, Cloud Service Mesh נועד לענות על דרישות ההתאמה שלכם.

גילוי שירותים ומעקב אחרי נקודות הקצה והקצה העורפי

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

איזון עומסים גלובלי ויתירות כשל

‫Cloud Service Mesh משתמש באיזון עומסים גלובלי ובבדיקות תקינות של Google כדי לאזן את תעבורת הנתונים בצורה אופטימלית על סמך המיקום של הלקוח והקצה העורפי, הקרבה לקצה העורפי, התקינות והקיבולת. אתם יכולים לשפר את הזמינות של השירות על ידי העברה אוטומטית של תעבורה (failover) אל עורפי קצה תקינים עם קיבולת. אתם יכולים להתאים אישית את איזון העומסים כדי לחלק את התנועה בצורה שתתמוך בצורה נכונה בצרכים העסקיים שלכם.

ניהול תנועה

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

ניראות (observability)

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

VPC Service Controls

אתם יכולים להשתמש ב-VPC Service Controls כדי לספק אבטחה נוספת למשאבים ולשירותים של האפליקציה. אתם יכולים להוסיף פרויקטים לגבולות גזרה לשירות שמגינים על המשאבים והשירותים (כמו Cloud Service Mesh) מפני בקשות שמקורן מחוץ לגבולות הגזרה. מידע נוסף על VPC Service Controls זמין בסקירה כללית על VPC Service Controls.

מידע נוסף על שימוש ב-Cloud Service Mesh עם VPC Service Controls זמין בדף מוצרים נתמכים.

המאמרים הבאים

זהו מסמך מדור קודם שרלוונטי בעיקר לממשקי ה-API של איזון העומסים. מומלץ מאוד לא להגדיר את Cloud Service Mesh באמצעות ממשקי API של איזון עומסים.

• כדי לפרוס את Cloud Service Mesh:

  • ב-Compute Engine עם מכונות וירטואליות, משתמשים בממשקי ה-API לניתוב שירותים.
  • ב-Google Kubernetes Engine עם Pods, משתמשים בממשקי Gateway API.

• כדי למצוא תרחישי שימוש ודפוסי ארכיטקטורה לשירותי gRPC בלי שרת Proxy, אפשר לעיין בסקירה הכללית על שירותי gRPC בלי שרת Proxy.

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

• כדי להבין איך Cloud Service Mesh תומך בסביבות שחורגות מ-Google Cloud, אפשר לעיין במסמכים הבאים:

  • שילוב של Cloud Service Mesh עם Service Directory
  • Cloud Service Mesh עם קבוצות של נקודות קצה ברשת לקישוריות היברידית (ממשקי API מדור קודם בלבד)
  • Cloud Service Mesh עם קבוצות של נקודות קצה ברשת האינטרנט (ממשקי API מדור קודם בלבד)