שימוש ב-Envoy Proxy לאיזון עומסים של שירותי gRPC ב-GKE

Last reviewed 2019-05-30 UTC

במדריך הזה נסביר איך לחשוף כמה שירותי gRPC שנפרסו ב-Google Kubernetes Engine ‏ (GKE) בכתובת IP חיצונית אחת באמצעות מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי ו-Envoy Proxy. במדריך הזה מודגשים כמה מהתכונות המתקדמות ש-Envoy מספק ל-gRPC.

מבוא

‫gRPC היא מסגרת RPC מבוססת קוד פתוח, שאינה תלויה בשפה, שמבוססת על HTTP/2 ומשתמשת ב-protocol buffers לייצוג יעיל של נתונים בשידור ולסריאליזציה מהירה. בהשראת Stubby, מסגרת ה-RPC הפנימית של Google, ‏ gRPC מאפשרת תקשורת עם השהיה נמוכה בין מיקרו-שירותים ובין לקוחות ניידים וממשקי API.

פרוטוקול gRPC פועל על HTTP/2 ומציע כמה יתרונות על פני HTTP/1.1, כמו קידוד בינארי יעיל, ריבוב של בקשות ותגובות על פני חיבור יחיד ובקרה על זרימת נתונים אוטומטית. בנוסף, פרוטוקול gRPC מציע כמה אפשרויות לאיזון עומסים. ההדרכה הזו מתמקדת במצבים שבהם הלקוחות לא מהימנים, כמו לקוחות ניידים ולקוחות שפועלים מחוץ לגבולות המהימנות של ספק השירות. מבין אפשרויות איזון העומסים ש-gRPC מספק, במדריך הזה נעשה שימוש באיזון עומסים מבוסס-proxy.

במדריך הזה, פורס שירות Kubernetes של TYPE=LoadBalancer, שנחשף כמאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי בשכבת התעבורה (שכבה 4) ב-Google Cloud. השירות הזה מספק כתובת IP ציבורית אחת ומעביר חיבורי TCP ישירות אל השרתים העורפיים שהוגדרו. במדריך, הבק אנד הוא פריסת Kubernetes של מופעי Envoy.

‫Envoy הוא פרוקסי קוד פתוח של שכבת האפליקציה (שכבה 7) שמציע תכונות מתקדמות רבות. במדריך הזה נשתמש בו כדי לסיים חיבורי TLS ולנתב תעבורת gRPC לשירות המתאים ב-Kubernetes. בהשוואה לפתרונות אחרים בשכבת האפליקציה, כמו Kubernetes Ingress, שימוש ישיר ב-Envoy מספק אפשרויות רבות להתאמה אישית, כמו האפשרויות הבאות:

  • זיהוי שירותים
  • אלגוריתמים של איזון עומסים
  • שינוי בקשות ותגובות – למשל, ל-JSON או ל-gRPC-Web
  • אימות בקשות באמצעות אימות טוקנים מסוג JWT
  • בדיקות תקינות של gRPC

אם משלבים מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי עם Envoy, אפשר להגדיר נקודת קצה (כתובת IP חיצונית) שמעבירה תעבורת נתונים לקבוצה של מופעי Envoy שפועלים באשכול Google Kubernetes Engine. לאחר מכן, המופעים האלה משתמשים במידע של שכבת האפליקציה כדי להעביר בקשות באמצעות פרוקסי לשירותי gRPC שונים שפועלים באשכול. מופעי Envoy משתמשים ב-DNS של אשכול כדי לזהות ולאזן עומסים של בקשות gRPC נכנסות לפודים תקינים שפועלים עבור כל שירות. כלומר, איזון העומסים של התנועה מתבצע בפודים לפי בקשת RPC ולא לפי חיבור TCP מהלקוח.

ארכיטקטורה

במדריך הזה פורסים שני שירותי gRPC,‏ echo-grpc ו-reverse-grpc, באשכול Google Kubernetes Engine ‏ (GKE) וחושפים אותם לאינטרנט בכתובת IP ציבורית. התרשים הבא מציג את הארכיטקטורה של חשיפת שני השירותים האלה דרך נקודת קצה אחת:

ארכיטקטורה לחשיפת echo-grpc ו-reverse-grpc דרך נקודת קצה אחת

מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי מקבל בקשות נכנסות מהאינטרנט (לדוגמה, מלקוחות ניידים או מצרכני שירות מחוץ לחברה). מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי מבצע את המשימות הבאות:

  • מאזן עומסים של חיבורים נכנסים לצמתים במאגר. תעבורת הנתונים מועברת אל envoy Kubernetes Service, שחשוף בכל הצמתים באשכול. פרוקסי הרשת של Kubernetes מעביר את החיבורים האלה לקבוצות Pod שמריצות Envoy.
  • מבצע בדיקות תקינות של HTTP בצמתים באשכול.

‫Envoy מבצע את המשימות הבאות:

  • מסיים חיבורי TLS.
  • מגלה את הפודים שמריצים את שירותי gRPC על ידי שליחת שאילתה לשירות ה-DNS הפנימי של האשכול.
  • מנתב את התעבורה ומאזן את העומס על הפודים של שירות gRPC.
  • מבצע בדיקות תקינות של שירותי gRPC בהתאם לפרוטוקול בדיקת התקינות של gRPC.
  • חשיפת נקודת קצה לבדיקת התקינות של מופעי Envoy על ידי מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי.

שירותי ה-gRPC‏ (echo-grpc ו-reverse-grpc) נחשפים כשירותים חסרי ראש (headless) של Kubernetes. המשמעות היא שלא מוקצית כתובת clusterIP, ופרוקסי הרשת של Kubernetes לא מבצע איזון עומסים של תעבורת הנתונים לקבוצות ה-Pod. במקום זאת, נוצרת רשומת DNS A שמכילה את כתובות ה-IP של הפוד בשירות ה-DNS של האשכול. ‫Envoy מגלה את כתובות ה-IP של ה-pod מתוך רשומת ה-DNS הזו ומבצע איזון עומסים ביניהן בהתאם למדיניות שהוגדרה ב-Envoy.

בתרשים הבא מוצגים אובייקטים של Kubernetes שמוזכרים במדריך הזה:

אובייקטים של Kubernetes שמשמשים במדריך הזה, כולל שירותים, קובצי YAML, רשומות DNS A, סודות, פודים ורשומת proxy

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

כדי להעריך את ההוצאות בהתאם לתחזית השימוש שלכם, אתם יכולים להיעזר במחשבון העלויות.

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

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

  1. בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.

    תפקידים שנדרשים כדי לבחור או ליצור פרויקט

    • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

    כניסה לדף לבחירת הפרויקט

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

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

    הפעלת Cloud Shell

הכנת הסביבה

  1. ב-Cloud Shell, מגדירים את הפרויקט שבו רוצים להשתמש במדריך הזה: Google Cloud 

    gcloud config set project PROJECT_ID

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

  2. מפעילים את ממשקי ה-API של Artifact Registry ו-GKE:

    gcloud services enable artifactregistry.googleapis.com \
    container.googleapis.com

יצירת אשכול GKE

  1. ב-Cloud Shell, יוצרים אשכול GKE להרצת שירותי gRPC:

    gcloud container clusters create envoy-grpc-tutorial \
    --enable-ip-alias \
    --release-channel rapid \
    --scopes cloud-platform \
    --workload-pool PROJECT_ID.svc.id.goog \
    --location us-central1-f

    במדריך הזה נעשה שימוש באזור us-central1-f. אפשר להשתמש באזור או בתחום אחרים.

  2. כדי לוודא שההקשר kubectl הוגדר, מציגים את הצמתים באשכול:

    kubectl get nodes --output name

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

    node/gke-envoy-grpc-tutorial-default-pool-c9a3c791-1kpt
node/gke-envoy-grpc-tutorial-default-pool-c9a3c791-qn92
node/gke-envoy-grpc-tutorial-default-pool-c9a3c791-wf2h

יצירת מאגר Artifact Registry

  1. ב-Cloud Shell, יוצרים מאגר חדש לאחסון קובצי אימג' של קונטיינרים:

    gcloud artifacts repositories create envoy-grpc-tutorial-images \
    --repository-format docker \
    --location us-central1

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

  2. נותנים את התפקיד Artifact Registry Reader במאגר לחשבון השירות של Google שמשמש את המכונות הווירטואליות של הצמתים באשכול GKE:

    PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format 'value(projectNumber)')

