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

במדריך הזה מוסבר איך להגדיר מארחי Google Kubernetes Engine או Kubernetes Pod ורכיבי איזון העומסים שנדרשים ל-Cloud Service Mesh.

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

אפשר להגדיר את Cloud Service Mesh באמצעות ה-SDK של איזון העומסים ב-Compute Engine או ממשקי API ל-REST. אפשר לעיין בהפניות ל-API של איזון עומסים ול-gcloud.

הגדרת אשכולות GKE/Kubernetes ל-Cloud Service Mesh

בקטע הזה מוסבר איך מאפשרים לאשכולות GKE/Kubernetes לעבוד עם Cloud Service Mesh.

יצירת אשכול GKE

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

בדוגמה הבאה מוצג אופן היצירה של אשכול GKE בשם traffic-director-cluster באזור us-central1-a.

המסוף

כדי ליצור אשכול באמצעות מסוף Google Cloud :

  1. עוברים לתפריט Kubernetes Engine במסוף Google Cloud .

    מעבר לתפריט Google Kubernetes Engine

  2. לוחצים על יצירת אשכול.

  3. ממלאים את השדות הבאים:

    • שם: מזינים traffic-director-cluster.
    • סוג המיקום: Zonal.
    • תחום: us-central1-a.

  4. בחלונית הניווט, בקטע Node Pools (מאגרי צמתים), לוחצים על default-pool (מאגר ברירת המחדל).

  5. בשדה גודל מצוין מספר הצמתים שייווצרו באשכול. צריכה להיות לכם מכסת משאבים זמינה לצמתים ולמשאבים שלהם (כמו מסלולי חומת אש).

  6. בחלונית הניווט, בקטע default-pool, לוחצים על Nodes (צמתים).

  7. בשדה Machine type (סוג המכונה) מצוין סוג המכונה של Compute Engine שבו יש להשתמש עבור המופעים. החיוב על כל סוג מכונה מתבצע באופן שונה. מידע על המחירים של סוגי המכונות זמין בדף המחירים של Compute Engine.

  8. בחלונית הניווט, בקטע default-pool, לוחצים על אבטחה.

  9. בקטע Access scopes (היקפי גישה) לוחצים על Allow full access to all Cloud APIs (הרשאת גישה מלאה לכל ממשקי Cloud API).

  10. מתאימים אישית את האשכול לפי הצורך.

  11. לוחצים על יצירה.

אחרי שיוצרים אשכול ב- Google Cloud console, צריך להגדיר את kubectl כדי ליצור אינטראקציה עם האשכול. מידע נוסף זמין במאמר בנושא יצירת רשומה של kubeconfig.

gcloud

gcloud container clusters create traffic-director-cluster \
  --zone us-central1-a \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

קבלת ההרשאות הנדרשות באשכול GKE

ב-GKE, עוברים לאשכול(2) שיצרתם באמצעות הפקודה הבאה. הפעולה הזו תפנה את kubectl לאשכול הנכון.

gcloud container clusters get-credentials traffic-director-cluster \
    --zone us-central1-a

הגדרת שירותי GKE/Kubernetes

בקטע הזה מוסבר איך להכין מפרטים של פריסת Kubernetes כדי לעבוד עם Cloud Service Mesh. התהליך כולל הגדרת שירותים עם NEGs וגם הוספה של פרוקסי מסוג sidecar ל-Pods שנדרשת להם גישה לשירותים שמנוהלים על ידי Cloud Service Mesh.

הגדרת כלל לחומת האש

כדי לוודא שפודים של ה-Backend פועלים, צריך להגדיר כלל בחומת האש שיאפשר את טווחי כתובות ה-IP של בודק התקינות.

