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

הוספת עומסי עבודה של 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 של קובץ עזר חיצוני

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

הזרקה אוטומטית של שרת proxy מסוג קובץ עזר חיצוני (הזרקה אוטומטית) מתרחשת כש-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
מפעילים מחדש את הפודים המושפעים באמצעות השלבים שמתוארים בקטע הבא.

מוסיפים את ההערה הבאה למרחב השמות 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 מצוין שיש שני מאגרים לכל עומס עבודה: המאגר הראשי והמאגר של קובץ העזר החיצוני.
```
NAME                    READY   STATUS    RESTARTS   AGE
WORKLOAD           2/2     Running   0          20s
...
```

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

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

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

מנוהל (TD)

מנוהל (Istiod)

בתוך האשכול

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

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

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

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

מנוהל (TD)

מנוהל (Istiod)

בתוך האשכול

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