מ-edge לרשת מרובת אשכולות: פריסת אפליקציות מבוזרות גלובלית באמצעות GKE Gateway ו-Cloud Service Mesh

Last reviewed 2026-06-04 UTC

במאמר הזה מוסבר איך לבצע את הפעולות הבאות:

• פריסה של אפליקציות שמפוזרות גלובלית ונחשפות דרך GKE Gateway ו-Cloud Service Mesh.
• אפשר לחשוף אפליקציה לכמה לקוחות על ידי שילוב של Cloud Load Balancing עם Cloud Service Mesh.
• שילוב מאזני עומסים עם Service mesh שנפרס על פני Google Cloud אזורים.

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

ארכיטקטורה

בתרשים הבא מוצגת טופולוגיית ברירת המחדל של Ingress ב-Service Mesh – מאזן עומסים חיצוני של TCP/UDP שחושף את שרתי ה-proxy של שער ה-Ingress באשכול יחיד:

במדריך הפריסה הזה נעשה שימוש במשאבי שער של Google Kubernetes Engine‏ (GKE). הוא משתמש בשער מרובה אשכולות כדי להגדיר איזון עומסים במספר אזורים מול כמה אשכולות של Autopilot שמפוזרים בשני אזורים.

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

מטרות

• פריסה של צמד אשכולות GKE Autopilot ב- Google Cloud באותו צי.
• פריסת Cloud Service Mesh מבוסס Istio לאותו צי.
• מגדירים מאזן עומסים באמצעות GKE Gateway כדי להפסיק תעבורת HTTPS ציבורית.
• הפניית תעבורת HTTPS ציבורית ישירות לאפליקציות שמתארחות ב-Cloud Service Mesh ונפרסות בכמה אשכולות ואזורים.
• פורסים את אפליקציית הדוגמה whereami בשני אשכולות Autopilot.

הוזלת עלויות

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

• Google Kubernetes Engine
• Cloud Load Balancing
• Cloud Service Mesh
• Multi Cluster Ingress
• Google Cloud Armor
• Certificate Manager
• Cloud Endpoints

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

משתמשים חדשים של 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

   מריצים את כל פקודות הטרמינל לפריסה הזו מ-Cloud Shell.

4. מגדירים את Google Cloud פרויקט ברירת המחדל:

   export PROJECT=PROJECT_ID
   export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")
   gcloud config set project PROJECT_ID
   

   מחליפים את PROJECT_ID במזהה הפרויקט שבו רוצים להשתמש לפריסה הזו.

5. יוצרים ספריית עבודה:

   mkdir -p ${HOME}/edge-to-mesh-multi-region
   cd ${HOME}/edge-to-mesh-multi-region
   export WORKDIR=`pwd`
   

יצירת אשכולות GKE

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

1. יוצרים קובץ kubeconfig חדש ב-Cloud Shell. השלב הזה מבטיח שלא ייווצר קונפליקט עם קובץ kubeconfig הקיים (ברירת המחדל).

   touch edge2mesh_mr_kubeconfig
   export KUBECONFIG=${WORKDIR}/edge2mesh_mr_kubeconfig
   

2. הגדרת משתני הסביבה שמשמשים ליצירת אשכולות GKE והמשאבים בתוכם. משנים את ברירת המחדל של האזורים כדי להתאים אותה למטרות שלכם.

   export CLUSTER_1_NAME=edge-to-mesh-01
   export CLUSTER_2_NAME=edge-to-mesh-02
   export CLUSTER_1_REGION=us-central1
   export CLUSTER_2_REGION=us-east4
   export PUBLIC_ENDPOINT=frontend.endpoints.PROJECT_ID.cloud.goog
   

3. מפעילים את ממשקי Google Cloud API שמשמשים לאורך המדריך הזה:

   gcloud services enable \
     container.googleapis.com \
     mesh.googleapis.com \
     gkehub.googleapis.com \
     multiclusterservicediscovery.googleapis.com \
     multiclusteringress.googleapis.com \
     trafficdirector.googleapis.com \
     certificatemanager.googleapis.com
   

4. יצירת אשכול GKE Autopilot עם צמתים פרטיים ב-CLUSTER_1_REGION. כדי לא לחכות עד שהאשכול הראשון יוקצה וירשם ל-Fleet, משתמשים בדגל --async:

   gcloud container clusters create-auto --async \
   ${CLUSTER_1_NAME} --region ${CLUSTER_1_REGION} \
   --release-channel rapid \
   --enable-private-nodes --enable-fleet
   

5. יוצרים ומลงים אשכול שני של Autopilot ב-CLUSTER_2_REGION:

   gcloud container clusters create-auto \
   ${CLUSTER_2_NAME} --region ${CLUSTER_2_REGION} \
   --release-channel rapid \
   --enable-private-nodes --enable-fleet
   

6. מוודאים שהאשכולות פועלים. יכול להיות שיחלפו עד 20 דקות עד שכל האשכולות יפעלו:

   gcloud container clusters list
   

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

   NAME             LOCATION     MASTER_VERSION      MASTER_IP      MACHINE_TYPE   NODE_VERSION        NUM_NODES  STATUS   STACK_TYPE
   edge-to-mesh-01  us-central1  1.35.5-gke.1000000  34.31.166.104  ek-standard-8  1.35.5-gke.1000000  1          RUNNING  IPV4
   edge-to-mesh-02  us-east4     1.35.5-gke.1000000  35.245.233.88  ek-standard-8  1.35.5-gke.1000000  1          RUNNING  IPV4
   

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

   gcloud container clusters get-credentials ${CLUSTER_1_NAME} \
       --region ${CLUSTER_1_REGION}
   