המסוף

  1. נכנסים לדף Firewall policies במסוף Google Cloud .
    כניסה לדף Firewall policies
  2. לוחצים על יצירת כללים לחומת האש.
  3. בדף Create a firewall rule (יצירת כלל לחומת האש), מזינים את הפרטים הבאים:
    • שם: נותנים שם לכלל. בדוגמה הזו, נשתמש בפקודה fw-allow-health-checks.
    • רשת: בוחרים רשת VPC.
    • עדיפות: מזינים מספר לעדיפות. מספרים נמוכים יותר מייצגים עדיפות גבוהה יותר. חשוב לוודא שלכלל חומת האש יש עדיפות גבוהה יותר מכללים אחרים שעשויים לדחות תעבורת נתונים נכנסת.
    • כיוון התנועה: בוחרים באפשרות תנועה נכנסת (ingress).
    • פעולה על התאמה: בוחרים באפשרות אישור.
    • יעדים: בוחרים באפשרות כל המקרים ברשת.
    • מסנן מקור: בוחרים את סוג טווח כתובות ה-IP הנכון.
    • טווח כתובות ה-IP של המקור: 35.191.0.0/16,130.211.0.0/22
    • מסנן יעד: בוחרים את סוג ה-IP.
    • פרוטוקולים ויציאות: לוחצים על פרוטוקולים ויציאות שצוינו ואז מסמנים את התיבה tcp. ‫TCP הוא הפרוטוקול הבסיסי לכל הפרוטוקולים של בדיקות תקינות.
    • לוחצים על יצירה.

gcloud

  1. כדי ליצור כלל לחומת האש בשם fw-allow-health-checks שמאפשר חיבורים נכנסים למופעים ברשת עם התג allow-health-checks, משתמשים בפקודה gcloud הבאה. מחליפים את NETWORK_NAME בשם הרשת.

    gcloud compute firewall-rules create fw-allow-health-checks \
    --network NETWORK_NAME \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges 35.191.0.0/16,130.211.0.0/22 \
    --rules tcp

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

