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

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

מדריך ההגדרה הזה כולל הוראות בסיסיות לגבי הפעולות הבאות:

  • הגדרת Cloud Service Mesh לשימוש ב-NEG באינטרנט וב-TLS לא מאומת לתנועה יוצאת
  • ניתוב תעבורה לשירות Cloud Run מ-Service Mesh

לפני שמתחילים

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

לצורך המדריך הזה, ההגדרות לדוגמה מבוססות על ההנחות הבאות:

  • כל המשאבים הרלוונטיים של Compute Engine, כמו פרוקסי ביניים, משאבי Cloud Service Mesh, אזורי Cloud DNS וקישוריות היברידית, מצורפים לרשת ברירת המחדל של הענן הווירטואלי הפרטי (VPC).
  • השירות example.com:443 פועל בתשתית המקומית שלכם. הדומיין example.com מוגש על ידי שלוש נקודות קצה: 10.0.0.100, 10.0.0.101 ו-10.0.0.102. קיימים נתיבים שמבטיחים קישוריות משרתי ה-proxy של Envoy לנקודות הקצה המרוחקות האלה.

הפריסה שמתקבלת דומה לזו שמוצגת בהמשך.

דוגמה להגדרה עם קבוצת נקודות קצה ברשת האינטרנט.
דוגמה להגדרה עם NEG באינטרנט (לחצו כדי להגדיל)

ניתוב תנועה עם NEG באינטרנט ו-TLS עם SNI

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

איך תעבורת הנתונים מנותבת בדוגמה.
איך התנועה מנותבת בדוגמה (לחצו כדי להגדיל)

השלבים במקרא הבא תואמים למספור בתרשים הקודם.

שלב תיאור
0 ‫Envoy מקבל את הגדרת הקצה העורפי של ה-FQDN מ-Cloud Service Mesh דרך xDS.
0 ‫Envoy, שפועל במכונה הווירטואלית, שולח שאילתות DNS באופן רציף לגבי ה-FQDN שהוגדר.
1 אפליקציית המשתמש יוזמת בקשה.
2 הפרמטרים של הבקשה.
3 שרת ה-proxy של Envoy מיירט את הבקשה. בדוגמה הזו מניחים שמשתמשים ב-0.0.0.0 ככתובת ה-IP הווירטואלית (VIP) של כלל ההעברה. כאשר 0.0.0.0 הוא ה-VIP, ‏ Envoy מיירט את כל הבקשות. ניתוב הבקשות מבוסס רק על פרמטרים של שכבה 7, בלי קשר לכתובת ה-IP של היעד בבקשה המקורית שנוצרה על ידי האפליקציה.
4 ‫Envoy בוחר נקודת קצה בריאה מרחוק ומבצע לחיצת יד של TLS עם ה-SNI שהתקבל ממדיניות ה-TLS של הלקוח.
5 ‫Envoy מעביר את הבקשה לנקודת הקצה המרוחקת.

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

הגדרת קישוריות היברידית

בנוסף, אנחנו מניחים שכבר הוגדרה קישוריות היברידית:

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

הגדרת Cloud DNS

משתמשים בפקודות הבאות כדי להגדיר אזור פרטי ב-Cloud DNS לדומיין (FQDN) example.com שיש לו רשומות A שמפנות לנקודות קצה 10.0.0.100, 10.0.0.101, 10.0.0.102 ו-10.0.0.103.

gcloud

  1. יוצרים תחום פרטי מנוהל ב-DNS ומצרפים אותו לרשת ברירת המחדל:
    gcloud dns managed-zones create example-zone \
        --description=test \
        --dns-name=example.com \
        --networks=default \
        --visibility=private
  1. מוסיפים רשומות DNS לאזור הפרטי:
    gcloud dns record-sets transaction start \
        --zone=example-zone

    gcloud dns record-sets transaction add 10.0.0.100 10.0.0.101 10.0.0.102 10.0.0.103 \
        --name=example.com \
        --ttl=300 \
        --type=A \
        --zone=example-zone

    gcloud dns record-sets transaction execute \
        --zone=example-zone