8. כדי להבהיר את השמות של הקונטקסטים של Kubernetes, משנים את השמות שלהם לשמות של האשכולות:

   kubectl config rename-context gke_PROJECT_ID_${CLUSTER_1_REGION}_${CLUSTER_1_NAME} ${CLUSTER_1_NAME}
   kubectl config rename-context gke_PROJECT_ID_${CLUSTER_2_REGION}_${CLUSTER_2_NAME} ${CLUSTER_2_NAME}
   

התקנת service mesh

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

1. ב-Cloud Shell, מפעילים את Cloud Service Mesh בצי:

   gcloud container fleet mesh enable
   

2. הפעלה של ניהול אוטומטי של מישור הבקרה ומישור הנתונים:

   gcloud container fleet mesh update \
     --management automatic \
     --memberships ${CLUSTER_1_NAME},${CLUSTER_2_NAME}
   

3. ממתינים כ-20 דקות. לאחר מכן מוודאים שסטטוס מישור הבקרה הוא ACTIVE:

   gcloud container fleet mesh describe
   

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

   createTime: '2026-06-04T23:40:02.666228685Z'
   membershipSpecs:
     projects/497535075790/locations/us-central1/memberships/edge-to-mesh-01:
       mesh:
         management: MANAGEMENT_AUTOMATIC
     projects/497535075790/locations/us-east4/memberships/edge-to-mesh-02:
       mesh:
         management: MANAGEMENT_AUTOMATIC
   membershipStates:
     projects/497535075790/locations/us-central1/memberships/edge-to-mesh-01:
       servicemesh:
         conditions:
         - code: VPCSC_GA_SUPPORTED
           details: This control plane supports VPC-SC GA.
           documentationLink: http://cloud.google.com/service-mesh/docs/managed/vpc-sc
           severity: INFO
         controlPlaneManagement:
           details:
           - code: REVISION_READY
             details: 'Ready: asm-managed-rapid'
           implementation: TRAFFIC_DIRECTOR
           state: ACTIVE
         dataPlaneManagement:
           details:
           - code: OK
             details: Service is running.
           state: ACTIVE
       state:
         code: OK
         description: 'Revision ready for use: asm-managed-rapid.'
         updateTime: '2026-06-04T23:45:52.958139396Z'
     projects/497535075790/locations/us-east4/memberships/edge-to-mesh-02:
       servicemesh:
         conditions:
         - code: VPCSC_GA_SUPPORTED
           details: This control plane supports VPC-SC GA.
           documentationLink: http://cloud.google.com/service-mesh/docs/managed/vpc-sc
           severity: INFO
         controlPlaneManagement:
           details:
           - code: REVISION_READY
             details: 'Ready: asm-managed-rapid'
           implementation: TRAFFIC_DIRECTOR
           state: ACTIVE
         dataPlaneManagement:
           details:
           - code: OK
             details: Service is running.
           state: ACTIVE
       state:
         code: OK
         description: 'Revision ready for use: asm-managed-rapid.'
         updateTime: '2026-06-04T23:45:54.621862416Z'
   name: projects/e2m-mc-h2c/locations/global/features/servicemesh
   resourceState:
     state: ACTIVE
   spec: {}
   updateTime: '2026-06-04T23:40:55.123874541Z'
   

פריסה של מאזן עומסים חיצוני של אפליקציות (ALB) ויצירה של שערי תעבורת נתונים נכנסת (ingress)

בקטע הזה פורסים מאזן עומסים של אפליקציות (ALB) חיצוני באמצעות GKE Gateway Controller ויוצרים שערי Ingress לשני האשכולות. המשאבים gateway ו-gatewayClass מבצעים אוטומציה של הקצאת מאזן העומסים ובדיקת התקינות של ה-backend. כדי לספק סיום TLS במאזן העומסים, יוצרים משאבים של Certificate Manager ומצרפים אותם למאזן העומסים. בנוסף, אתם יכולים להשתמש בנקודות קצה כדי להקצות באופן אוטומטי שם DNS ציבורי לאפליקציה.

התקנת שער כניסה בשני האשכולות

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

1. ב-Cloud Shell, יוצרים מרחב שמות ייעודי ingress-gateway בכל אשכול:

   kubectl --context=${CLUSTER_1_NAME} create namespace ingress-gateway
   kubectl --context=${CLUSTER_2_NAME} create namespace ingress-gateway
   

2. מוסיפים תווית של מרחב שמות לingress-gateway מרחבי השמות:

   kubectl --context=${CLUSTER_1_NAME} label namespace ingress-gateway istio-injection=enabled
   kubectl --context=${CLUSTER_2_NAME} label namespace ingress-gateway istio-injection=enabled
   

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

   namespace/ingress-gateway labeled
   

   הוספת התווית ingress-gateway למרחבי השמות istio-injection=enabled מורה ל-Cloud Service Mesh להוסיף אוטומטית פרוקסי מסוג Envoy sidecar כשפורסים פוד.

