‫Anthos Service Mesh ו-Traffic Director נקראים עכשיו Cloud Service Mesh. מידע נוסף זמין בסקירה הכללית על Cloud Service Mesh.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

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

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

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

הגדרת נקודת קצה ל-API של `network-services`

לפני שיוצרים שירות לקצה העורפי ומשתמשים בו, צריך לוודא שנקודת קצה ל-API‏ network-services מוגדרת כך שהמשאבים של כבילת השירות שמופיעים בקטע network-servicesresources מפנים למקום הנכון. מגדירים את נקודת הקצה של 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, אפשר להשתמש במנגנונים אחרים:

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

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

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

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

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

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

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

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

יצירת השילוב

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

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

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

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

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

יוצרים כבילת שירות שמפנה לשירות 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

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

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 שיצרתם בקטע הקודם.

יוצרים את המפרט 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"

מייבאים את המפרט 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, שיצרתם בשלב הקודם.
בשלב הבא, מוסיפים כלל host למפת URL. כלל המארח הזה גורם לשימוש בכלי להתאמת נתיבים אם בקשה מציינת את שם המארח myservice.example.com.

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

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

ממפים את שירות לקצה העורפי לכלל מארח חדש במפת 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 לאותו שירות לקצה העורפי. לדוגמה, יכול להיות שיש לכם שני שירותים בספריית השירותים, שכל אחד מהם זהה לשני, אבל עם נקודות קצה באזורים או באזורים שונים. Google Cloud במילים אחרות, לשירות קצה עורפי גלובלי יחיד יכולים להיות שני קישורי שירות גלובליים, שאחד מהם מצביע על שירות ב-us-east1 והשני מצביע על שירות ב-us-west1.

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

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

יוצרים קישור שירות לשירות 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 \

יוצרים קישור שירות לשירות 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 \

מאגדים את השירותים 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, שיכול לשלוח תנועה לשירות קצה עורפי אחר כשהבקשה מעובדת. התהליך הזה נקרא גם העתקת בקשה, והוא מאפשר לכם לבדוק את התנועה בלי להשפיע על שירותי הייצור.

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

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

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

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

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

יוצרים כבילת שירות שמפנה לשירות 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 \

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

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

עורכים את מפת ה-URL כדי לשקף בקשות לשירות הבדיקה.
```
gcloud compute url-maps edit my-url-map \
  --region=global
```

אחרי שהגדרת מפת 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.

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

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