הכנת אפליקציה ל-Cloud Service Mesh

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

אם אתם כבר מכירים את המושגים של Kubernetes ו-service mesh, אתם יכולים לדלג על המדריך הזה ולעבור ישירות אל מדריך ההתקנה של Cloud Service Mesh.

מטרות

  1. לגלות אפליקציית hello world פשוטה עם כמה שירותים.
  2. הרצת האפליקציה מקוד המקור
  3. העברת האפליקציה לקונטיינר.
  4. יוצרים אשכול Kubernetes.
  5. פורסים את הקונטיינרים באשכול.

לפני שמתחילים

כדי להפעיל את Cloud Service Mesh API, מבצעים את השלבים הבאים:
  1. נכנסים ל דף Kubernetes Engine במסוף Google Cloud .
  2. יוצרים או בוחרים פרויקט.
  3. מחכים עד שממשק ה-API והשירותים הקשורים מופעלים. הפעולה הזו עשויה להימשך כמה דקות.

  4. מוודאים שהחיוב מופעל בפרויקט Google Cloud .

במדריך הזה משתמשים ב-Cloud Shell, שמקצה מכונה וירטואלית (VM) מסוג g1-small Compute Engine שמריצה מערכת הפעלה מבוססת-Debian Linux.

הכנת Cloud Shell

היתרונות של שימוש ב-Cloud Shell:

  • סביבות הפיתוח של Python 2 ו-Python 3 (כולל virtualenv) מוגדרות.
  • כלי שורת הפקודה gcloud,‏ docker,‏ git ו-kubectl שמשמשים במדריך הזה כבר מותקנים.

  • אתם יכולים לבחור מבין עורכי הטקסט הבאים:

    • עורך קוד, שאליו ניגשים בלחיצה על בחלק העליון של חלון Cloud Shell.

    • ‫Emacs,‏ Vim או Nano, שאפשר לגשת אליהם משורת הפקודה ב-Cloud Shell.

במסוף Google Cloud , מפעילים את Cloud Shell.

הפעלת Cloud Shell

בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

הורדת קוד לדוגמה

  1. מורידים את קוד המקור של helloserver:

    git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-samples

  2. עוברים לספרייה של הקוד לדוגמה:

    cd anthos-service-mesh-samples/docs/helloserver

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

אפליקציית הדוגמה כתובה ב-Python, ויש לה שני רכיבים שמתקשרים באמצעות REST:

  • server: שרת פשוט עם נקודת קצה אחת GET, ‏ / , שמדפיסה את המחרוזת hello world במסוף.
  • ‫loadgen: סקריפט ששולח תנועה אל server, עם מספר בקשות שניתן להגדרה לשנייה (RPS).

אפליקציה לדוגמה

הרצת האפליקציה מקוד המקור

כדי להכיר את האפליקציה לדוגמה, מפעילים פתרונות חכמים ב-Cloud Shell.

  1. מהספרייה sample-apps/helloserver, מריצים את הפקודה server:

    python3 server/server.py

    בזמן ההפעלה, ב-server מוצגים הנתונים הבאים:

    INFO:root:Starting server...

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

  3. שליחת בקשה אל server:

    curl http://localhost:8080

    ‫server משיב:

    Hello World!

  4. מהספרייה שבה הורדתם את הקוד לדוגמה, עוברים לספרייה שמכילה את loadgen:

    cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/loadgen

  5. יוצרים את משתני הסביבה הבאים:

    export SERVER_ADDR=http://localhost:8080
export REQUESTS_PER_SECOND=5

  6. התחלה virtualenv:

    virtualenv --python python3 env

  7. מפעילים את הסביבה הווירטואלית:

    source env/bin/activate

  8. מתקינים את הדרישות ל-loadgen:

    pip3 install -r requirements.txt

  9. מריצים את הפקודה loadgen:

    python3 loadgen.py

    בזמן ההפעלה, loadgen מציג הודעה שדומה לזו:

    Starting loadgen: 2019-05-20 10:44:12.448415
