הגדרה של פודים ב-Google Kubernetes Engine באמצעות הזרקה אוטומטית של Envoy

סקירה כללית

ב-service mesh, קוד האפליקציה לא צריך לדעת על הגדרות הרשת. במקום זאת, האפליקציות שלכם מתקשרות דרך מישור נתונים, שמוגדר על ידי מישור בקרה שמטפל ברשת השירות. במדריך הזה, Cloud Service Mesh הוא מישור הבקרה, ופרוקסי Envoy sidecar הם מישור הנתונים.

הכלי להוספת Envoy sidecar ש-Google מנהלת מוסיף פרוקסי Envoy sidecar ל-Pods שלכם ב-Google Kubernetes Engine. כש-Envoy sidecar injector מוסיף שרת proxy, הוא גם מגדיר את השרת הזה לטיפול בתנועת נתונים של אפליקציות ולחיבור ל-Cloud Service Mesh לצורך הגדרה.

במדריך מוסבר איך להגדיר בקלות את Cloud Service Mesh באמצעות Google Kubernetes Engine. השלבים האלה מספקים את הבסיס שאפשר להרחיב לתרחישי שימוש מתקדמים, כמו Service mesh שמתפרס על פני כמה אשכולות של Google Kubernetes Engine, ואולי גם על מכונות וירטואליות של Compute Engine. אפשר גם להשתמש בהוראות האלה אם אתם מגדירים את Cloud Service Mesh עם VPC משותף.

תהליך ההגדרה כולל:

1. יצירת אשכול GKE לעומסי העבודה.
2. התקנת Envoy sidecar injector והפעלת ההחדרה.
3. פריסת לקוח לדוגמה ואימות ההחדרה.
4. פריסת שירות Kubernetes לצורך בדיקה.
5. הגדרת Cloud Service Mesh עם רכיבי Cloud Load Balancing להפניית תנועה לשירות הבדיקה.
6. בודקים את ההגדרה על ידי שליחת בקשה מלקוח לדוגמה לשירות הבדיקה.

דרישות מוקדמות

לפני שמבצעים את ההוראות במדריך הזה, צריך להשלים את המשימות המקדימות שמתוארות במאמר הכנה להגדרה של ממשקי API לניתוב שירותים באמצעות Envoy ועומסי עבודה בלי שרת Proxy.

מידע על גרסת Envoy הנתמכת זמין בהערות הגרסה של Cloud Service Mesh.

דרישות מוקדמות נוספות ל-VPC משותף

אם אתם מגדירים את Cloud Service Mesh בסביבת VPC משותף, חשוב לוודא את הדברים הבאים.

• יש לכם את ההרשאות והתפקידים הנכונים ל-VPC משותף.
• הגדרתם את הפרויקטים והחיוב בצורה נכונה.
• הפעלתם את החיוב בפרויקטים.
• הפעלתם את ממשקי ה-API של Cloud Service Mesh ו-GKE בכל פרויקט, כולל פרויקט המארח.
• הגדרתם את חשבונות השירות הנכונים לכל פרויקט.
• יצרתם רשתות VPC ותת-רשתות.
• הפעלתם VPC משותף.

מידע נוסף זמין במאמר בנושא VPC משותף.

הגדרת תפקידים ב-IAM

בדוגמה הזו של הגדרת תפקיד IAM, יוצאים מנקודת הנחה שלפרויקט המארח של ה-VPC המשותף יש שתי תת-רשתות, ושב-VPC המשותף יש שני פרויקטים של שירותים.

1. ב-Cloud Shell, יוצרים תיקיית עבודה (WORKDIR)) שבה יוצרים את הקבצים שמשויכים לקטע הזה:

   mkdir -p ~/td-shared-vpc
   cd ~/td-shared-vpc
   export WORKDIR=$(pwd)
   