3. יצירת אישור בחתימה עצמית לשימוש עתידי:

   openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 \
    -subj "/CN=frontend.endpoints.PROJECT_ID.cloud.goog/O=Edge2Mesh Inc" \
    -keyout ${WORKDIR}/frontend.endpoints.PROJECT_ID.cloud.goog.key \
    -out ${WORKDIR}/frontend.endpoints.PROJECT_ID.cloud.goog.crt
   

   האישור מספק שכבת הצפנה נוספת בין מאזן העומסים לבין שערי Service mesh. היא גם מפעילה תמיכה בפרוטוקולים מבוססי HTTP/2 כמו gRPC. הוראות לצירוף האישור בחתימה עצמית לשערי הכניסה מופיעות בהמשך המאמר יצירת משאבים של כתובת IP חיצונית, רשומת DNS ואישור TLS.

   אם אתם רוצים להשתמש ב-HTTP/2 לחיבור בין GFE ל-mesh אבל לא צריך הצפנה משלכם, אתם יכולים להשתמש ב-H2C.

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

4. יוצרים סוד של Kubernetes בכל אשכול כדי לאחסן את האישור בחתימה עצמית:

   kubectl --context ${CLUSTER_1_NAME} -n ingress-gateway create secret tls \
    edge2mesh-credential \
    --key=${WORKDIR}/frontend.endpoints.PROJECT_ID.cloud.goog.key \
    --cert=${WORKDIR}/frontend.endpoints.PROJECT_ID.cloud.goog.crt
   kubectl --context ${CLUSTER_2_NAME} -n ingress-gateway create secret tls \
    edge2mesh-credential \
    --key=${WORKDIR}/frontend.endpoints.PROJECT_ID.cloud.goog.key \
    --cert=${WORKDIR}/frontend.endpoints.PROJECT_ID.cloud.goog.crt
   

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

   mkdir -p ${WORKDIR}/asm-ig/base
   
   cat <<EOF > ${WORKDIR}/asm-ig/base/kustomization.yaml
   resources:
     - github.com/GoogleCloudPlatform/anthos-service-mesh-samples/docs/ingress-gateway-asm-manifests/base
   EOF
   
   mkdir ${WORKDIR}/asm-ig/variant
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/role.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: asm-ingressgateway
     namespace: ingress-gateway
   rules:
   - apiGroups: [""]
     resources: ["secrets"]
     verbs: ["get", "watch", "list"]
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/rolebinding.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: asm-ingressgateway
     namespace: ingress-gateway
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: asm-ingressgateway
   subjects:
     - kind: ServiceAccount
       name: asm-ingressgateway
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/service-proto-type.yaml
   apiVersion: v1
   kind: Service
   metadata:
     name: asm-ingressgateway
     namespace: ingress-gateway
   spec:
     ports:
     - name: status-port
       port: 15021
       protocol: TCP
       targetPort: 15021
     - name: http
       port: 80
       targetPort: 8080
       appProtocol: HTTP
     - name: https
       port: 443
       targetPort: 8443
       appProtocol: HTTP2
     type: ClusterIP
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/gateway.yaml
   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: asm-ingressgateway
     namespace: ingress-gateway
   spec:
    servers:
     - port:
         number: 443
         name: https
         protocol: HTTPS
       hosts:
       - "*" # IMPORTANT: Must use wildcard here when using SSL, as SNI isn't passed from GFE
       tls:
         mode: SIMPLE
         credentialName: edge2mesh-credential
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/kustomization.yaml
   namespace: ingress-gateway
   resources:
   - ../base
   - role.yaml
   - rolebinding.yaml
   patches:
   - path: service-proto-type.yaml
     target:
       kind: Service
   - path: gateway.yaml
     target:
       kind: Gateway
   EOF
   

6. החלת ההגדרות של שער הכניסה על שני האשכולות:

   kubectl --context ${CLUSTER_1_NAME} apply -k ${WORKDIR}/asm-ig/variant
   kubectl --context ${CLUSTER_2_NAME} apply -k ${WORKDIR}/asm-ig/variant
   

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

בקטע הזה מייצאים את ה-pods של שער הכניסה באמצעות ServiceExport משאב בהתאמה אישית. צריך לייצא את הפודים של שער הכניסה באמצעות משאב מותאם אישית ServiceExport מהסיבות הבאות:

• מאפשר למאזן העומסים לפנות לתרמילים של שער הכניסה במספר אשכולות.
• מאפשר ל-pods של שער הכניסה להעביר בקשות לשרתים שפועלים בתוך Service mesh.

1. ב-Cloud Shell, מפעילים את התכונה 'שירותים מרובי אשכולות' (MCS) ב-Fleet:

   gcloud container fleet multi-cluster-services enable
   

2. מעניקים ל-MCS את הרשאות ה-IAM הנדרשות לפרויקט או ל-Fleet:

   gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer]" \
    --role "roles/compute.networkViewer"
   

3. יוצרים את קובץ ה-YAML‏ ServiceExport:

   cat <<EOF > ${WORKDIR}/svc_export.yaml
   kind: ServiceExport
   apiVersion: net.gke.io/v1
   metadata:
     name: asm-ingressgateway
     namespace: ingress-gateway
   EOF
   

4. מחילים את קובץ ה-YAML‏ ServiceExport על שני האשכולות:

   kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/svc_export.yaml
   kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/svc_export.yaml
   

   אם מופיעה הודעת השגיאה הבאה, צריך לחכות כמה רגעים עד להתקנה של הגדרות המשאבים המותאמים (CRD) של MCS. לאחר מכן מריצים מחדש את הפקודות כדי להחיל את קובץ ה-YAML‏ ServiceExport על שני האשכולות.

   error: resource mapping not found for name: "asm-ingressgateway" namespace: "ingress-gateway" from "svc_export.yaml": no matches for kind "ServiceExport" in version "net.gke.io/v1"
   ensure CRDs are installed first
   

יצירת משאבים של כתובת IP חיצונית, רשומת DNS ואישור TLS

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