הגדרת Cloud Service Mesh עם NEG של FQDN באינטרנט

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

יצירה של NEG, בדיקת תקינות ושירות קצה עורפי

gcloud

  1. יוצרים את ה-NEG של האינטרנט:
    gcloud compute network-endpoint-groups create on-prem-service-a-neg \
        --global \
        --network-endpoint-type INTERNET_FQDN_PORT
  1. מוסיפים את נקודת הקצה FQDN:Port ל-NEG של האינטרנט:
    gcloud compute network-endpoint-groups update on-prem-service-a-neg \
        --global \
        --add-endpoint=fqdn=example.com,port=443
  1. יצירת בדיקת תקינות גלובלית:
    gcloud compute health-checks create http service-a-http-health-check \
        --global
  1. יוצרים שירות לקצה העורפי גלובלי בשם on-prem-service-a ומשייכים אליו את בדיקת תקינות:
    gcloud compute backend-services create on-prem-service-a \
        --global \
        --load-balancing-scheme=INTERNAL_SELF_MANAGED \
        --health-checks service-a-http-health-check
  1. מוסיפים את ה-NEG שנקרא on-prem-service-a-neg כקצה העורפי של שירות הקצה העורפי:
    gcloud compute backend-services add-backend on-prem-service-a \
        --global \
        --global-network-endpoint-group \
        --network-endpoint-group on-prem-service-a-neg

יצירת מפה של כללי ניתוב

מפת ה-URL, פרוקסי HTTP של היעד וכלל ההעברה מהווים מפת כללי ניתוב, שמספקת מידע על ניתוב התנועה ברשת.

מפת URL זו מכילה כלל שמנתב את כל תנועת ה-HTTP אל on-prem-service-a.

gcloud

  1. יוצרים את מפת ה-URL:
    gcloud compute url-maps create td-url-map \
        --default-service on-prem-service-a
  1. יוצרים את שרת ה-proxy של HTTP ליעד ומשייכים את מפת ה-URL לשרת ה-proxy ליעד:
    gcloud compute target-http-proxies create td-proxy \
        --url-map td-url-map
  1. יוצרים את כלל ההעברה הגלובלי באמצעות כתובת ה-IP‏ 0.0.0.0. זוהי כתובת IP מיוחדת שגורמת למישור הנתונים להתעלם מכתובת ה-IP של היעד ולנתב בקשות על סמך פרמטרי ה-HTTP של הבקשה בלבד.
    gcloud compute forwarding-rules create td-forwarding-rule \
        --global \
        --load-balancing-scheme=INTERNAL_SELF_MANAGED \
        --address=0.0.0.0 \
        --target-http-proxy=td-proxy \
        --ports=443 \
        --network=default

הגדרת TLS ו-HTTPS לא מאומתים

אם רוצים להגדיר HTTPS לא מאומת בין שרתי ה-proxy של Envoy לבין השירותים המקומיים, אפשר לפעול לפי ההוראות האלה. ההוראות האלה מראות גם איך להגדיר SNI בלחיצת היד של TLS.

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