2. מגדירים הרשאות IAM בפרויקט המארח כדי שפרויקטי שירות יוכלו להשתמש במשאבים ב-VPC המשותף.

   בשלב הזה מגדירים את הרשאות ה-IAM כך שפרויקט שירות 1 יוכל לגשת אל subnet-1 ופרויקט שירות 2 יוכל לגשת אל subnet-2. מקצים את התפקיד 'משתמש ברשת של Compute' ב-IAM (roles/compute.networkUser) לחשבון השירות שמשמש כברירת מחדל של Compute Engine ולחשבון השירות של API ‏( Google Cloud ) בכל פרויקט שירות לכל רשת משנה.

   1. בפרויקט שירות 1, מגדירים הרשאות IAM עבור subnet-1:

      export SUBNET_1_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-1 --project ${HOST_PROJECT} --region ${REGION_1} --format=json | jq -r '.etag')
      
      cat > subnet-1-policy.yaml <<EOF
      bindings:
      - members:
        - serviceAccount:${SVC_PROJECT_1_API_SA}
        - serviceAccount:${SVC_PROJECT_1_GKE_SA}
        role: roles/compute.networkUser
      etag: ${SUBNET_1_ETAG}
      EOF
      
      gcloud beta compute networks subnets set-iam-policy subnet-1 \
      subnet-1-policy.yaml \
          --project ${HOST_PROJECT} \
          --region ${REGION_1}
      

   2. בפרויקט שירות 2, מגדירים הרשאות IAM עבור subnet-2:

      export SUBNET_2_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-2 --project ${HOST_PROJECT} --region ${REGION_2} --format=json | jq -r '.etag')
      
      cat > subnet-2-policy.yaml <<EOF
      bindings:
      - members:
        - serviceAccount:${SVC_PROJECT_2_API_SA}
        - serviceAccount:${SVC_PROJECT_2_GKE_SA}
        role: roles/compute.networkUser
      etag: ${SUBNET_2_ETAG}
      EOF
      
      gcloud beta compute networks subnets set-iam-policy subnet-2 \
      subnet-2-policy.yaml \
          --project ${HOST_PROJECT} \
          --region ${REGION_2}
      

3. בכל פרויקט שירות, צריך להעניק לחשבון השירות של GKE בפרויקט המארח את התפקיד Kubernetes Engine Host Service Agent User IAM ‏(roles/container.hostServiceAgentUser):

   gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
       --member serviceAccount:${SVC_PROJECT_1_GKE_SA} \
       --role roles/container.hostServiceAgentUser
   
   gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
       --member serviceAccount:${SVC_PROJECT_2_GKE_SA} \
       --role roles/container.hostServiceAgentUser
   

   התפקיד הזה מאפשר לחשבון השירות של GKE בפרויקט השירות להשתמש בחשבון השירות של GKE בפרויקט המארח כדי להגדיר משאבי רשת משותפים.

4. בכל פרויקט שירות, מקצים לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine את התפקיד Compute Network Viewer ב-IAM ‏(roles/compute.networkViewer) בפרויקט המארח.

   gcloud projects add-iam-policy-binding ${SVC_PROJECT_1} \
       --member serviceAccount:${SVC_PROJECT_1_COMPUTE_SA} \
       --role roles/compute.networkViewer
   
   gcloud projects add-iam-policy-binding ${SVC_PROJECT_2} \
       --member serviceAccount:${SVC_PROJECT_2_COMPUTE_SA} \
       --role roles/compute.networkViewer
   

   כששרת ה-proxy של Envoy sidecar מתחבר לשירות xDS (Traffic Director API), שרת ה-proxy משתמש בחשבון השירות של המכונה הווירטואלית (VM) המארחת ב-Compute Engine או של מופע הצומת ב-GKE. לחשבון השירות צריכה להיות הרשאת IAM ברמת הפרויקט compute.globalForwardingRules.get. התפקיד 'בעל הרשאת צפייה' ברשת Compute מספיק בשביל השלב הזה.