1. ב-Cloud Shell, שומרים כתובת IP חיצונית סטטית:

   gcloud compute addresses create mcg-ip --global
   

   כתובת IP סטטית משמשת את משאב GKE Gateway. כך כתובת ה-IP נשארת זהה, גם אם מאזן העומסים החיצוני נוצר מחדש.

2. מקבלים את כתובת ה-IP הסטטית ומאחסנים אותה כמשתנה סביבה:

   export MCG_IP=$(gcloud compute addresses describe mcg-ip --global --format "value(address)")
   echo ${MCG_IP}
   

   כדי ליצור מיפוי יציב וידידותי למשתמש לכתובת ה-IP של השער, צריך רשומת DNS ציבורית.

   אתם יכולים להשתמש בכל ספק DNS ובכל תוכנית אוטומציה שתרצו. הפריסה הזו משתמשת ב-Endpoints במקום ליצור אזור DNS מנוהל. ‫Endpoints מספקת רשומת DNS בניהול Google בחינם לכתובת IP חיצונית.

3. מריצים את הפקודה הבאה כדי ליצור קובץ YAML בשם dns-spec.yaml:

   cat <<EOF > ${WORKDIR}/dns-spec.yaml
   swagger: "2.0"
   info:
     description: "Cloud Endpoints DNS"
     title: "Cloud Endpoints DNS"
     version: "1.0.0"
   paths: {}
   host: "frontend.endpoints.PROJECT_ID.cloud.goog"
   x-google-endpoints:
   - name: "frontend.endpoints.PROJECT_ID.cloud.goog"
     target: "${MCG_IP}"
   EOF
   

   קובץ dns-spec.yaml מגדיר את רשומת ה-DNS הציבורית בפורמט frontend.endpoints.PROJECT_ID.cloud.goog, כאשר PROJECT_ID הוא המזהה הייחודי של הפרויקט.

4. פורסים את הקובץ dns-spec.yaml כדי ליצור את רשומת ה-DNS. התהליך הזה נמשך כמה דקות.

   gcloud endpoints services deploy ${WORKDIR}/dns-spec.yaml
   

5. יוצרים אישור באמצעות Certificate Manager עבור שם רשומת ה-DNS שיצרתם בשלב הקודם:

   gcloud certificate-manager certificates create mcg-cert \
       --domains="frontend.endpoints.PROJECT_ID.cloud.goog"
   

   אישור TLS (אבטחת שכבת התעבורה) שמנוהל על ידי Google משמש לסיום בקשות של לקוחות נכנסים במאזן העומסים.

6. יצירת מפת אישורים:

   gcloud certificate-manager maps create mcg-cert-map
   

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

7. יוצרים רשומת מיפוי לאישורים לאישור שיצרתם קודם בקטע הזה:

   gcloud certificate-manager maps entries create mcg-cert-map-entry \
       --map="mcg-cert-map" \
       --certificates="mcg-cert" \
       --hostname="frontend.endpoints.PROJECT_ID.cloud.goog"
   

יצירת מדיניות של שירותים לקצה העורפי ומשאבים של מאזן עומסים

בקטע הזה תבצעו את המשימות הבאות:

• יוצרים כללי מדיניות אבטחה של Cloud Armor.
• יוצרים מדיניות שמאפשרת למאזן העומסים לבדוק את זמן התגובה של הפודים של שער הכניסה דרך קובץ ה-YAML‏ ServiceExport שיצרתם קודם.
• משתמשים ב-GKE Gateway API כדי ליצור משאב של מאזן עומסים.
• משתמשים במשאב המותאם אישית GatewayClass כדי להגדיר את הסוג הספציפי של איזון העומסים.
• מפעילים איזון עומסים מרובה אשכולות עבור ה-Fleet ומגדירים אחד מהאשכולות כאשכול ההגדרות של ה-Fleet.

1. ב-Cloud Shell, יוצרים מדיניות אבטחה של Cloud Armor:

   gcloud compute security-policies create edge-fw-policy \
       --description "Block XSS attacks"
   

2. יוצרים כלל למדיניות האבטחה:

   gcloud compute security-policies rules create 1000 \
       --security-policy edge-fw-policy \
       --expression "evaluatePreconfiguredExpr('xss-stable')" \
       --action "deny-403" \
       --description "XSS attack filtering"
   

3. יוצרים קובץ YAML למדיניות האבטחה ומפנים לקובץ ה-YAML של ServiceExport באמצעות קובץ YAML תואם של ServiceImport:

   cat <<EOF > ${WORKDIR}/cloud-armor-backendpolicy.yaml
   apiVersion: networking.gke.io/v1
   kind: GCPBackendPolicy
   metadata:
     name: cloud-armor-backendpolicy
     namespace: ingress-gateway
   spec:
     default:
       securityPolicy: edge-fw-policy
     targetRef:
       group: net.gke.io
       kind: ServiceImport
       name: asm-ingressgateway
   EOF
   

4. מחילים את מדיניות Cloud Armor על שני האשכולות:

   kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/cloud-armor-backendpolicy.yaml
   kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/cloud-armor-backendpolicy.yaml
   

5. יוצרים קובץ YAML בהתאמה אישית שמאפשר למאזן העומסים לבצע בדיקות תקינות מול נקודת הקצה של Envoy לבדיקת תקינות (יציאה 15021 בנתיב /healthz/ready) של הפודים של שער הכניסה בשני האשכולות:

   cat <<EOF > ${WORKDIR}/ingress-gateway-healthcheck.yaml
   apiVersion: networking.gke.io/v1
   kind: HealthCheckPolicy
   metadata:
     name: ingress-gateway-healthcheck
     namespace: ingress-gateway
   spec:
     default:
       config:
         httpHealthCheck:
           port: 15021
           portSpecification: USE_FIXED_PORT
           requestPath: /healthz/ready
         type: HTTP
     targetRef:
       group: net.gke.io
       kind: ServiceImport
       name: asm-ingressgateway
   EOF
   