gcloud

  1. יוצרים ומייבאים את מדיניות ה-TLS של הלקוח, ומגדירים את ה-SNI ל-FQDN שהגדרתם ב-NEG:
    cat << EOF > client_unauthenticated_tls_policy.yaml
    name: "client_unauthenticated_tls_policy"
    sni: "example.com"
    EOF

    gcloud beta network-security client-tls-policies import client_unauthenticated_tls_policy \
        --source=client_unauthenticated_tls_policy.yaml \
        --location=global
  1. אם הגדרתם בדיקת תקינות עם שירות לקצה העורפי בקטע הקודם, צריך לנתק את בדיקת התקינות משירות לקצה העורפי:HTTP
    gcloud compute backend-services update on-prem-service-a \
        --global \
        --no-health-checks
  1. יוצרים בדיקת תקינות HTTPS:
    gcloud compute health-checks create https service-a-https-health-check \
        --global
  1. מצרפים את מדיניות ה-TLS של הלקוח לשירות הקצה העורפי שיצרתם קודם. כך תיאכף HTTPS לא מאומת על כל הבקשות היוצאות מהלקוח לשירות הקצה העורפי הזה:
    gcloud compute backend-services export on-prem-service-a \
        --global \
        --destination=on-prem-service-a.yaml

    cat << EOF >> on-prem-service-a.yaml
    securitySettings:
      clientTlsPolicy: projects/${PROJECT_ID}/locations/global/clientTlsPolicies/client_unauthenticated_tls_policy
    healthChecks:
      - projects/${PROJECT_ID}/global/healthChecks/service-a-https-health-check
    EOF

    gcloud compute backend-services import on-prem-service-a \
        --global \
        --source=on-prem-service-a.yaml

אפשר להשתמש ב-NEGs של FQDN באינטרנט כדי לנתב תנועה לכל שירות שאפשר להגיע אליו באמצעות FQDN – לדוגמה, שירותים חיצוניים ופנימיים שאפשר לפתור את ה-DNS שלהם או שירותים של Cloud Run.

העברה מ-IP:Port NEG ל-FQDN:Port NEG

NON_GCP_PRIVATE_IP_PORT ב-NEG צריך לתכנת את נקודות הקצה של השירות לתוך ה-NEG כזוגות סטטיים של IP:PORT, בעוד שב-INTERNET_FQDN_NEG נקודות הקצה יכולות להיפתר באופן דינמי באמצעות DNS. כדי לבצע מיגרציה ל-NEG באינטרנט, צריך להגדיר רשומות DNS לנקודות הקצה של השירות המקומי ולהגדיר את Cloud Service Mesh כמו שמתואר בשלבים הבאים:

  1. מגדירים רשומות DNS עבור ה-FQDN.
  2. יוצרים NEG חדש לאינטרנט עם ה-FQDN.
  3. יוצרים שירות קצה עורפי חדש עם ה-NEG באינטרנט שיצרתם בשלב 2 בתור הקצה העורפי שלו. משייכים את אותה בדיקת תקינות שבה השתמשתם עם שירות הקצה העורפי של ה-NEG של הקישוריות ההיברידית לשירות הקצה העורפי החדש. מוודאים שנקודות הקצה החדשות של השלט רחוק תקינות.
  4. מעדכנים את מפת כללי הניתוב כדי להפנות לשירות לקצה העורפי החדש, על ידי החלפת העורפי הישן שכולל את ה-NEG של הקישוריות ההיברידית.
  5. אם רוצים אפס זמן השבתה במהלך מיגרציה פעילה בפריסת ייצור, אפשר להשתמש בתנועה שמבוססת על משקל. בהתחלה, מגדירים את שירות ה-Backend החדש כך שיקבל רק אחוז קטן מהתנועה, למשל 5%. אפשר להשתמש בהוראות להגדרת פיצול תנועה.
    1. מוודאים שנקודות הקצה החדשות המרוחקות משרתות את התנועה בצורה תקינה.
  6. אם אתם משתמשים בפיצול תעבורה לפי משקל, צריך להגדיר את שירות ה-Backend החדש כך שיקבל 100% מהתעבורה. בשלב הזה מתבצע ניתוק של שירות ה-Backend הישן.
  7. אחרי שמוודאים שהקצה העורפי החדש משרת את התנועה ללא בעיות, מוחקים את שירות הקצה העורפי הישן.

פתרון בעיות

כדי לפתור בעיות בהטמעה, פועלים לפי ההוראות שבקטע הזה. אם הבעיות לא נפתרות בעזרת המידע הזה, אפשר לעיין במאמר פתרון בעיות בהטמעות שמשתמשות ב-Envoy.

נקודת קצה מקומית לא מקבלת תנועה

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

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