הגדרת שירותי GKE / Kubernetes באמצעות קבוצות של נקודות קצה ברשת (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": "NEG-NAME"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

לכל שירות נוצרת קבוצת נקודות קצה עצמאית (NEG) שמכילה נקודות קצה שהן כתובות ה-IP והיציאות של ה-Pod. מידע נוסף ודוגמאות זמינים במאמר Standalone network endpoint groups (קבוצות עצמאיות של נקודות קצה ברשת).

לצורך הדגמה, אפשר לפרוס שירות לדוגמה שמציג את שם המארח שלו באמצעות HTTP ביציאה 80:

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

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

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       1/1       Running   0          6m
[..skip..]

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

מחפשים את ה-NEG שנוצר מהדוגמה שלמעלה ורושמים את השם שלו.

המסוף

כדי לראות רשימה של קבוצות של נקודות קצה ברשת, נכנסים לדף Network Endpoint Groups במסוף Google Cloud .
מעבר לדף Network Endpoint Groups

gcloud

gcloud compute network-endpoint-groups list

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

NAME                 LOCATION          ENDPOINT_TYPE      SIZE
NEG-NAME           us-central1-a     GCE_VM_IP_PORT      1

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

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

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

ההוראות בקטע הזה מבטיחות ששירותי GKE יהיו נגישים במאזן העומסים של VIP השירות שמאוזן על ידי Cloud Service Mesh, באמצעות הגדרת איזון עומסים שדומה למוצרים אחרים של Google Cloud Load Balancing.

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

בדוגמה הבאה של הגדרות Cloud Service Mesh מניחים את ההנחות הבאות:

  1. קבוצות ה-NEG וכל שאר המשאבים נוצרים ברשת default, במצב אוטומטי, באזור us-central1-a.
  2. השם של קבוצת ה-NEG עבור האשכול מאוחסן במשתנה ${NEG_NAME}.

יצירת בדיקת התקינות

יוצרים את בדיקת התקינות.

המסוף

  1. נכנסים לדף Health checks במסוף Google Cloud .
    כניסה לדף Health checks
  2. לוחצים על יצירת בדיקת תקינות.
  3. בשדה השם, מזינים td-gke-health-check.
  4. בפרוטוקול, בוחרים באפשרות HTTP.
  5. לוחצים על יצירה.

gcloud 

gcloud compute health-checks create http td-gke-health-check \
  --use-serving-port

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

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

המסוף

  1. נכנסים לדף Cloud Service Mesh במסוף Google Cloud .

    כניסה לדף Cloud Service Mesh

  2. בכרטיסייה Services (שירותים), לוחצים על Create Service (יצירת שירות).

  3. לוחצים על Continue.

  4. בשם השירות, מזינים td-gke-service.

  5. בקטע סוג קצה עורפי, בוחרים באפשרות קבוצות של נקודות קצה ברשת.

  6. בוחרים את קבוצת נקודות הקצה ברשת שיצרתם.

  7. מגדירים את הבקשות המקסימליות לשנייה ל-5.

  8. לוחצים על סיום.

  9. בקטע בדיקת תקינות, בוחרים באפשרות td-gke-health-check, שהיא בדיקת התקינות שיצרתם.

  10. לוחצים על Continue.

gcloud

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

    gcloud compute backend-services create td-gke-service \
 --global \
 --health-checks td-gke-health-check \
 --load-balancing-scheme INTERNAL_SELF_MANAGED

  2. מוסיפים את קבוצות ה-NEG של ה-Backend לשירות לקצה העורפי.

    gcloud compute backend-services add-backend td-gke-service \
 --global \
 --network-endpoint-group ${NEG_NAME} \
 --network-endpoint-group-zone us-central1-a \
 --balancing-mode RATE \
 --max-rate-per-endpoint 5

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

במאמר הזה מוסבר איך ליצור את כלל הניתוב, כלל ההעברה וכתובת ה-IP הפנימית להגדרת Cloud Service Mesh.

תנועת נתונים שנשלחת לכתובת ה-IP הפנימית נחסמת על ידי שרת ה-Proxy של Envoy ונשלחת לשירות המתאים בהתאם לכללי המארח והנתיב.

כלל ההעברה נוצר ככלל העברה גלובלי עם הערך load-balancing-scheme שמוגדר ל-INTERNAL_SELF_MANAGED.

אפשר להגדיר את הכתובת של כלל ההעברה ל-0.0.0.0. אם כן, התנועה מנותבת על סמך שם המארח ופרטי הנתיב של HTTP שהוגדרו במפת URL, ללא קשר לכתובת ה-IP בפועל שאליה שם המארח מפנה. במקרה כזה, כתובות ה-URL (שם המארח בתוספת נתיב כתובת ה-URL) של השירותים, כפי שהוגדרו בכללי המארח, צריכות להיות ייחודיות בהגדרת Service mesh. כלומר, אי אפשר להגדיר שני שירותים שונים עם קבוצות שונות של שרתי קצה עורפיים, ששניהם משתמשים באותו שילוב של שם מארח ונתיב.

אפשרות אחרת היא להפעיל ניתוב על סמך כתובת ה-VIP של היעד בפועל של השירות. אם מגדירים את כתובת ה-IP הווירטואלית של השירות כפרמטר address של כלל ההעברה, רק בקשות שמיועדות לכתובת ה-IP הזו מנותבות על סמך פרמטרי ה-HTTP שצוינו במפת URL.

המסוף

במסוף, שרת ה-proxy של היעד משולב עם כלל ההעברה. כשיוצרים את כלל ההעברה,מערכת Google Cloud יוצרת באופן אוטומטי פרוקסי HTTP ליעד ומצרפת אותו למפת ה-URL.

כלל הניתוב מורכב מכלל ההעברה ומכללי המארח והנתיב (שנקראים גם מפת URL).

  1. נכנסים לדף Cloud Service Mesh במסוף Google Cloud .

    כניסה לדף Cloud Service Mesh

  2. לוחצים על מיפוי של כללי ניתוב.

  3. לוחצים על יצירת כלל ניתוב.

  4. מזינים td-gke-url-map בתור Name (שם) של מפת URL.

  5. לוחצים על הוספת כלל להעברה.

  6. בשדה 'שם כלל ההעברה', מזינים td-gke-forwarding-rule.

  7. בוחרים את הרשת.

  8. בוחרים את כתובת ה-IP הפנימית.

  9. לוחצים על Save.

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

  11. מגדירים את המארח ל-service-test.

  12. לוחצים על Save.

gcloud

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

    gcloud compute url-maps create td-gke-url-map \
   --default-service td-gke-service

  2. יוצרים התאמה של נתיב במפת URL וכלל מארח כדי להפנות תנועה לשירות על סמך שם המארח ונתיב. בדוגמה הזו, service-test הוא שם השירות, ויש התאמה לכל בקשות הנתיב עבור המארח הזה (/*). service-test הוא גם השם המוגדר של שירות Kubernetes שמשמש בדוגמה של ההגדרה שלמעלה.

    gcloud compute url-maps add-path-matcher td-gke-url-map \
   --default-service td-gke-service \
   --path-matcher-name td-gke-path-matcher

    gcloud compute url-maps add-host-rule td-gke-url-map \
   --hosts service-test \
   --path-matcher-name td-gke-path-matcher

  3. יוצרים את ה-proxy מסוג HTTP ליעד.

    gcloud compute target-http-proxies create td-gke-proxy \
   --url-map td-gke-url-map

  4. יוצרים את כלל ההעברה.

    gcloud compute forwarding-rules create td-gke-forwarding-rule \
  --global \
  --load-balancing-scheme=INTERNAL_SELF_MANAGED \
  --address=0.0.0.0 \
  --target-http-proxy=td-gke-proxy \
  --ports 80 --network default

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

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

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

בקטע הזה מוסבר איך להגיע לשרתי קצה עורפיים של Cloud Service Mesh מאפליקציית לקוח.

כדי להדגים את הפונקציונליות, אפשר לפרוס Pod לדוגמה שמריץ Busybox. ל-pod יש גישה אל service-test, שנוצר בקטע הקודם ומקבל תנועה שמתבצעת בה איזון עומסים על ידי Cloud Service Mesh.

הוספת קובץ עזר חיצוני (sidecar) ל-Pods של GKE / Kubernetes

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

בדוגמה הזו, אתם פורסים לקוח Busybox עם Istio-proxy sidecar ועם מאגרי init שנוספו לפריסה באמצעות מפרט ההפניה.

אם אתם משתמשים בממשקי API ישנים יותר, מחליפים את המשתנים PROJECT_NUMBER ו-NETWORK_NAME במספר הפרויקט ובשם הרשת:

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_sample_xdsv3.yaml
sed -i "s/NETWORK_NAME/NETWORK_NAME/g" trafficdirector_client_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_sample_xdsv3.yaml

אם אתם משתמשים בממשקי ה-API החדשים לניתוב שירותים, שנמצאים כרגע בתצוגה מקדימה, צריך להחליף את המשתנים PROJECT_NUMBER ו-MESH_NAME במספר הפרויקט ובשם Mesh:

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/MESH_NAME/MESH_NAME/g" trafficdirector_client_new_api_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_new_api_sample_xdsv3.yaml

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

kubectl describe pods -l run=client

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

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

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

# Get name of the Pod  with 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.
TEST_CMD="wget -q -O - service-test; echo"

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

הסבר על חסימת תנועה על ידי שרת proxy מסוג sidecar

שימו לב שבמקרה הזה, כשלקוח Busybox שולח בקשות לשירות לקצה העורפי, כל בקשה מועברת דרך קובץ עזר חיצוני.

באפליקציית ההדגמה הזו נעשה שימוש בשרת ה-proxy של Envoy. לכן, הלקוח רואה 'server: envoy' בכותרת של תגובות השרת.

כדי לוודא זאת, משתמשים בפקודות הבאות:

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

# Command to send a request to service-test and output server response headers.
TEST_CMD="wget -S --spider service-test; echo"

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

בדוגמה הזו, יצרתם כלל העברה באמצעות כתובת ה-VIP‏ 0.0.0.0. המשמעות היא ש-Cloud Service Mesh מעביר בקשות לקצה העורפי רק על סמך הכותרת Host. במקרה הזה, כתובת ה-IP של היעד יכולה להיות כל כתובת, כל עוד כותרת המארח של הבקשה תואמת למארח שהוגדר במפת URL‏ service-test.

כדי לוודא זאת, מריצים את פקודות הבדיקה הבאות:

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

# Command to send a request to service-test setting the Host header and using a random IP address.
TEST_CMD="wget -q --header 'Host: service-test' -O - 1.2.3.4; echo"

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

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