הגדרת פרטי הפרויקט

אם עדיין לא יצרתם Google Cloud פרויקט או התקנתם את Google Cloud CLI, אתם יכולים לפעול לפי ההוראות האלה. אם עדיין לא התקנתם את kubectl, אתם יכולים לפעול לפי ההוראות האלה.

# The project that contains your GKE cluster.
export CLUSTER_PROJECT_ID=YOUR_CLUSTER_PROJECT_ID_HERE
# The name of your GKE cluster.
export CLUSTER=YOUR_CLUSTER_NAME
# The channel of your GKE cluster. Eg: rapid, regular, stable. This channel
# should correspond to the channel for your GKE cluster. If your GKE cluster
# does not have a specified channel, please use unspecified in this field.
export CHANNEL=YOUR_CLUSTER_CHANNEL
# The location of your GKE cluster, Eg: us-central1 for regional GKE cluster,
# us-central1-a for zonal GKE cluster
export LOCATION=ZONE

# The network name of the traffic director load balancing API.
export MESH_NAME=default
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_MESH_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/global/networks/${MESH_NAME}

gcloud config set project ${CLUSTER_PROJECT_ID}

אם אתם משתמשים בממשקי ה-API החדשים לניתוב שירותים, כדי להגדיר MESH_NAME, ‏ MESH_PROJECT_NUMBER ו-TARGET עבור משאב Mesh, אתם יכולים להיעזר בהוראות הבאות:

# The mesh name of the traffic director load balancing API.
export MESH_NAME=YOUR_MESH_NAME
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_MESH_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/locations/global/meshes/${MESH_NAME}

בשביל משאב שער, פועלים לפי ההוראות הבאות כדי להגדיר את SCOPE_NAME,‏ SCOPE_PROJECT_NUMBER ו-TARGET:

# The gateway scope name of the traffic director load balancing API.
export SCOPE_NAME=YOUR_SCOPE_NAME
# The project that holds the gateway resources.
export SCOPE_PROJECT_NUMBER=YOUR_GATEWAY_PROJECT_NUMBER_HERE

export TARGET=projects/${SCOPE_PROJECT_NUMBER}/locations/global/gatewayScopes/${SCOPE_NAME}

ברוב התרחישים, CLUSTER_PROJECT_ID וMESH_PROJECT_NUMBER מתייחסים לאותו פרויקט. אבל אם הגדרתם פרויקט אחר, למשל כשמשתמשים ב-VPC משותף, CLUSTER_PROJECT_ID מתייחס למזהה הפרויקט שמכיל את אשכול GKE, ו-MESH_PROJECT_NUMBER מתייחס למספר הפרויקט שמכיל את המשאבים. מוודאים שהגדרתם את ההרשאות המתאימות כדי לאפשר ל-Envoy המוזרק לאחזר הגדרות מה

הפעלת Mesh Config API

כדי להתחיל להשתמש ב-Google managed sidecar injector, צריך להפעיל את ה-API הבא.

gcloud services enable --project=${CLUSTER_PROJECT_ID} meshconfig.googleapis.com

יצירת אשכול GKE לעומסי העבודה

כדי לתמוך ב-Cloud Service Mesh, אשכולות GKE צריכים לעמוד בדרישות הבאות:

• צריך להפעיל את התמיכה בקבוצות של נקודות קצה ברשת. מידע נוסף ודוגמאות זמינים במאמר Standalone network endpoint groups (קבוצות עצמאיות של נקודות קצה ברשת).
• לחשבון השירות של הצמתים או הפודים ב-GKE צריכה להיות הרשאה לגשת ל-Traffic Director API. מידע נוסף על ההרשאות הנדרשות זמין במאמר הפעלת הגישה של חשבון השירות ל-Traffic Director API.

יצירת אשכול GKE

יוצרים אשכול GKE באזור המועדף, לדוגמה, us-central1-a.

