Cloud Service Mesh עם קבוצות של נקודות קצה ברשת באינטרנט

אתם יכולים להגדיר את Cloud Service Mesh כך שישתמש בקבוצות של נקודות קצה ברשת (NEGs) באינטרנט מסוג INTERNET_FQDN_PORT. השירות החיצוני מיוצג על ידי שם הדומיין שמוגדר במלואו (FQDN) ומספר היציאה ב-NEG. קבוצת ה-NEG יכולה להכיל רק זוג FQDN:Port אחד, ושירות לקצה העורפי יכול להכיל רק קבוצת NEG אחת מהסוג הזה. שם הדומיין שמוגדר במלואו (FQDN) מפוענח באמצעות סדר פענוח השמות של רשת הענן הווירטואלי הפרטי (VPC) הבסיסית.

הרחבת רשת שירותים של Cloud Service Mesh באמצעות עורפי קצה של FQDN

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

הרחבת רשת שירותים של Cloud Service Mesh למיקומים מקומיים או מרובי עננים (multi-cloud) באמצעות קצה עורפי של FQDN דרך קישוריות היברידית.
הרחבת Cloud Service Mesh למיקומים מקומיים או למיקומים מרובי-ענן באמצעות עורפי FQDN דרך קישוריות היברידית (לחצו כדי להגדיל)

אפשר גם לנתב תנועה לשירותים שאפשר להגיע אליהם דרך האינטרנט הציבורי.

הרחבת רשת שירותים של Cloud Service Mesh לשירות אינטרנט באמצעות עורפי קצה של FQDN.
הרחבת רשת השירותים של Cloud Service Mesh לשירות אינטרנט באמצעות קצה עורפי של FQDN (לחצו כדי להגדיל)

Google Cloud משאבים וארכיטקטורה

בקטע הזה מתוארים המשאבים והארכיטקטורה להגדרת Cloud Service Mesh עם NEG לאינטרנט.

INTERNET_FQDN_PORT קבוצה של נקודות קצה ברשת

כדי לנתב תנועה לשירות חיצוני שמפנים אליו באמצעות ה-FQDN שלו, משתמשים ב-NEG גלובלי לאינטרנט מהסוג INTERNET_FQDN_PORT. ה-NEG מכיל את ה-FQDN של השירות ואת מספר היציאה שלו. ‫Cloud Service Mesh מתכנת את ה-FQDN בשרתי proxy של Envoy באמצעות הגדרת xDS.

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

בדיקות תקינות

התנהגות בדיקת התקינות של נקודות קצה ברשת מהסוג INTERNET_FQDN_PORT שונה מהתנהגות בדיקת התקינות של סוגים אחרים של נקודות קצה ברשת שמשמשות עם Cloud Load Balancing ו-Cloud Service Mesh. ברוב הסוגים האחרים של נקודות קצה ברשת נעשה שימוש במערכת המרכזית לבדיקת תקינות של Google Cloud, אבל ב-NEGs שמשמשים לנקודות קצה בסביבות מרובות עננים (INTERNET_FQDN_PORT ו-NON_GCP_PRIVATE_IP_PORT) נעשה שימוש במנגנון המבוזר לבדיקת תקינות של Envoy.

‫Envoy תומך בפרוטוקולים הבאים לבדיקת תקינות:

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

אתם מגדירים בדיקות תקינות באמצעות Compute Engine APIs.

שיקולים לגבי DNS

יש שני שיקולים שונים שקשורים ל-DNS:

  • שרת ה-DNS שמארח את רשומות המשאבים של השירות החיצוני.
  • המצב שבו שרת ה-proxy של Envoy מוגדר להשתמש ב-DNS לניהול חיבורים.

שרת Cloud DNS

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

מצב DNS של Envoy

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

מידע נוסף על זיהוי שירותים זמין במאמרי העזרה של Envoy.

קישוריות וניתוב

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

  • קישוריות היברידית בין רשת ה-VPC לבין מרכז הנתונים המקומי או הענן הציבורי של צד שלישי נוצרת באמצעות Cloud VPN או Cloud Interconnect.
  • כללי חומת האש והנתיבים של ה-VPC מוגדרים בצורה נכונה כדי ליצור נגישות דו-כיוונית מ-Envoy לנקודות הקצה של השירות הפרטי שלכם, ואם רלוונטי, לשרת ה-DNS המקומי.
  • כדי שמעבר הגיבוי האוטומטי בזמינות גבוהה באזור יתבצע בהצלחה, צריך להפעיל ניתוב דינמי גלובלי. מידע נוסף זמין במאמר בנושא מצב ניתוב דינמי.

אם אתם מעבירים תנועה לשירות חיצוני שאפשר לגשת אליו באינטרנט, אתם צריכים לעמוד בדרישות הבאות:

  • למכונות הווירטואליות של הלקוח ברשת ה-VPC צריכה להיות כתובת IP חיצונית או Cloud NAT.
  • מסלול ברירת המחדל חייב להיות קיים כדי לאפשר יציאה של תנועה לאינטרנט.

בשני המקרים הקודמים, התעבורה משתמשת בניתוח המסלולים של רשת ה-VPC.

אבטחה

בקצה העורפי של FQDN יש תאימות לתכונות האבטחה ולממשקי ה-API של Cloud Service Mesh. בחיבורים היוצאים לשירות החיצוני, אפשר להגדיר FQDN בכותרת SNI באמצעות מדיניות TLS של לקוח.

מגבלות ושיקולים

  • אין תמיכה ב-NEGs באינטרנט מהסוג INTERNET_IP_PORT ב-Cloud Service Mesh.
  • נדרשת גרסה 1.15.0 ואילך של Envoy עם עורפי FQDN.
  • משתמשים ב-Google Cloud CLI או בממשקי REST API כדי להגדיר את Cloud Service Mesh. אין תמיכה בהגדרה מקצה לקצה באמצעות מסוף Google Cloud .
  • יש תמיכה בשרתי קצה עורפיים של FQDN רק ב-Envoy. אין תמיכה ב-gRPC ללא proxy.

  • כשמשתמשים בסוג ה-NEG‏ INTERNET_FQDN_PORT עם Cloud Service Mesh, בדיקות תקינות של נקודות הקצה המרוחקות מתבצעות באמצעות מנגנון בדיקת התקינות המבוזר של Envoy. בכל פעם שמוסיפים נקודת קצה מרוחקת חדשה, כל שרתי ה-proxy של Envoy מתחילים לבדוק את תקינותה באופן עצמאי.

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

  • סטטוס בדיקת התקינות לא מוצג במסוף Google Cloud לשרתי קצה של FQDN.

  • אין תמיכה בבדיקות תקינות שמשתמשות בפרוטוקולים UDP,‏ SSL ו-gRPC.

  • אפשרויות בדיקת התקינות הבאות לא נתמכות:

    • בדיקת תקינות של HTTP/HTTP2/HTTPS
      • --proxy-header
      • --response
    • בדיקת תקינות של TCP
      • --proxy-header
      • --request
      • --response

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