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

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

הוספת עומסי עבודה של Kubernetes

בדף הזה מוסבר איך להוסיף עומסי עבודה של Kubernetes ל-Cloud Service Mesh.

פריסת שירותי Kubernetes

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

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

הדוגמה הבאה של פריסה ושירות ממחישה את הדרישות האלה:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloserver
  template:
    metadata:
      labels:
        app: helloserver
    spec:
      containers:
      - image: gcr.io/google-samples/istio/helloserver:v0.0.1
        imagePullPolicy: Always
        name: main
      restartPolicy: Always
      terminationGracePeriodSeconds: 5

apiVersion: v1
kind: Service
metadata:
  name: hellosvc
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: helloserver
  type: LoadBalancer

אחרי פריסת השירותים באשכול עם Cloud Service Mesh, חשוב להוסיף פרוקסי מסוג sidecar.

דוגמה: פריסת הדוגמה של Online Boutique

אפליקציית הדוגמה Online Boutique במאגר anthos-service-mesh-packages שונתה מהקבוצה המקורית של קובצי המניפסט במאגר microservices-demo. בהתאם לשיטות המומלצות, כל שירות נפרס במרחב שמות נפרד עם חשבון שירות ייחודי.

יוצרים את מרחבי השמות של האפליקציה:

kubectl apply -f \
  DIR_PATH/samples/online-boutique/kubernetes-manifests/namespaces

הפלט אמור להיראות כך:

namespace/ad created
namespace/cart created
namespace/checkout created
namespace/currency created
namespace/email created
namespace/frontend created
namespace/loadgenerator created
namespace/payment created
namespace/product-catalog created
namespace/recommendation created
namespace/shipping created

מפעילים את מרחבי השמות להחדרה. השלבים תלויים בהטמעה של מישור הבקרה.
מנוהל (TD)
מחילים את תווית ההזרקה שמוגדרת כברירת מחדל על מרחב השמות:
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns \ istio.io/rev- istio-injection=enabled --overwrite done;
מנוהל (Istiod)
מומלץ: מריצים את הפקודה הבאה כדי להחיל את תווית ברירת המחדל של הזרקה על מרחב השמות:
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns \ istio.io/rev- istio-injection=enabled --overwrite done;
אם אתם משתמשים קיימים במישור הבקרה המנוהל של Istiod: מומלץ להשתמש בהזרקה שמוגדרת כברירת מחדל, אבל יש תמיכה גם בהזרקה מבוססת-עדכון. פועלים לפי ההוראות הבאות:
1. מריצים את הפקודה הבאה כדי לאתר את ערוצי ההפצה הזמינים:
  
  kubectl -n istio-system get controlplanerevision
  
  הפלט אמור להיראות כך:
  
  NAME AGE asm-managed-rapid 6d7h
  הערה: אם מופיעות שתי גרסאות של מישור הבקרה ברשימה הקודמת, צריך להסיר אחת מהן. אין תמיכה בכמה ערוצי מישור בקרה באשכול.
  
  בפלט, הערך בעמודה NAME הוא תווית הגרסה שתואמת לערוץ ההפצה שזמין לגרסה של Cloud Service Mesh.
2. החלת תווית הגרסה על מרחב השמות:
  
  for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite done;
באשכול
מומלץ: מריצים את הפקודה הבאה כדי להחיל את תווית ברירת המחדל של הזרקה על מרחב השמות:
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns \ istio.io/rev- istio-injection=enabled --overwrite done;
מומלץ להשתמש בהחדרה שמוגדרת כברירת מחדל, אבל יש תמיכה גם בהחדרה שמבוססת על עדכון: פועלים לפי ההוראות הבאות:
1. משתמשים בפקודה הבאה כדי לאתר את תווית הגרסה ב-istiod:
  
  kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
2. מחילים את תווית הגרסה על מרחב השמות. בפקודה הבאה, REVISION_LABEL הוא הערך של התווית istiod revision שרשמתם בשלב הקודם.
  
  for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite done;

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