6. מחילים את קובץ ה-YAML בהתאמה אישית שיצרתם בשלב הקודם על שני האשכולות:

   kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/ingress-gateway-healthcheck.yaml
   kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/ingress-gateway-healthcheck.yaml
   

7. מפעילים איזון עומסים מרובה אשכולות עבור ה-Fleet, ומגדירים את CLUSTER_1_NAME כאשכול ההגדרות:

   gcloud container fleet ingress enable \
     --config-membership=${CLUSTER_1_NAME} \
     --location=${CLUSTER_1_REGION}
   

8. מעניקים הרשאות IAM לבקר של שער הכניסה ב-Fleet:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member "serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-multiclusteringress.iam.gserviceaccount.com" \
       --role "roles/container.admin"
   

9. יוצרים את קובץ ה-YAML של איזון העומסים באמצעות משאב בהתאמה אישית של Gateway שמפנה אל gke-l7-global-external-managed-mc gatewayClass ואל כתובת ה-IP הסטטית שיצרתם קודם:

   cat <<EOF > ${WORKDIR}/frontend-gateway.yaml
   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: external-http
     namespace: ingress-gateway
     annotations:
       networking.gke.io/certmap: mcg-cert-map
   spec:
     gatewayClassName: gke-l7-global-external-managed-mc
     listeners:
     - name: http # list the port only so we can redirect any incoming http requests to https
       protocol: HTTP
       port: 80
     - name: https
       protocol: HTTPS
       port: 443
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
     addresses:
     - type: NamedAddress
       value: mcg-ip
   EOF
   

10. מחילים את קובץ ה-YAML‏ frontend-gateway על שני האשכולות. רק CLUSTER_1_NAME הוא המקור המוסמך, אלא אם מציינים אשכול הגדרות אחר כמקור המוסמך:

    kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/frontend-gateway.yaml
    kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/frontend-gateway.yaml
    

11. יוצרים קובץ HTTPRoute YAML בשם default-httproute.yaml שמכיל את ההגדרות הבאות:

    cat << EOF > ${WORKDIR}/default-httproute.yaml
    apiVersion: gateway.networking.k8s.io/v1
    kind: HTTPRoute
    metadata:
      name: default-httproute
      namespace: ingress-gateway
    spec:
      parentRefs:
      - name: external-http
        namespace: ingress-gateway
        sectionName: https
      rules:
      - backendRefs:
        - group: net.gke.io
          kind: ServiceImport
          name: asm-ingressgateway
          port: 443
    EOF
    

12. מחילים את קובץ ה-YAML‏ HTTPRoute שיצרתם בשלב הקודם על שני האשכולות:

    kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/default-httproute.yaml
    kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/default-httproute.yaml
    

13. כדי לבצע הפניות אוטומטיות מ-HTTP ל-HTTP(S), יוצרים קובץ YAML נוסף בשם default-httproute-redirect.yaml:HTTPRoute

    cat << EOF > ${WORKDIR}/default-httproute-redirect.yaml
    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/v1
    metadata:
      name: http-to-https-redirect-httproute
      namespace: ingress-gateway
    spec:
      parentRefs:
      - name: external-http
        namespace: ingress-gateway
        sectionName: http
      rules:
      - filters:
        - type: RequestRedirect
          requestRedirect:
            scheme: https
            statusCode: 301
    EOF
    

14. מחילים את קובץ ה-YAML של ההפניה האוטומטית HTTPRoute על שני האשכולות:

    kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/default-httproute-redirect.yaml
    kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/default-httproute-redirect.yaml
    

15. בודקים את משאב השער כדי לראות את התקדמות הפריסה של מאזן העומסים:

    kubectl --context=${CLUSTER_1_NAME} describe gateway external-http -n ingress-gateway
    

    בפלט מוצג המידע שהזנתם בקטע הזה.

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

במדריך הזה נעשה שימוש באפליקציית הדוגמה whereami כדי לספק משוב ישיר לגבי האשכולות שמשיבים לבקשות. בקטע הבא מוגדרות שתי פריסות נפרדות של whereami בשני האשכולות: פריסת frontend ופריסת backend.

פריסת frontend היא עומס העבודה הראשון שמקבל את הבקשה. לאחר מכן המערכת קוראת לפריסת backend.

המודל הזה משמש להדגמה של ארכיטקטורת אפליקציה מרובת שירותים. שני השירותים, frontend ו-backend, נפרסים בשני האשכולות.

1. ב-Cloud Shell, יוצרים את מרחבי השמות של whereami frontend ושל whereami backend בשני האשכולות ומפעילים את הזרקת מרחב השמות:

   kubectl --context=${CLUSTER_1_NAME} create ns frontend
   kubectl --context=${CLUSTER_1_NAME} label namespace frontend istio-injection=enabled
   kubectl --context=${CLUSTER_1_NAME} create ns backend
   kubectl --context=${CLUSTER_1_NAME} label namespace backend istio-injection=enabled
   kubectl --context=${CLUSTER_2_NAME} create ns frontend
   kubectl --context=${CLUSTER_2_NAME} label namespace frontend istio-injection=enabled
   kubectl --context=${CLUSTER_2_NAME} create ns backend
   kubectl --context=${CLUSTER_2_NAME} label namespace backend istio-injection=enabled
   

