הגדרת שילוב עם Service Directory

במדריך הזה אנחנו מניחים שיש לכם פריסה פעילה של Cloud Service Mesh ושרשמתם לפחות שירות אחד ב-Service Directory. הוראות ההגדרה רלוונטיות גם אם משתמשים ב-Envoy וגם אם משתמשים ב-gRPC ללא proxy.

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

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

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

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

  1. מוודאים שכלל ההעברה של Cloud Service Mesh משתמש ב0.0.0.0כתובת IP וירטואלית (VIP).
  2. אם יש לכם אזור פרטי, ודאו שכלל המארח במפת URL תואם לשם ה-DNS ש-Service Directory מגדיר באזור הפרטי של Cloud DNS.

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

הגדרת נקודת קצה ל-APInetwork-services

לפני שיוצרים שירות לקצה העורפי ומשתמשים בו, צריך לוודא שנקודת הקצה של API‏ network-services מוגדרת כך שהמשאבים של כבילות השירותים ב-network-services resources מפנים למקום הנכון. מגדירים את נקודת קצה ל-network-services API באמצעות הפקודה הבאה.

export CLOUDSDK_API_ENDPOINT_OVERRIDES_NETWORKSERVICES="https://networkservices.googleapis.com/"

דרישות לגבי תפקידים והרשאות

לפני שיוצרים פריסה של Cloud Service Mesh, צריך לוודא שיש לכם את ההרשאות והתפקידים הבאים:

הרשאות ותפקידים של כבילת שירות

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

פעולה הרשאה תפקידים
יוצרים כבילת שירות. networkservices.serviceBindings.create אדמין רשתות
אחזור של כבילת שירות. networkservices.serviceBindings.get אדמין רשתות, צפייה ברשת
הצגת רשימה של שירותים שמקושרים לפרויקט ב- Google Cloud . networkservices.serviceBindings.list אדמין רשתות, צפייה ברשת
עדכון של קישורי שירות. networkservices.serviceBindings.update אדמין רשתות
מחיקת קישורי שירות. networkservices.serviceBindings.delete אדמין רשתות

הרשאות שירות של Service Directory

האדמין של Service Directory צריך להעניק את ההרשאה servicedirectory.services.bind לחשבון השירות שמנסה לצרף את הקישור לשירות לשירות Service Directory. כך חשבון השירות יכול להשתמש בשירות Service Directory, כלומר הוא יכול להפנות לשירות Service Directory בהתקשרות לשירות.

אכיפת הרשאות

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

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

כדי למנוע מלקוח רשת Mesh לתקשר עם שירות Service Directory, אפשר להשתמש במנגנונים אחרים:

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

שיטות מומלצות

שימוש ב-Service Directory לזיהוי שירותים

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

פרטי ההגדרה לשימוש ב-Service Directory לזיהוי שירותים.
פרטי ההגדרה לשימוש ב-Service Directory לגילוי שירותים (לחצו כדי להגדיל)

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

  1. יוצרים שירות קצה עורפי חדש ב-Cloud Service Mesh ולא יוצרים קצה עורפי לשירות הקצה העורפי.
  2. יוצרים קישור גלובלי לשירות Service Directory.

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

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

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

יצירת השילוב

במאמר הזה מוסבר איך לשלב את Cloud Service Mesh עם Service Directory.

יצירת שירות לקצה העורפי

כדי ליצור שירות לקצה העורפי בפריסת Cloud Service Mesh:

  1. יוצרים שירות לקצה העורפי לשימוש עם שירותי Service Directory.

    gcloud compute backend-services create td-sd-demo-service \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED

  2. יוצרים כבילת שירות שמפנה לשירות Service Directory.

    gcloud beta network-services service-bindings create my-sd-binding \
 --location global \
 --service-directory-region us-east1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service

  3. מקשרים את השירות לשירות הקצה העורפי.

    gcloud beta compute backend-services update td-sd-demo-service \
 --global \
 --service-bindings my-sd-binding

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

הגדרת ניתוב

כדי לעדכן את הגדרות הניתוב, פועלים לפי ההוראות הבאות.

ממשקי API לניתוב שירותים

בדוגמה הבאה אנחנו מניחים שיש לכם משאב Mesh בשם sidecar- mesh. יוצרים משאב HTTPRoute עם שמות מארחים שמוגדרים ל-myservice.example.com ויעד שמוגדר לשירות הקצה העורפי td-sd-demo-service שיצרתם בקטע הקודם.

  1. יוצרים את המפרט HTTPRoute ושומרים אותו בקובץ בשם httproute.yaml.

    name: td-sd-demo-route
hostnames:
‐ myservice.example.com
meshes:
‐ projects/PROJECT_NUMBER/locations/global/meshes/sidecar-mesh
rules:
‐ action:
  destinations:
  ‐ serviceName: "projects/PROJECT_NUMBER/locations/global/backendServices/td-sd-demo-service"

  2. מייבאים את המפרט של HTTPRoute.

    gcloud network-services httproutes import td-sd-demo-route \
  --source=httproute.yaml \
  --location=global