5 request(s) complete to http://localhost:8080

    בחלון המסוף השני, server כותב הודעות למסוף בדומה להודעות הבאות:

    127.0.0.1 - - [21/Jun/2019 14:22:01] "GET / HTTP/1.1" 200 -
INFO:root:GET request,
Path: /
Headers:
Host: localhost:8080
User-Agent: python-requests/2.22.0
Accept-Encoding: gzip, deflate
Accept: */*

    מבחינת הרשת, כל האפליקציה פועלת עכשיו באותו מארח. לכן אפשר להשתמש ב-localhost כדי לשלוח בקשות אל server.

  10. כדי לעצור את loadgen ואת server, מזינים Ctrl-c בכל חלון של מסוף.

  11. בחלון הטרמינל loadgen, משביתים את הסביבה הווירטואלית:

    deactivate

העברת האפליקציה לקונטיינר

כדי להריץ את האפליקציה ב-GKE, צריך לארוז את האפליקציה לדוגמה – גם את server וגם את loadgen – בקונטיינרים. קונטיינר הוא דרך לארוז אפליקציה כך שהיא מבודדת מהסביבה הבסיסית.

כדי להוסיף את האפליקציה לקונטיינר, צריך Dockerfile. ‫DockerfileDockerfile הוא קובץ טקסט שמגדיר את הפקודות שנדרשות כדי להרכיב את קוד המקור של האפליקציה ואת יחסי התלות שלה לתוך תמונתDocker. אחרי שיוצרים את האימג', מעלים אותו למאגר קונטיינרים, כמו Docker Hub או Container Registry.

הדוגמה כוללת Dockerfile גם ל-server וגם ל-loadgen עם כל הפקודות שנדרשות כדי ליצור את קובצי האימג'. הנה Dockerfile של server:

FROM python:3.14-slim as base
FROM base as builder
RUN apt-get -qq update \
    && apt-get install -y --no-install-recommends \
        g++ \
    && rm -rf /var/lib/apt/lists/*

# Enable unbuffered logging
FROM base as final
ENV PYTHONUNBUFFERED=1

RUN apt-get -qq update \
    && apt-get install -y --no-install-recommends \
        wget

WORKDIR /helloserver

# Grab packages from builder
COPY --from=builder /usr/local/lib/python3.* /usr/local/lib/

# Add the application
COPY . .

EXPOSE 8080
ENTRYPOINT [ "python", "server.py" ]
  • הפקודה FROM python:3-slim as base אומרת ל-Docker להשתמש בקובץ האימג' העדכני ביותר של Python 3 כקובץ האימג' הבסיסי.
  • הפקודה COPY . . מעתיקה את קובצי המקור בספריית העבודה הנוכחית (במקרה הזה, רק server.py) למערכת הקבצים של הקונטיינר.
  • התג ENTRYPOINT מגדיר את הפקודה שמשמשת להפעלת הקונטיינר. במקרה הזה, הפקודה כמעט זהה לזו שבה השתמשתם כדי להריץ את server.py מקוד המקור.
  • הפקודה EXPOSE מציינת שהשירות server מאזין ליציאה 8080. הפקודה הזו לא חושפת יציאות, אבל היא משמשת כתיעוד שצריך לפתוח את יציאה 8080 כשמריצים את הקונטיינר.

הכנה להעברת האפליקציה לקונטיינר

  1. מגדירים את משתני הסביבה הבאים. מחליפים את PROJECT_ID במזהה שלGoogle Cloud הפרויקט.

    export PROJECT_ID="PROJECT_ID"
     
    export GCR_REPO="asm-ready"

    משתמשים בערך של PROJECT_ID ושל GCR_REPO כדי לתייג את קובץ האימג' של Docker כשיוצרים אותו ואז מעבירים אותו בדחיפה ל-Container Registry הפרטי.

  2. מגדירים את פרויקט ברירת המחדל Google Cloud ל-Google Cloud CLI.

    gcloud config set project $PROJECT_ID

  3. מגדירים את אזור ברירת המחדל ל-Google Cloud CLI.

    gcloud config set compute/zone us-central1-b

  4. מוודאים ששירות Container Registry מופעל בGoogle Cloud פרויקט.

    gcloud services enable containerregistry.googleapis.com

העברה לקונטיינרים של server

  1. עוברים לספרייה שבה נמצאת הדוגמה server:

    cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/server/

  2. יוצרים את התמונה באמצעות Dockerfile ומשתני הסביבה שהגדרתם קודם:

    docker build -t gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1 .

    הדגל -t מייצג את תג Docker. זה השם של קובץ האימג' שבו משתמשים כשפורסים את הקונטיינר.

  3. מעבירים את האימג' בדחיפה ל-Container Registry:

    docker push gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1

העברה לקונטיינרים של loadgen

  1. עוברים לספרייה שבה נמצאת הדוגמה loadgen:

    cd ../loadgen

  2. יוצרים את התמונה:

    docker build -t gcr.io/$PROJECT_ID/$GCR_REPO/loadgen:v0.0.1 .

  3. מעבירים את האימג' בדחיפה ל-Container Registry:

    docker push gcr.io/$PROJECT_ID/$GCR_REPO/loadgen:v0.0.1

הכנת רשימה של התמונות

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

gcloud container images list --repository gcr.io/$PROJECT_ID/asm-ready

הפקודה מחזירה את שמות התמונות שדחפתם:

NAME
gcr.io/PROJECT_ID/asm-ready/helloserver
gcr.io/PROJECT_ID/asm-ready/loadgen

יצירת אשכול GKE

אפשר להריץ את הקונטיינרים האלה במכונה הווירטואלית של Cloud Shell באמצעות הפקודה docker run. אבל בסביבת ייצור, צריך לתזמן את הפעולה של הקונטיינרים בצורה אחידה יותר. לדוגמה, אתם צריכים מערכת שתוודא שהקונטיינרים תמיד פועלים, ודרך להגדיל את מספר המופעים של קונטיינר ולהפעיל מופעים נוספים כדי לטפל בעלייה בתנועה.

אפשר להשתמש ב-GKE כדי להריץ אפליקציות בקונטיינרים. ‫GKE היא פלטפורמה לניהול קונטיינרים שפועלת על ידי חיבור מכונות וירטואליות לאשכול. כל מכונה וירטואלית נקראת צומת. אשכולות GKE מבוססים על מערכת ניהול האשכולות בקוד פתוח Kubernetes. ‫Kubernetes מספקת את המנגנונים שדרכם מתבצעת האינטראקציה עם האשכול.

כדי ליצור אשכול GKE:

  1. יוצרים את האשכול:

    gcloud container clusters create asm-ready \
  --cluster-version latest \
  --machine-type=n1-standard-4 \
  --num-nodes 4

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

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

    NAME        LOCATION       MASTER_VERSION  MASTER_IP      MACHINE_TYPE   NODE_VERSION   NUM_NODES  STATUS
asm-ready  us-central1-b  1.13.5-gke.10   203.0.113.1    n1-standard-2  1.13.5-gke.10  4          RUNNING

  2. מספקים פרטי כניסה לכלי kubectl בשורת הפקודה כדי שתוכלו להשתמש בו לניהול האשכול:

    gcloud container clusters get-credentials asm-ready

  3. עכשיו אפשר להשתמש ב-kubectl כדי לתקשר עם Kubernetes. לדוגמה, אפשר להריץ את הפקודה הבאה כדי לקבל את הסטטוס של הצמתים:

    kubectl get nodes

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

    NAME                                       STATUS   ROLES    AGE    VERSION
gke-asm-ready-default-pool-dbeb23dc-1vg0   Ready    <none>   99s    v1.13.6-gke.13
gke-asm-ready-default-pool-dbeb23dc-36z5   Ready    <none>   100s   v1.13.6-gke.13
gke-asm-ready-default-pool-dbeb23dc-fj7s   Ready    <none>   99s    v1.13.6-gke.13
gke-asm-ready-default-pool-dbeb23dc-wbjw   Ready    <none>   99s    v1.13.6-gke.13

הסבר על מושגי מפתח ב-Kubernetes

בתרשים הבא מוצגת האפליקציה שפועלת ב-GKE:

אפליקציה בקונטיינר

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

  • צמתים ואשכולות: ב-GKE, צומת הוא מכונה וירטואלית. בפלטפורמות אחרות של Kubernetes, צומת יכול להיות מכונה פיזית או וירטואלית. קלאסטר הוא קבוצה של צמתים שאפשר להתייחס אליהם יחד כמכונה אחת, שבה פורסים אפליקציה מבוססת-קונטיינר.

  • ‫Pods: ב-Kubernetes, קונטיינרים פועלים בתוך Pod. קבוצת Pod היא היחידה האטומית ב-Kubernetes. ‫Pod מכיל מאגר אחד או יותר. פורסים את מאגרי התגים server ו-loadgen, כל אחד ב-Pod משלו. כש-Pod מריץ כמה קונטיינרים (לדוגמה, שרת אפליקציות ושרת proxy), הקונטיינרים מנוהלים כישות אחת וחולקים את המשאבים של ה-Pod.

  • פריסות: פריסה היא אובייקט Kubernetes שמייצג קבוצה של קובצי Pod זהים. פריסה מפעילה כמה עותקים של ה-Pods שמפוזרים בין הצמתים של אשכול. פריסת Deployment מחליפה באופן אוטומטי כל Pod שנכשל או מפסיק להגיב.

  • ‫Kubernetes Service: הרצת קוד האפליקציה ב-GKE משנה את הרישות בין loadgen לבין server. כשמריצים את השירותים במכונה וירטואלית ב-Cloud Shell, אפשר לשלוח בקשות אל server באמצעות הכתובת localhost:8080. אחרי הפריסה ב-GKE, ה-Pods מתוזמנים להפעלה בצמתים הזמינים. כברירת מחדל, אי אפשר לקבוע באיזה צומת פועל ה-Pod, ולכן ל-Pods אין כתובות IP יציבות.

    כדי לקבל כתובת IP עבור server, צריך להגדיר הפשטה של הרשת מעל קבוצות ה-Pod, שנקראת Kubernetes Service. שירות Kubernetes מספק נקודת קצה יציבה ברשת עבור קבוצה של Pods. יש כמה סוגים של שירותים. ‫server משתמש ב-LoadBalancer, שחושף כתובת IP חיצונית כדי שתוכלו להגיע אל server מחוץ לאשכול.

    ל-Kubernetes יש גם מערכת DNS מובנית, שמקצה שמות DNS (לדוגמה, helloserver.default.cluster.local) לשירותים. כך אפשר ל-Pods בתוך האשכול להגיע ל-Pods אחרים באשכול עם כתובת יציבה. אי אפשר להשתמש בשם ה-DNS הזה מחוץ לאשכול, למשל מ-Cloud Shell.

מניפסטים של Kubernetes

כשמריצים את האפליקציה מקוד המקור, משתמשים בפקודה אימפרטיבית: python3 server.py

ציווי הוא פועל שמוביל את המשפט: "תעשה את זה".

לעומת זאת, Kubernetes פועל על מודל הצהרתי. כלומר, במקום להגיד ל-Kubernetes בדיוק מה לעשות, אתם מספקים ל-Kubernetes מצב רצוי. לדוגמה, Kubernetes מפעיל ומפסיק את ה-Pods לפי הצורך, כך שהמצב בפועל של המערכת תואם למצב הרצוי.

מציינים את המצב הרצוי בקבוצה של מניפסטים או בקובצי YAML. קובץ YAML מכיל את המפרט של אובייקט Kubernetes אחד או יותר.

הדוגמה מכילה קובץ YAML עבור server ו-loadgen. כל קובץ YAML מציין את המצב הרצוי של אובייקט הפריסה והשירות של Kubernetes.

שרת

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
  • ‫kind מציין את סוג האובייקט.
  • ‫metadata.name מציין את השם של הפריסה.
  • השדה הראשון spec מכיל תיאור של המצב הרצוי.
  • ‫spec.replicas מציין את מספר ה-Pods הרצוי.
  • בקטע spec.template מוגדרת תבנית של Pod. במפרט של ה-Pods נכלל השדה image, שהוא השם של האימג' שצריך לשלוף מ-Container Registry.

השירות מוגדר באופן הבא:

apiVersion: v1
kind: Service
metadata:
  name: hellosvc
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: helloserver
  type: LoadBalancer
  • ‫LoadBalancer: לקוחות שולחים בקשות לכתובת ה-IP של מאזן עומסים ברשת, שיש לו כתובת IP יציבה שאפשר להגיע אליה מחוץ לאשכול.
  • ‫targetPort: כדאי לזכור שהפקודה EXPOSE 8080 ב-Dockerfile לא חושפת אף יציאה. חושפים את הפורט 8080 כדי שאפשר יהיה להגיע למאגר server מחוץ לאשכול. במקרה הזה, ‫hellosvc.default.cluster.local:80 (שם קצר: hellosvc) ממופה ליציאה 8080 של כתובת ה-IP של ה-Pod‏ helloserver.
  • ‫port: מספר היציאה ששירותים אחרים באשכול משתמשים בו כששולחים בקשות.

Load Generator

אובייקט הפריסה ב-loadgen.yaml דומה ל-server.yaml. הבדל בולט אחד הוא שאובייקט הפריסה מכיל קטע שנקרא env. בקטע הזה מוגדרים משתני הסביבה שנדרשים ל-loadgen, שהגדרתם קודם כשביצעתם את האפליקציה מהמקור.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: loadgenerator
spec:
  replicas: 1
  selector:
    matchLabels:
      app: loadgenerator
  template:
    metadata:
      labels:
        app: loadgenerator
    spec:
      containers:
      - env:
        - name: SERVER_ADDR
          value: http://hellosvc:80/
        - name: REQUESTS_PER_SECOND
          value: '10'
        image: gcr.io/google-samples/istio/loadgen:v0.0.1
        imagePullPolicy: Always
        name: main
        resources:
          limits:
            cpu: 500m
            memory: 512Mi
          requests:
            cpu: 300m
            memory: 256Mi
      restartPolicy: Always
      terminationGracePeriodSeconds: 5

מכיוון ש-loadgen לא מקבל בקשות נכנסות, השדה type מוגדר ל-ClusterIP. הסוג הזה מספק כתובת IP יציבה ששירותים באשכול יכולים להשתמש בה, אבל כתובת ה-IP לא חשופה ללקוחות חיצוניים.

apiVersion: v1
kind: Service
metadata:
  name: loadgensvc
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: loadgenerator
  type: ClusterIP

פריסת הקונטיינרים ב-GKE

  1. עוברים לספרייה שבה נמצאת הדוגמה server:

    cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/server/

  2. פותחים את server.yaml בכלי לעריכת טקסט.

  3. מחליפים את השם בשדה image בשם של קובץ אימג' של Docker.

    image: gcr.io/PROJECT_ID/asm-ready/helloserver:v0.0.1

    מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

  4. שמירה וסגירה server.yaml.

  5. פורסים את קובץ ה-YAML ל-Kubernetes:

    kubectl apply -f server.yaml

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

    deployment.apps/helloserver created
service/hellosvc created

  6. עוברים לספרייה שבה נמצא הקובץ loadgen.

    cd ../loadgen

  7. פותחים את loadgen.yaml בכלי לעריכת טקסט.

  8. מחליפים את השם בשדה image בשם של קובץ אימג' של Docker.

    image: gcr.io/PROJECT_ID/asm-ready/loadgen:v0.0.1

    מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

  9. שומרים וסוגרים loadgen.yaml, וסוגרים את הכלי לעריכת טקסט.

  10. פורסים את קובץ ה-YAML ל-Kubernetes:

    kubectl apply -f loadgen.yaml

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

    deployment.apps/loadgenerator created
service/loadgensvc created

  11. בודקים את הסטטוס של ה-Pods:

    kubectl get pods

    התגובה של הפקודה תכלול סטטוס שדומה לזה:

    NAME                             READY   STATUS    RESTARTS   AGE
helloserver-69b9576d96-mwtcj     1/1     Running   0          58s
loadgenerator-774dbc46fb-gpbrz   1/1     Running   0          57s

  12. מקבלים את יומני האפליקציה מ-Pod‏ loadgen. מחליפים את POD_ID במזהה מהפלט הקודם.

    kubectl logs loadgenerator-POD_ID

  13. קבלת כתובות ה-IP החיצוניות של hellosvc:

    kubectl get service

    התגובה של הפקודה אמורה להיראות כך:

    NAME         TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
hellosvc     LoadBalancer   10.81.15.158   192.0.2.1       80:31127/TCP   33m
kubernetes   ClusterIP      10.81.0.1      <none>          443/TCP        93m
loadgensvc   ClusterIP      10.81.15.155   <none>          80/TCP         4m52s

  14. שליחת בקשה אל hellosvc. מחליפים את EXTERNAL_IP בכתובת ה-IP החיצונית של hellosvc.

    curl http://EXTERNAL_IP

מוכן ל-Cloud Service Mesh

עכשיו האפליקציה פרוסה ב-GKE. ‫loadgen יכול להשתמש ב-DNS של Kubernetes‏ (hellosvc:80) כדי לשלוח בקשות אלserver, ואפשר לשלוח בקשות אל server עם כתובת IP חיצונית. למרות ש-Kubernetes מספקת לכם תכונות רבות, חסר מידע מסוים על השירותים:

  • איך השירותים פועלים יחד? מה הקשר בין השירותים? איך התעבורה זורמת בין השירותים? אתם יודעים ש-loadgen שולח בקשות אל server, אבל נניח שאתם לא מכירים את האפליקציה. אי אפשר לענות על השאלות האלה על סמך רשימת ה-Pods הפועלים ב-GKE.
  • מדדים: כמה זמן לוקח ל-server להגיב לבקשות נכנסות? כמה בקשות בשנייה (RPS) נכנסות אל server? האם יש תשובות שגיאה?
  • פרטי אבטחה: האם התנועה בין loadgen לבין server היא רגילה HTTP או mTLS?

בעזרת Cloud Service Mesh אפשר לקבל תשובות לשאלות האלה. ‫Cloud Service Mesh היא גרסה מנוהלת של פרויקט הקוד הפתוח Istio. Google Cloud‫Cloud Service Mesh פועל על ידי הצבת פרוקסי של Envoy בקובץ עזר בכל Pod. שרת ה-proxy של Envoy מיירט את כל התנועה הנכנסת והיוצאת לקונטיינרים של האפליקציה. כלומר, ל-server ול-loadgen יש קובץ עזר חיצוני Envoy, וכל התנועה מ-loadgen ל-server מתווכת על ידי פרוקסי Envoy. הקשרים בין שרתי ה-proxy האלה של Envoy יוצרים את Service mesh. ארכיטקטורת ה-service mesh הזו מספקת שכבת בקרה מעל Kubernetes.

Service mesh

מכיוון ששרתי ה-proxy של Envoy פועלים בקונטיינרים משלהם, אתם יכולים להתקין את Cloud Service Mesh על אשכול GKE בלי לבצע שינויים משמעותיים בקוד האפליקציה. עם זאת, יש כמה דרכים עיקריות שבהן הכנתם את האפליקציה להטמעה באמצעות Cloud Service Mesh:

  • שירותים לכל מאגרי התגים: גם לפריסות של server וגם לפריסות של loadgen מצורף שירות Kubernetes. גם ל-loadgen, שלא מקבל בקשות נכנסות, יש שירות.
  • צריך לתת שמות ליציאות בשירותים: למרות ש-GKE מאפשר להגדיר יציאות שירות ללא שם, ב-Cloud Service Mesh צריך לספק שם ליציאה שתואם לפרוטוקול של היציאה. בקובץ ה-YAML, היציאה של server נקראת http כי server משתמש בפרוטוקול התקשורת HTTP. אם השתמשתם ב-service, תצטרכו לתת ליציאה את השם grpc.gRPC
  • פריסות מקבלות תווית: כך אפשר להשתמש בתכונות של Cloud Service Mesh לניהול תעבורת נתונים, כמו פיצול תעבורת נתונים בין גרסאות של אותו שירות.

התקנה של Cloud Service Mesh

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

הסרת המשאבים

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

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

gcloud container clusters delete asm-ready

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