2. יוצרים וריאנט של kustomize עבור whereami backend:

   mkdir -p ${WORKDIR}/whereami-backend/base
   
   cat <<EOF > ${WORKDIR}/whereami-backend/base/kustomization.yaml
   resources:
     - github.com/GoogleCloudPlatform/kubernetes-engine-samples/quickstarts/whereami/k8s
   EOF
   
   mkdir ${WORKDIR}/whereami-backend/variant
   
   cat <<EOF > ${WORKDIR}/whereami-backend/variant/cm-flag.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: whereami
   data:
     BACKEND_ENABLED: "False" # assuming you don't want a chain of backend calls
     METADATA:        "backend"
   EOF
   
   cat <<EOF > ${WORKDIR}/whereami-backend/variant/service-type.yaml
   apiVersion: "v1"
   kind: "Service"
   metadata:
     name: "whereami"
   spec:
     type: ClusterIP
   EOF
   
   cat <<EOF > ${WORKDIR}/whereami-backend/variant/kustomization.yaml
   nameSuffix: "-backend"
   namespace: backend
   labels:
   - includeSelectors: true
     includeTemplates: true
     pairs:
       app: whereami-backend
   resources:
   - ../base
   patches:
   - path: cm-flag.yaml
     target:
       kind: ConfigMap
   - path: service-type.yaml
     target:
       kind: Service
   EOF
   

3. מחילים את וריאנט whereami backend על שני האשכולות:

   kubectl --context=${CLUSTER_1_NAME} apply -k ${WORKDIR}/whereami-backend/variant
   kubectl --context=${CLUSTER_2_NAME} apply -k ${WORKDIR}/whereami-backend/variant
   

4. יוצרים וריאנט של kustomize עבור whereami frontend:

   mkdir -p ${WORKDIR}/whereami-frontend/base
   
   cat <<EOF > ${WORKDIR}/whereami-frontend/base/kustomization.yaml
   resources:
     - github.com/GoogleCloudPlatform/kubernetes-engine-samples/quickstarts/whereami/k8s
   EOF
   
   mkdir whereami-frontend/variant
   
   cat <<EOF > ${WORKDIR}/whereami-frontend/variant/cm-flag.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: whereami
   data:
     BACKEND_ENABLED: "True"
     BACKEND_SERVICE: "http://whereami-backend.backend.svc.cluster.local"
   EOF
   
   cat <<EOF > ${WORKDIR}/whereami-frontend/variant/service-type.yaml
   apiVersion: "v1"
   kind: "Service"
   metadata:
     name: "whereami"
   spec:
     type: ClusterIP
   EOF
   
   cat <<EOF > ${WORKDIR}/whereami-frontend/variant/kustomization.yaml
   nameSuffix: "-frontend"
   namespace: frontend
   labels:
   - includeSelectors: true
     includeTemplates: true
     pairs:
       app: whereami-frontend
   resources:
   - ../base
   patches:
   - path: cm-flag.yaml
     target:
       kind: ConfigMap
   - path: service-type.yaml
     target:
       kind: Service
   EOF
   

5. מחילים את וריאנט whereami frontend על שני האשכולות:

   kubectl --context=${CLUSTER_1_NAME} apply -k ${WORKDIR}/whereami-frontend/variant
   kubectl --context=${CLUSTER_2_NAME} apply -k ${WORKDIR}/whereami-frontend/variant
   

6. יוצרים קובץ YAML‏ VirtualService כדי להפנות בקשות אל frontend:

   cat << EOF > ${WORKDIR}/frontend-vs.yaml
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: whereami-vs
     namespace: frontend
   spec:
     gateways:
     - ingress-gateway/asm-ingressgateway
     hosts:
     - 'frontend.endpoints.PROJECT_ID.cloud.goog'
     http:
     - route:
       - destination:
           host: whereami-frontend
           port:
             number: 80
   EOF
   

7. מחילים את קובץ ה-YAML‏ frontend-vs על שני האשכולות:

   kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/frontend-vs.yaml
   kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/frontend-vs.yaml
   

8. אחרי שפרסתם את frontend-vs.yaml בשני האשכולות, נסו לקרוא לנקודת הקצה הציבורית של האשכולות:

   curl -s https://frontend.endpoints.PROJECT_ID.cloud.goog | jq
   

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

   {
     "backend_result": {
       "cluster_name": "edge-to-mesh-02",
       "gce_instance_id": "8396338201253702608",
       "gce_service_account": "e2m-mcg-01.svc.id.goog",
       "host_header": "whereami-backend.backend.svc.cluster.local",
       "metadata": "backend",
       "node_name": "gk3-edge-to-mesh-02-pool-2-675f6abf-645h",
       "pod_ip": "10.124.0.199",
       "pod_name": "whereami-backend-7cbdfd788-8mmnq",
       "pod_name_emoji": "📸",
       "pod_namespace": "backend",
       "pod_service_account": "whereami-backend",
       "project_id": "e2m-mcg-01",
       "timestamp": "2023-12-01T03:46:24",
       "zone": "us-east4-b"
     },
     "cluster_name": "edge-to-mesh-01",
     "gce_instance_id": "1047264075324910451",
     "gce_service_account": "e2m-mcg-01.svc.id.goog",
     "host_header": "frontend.endpoints.e2m-mcg-01.cloud.goog",
     "metadata": "frontend",
     "node_name": "gk3-edge-to-mesh-01-pool-2-d687e3c0-5kf2",
     "pod_ip": "10.54.1.71",
     "pod_name": "whereami-frontend-69c4c867cb-dgg8t",
     "pod_name_emoji": "🪴",
     "pod_namespace": "frontend",
     "pod_service_account": "whereami-frontend",
     "project_id": "e2m-mcg-01",
     "timestamp": "2023-12-01T03:46:24",
     "zone": "us-central1-c"
   }
   