gcloud container clusters create YOUR_CLUSTER_NAME \
  --zone ZONE \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

הפניית kubectl לאשכול החדש שנוצר

כדי לשנות את ההקשר הנוכחי של kubectl לאשכול החדש שנוצר, מריצים את הפקודה הבאה:

gcloud container clusters get-credentials traffic-director-cluster \
    --zone ZONE

החלת ההגדרות של Mutating Webhook

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

מחילים על האשכול את ההגדרות הבאות של webhook לשינוי.

cat <<EOF | kubectl apply -f -
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  labels:
    app: sidecar-injector
  name: td-mutating-webhook
webhooks:
- admissionReviewVersions:
  - v1beta1
  - v1
  clientConfig:
    url: https://meshconfig.googleapis.com/v1internal/projects/${CLUSTER_PROJECT_ID}/locations/${LOCATION}/clusters/${CLUSTER}/channels/${CHANNEL}/targets/${TARGET}:tdInject
  failurePolicy: Fail
  matchPolicy: Exact
  name: namespace.sidecar-injector.csm.io
  namespaceSelector:
    matchExpressions:
    - key: td-injection
      operator: Exists
  reinvocationPolicy: Never
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods
    scope: '*'
  sideEffects: None
  timeoutSeconds: 30
EOF

הפעלת החדרת sidecar

הפקודה הבאה מפעילה הזרקה למרחב השמות default. הכלי להחדרת sidecar מחדיר קונטיינרים של sidecar לפודים שנוצרו במרחב השמות הזה:

kubectl label namespace default td-injection=enabled

כדי לוודא שהמרחב לשמות default מופעל כמו שצריך, מריצים את הפקודה הבאה:

kubectl get namespace -L td-injection

הפלט צריך להיות:

NAME              STATUS   AGE     TD-INJECTION
default           Active   7d16h   enabled

אם אתם מגדירים אבטחת שירות ל-Cloud Service Mesh עם Envoy, אתם צריכים לחזור לקטע הגדרת שירות בדיקה במדריך ההגדרה.

פריסת לקוח לדוגמה ואימות ההחדרה

בקטע הזה מוסבר איך פורסים פוד לדוגמה שמריץ Busybox, שמספק ממשק פשוט להגעה לשירות בדיקה. בהטמעה אמיתית, צריך להטמיע אפליקציית לקוח משלכם.

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: client
  name: busybox
spec:
  replicas: 1
  selector:
    matchLabels:
      run: client
  template:
    metadata:
      labels:
        run: client
    spec:
      containers:
      - name: busybox
        image: busybox
        command:
        - sh
        - -c
        - while true; do sleep 1; done
EOF

ה-pod של Busybox מורכב משני קונטיינרים. הקונטיינר הראשון הוא הלקוח שמבוסס על תמונת Busybox, והקונטיינר השני הוא פרוקסי Envoy שמוזרק על ידי sidecar injector. כדי לקבל מידע נוסף על ה-pod, מריצים את הפקודה הבאה:

kubectl describe pods -l run=client

הפלט צריך להיות:

…
Init Containers:
# Istio-init sets up traffic interception for the pod.
  Istio-init:
…
Containers:
# busybox is the client container that runs application code.
  busybox:
…
# Envoy is the container that runs the injected Envoy proxy.
  envoy:
…

Cloud Service Mesh Proxy

הכלי המנוהל להוספת sidecar ישתמש בתמונה של Cloud Service Mesh Proxy כשרת proxy. ה-Proxy של Cloud Service Mesh הוא קונטיינר sidecar שאחראי להפעלת Envoy Proxy עבור מופעים שמופעל בהם Mesh. תמונת ה-proxy משתמשת בתמונת ה-OSS envoy יחד עם סוכן proxy שאחראי להפעלת ה-envoy, לספק תצורת bootstrap ולבצע בדיקות תקינות של ה-envoy. גרסאות התמונות של Cloud Service Mesh Proxy תואמות לגרסת ה-OSS Envoy. אפשר לעקוב אחרי תמונות ה-proxy הזמינות כאן: https://gcr.io/gke-release/asm/csm-mesh-proxy