gcloud artifacts repositories add-iam-policy-binding envoy-grpc-tutorial-images \
    --location us-central1 \
    --member serviceAccount:$PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --role roles/artifactregistry.reader

  3. מוסיפים רשומה של כלי עזר לפרטי כניסה לשם המארח של המאגר לקובץ התצורה של Docker בספריית הבית של Cloud Shell:

    gcloud auth configure-docker us-central1-docker.pkg.dev

    הערך של credential helper מאפשר לכלים של קובצי אימג' של קונטיינר שפועלים ב-Cloud Shell לעבור אימות למיקום המאגר של Artifact Registry כדי לשלוף ולדחוף קובצי אימג' של קונטיינר.

פריסת שירותי gRPC

כדי לנתב תנועה לכמה שירותי gRPC מאחורי מאזן עומסים אחד, פורסים שני שירותי gRPC לדוגמה: echo-grpc ו-reverse-grpc. בשני השירותים יש שיטה אוניטרית שמקבלת מחרוזת בשדה הבקשה content. ‫echo-grpc מגיב עם התוכן ללא שינוי, ואילו reverse-grpc מגיב עם מחרוזת התוכן הפוכה.

  1. ב-Cloud Shell, משכפלים את המאגר שמכיל את שירותי ה-gRPC ועוברים לספריית המאגר:

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
cd kubernetes-engine-samples/networking/grpc-gke-nlb-tutorial/

  2. יוצרים אישור TLS בחתימה עצמית ומפתח פרטי:

    openssl req -x509 -newkey rsa:4096 -nodes -sha256 -days 365 \
    -keyout privkey.pem -out cert.pem -extensions san \
    -config \
    <(echo "[req]";
      echo distinguished_name=req;
      echo "[san]";
      echo subjectAltName=DNS:grpc.example.com
     ) \
    -subj '/CN=grpc.example.com'

  3. יוצרים סוד של Kubernetes בשם envoy-certs שמכיל את אישור ה-TLS בחתימה עצמית ואת המפתח הפרטי:

    kubectl create secret tls envoy-certs \
    --key privkey.pem --cert cert.pem \
    --dry-run=client --output yaml | kubectl apply --filename -

    ‫Envoy משתמש באישור ה-TLS ובמפתח הפרטי הזה כשהוא מסיים חיבורי TLS.

  4. יוצרים את קובצי האימג' של הקונטיינרים עבור האפליקציות לדוגמה echo-grpc ו-reverse-grpc, מעבירים את קובצי האימג' בדחיפה ל-Artifact Registry ופורסים את האפליקציות לאשכול GKE באמצעות Skaffold:

    skaffold run \
    --default-repo=us-central1-docker.pkg.dev/PROJECT_ID/envoy-grpc-tutorial-images \
    --module=echo-grpc,reverse-grpc \
    --skip-tests

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

  5. פורסים את Envoy באשכול GKE באמצעות Skaffold:

    skaffold run \
    --digest-source=none \
    --module=envoy \
    --skip-tests

  6. בודקים ששני פודים מוכנים לכל פריסה:

    kubectl get deployments

    הפלט אמור להיראות כך: הערכים של READY צריכים להיות 2/2 בכל הפריסות.

    NAME           READY   UP-TO-DATE   AVAILABLE   AGE
echo-grpc      2/2     2            2           1m
envoy          2/2     2            2           1m
reverse-grpc   2/2     2            2           1m

  7. מוודאים שקיימים השירותים echo-grpc, ‏envoy ו-reverse-grpc כשירותי Kubernetes:

    kubectl get services --selector skaffold.dev/run-id

    הפלט אמור להיראות כך: גם echo-grpc וגם reverse-grpc צריכים לכלול את הערכים TYPE=ClusterIP ו-CLUSTER-IP=None.

    NAME           TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)         AGE
echo-grpc      ClusterIP      None          <none>           8081/TCP        2m
envoy          LoadBalancer   10.40.2.203   203.0.113.1      443:31516/TCP   2m
reverse-grpc   ClusterIP      None          <none>           8082/TCP        2m

בדיקת שירותי gRPC

כדי לבדוק את השירותים, משתמשים בכלי שורת הפקודה grpcurl.

  1. ב-Cloud Shell, מתקינים את grpcurl:

    go install github.com/fullstorydev/grpcurl/cmd/grpcurl@latest

  2. מקבלים את כתובת ה-IP החיצונית של שירות Kubernetes‏ envoy ושומרים אותה במשתנה סביבה:

    EXTERNAL_IP=$(kubectl get service envoy \
    --output=jsonpath='{.status.loadBalancer.ingress[0].ip}')

  3. שליחת בקשה לאפליקציה לדוגמה echo-grpc:

    grpcurl -v -d '{"content": "echo"}' \
    -proto echo-grpc/api/echo.proto \
    -authority grpc.example.com -cacert cert.pem \
    $EXTERNAL_IP:443 api.Echo/Echo

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

    Resolved method descriptor:
rpc Echo ( .api.EchoRequest ) returns ( .api.EchoResponse );

Request metadata to send:
(empty)

Response headers received:
content-type: application/grpc
date: Wed, 02 Jun 2021 07:18:22 GMT
hostname: echo-grpc-75947768c9-jkdcw
server: envoy
x-envoy-upstream-service-time: 3

Response contents:
{
  "content": "echo"
}

Response trailers received:
(empty)
Sent 1 request and received 1 response

    בכותרת התגובה hostname מוצג השם של echo-grpc הפוד שטיפל בבקשה. אם חוזרים על הפקודה כמה פעמים, אמורים לראות שני ערכים שונים בכותרת התגובה hostname, שמתאימים לשמות של תרמילי ה-echo-grpc.

  4. בודקים את אותה התנהגות בשירות gRPC ההפוך:

    grpcurl -v -d '{"content": "reverse"}' \
    -proto reverse-grpc/api/reverse.proto \
    -authority grpc.example.com -cacert cert.pem \
    $EXTERNAL_IP:443 api.Reverse/Reverse

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

    Resolved method descriptor:
rpc Reverse ( .api.ReverseRequest ) returns ( .api.ReverseResponse );

Request metadata to send:
(empty)

Response headers received:
content-type: application/grpc
date: Wed, 02 Jun 2021 07:20:15 GMT
hostname: reverse-grpc-5c9b974f54-wlfwt
server: envoy
x-envoy-upstream-service-time: 1

Response contents:
{
  "content": "esrever"
}

Response trailers received:
(empty)
Sent 1 request and received 1 response

הגדרות Envoy

כדי להבין טוב יותר את ההגדרה של Envoy, אפשר לעיין בקובץ ההגדרה envoy/k8s/envoy.yaml במאגר Git.

בקטע route_config מפורט איך בקשות נכנסות מנותבות לאפליקציות לדוגמה echo-grpc וreverse-grpc.

route_config:
  name: local_route
  virtual_hosts:
  - name: local_service
    domains:
    - "*"
    routes:
    - match:
        prefix: "/api.Echo/"
      route:
        cluster: echo-grpc
    - match:
        prefix: "/api.Reverse/"
      route:
        cluster: reverse-grpc

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

clusters:
- name: echo-grpc
  connect_timeout: 0.5s
  type: STRICT_DNS
  dns_lookup_family: V4_ONLY
  lb_policy: ROUND_ROBIN
  http2_protocol_options: {}
  load_assignment:
    cluster_name: echo-grpc
    endpoints:
    - lb_endpoints:
      - endpoint:
          address:
            socket_address:
              address: echo-grpc.default.svc.cluster.local
              port_value: 8081
  health_checks:
    timeout: 1s
    interval: 10s
    unhealthy_threshold: 2
    healthy_threshold: 2
    grpc_health_check: {}

השדות type: STRICT_DNS ו-lb_policy: ROUND_ROBIN בהגדרת האשכול מציינים ש-Envoy מבצע חיפושי DNS של שם המארח שצוין בשדה address, ומבצע איזון עומסים בין כתובות ה-IP בתגובה לחיפוש ה-DNS. התשובה מכילה כמה כתובות IP כי אובייקטים של שירות Kubernetes שמגדירים את האפליקציות לדוגמה מציינים שירותים ללא ראש.

השדה http2_protocol_options מציין ש-Envoy משתמש בפרוטוקול HTTP/2 באפליקציות לדוגמה.

השדה grpc_health_check בקטע health_checks מציין ש-Envoy משתמש בפרוטוקול בדיקת התקינות של gRPC כדי לקבוע את התקינות של האפליקציות לדוגמה.

פתרון בעיות

אם נתקלתם בבעיות במדריך הזה, מומלץ לעיין במסמכים הבאים:

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

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

    kubectl port-forward \
    $(kubectl get pods -o name | grep envoy | head -n1) 8080:8090

  2. מחכים עד שהפלט הבא יופיע במסוף:

    Forwarding from 127.0.0.1:8080 -> 8090

  3. לוחצים על הלחצן Web preview (תצוגה מקדימה של אתר) ב-Cloud Shell ובוחרים באפשרות Preview on port 8080 (תצוגה מקדימה ביציאה 8080). ייפתח חלון חדש בדפדפן עם ממשק הניהול.

    ממשק האדמין של Envoy עם תצוגה מקדימה שנבחרה

  4. כשמסיימים, חוזרים ל-Cloud Shell ומקישים על Control+C כדי לסיים את העברת היציאות.