הערה: הקצאת האישור נמשכת כ-20 דקות. אם לא מתקבלת תגובה, משתמשים בדגל -v בפקודה curl בשלב הזה כדי לבדוק אם השגיאה קשורה לשגיאות TLS.

אם מריצים את הפקודה curl כמה פעמים, אפשר לראות שהתשובות (גם מ-frontend וגם מ-backend) מגיעות מאזורים שונים. בתגובה שלו, מאזן העומסים מספק ניתוב גיאוגרפי. כלומר, מאזן העומסים מנתב בקשות מהלקוח לאשכול הפעיל הקרוב ביותר, אבל הבקשות עדיין מגיעות באופן אקראי. כשבקשות עוברות מדי פעם מאזור אחד לאזור אחר, זמן האחזור והעלות גדלים.

בקטע הבא, מטמיעים איזון עומסים מקומי ב-Service mesh כדי שהבקשות יישארו מקומיות.

הפעלה ובדיקה של איזון עומסים לפי אזור עבור whereami

בקטע הזה מטמיעים איזון עומסים מקומי ב-Service mesh כדי שהבקשות יישארו מקומיות. אתם גם מבצעים כמה בדיקות כדי לראות איך whereami מתמודד עם תרחישי כשל שונים.

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

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

1. ב-Cloud Shell, יוצרים קובץ YAML‏ DestinationRule שמאפשר מעבר לגיבוי אזורי של איזון עומסים לפי מיקום בשירות frontend:

   cat << EOF > ${WORKDIR}/frontend-dr.yaml
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: frontend
     namespace: frontend
   spec:
     host: whereami-frontend.frontend.svc.cluster.local
     trafficPolicy:
       connectionPool:
         http:
           maxRequestsPerConnection: 0
       loadBalancer:
         simple: LEAST_REQUEST
         localityLbSetting:
           enabled: true
       outlierDetection:
         consecutive5xxErrors: 1
         interval: 1s
         baseEjectionTime: 1m
   EOF
   

   בדוגמת הקוד שלמעלה מופעלת ניתוב מקומי רק לשירות frontend. צריך גם הגדרה נוספת שמטפלת בקצה העורפי.

2. מחילים את קובץ ה-YAML‏ frontend-dr על שני האשכולות:

   kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/frontend-dr.yaml
   kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/frontend-dr.yaml
   

3. יוצרים קובץ DestinationRule YAML שמפעיל מעבר ליתירות כשל אזורית של איזון עומסים לפי מיקום בשירות backend:

   cat << EOF > ${WORKDIR}/backend-dr.yaml
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: backend
     namespace: backend
   spec:
     host: whereami-backend.backend.svc.cluster.local
     trafficPolicy:
       connectionPool:
         http:
           maxRequestsPerConnection: 0
       loadBalancer:
         simple: LEAST_REQUEST
         localityLbSetting:
           enabled: true
       outlierDetection:
         consecutive5xxErrors: 1
         interval: 1s
         baseEjectionTime: 1m
   EOF
   

4. מחילים את קובץ ה-YAML‏ backend-dr על שני האשכולות:

   kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/backend-dr.yaml
   kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/backend-dr.yaml
   

   אחרי שמחילים את שני קבוצות קובצי ה-YAML‏ DestinationRule על שני האשכולות, הבקשות נשארות מקומיות לאשכול שאליו הבקשה מנותבת.

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

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

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

   kubectl --context=${CLUSTER_1_NAME} -n ingress-gateway scale --replicas=0 deployment/asm-ingressgateway
   

   הערה: למרות שמוגדר HorizontalPodAutoscaler עם minReplicas:3 לפריסת asm-ingressgateway, שינוי הגודל מושבת באופן זמני כשמספר הרפליקות של הפריסה מוגדר כ-0. מידע נוסף זמין במאמר התאמה אופקית של קבוצות Pod לעומס - Implicit maintenance-mode deactivation.

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

   $ curl -s https://frontend.endpoints.PROJECT_ID.cloud.goog | jq
   {
     "backend_result": {
       "cluster_name": "edge-to-mesh-02",
       "gce_instance_id": "2717459599837162415",
       "gce_service_account": "e2m-mcg-01.svc.id.goog",
       "host_header": "whereami-backend.backend.svc.cluster.local",
       "metadata": "backend",
       "node_name": "gk3-edge-to-mesh-02-pool-2-675f6abf-dxs2",
       "pod_ip": "10.124.1.7",
       "pod_name": "whereami-backend-7cbdfd788-mp8zv",
       "pod_name_emoji": "🏌🏽‍♀",
       "pod_namespace": "backend",
       "pod_service_account": "whereami-backend",
       "project_id": "e2m-mcg-01",
       "timestamp": "2023-12-01T05:41:18",
       "zone": "us-east4-b"
     },
     "cluster_name": "edge-to-mesh-02",
     "gce_instance_id": "6983018919754001204",
     "gce_service_account": "e2m-mcg-01.svc.id.goog",
     "host_header": "frontend.endpoints.e2m-mcg-01.cloud.goog",
     "metadata": "frontend",
     "node_name": "gk3-edge-to-mesh-02-pool-3-d42ddfbf-qmkn",
     "pod_ip": "10.124.1.142",
     "pod_name": "whereami-frontend-69c4c867cb-xf8db",
     "pod_name_emoji": "🏴",
     "pod_namespace": "frontend",
     "pod_service_account": "whereami-frontend",
     "project_id": "e2m-mcg-01",
     "timestamp": "2023-12-01T05:41:18",
     "zone": "us-east4-b"
   }
   

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

   kubectl --context=${CLUSTER_1_NAME} -n ingress-gateway scale --replicas=3 deployment/asm-ingressgateway
   