יוצרים את חשבונות השירות ואת הפריסות:

kubectl apply -f \
 DIR_PATH/samples/online-boutique/kubernetes-manifests/deployments

הפלט אמור להיראות כך:

serviceaccount/ad created
deployment.apps/adservice created
serviceaccount/cart created
deployment.apps/cartservice created
serviceaccount/checkout created
deployment.apps/checkoutservice created
serviceaccount/currency created
deployment.apps/currencyservice created
serviceaccount/email created
deployment.apps/emailservice created
serviceaccount/frontend created
deployment.apps/frontend created
serviceaccount/loadgenerator created
deployment.apps/loadgenerator created
serviceaccount/payment created
deployment.apps/paymentservice created
serviceaccount/product-catalog created
deployment.apps/productcatalogservice created
serviceaccount/recommendation created
deployment.apps/recommendationservice created
serviceaccount/shipping created
deployment.apps/shippingservice created

יוצרים את השירותים:

kubectl apply -f \
 DIR_PATH/samples/online-boutique/kubernetes-manifests/services

הפלט אמור להיראות כך:

service/adservice created
service/cartservice created
service/checkoutservice created
service/currencyservice created
service/emailservice created
service/frontend created
service/frontend-external created
service/paymentservice created
service/productcatalogservice created
service/recommendationservice created
service/shippingservice created

יוצרים את רשומות השירות:

kubectl apply -f \
 DIR_PATH/samples/online-boutique/istio-manifests/allow-egress-googleapis.yaml

הפלט אמור להיראות כך:

serviceentry.networking.istio.io/allow-egress-googleapis created
serviceentry.networking.istio.io/allow-egress-google-metadata created

יציאות של שירות שמות

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

apiVersion: v1
kind: Service
metadata:
  name: ratings
  labels:
    app: ratings
    service: ratings
spec:
  ports:
  - port: 9080
    name: http

שם יציאת השירות יכול לכלול סיומת בתחביר הבא: name: protocol[-suffix] כאשר הסוגריים המרובעים מציינים סיומת אופציונלית שחייבת להתחיל במקף, לדוגמה:

kind: Service
metadata:
  name: myservice
spec:
  ports:
  - number: 3306
    name: mysql
  - number: 80
    name: http-web

כדי שהמדדים יוצגו במסוף Google Cloud , צריך לתת לשמות של יציאות השירות אחד מהפרוטוקולים הבאים: http,‏ http2 או grpc. יציאות שירות שנקראות על שם הפרוטוקול https נחשבות ל-tcp, והמדדים של השירותים האלה לא מוצגים.

החדרת שרתי proxy של קובץ עזר חיצוני

בקטע הזה מוסבר איך להגדיר הזרקת פרוקסי של Sidecar באמצעות Cloud Service Mesh כדי לשפר את אבטחת הרשת, המהימנות והניראות (observability). הפונקציות האלה מופשטות מהקונטיינר הראשי של האפליקציה ומיושמות ב-Proxy נפוץ מחוץ לתהליך (sidecar), שמועבר כקונטיינר נפרד באותו Pod. אתם יכולים להשתמש בתכונות של Cloud Service Mesh בלי לעצב מחדש את אפליקציות הייצור כדי להשתתף ב-Service Mesh.

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

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

כדי לבצע את המשימות שמתוארות בדף הזה, צריך להיות לכם תפקיד roles/container.clusterAdmin או תפקיד גבוה יותר. במאמר תפקידים ב-Google Kubernetes Engine מפורטות ההרשאות שכלולות בתפקיד הזה.

הפעלת הזרקה אוטומטית של קובץ sidecar