שרת ה-proxy של Cloud Service Mesh שמוזרק משתנה בהתאם לערוץ שהמשתמש בחר עבור אשכול GKE. גרסת Envoy מתעדכנת באופן קבוע על סמך הגרסאות הנוכחיות של Envoy ב-OSS, ונבדקת עם הגרסה הספציפית של GKE כדי לוודא שהיא תואמת.

גרסת ה-Proxy של Cloud Service Mesh

בטבלה הבאה מפורט המיפוי הנוכחי של ערוצי אשכולות GKE לגרסאות של Cloud Service Mesh Proxy:

שדרוג של שרת Proxy ב-Cloud Service Mesh

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

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

kubectl rollout restart deployment -n YOUR_NAMESPACE_HERE

פריסת שירות Kubernetes לצורך בדיקה

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

הגדרת שירותי GKE באמצעות NEGs

שירותי GKE צריכים להיות חשופים דרך קבוצות של נקודות קצה ברשת (NEGs) כדי שתוכלו להגדיר אותם כשרתי קצה של שירות קצה של Cloud Service Mesh. מוסיפים את הערת ה-NEG למפרט השירות של Kubernetes ובוחרים שם (על ידי החלפת NEG-NAME בדוגמה שלמטה) כדי שיהיה קל למצוא אותו בהמשך. תצטרכו את השם הזה כשתצרפו את ה-NEG לשירות לקצה העורפי של Cloud Service Mesh. מידע נוסף על הוספת הערות ל-NEGs זמין במאמר בנושא מתן שמות ל-NEGs.

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "service-test-neg"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

ההערה הזו יוצרת NEG עצמאי שמכיל נקודות קצה שתואמות לכתובות ה-IP ולפורטים של ה-Pods של השירות. מידע נוסף ודוגמאות זמינים במאמר קבוצות עצמאיות של נקודות קצה ברשת.

בדוגמה הבאה של שירות כלולה ההערה NEG. השירות מציג את שם המארח באמצעות HTTP ביציאה 80. כדי לקבל את השירות ולפרוס אותו באשכול GKE, משתמשים בפקודה הבאה.

wget -q -O - \
https://storage.googleapis.com/traffic-director/demo/trafficdirector_service_sample.yaml \
| kubectl apply -f -

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

kubectl get svc

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

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service-test     ClusterIP   10.71.9.71   none          80/TCP    41m
[..skip..]

מוודאים שפוד האפליקציה שמשויך לשירות הזה פועל:

kubectl get pods

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       2/2       Running   0          6m
busybox-5dcf86f4c7-jvvdd    2/2       Running   0          10m
[..skip..]

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

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

gcloud compute network-endpoint-groups list

הפונקציה מחזירה את הערכים הבאים:

NAME                       LOCATION            ENDPOINT_TYPE       SIZE
service-test-neg           ZONE     GCE_VM_IP_PORT      1

שומרים את השם של ה-NEG במשתנה NEG_NAME:

NEG_NAME=$(gcloud compute network-endpoint-groups list \
| grep service-test | awk '{print $1}')

הגדרת Cloud Service Mesh עם רכיבי Cloud Load Balancing

בקטע הזה מוגדר Cloud Service Mesh באמצעות משאבי איזון עומסים של Compute Engine. כך שרת ה-proxy מסוג קובץ עזר חיצוני של הלקוח לדוגמה יוכל לקבל הגדרות מ-Cloud Service Mesh. בקשות יוצאות מהלקוח לדוגמה מטופלות על ידי קובץ עזר חיצוני ומופנות לשירות הבדיקה.

צריך להגדיר את הרכיבים הבאים:

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