7. מדמים כשל בשירות backend על ידי צמצום מספר העותקים באזור הראשי ל-0:

   kubectl --context=${CLUSTER_1_NAME} -n backend scale --replicas=0 deployment/whereami-backend
   

   מוודאים שהתשובות משירות frontend מגיעות מהאזור הראשי us-central1 דרך מאזן העומסים, והתשובות משירות backend מגיעות מהאזור המשני us-east4.

   הפלט צריך לכלול גם תשובה לשירות frontend מהאזור הראשי (us-central1), ותשובה לשירות backend מהאזור המשני (us-east4), כצפוי.

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

   kubectl --context=${CLUSTER_1_NAME} -n backend scale --replicas=3 deployment/whereami-backend
   

עכשיו יש לכם מאזן עומסים גלובלי של HTTP(S) שמשמש כקצה קדמי לאפליקציה שלכם שמארחת רשת שירותים במספר אזורים.

הסרת המשאבים

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

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

זהירות: כשמוחקים פרויקט:

• התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
• מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-URL שמשתמשות במזהה הפרויקט, כמו appspot.com, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.

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

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

   כניסה לדף Manage resources

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

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

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

1. ב-Cloud Shell, מוחקים את המשאבים HTTPRoute:

   kubectl --context=${CLUSTER_1_NAME} delete -f ${WORKDIR}/default-httproute-redirect.yaml
   kubectl --context=${CLUSTER_2_NAME} delete -f ${WORKDIR}/default-httproute-redirect.yaml
   kubectl --context=${CLUSTER_1_NAME} delete -f ${WORKDIR}/default-httproute.yaml
   kubectl --context=${CLUSTER_2_NAME} delete -f ${WORKDIR}/default-httproute.yaml
   

2. מחיקת משאבי GKE Gateway:

   kubectl --context=${CLUSTER_1_NAME} delete -f ${WORKDIR}/frontend-gateway.yaml
   kubectl --context=${CLUSTER_2_NAME} delete -f ${WORKDIR}/frontend-gateway.yaml
   

3. מחיקת כללי המדיניות:

   kubectl --context=${CLUSTER_1_NAME} delete -f ${WORKDIR}/ingress-gateway-healthcheck.yaml
   kubectl --context=${CLUSTER_2_NAME} delete -f ${WORKDIR}/ingress-gateway-healthcheck.yaml
   kubectl --context=${CLUSTER_1_NAME} delete -f ${WORKDIR}/cloud-armor-backendpolicy.yaml
   kubectl --context=${CLUSTER_2_NAME} delete -f ${WORKDIR}/cloud-armor-backendpolicy.yaml
   

4. מוחקים את קובצי הייצוא של השירות:

   kubectl --context=${CLUSTER_1_NAME} delete -f ${WORKDIR}/svc_export.yaml
   kubectl --context=${CLUSTER_2_NAME} delete -f ${WORKDIR}/svc_export.yaml
   

5. מוחקים את המשאבים של Cloud Armor:

   gcloud --project=PROJECT_ID compute security-policies rules delete 1000 --security-policy edge-fw-policy --quiet
   gcloud --project=PROJECT_ID compute security-policies delete edge-fw-policy --quiet
   

6. מוחקים את המשאבים של Certificate Manager:

   gcloud --project=PROJECT_ID certificate-manager maps entries delete mcg-cert-map-entry --map="mcg-cert-map" --quiet
   gcloud --project=PROJECT_ID certificate-manager maps delete mcg-cert-map --quiet
   gcloud --project=PROJECT_ID certificate-manager certificates delete mcg-cert --quiet
   

7. מוחקים את רשומת ה-DNS של נקודות הקצה:

   gcloud --project=PROJECT_ID endpoints services delete "frontend.endpoints.PROJECT_ID.cloud.goog" --quiet
   

8. מחיקת כתובת ה-IP הסטטית:

   gcloud --project=PROJECT_ID compute addresses delete mcg-ip --global --quiet
   

9. מוחקים את אשכולות GKE Autopilot. השלב הזה נמשך כמה דקות.

   gcloud --project=PROJECT_ID container clusters delete ${CLUSTER_1_NAME} --region ${CLUSTER_1_REGION} --quiet
   gcloud --project=PROJECT_ID container clusters delete ${CLUSTER_2_NAME} --region ${CLUSTER_2_REGION} --quiet
   

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

• מידע נוסף על תכונות של GKE Gateway שאפשר להשתמש בהן עם רשת השירותים
• מידע על הסוגים השונים של Cloud Load Balancing שזמינים ל-GKE
• מידע על התכונות והפונקציות של Cloud Service Mesh
• לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.

שותפים ביצירת התוכן

מחברים:

• אלכס מטסון | מהנדס מומחה לאפליקציות
• מארק צ'ילברס | מהנדס מומחה לאפליקציות

תורמי תוכן אחרים:

• Abdelfettah Sghiouar | Cloud Developer Advocate
• Greg Bray | Customer Engineer
• Paul Revello | Cloud Solutions Architect
• Valavan Rajakumar | Key Enterprise Architect