דרכים חלופיות לניתוב תנועת gRPC

אפשר לשנות את הפתרון הזה בכמה דרכים כדי שיתאים לסביבה שלכם.

מאזני עומסים חלופיים בשכבת האפליקציה

חלק מהפונקציות של שכבת האפליקציה ש-Envoy מספקת יכולות להיות מסופקות גם על ידי פתרונות אחרים לאיזון עומסים:

  • אתם יכולים להשתמש במאזן עומסים חיצוני גלובלי של אפליקציות או במאזן עומסים חיצוני אזורי של אפליקציות במקום במאזן עומסים חיצוני של רשת להעברת סיגנל ללא שינוי וב-Envoy בניהול עצמי. שימוש במאזן עומסים חיצוני של אפליקציות (ALB) מספק כמה יתרונות בהשוואה למאזן עומסי רשת חיצוני מסוג passthrough, כמו יכולת מתקדמת לניהול תעבורת נתונים, אישורי TLS מנוהלים ושילוב עם מוצרים אחרים של Google Cloud Google Cloud, כמו Cloud CDN,‏ Google Cloud Armor ו-IAP.

    מומלץ להשתמש במאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או במאזן עומסים חיצוני אזורי של אפליקציות (ALB) אם היכולות לניהול תעבורת נתונים שמספקים מאזני העומסים האלה מתאימות לתרחישי השימוש שלכם, ואם אתם לא צריכים תמיכה באימות מבוסס-אישור לקוח, שנקרא גם אימות mutual TLS ‏(mTLS). מידע נוסף זמין במאמרים הבאים:

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

    כדי שיהיה אפשר לנתב את שירותי הדוגמה במדריך הזה ב-Cloud Service Mesh או ב-Istio Service Mesh, צריך להסיר את השורה clusterIP: None ממניפסטים של שירותי Kubernetes ‏ (echo-service.yaml ו-reverse-service.yaml). המשמעות היא שצריך להשתמש בפונקציונליות של גילוי שירותים ואיזון עומסים ב-Cloud Service Mesh או ב-Istio במקום בפונקציונליות דומה ב-Envoy.

    אם אתם כבר משתמשים ב-Cloud Service Mesh או ב-Istio, מומלץ להשתמש בשער הכניסה כדי לנתב לשירותי ה-gRPC.

  • אפשר להשתמש ב-NGINX במקום ב-Envoy, כפריסה או באמצעות NGINX Ingress Controller for Kubernetes. השתמשנו ב-Envoy במדריך הזה כי הוא מספק פונקציונליות מתקדמת יותר של gRPC, כמו תמיכה בפרוטוקול בדיקת תקינות של gRPC.

קישוריות פנימית לרשת VPC

אם רוצים לחשוף את השירותים מחוץ לאשכול GKE אבל רק בתוך רשת ה-VPC, אפשר להשתמש במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי או במאזן עומסים של אפליקציות פנימי.

כדי להשתמש במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי במקום במאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי, מוסיפים את ההערה cloud.google.com/load-balancer-type: "Internal" למניפסט envoy-service.yaml.

כדי להשתמש במאזן עומסים פנימי של אפליקציות (ALB), אפשר לעיין במאמרי העזרה בנושא הגדרת Ingress למאזני עומסים פנימיים של אפליקציות (ALB).

הסרת המשאבים

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

מחיקת הפרויקט

  1. במסוף Google Cloud , נכנסים לדף Manage resources.

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

מחיקת המשאבים

אם רוצים לשמור את Google Cloud הפרויקט שבו השתמשתם במדריך הזה, צריך למחוק את המשאבים הבודדים:

  1. ב-Cloud Shell, מוחקים את השיבוט המקומי של מאגר ה-Git:

    cd ; rm -rf kubernetes-engine-samples/networking/grpc-gke-nlb-tutorial/

  2. מחיקת אשכול GKE:

    gcloud container clusters delete envoy-grpc-tutorial \
    --location us-central1-f --async --quiet

  3. מחיקת המאגר ב-Artifact Registry:

    gcloud artifacts repositories delete envoy-grpc-tutorial-images \
    --location us-central1 --async --quiet

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