יצירת בדיקת התקינות והכלל בחומת האש

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

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

יוצרים שירות לקצה העורפי גלובלי עם תוכנית לאיזון עומסים מסוג INTERNAL_SELF_MANAGED. במסוףGoogle Cloud , סכמת איזון העומסים מוגדרת באופן מרומז. מוסיפים את בדיקת תקינות לשירות לקצה העורפי.

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

מפת כללי הניתוב מגדירה איך Cloud Service Mesh מנתב תעבורה ברשת. כחלק ממיפוי כללי הניתוב, מגדירים כתובת IP וירטואלית (VIP) וקבוצה של כללים קשורים לניהול תעבורה, כמו ניתוב מבוסס-מארח. כשיישום שולח בקשה ל-VIP, פרוקסי Envoy sidecar המצורף מבצע את הפעולות הבאות:

1. מיירט את הבקשה.
2. המערכת מעריכה את כתובת ה-URL בהתאם לכללי ניהול התנועה במפת URL.
3. בחירת שירות קצה עורפי על סמך שם המארח בבקשה.
4. בוחר קצה עורפי או נקודת קצה שמשויכים לשירות הקצה העורפי שנבחר.
5. שליחת תעבורת נתונים ל-backend או לנקודת הקצה.

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

אימות ההגדרה

בקטע הזה מוסבר איך לוודא שתעבורת הנתונים שנשלחת מלקוח Busybox לדוגמה מנותבת לשירות service-test Kubernetes שלכם. כדי לשלוח בקשת בדיקה, אפשר לגשת למעטפת באחד מהקונטיינרים ולהריץ את פקודת האימות הבאה. ‫service-test Pod צריך להחזיר את שם המארח של ה-Pod שמשרת את הבקשה.

# Get the name of the pod running Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test at
# the VIP 10.0.0.1. Because 0.0.0.0 is configured in the forwarding rule, this
# can be any VIP.
TEST_CMD="wget -q -O - 10.0.0.1; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

כך מאמתים את ההגדרה:

• הלקוח לדוגמה שלח בקשה שצוין בה שם המארח service-test.
• ללקוח לדוגמה יש פרוקסי Envoy sidecar שהוזרק על ידי Envoy sidecar injector.
• קובץ העזר החיצוני חסם את הבקשה.
• באמצעות מפת URL, ‏ Envoy התאים את שם המארח service-test לשירות td-gke-service Cloud Service Mesh.
• ‫Envoy בחר נקודת קצה מתוך קבוצת נקודות הקצה ברשת שמשויכת ל-td-gke-service.
• ‫Envoy שלח את הבקשה ל-pod שמשויך לשירות service-test Kubernetes.

איך עוברים אל Managed Sidecar Injector

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

השבתה של החדרת sidecar בתוך האשכול

הפקודות הבאות משביתות את כלי ההזרקה של קובצי ה-sidecar מדור קודם באשכול עבור מרחב השמות שמוגדר כברירת מחדל

kubectl label namespace default istio-injection-

ניקוי של מזרים sidecar בתוך האשכול

מורידים ומחלצים את כלי ההזרקה של Envoy sidecar מדור קודם.

wget https://storage.googleapis.com/traffic-director/td-sidecar-injector-xdsv3.tgz
tar -xzvf td-sidecar-injector-xdsv3.tgz
cd td-sidecar-injector-xdsv3

מחיקת משאבים של כלי להחדרת sidecar באשכול

kubectl delete -f specs/

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

• מידע על ניהול מתקדם של תעבורת נתונים
• מידע נוסף על אבטחת שירותים ב-Cloud Service Mesh
• איך מגדירים יכולת מעקב באמצעות Envoy
• פתרון בעיות בפריסות של Cloud Service Mesh
• אפשרויות להגדרת Pod ב-Google Kubernetes Engine עם הזרקה אוטומטית של Envoy