מפעילים את מרחב השמות להחדרה. השלבים תלויים בהטמעה של מישור הבקרה.
מנוהל (TD)
1. מחילים את תווית ההזרקה שמוגדרת כברירת מחדל על מרחב השמות:
kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
מנוהל (Istiod)
מומלץ: מריצים את הפקודה הבאה כדי להחיל את תווית ברירת המחדל של הזרקה על מרחב השמות:
kubectl label namespace NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
אם אתם משתמשים קיימים במישור הבקרה המנוהל של Istiod: מומלץ להשתמש בהזרקה שמוגדרת כברירת מחדל, אבל יש תמיכה גם בהזרקה מבוססת-עדכון. פועלים לפי ההוראות הבאות:
1. מריצים את הפקודה הבאה כדי לאתר את ערוצי ההפצה הזמינים:
  
  kubectl -n istio-system get controlplanerevision
  
  הפלט אמור להיראות כך:
  
  NAME AGE asm-managed-rapid 6d7h
  
  הערה: אם ברשימה שלמעלה מופיעות שתי גרסאות של מישור הבקרה, צריך להסיר אחת מהן. אין תמיכה בכמה ערוצי מישור בקרה באשכול.
  
  בפלט, הערך בעמודה NAME הוא תווית הגרסה שתואמת לערוץ ההפצה שזמין לגרסה של Cloud Service Mesh.
2. החלת תווית הגרסה על מרחב השמות:
  
  kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
באשכול
מומלץ: מריצים את הפקודה הבאה כדי להחיל את תווית ברירת המחדל של הזרקה על מרחב השמות:
kubectl label namespace NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
מומלץ להשתמש בהחדרה שמוגדרת כברירת מחדל, אבל יש תמיכה גם בהחדרה שמבוססת על עדכון: פועלים לפי ההוראות הבאות:
1. משתמשים בפקודה הבאה כדי לאתר את תווית הגרסה ב-istiod:
  
  kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
2. מחילים את תווית הגרסה על מרחב השמות. בפקודה הבאה, REVISION_LABEL הוא הערך של התווית istiod revision שרשמתם בשלב הקודם.
  
  kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
מפעילים מחדש את ה-pods המושפעים באמצעות השלבים שמתוארים בקטע הבא.

מוסיפים הערה למרחב השמות demo באופן הבא:

kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'

הפעלה מחדשת של ה-Pods כדי לעדכן את ה-sidecar proxies

בעזרת הזרקת sidecar אוטומטית, אפשר לעדכן את ה-sidecars של פודים קיימים על ידי הפעלה מחדש של הפוד:

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

אם השתמשתם בפריסה, מפעילים מחדש את הפריסה, שמפעילה מחדש את כל ה-Pods עם sidecars:
```
kubectl rollout restart deployment -n NAMESPACE
```
אם לא השתמשתם בפריסה, מוחקים את ה-Pods והם נוצרים מחדש באופן אוטומטי עם sidecars:
```
kubectl delete pod -n NAMESPACE --all
```
בודקים שכל ה-Pods במרחב השמות כוללים sidecars מוזרקים:
```
kubectl get pod -n NAMESPACE
```
בדוגמה הבאה של פלט מהפקודה הקודמת, אפשר לראות שבעמודה READY מצוין שיש שני קונטיינרים לכל עומס עבודה: הקונטיינר הראשי וקובץ העזר החיצוני של ה-sidecar proxy.
```
NAME                    READY   STATUS    RESTARTS   AGE
WORKLOAD           2/2     Running   0          20s
...
```

הוספת עומסי עבודה של Kubernetes

פריסת שירותי Kubernetes

דוגמה: פריסת הדוגמה של Online Boutique

מנוהל (TD)

מנוהל (Istiod)

באשכול

יציאות של שירות שמות

החדרת שרתי proxy של קובץ עזר חיצוני

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

הפעלת הזרקה אוטומטית של קובץ sidecar

מנוהל (TD)

מנוהל (Istiod)

באשכול

הפעלה מחדשת של ה-Pods כדי לעדכן את ה-sidecar proxies