Load balacing APIs

בדוגמה הבאה מניחים שכבר יש לכם הגדרת ניתוב בסיסית, כולל מפת URL שנקראת my-url-map.

  • קודם יוצרים התאמה למסלול עבור מפת ה-URL הזו. התאמת הנתיבים לא מסובכת. כשמשתמשים בו, הוא מומר ל-td-sd-demo-service, שיצרתם בשלב הקודם.
  • בשלב הבא, מוסיפים כלל מארח למפת URL. כלל המארח הזה גורם לשימוש בכלי להתאמת נתיבים אם בקשה מציינת את שם המארח myservice.example.com.

  1. יוצרים התאמה פשוטה של נתיבים שמפנה לשירות הקצה העורפי.

    gcloud compute url-maps add-path-matcher my-url-map \
 --global \
 --default-service td-sd-demo-service \
 --path-matcher-name my-path-matcher

  2. ממפים את שירות לקצה העורפי לכלל מארח חדש במפת URL הקיימת.

    gcloud compute url-maps add-host-rule my-url-map \
 --global \
 --path-matcher-name=my-path-matcher \
 --hosts=myservice.example.com

צירוף אותו שירות מכמה אזורים

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

  1. יוצרים שירות לקצה העורפי בשביל השירות שיובא ל-Service Directory.

    gcloud compute backend-services create td-sd-demo-service \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED

  2. יוצרים קישור שירות לשירות Service Directory ב-us-east1.

    gcloud beta network-services service-bindings create us-east1-binding \
 --location global \
 --service-directory-region us-east1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service \

  3. יוצרים קישור שירות לשירות Service Directory ב-us-west1.

    gcloud beta network-services service-bindings create us-west1-binding \
 --location global
 --service-directory-region us-west1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service \

  4. מאגדים את השירותים us-east1 ו-us-west1 לשירות הקצה העורפי.

    gcloud compute backend-services update td-sd-demo-service \
  --global \
  --service-bindings us-east1-binding,us-west1-binding

החלת מדיניות מתקדמת לניהול תעבורת נתונים

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

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

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

שימוש ב-Service Directory לזיהוי שירותים עם שיקוף.
שימוש ב-Service Directory לגילוי שירותים עם שיקוף(לחצו כדי להגדיל)

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

  1. יוצרים שירות לקצה העורפי למדיניות שיקוף הבקשות.

    gcloud compute backend-services create payments-test-bes \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED

  2. יוצרים כבילת שירות שמפנה לשירות Service Directory.

    gcloud beta network-services service-bindings create my-sd-binding \
 --location global \
 --service-directory-region us-east1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service \

  3. מאגדים את שירות Service Directory לשירות הקצה העורפי לבדיקה.

    gcloud beta compute backend-services update payments-test-bes \
 --global \
 --service-bindings my-sd-binding

  4. עורכים את מפת כתובות ה-URL כדי לשקף בקשות לשירות הבדיקה.

    gcloud compute url-maps edit my-url-map \
  --region=global

  5. אחרי שהגדרת מפת URL נטענת לעורך, מוסיפים את מדיניות שיקוף הבקשות כדי לשקף בקשות לשירות הקיים של Service Directory.

    defaultService: my-project/global/default-service
   hostRules:
    - hosts:
      - '*'
      pathMatcher: path-matcher-one
   pathMatchers:
    - defaultService: my-project/global/default-service
     name: path-matcher-one
     pathRules:
      - paths:
        - /payments/
        service: my-project/global/default-service
        requestMirrorPolicy:
          backendService: myproject/global/payments-test-bes

הסרת קישור שירות משירות קצה עורפי

כדי להסיר שירות מקשור משירות הקצה העורפי, מעבירים רשימה חדשה של שירותים מקושרים לפקודה gcloud compute backend-services update. הרשימה החדשה לא יכולה לכלול את קישור השירות שרוצים למחוק:

  • כדי להסיר את כל הקישורים לשירותים, מגדירים את הדגל --no-service-bindings.
  • כדי להסיר קישורי שירות אחד או יותר: מעבירים רשימה חדשה של קישורי שירות שבה לא מופיעים קישורי השירות שרוצים להסיר, אל הדגל --service-bindings.

הוספה או הסרה של שיוכים לשירותים

הפקודה bind-service מוסיפה כבילת שירות לקבוצה של כבילות שירות קיימות בשירות לקצה העורפי.

gcloud compute backend-services bind-service BACKEND_SERVICE_NAME \
  --service-binding-name SERVICE_BINDING_URL \
  --global

הפקודה unbind-service מסירה כבילת שירות ממערך כבילות השירות הקיימות בשירות לקצה העורפי.

gcloud compute backend-services unbind-service BACKEND_SERVICE_NAME \
  --service-binding-name SERVICE_BINDING_URL \
  --global

הפקודות bind-service ו-unbind-service הן מבנים של Google Cloud CLI. הם לא מבנים ברמת ה-API.

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