כותרת המארח של HTTP לא תואמת ל-FQDN כשהבקשה מגיעה לשרת המקומי שלי

לדוגמה, הדומיין example.com מומר ל-10.0.0.1, שהיא כתובת ה-IP של כלל ההעברה, והדומיין altostrat.com מומר ל-10.0.0.100, שהיא נקודת הקצה של השירות המקומי. רוצים להפנות תנועה לדומיין altostrat.com, שמוגדר ב-NEG.

יכול להיות שהאפליקציה ב-Compute Engine או ב-GKE מגדירה את כותרת ה-HTTP ‏Host ל-example.com (Host: example.com), והיא מועברת לנקודת הקצה המקומית. אם אתם משתמשים ב-HTTPS, ‏ Envoy מגדיר את ה-SNI ל-altostrat.com במהלך לחיצת היד (handshake) ב-TLS. ‫Envoy מקבל את ה-SNI ממשאב מדיניות ה-TLS של הלקוח.

אם הקונפליקט הזה גורם לבעיות בעיבוד הבקשה או בהעברתה כשהיא מגיעה לנקודת הקצה המקומית, אפשר לכתוב מחדש את הכותרת Host ל-altostrat.com (Host: altostrat.com) כפתרון עקיף. אפשר לעשות את זה ב-Cloud Service Mesh באמצעות כתיבה מחדש של כתובת URL, או בנקודת הקצה המרוחקת אם יש לה יכולת כתיבה מחדש של כותרות.

פתרון עקיף פשוט יותר הוא להגדיר את הכותרת Host ל-altostrat.com (Host: altostrat.com) ולהשתמש בכתובת המיוחדת 0.0.0.0 ככתובת ה-IP של כלל ההעברה.

‫Envoy מחזיר הרבה שגיאות 5xx

אם Envy מחזיר מספר מוגזם של שגיאות 5xx, צריך לבצע את הפעולות הבאות:

  • בודקים את היומנים של Envoy כדי להבין אם התגובה מגיעה מהקצה העורפי (קצה עורפי מקומי) ומה הסיבה לשגיאת 5xx.
  • מוודאים ששאילתות ה-DNS מצליחות ושאין שגיאות SERVFAIL או NXDOMAIN.
  • מוודאים שכל נקודות הקצה המרוחקות עוברות את בדיקות התקינות.
  • אם לא הגדרתם בדיקות תקינות, צריך לוודא שניתן להגיע לכל נקודות הקצה מ-Envoy. צריך לבדוק את הכללים של חומת האש ואת המסלולים בצדGoogle Cloud וגם בצד המקומי.

אי אפשר לגשת לשירותים חיצוניים דרך האינטרנט הציבורי מ-Service mesh

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

  • מוודאים שהגדרתם את המסלולים הנכונים, במיוחד את מסלול ברירת המחדל 0.0.0.0/0, ואת כללי חומת האש.
  • מוודאים ששאילתות ה-DNS מצליחות ושאין שגיאות SERVFAIL או NXDOMAIN.
  • אם שרת ה-proxy של Envoy פועל במכונה וירטואלית ב-Compute Engine שאין לה כתובת IP חיצונית או באשכול GKE פרטי, צריך להגדיר Cloud NAT או אמצעי אחר כדי ליצור קישוריות לאינטרנט ליציאה.

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

אי אפשר לגשת לשירותים ללא שרתים מתוך Service mesh

אפשר לשלוח תעבורה לשירותים בלי שרת (serverless) (Cloud Run, פונקציות Cloud Run ו-App Engine) באמצעות קצה עורפי של FQDN ב-Cloud Service Mesh. אם שרת ה-proxy של Envoy פועל במכונה וירטואלית ב-Compute Engine שאין לה כתובת IP חיצונית או באשכול GKE פרטי, צריך להגדיר גישה פרטית ל-Google ברשת המשנה כדי לקבל גישה לממשקי API ולשירותים של Google.

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