פריסת אפליקציות ל-Windows ב-Kubernetes מנוהל

Last reviewed 2024-08-14 UTC

במאמר הזה מוסבר איך לפרוס את ארכיטקטורת ההפניה שמתוארת במאמר ניהול והתאמה של רשתות לאפליקציות של Windows שפועלות ב-Kubernetes מנוהל.

ההוראות האלה מיועדות לארכיטקטים של ענן, לאדמינים של רשתות ולמומחי IT שאחראים על התכנון והניהול של אפליקציות Windows שפועלות באשכולות של Google Kubernetes Engine ‏ (GKE).

ארכיטקטורה

בתרשים הבא מוצגת ארכיטקטורת ההפניה שבה משתמשים כשפורסים אפליקציות של Windows שפועלות באשכולות GKE מנוהלים.

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

מטרות

• יוצרים ומגדירים אשכול GKE להרצת אפליקציות Windows ושרתי proxy של Envoy.
• פורסים את אפליקציות Windows ומאמתים אותן.
• הגדרת Cloud Service Mesh כמישור הבקרה בשערי Envoy.
• משתמשים ב-Kubernetes Gateway API כדי להקצות את מאזן העומסים של אפליקציות (ALB) הפנימי ולחשוף את שערי Envoy.
• הסבר על פעולות הפריסה הרציפה שיצרתם.

עלויות

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

• Cloud Load Balancing
• Google Kubernetes Engine
• Cloud Service Mesh

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

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

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

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

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

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

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

3. מפעילים את Cloud Shell ואת Cloud Service Mesh API, אם הם עדיין לא מופעלים.

   התפקידים שנדרשים כדי להפעיל ממשקי API

   כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

   הפעלת ממשקי ה-API

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

   הפעלת Cloud Shell

אם אתם מריצים את הבדיקות בסביבת ענן וירטואלי פרטי (VPC) משותפת, אתם צריכים גם לפעול לפי ההוראות ליצירה ידנית של רשת משנה וכלל חומת אש לשרת proxy לבדיקות התגובה של Cloud Load Balancing.

יצירת אשכול GKE

כדי ליצור אשכול GKE, פועלים לפי השלבים הבאים: אשכול GKE משמש להכלה ולהפעלה של אפליקציות Windows ושרתי proxy של Envoy בפריסה הזו.

1. ב-Cloud Shell, מריצים את הפקודה הבאה של Google Cloud CLI כדי ליצור אשכול GKE אזורי עם צומת אחד בכל אחד מ-3 האזורים:

   gcloud container clusters create my-cluster
       --enable-ip-alias \
       --num-nodes=1 \
       --release-channel stable \
       --enable-dataplane-v2 \
       --region us-central1 \
       --scopes=cloud-platform \
       --gateway-api=standard
   

2. מוסיפים את מאגר הצמתים של Windows לאשכול GKE:

   gcloud container node-pools create win-pool \
       --cluster=my-cluster \
       --image-type=windows_ltsc_containerd \
       --no-enable-autoupgrade \
       --region=us-central1 \
       --num-nodes=1 \
       --machine-type=n1-standard-2 \
       --windows-os-version=ltsc2019
   

   הפעולה הזו עשויה להימשך כ-20 דקות.

3. שומרים את מזהה הפרויקט ב- Google Cloud במשתנה סביבה:

   export PROJECT_ID=$(gcloud config get project)
   

4. מתחברים לאשכול GKE:

   gcloud container clusters get-credentials my-cluster --region us-central1
   

5. מציגים רשימה של כל הצמתים באשכול GKE:

   kubectl get nodes
   

   בפלט צריכים להופיע שלושה צמתי Linux ושלושה צמתי Windows.

   אחרי שאשכול GKE מוכן, אפשר לפרוס שתי אפליקציות בדיקה מבוססות-Windows.

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

בקטע הזה פורסים שתי אפליקציות בדיקה מבוססות Windows. שתי אפליקציות הבדיקה מדפיסות את שם המארח שבו האפליקציה פועלת. יוצרים גם Kubernetes Service כדי לחשוף את האפליקציה דרך קבוצות עצמאיות של נקודות קצה ברשת (NEGs).

כשפורסים אפליקציה מבוססת-Windows ושירות Kubernetes באשכול אזורי, נוצר NEG לכל אזור שבו האפליקציה פועלת. בהמשך המדריך הזה מוסבר איך להגדיר את ה-NEGs האלה כקצה עורפי לשירותי Cloud Service Mesh.

1. ב-Cloud Shell, מפעילים את קובץ ה-YAML הבא באמצעות kubectl כדי לפרוס את אפליקציית הבדיקה הראשונה. הפקודה הזו פורסת שלוש מכונות של אפליקציית הבדיקה, אחת בכל אזור.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       app: win-webserver-1
     name: win-webserver-1
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: win-webserver-1
     template:
       metadata:
         labels:
           app: win-webserver-1
         name: win-webserver-1
       spec:
        containers:
         - name: windowswebserver
           image: k8s.gcr.io/e2e-test-images/agnhost:2.36
           command: ["/agnhost"]
           args: ["netexec", "--http-port", "80"]
        topologySpreadConstraints:
         - maxSkew: 1
           topologyKey: kubernetes.io/hostname
           whenUnsatisfiable: DoNotSchedule
           labelSelector:
             matchLabels:
               app: win-webserver-1
        nodeSelector:
         kubernetes.io/os: windows
   

2. מחילים את שירות Kubernetes התואם וחושפים אותו באמצעות NEG:

   apiVersion: v1
   kind: Service
   metadata:
     name: win-webserver-1
     annotations:
       cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "win-webserver-1"}}}'
   spec:
     type: ClusterIP
     selector:
       app: win-webserver-1
     ports:
     - name: http
       protocol: TCP
       port: 80
       targetPort: 80
   

3. מאמתים את הפריסה:

   kubectl get pods
   

   הפלט מראה שיש לאפליקציה שלושה Windows Pods שפועלים.

   NAME                               READY   STATUS    RESTARTS   AGE
   win-webserver-1-7bb4c57f6d-hnpgd   1/1     Running   0          5m58s
   win-webserver-1-7bb4c57f6d-rgqsb   1/1     Running   0          5m58s
   win-webserver-1-7bb4c57f6d-xp7ww   1/1     Running   0          5m58s
   

4. מוודאים ששירות Kubernetes נוצר:

   $ kubectl get svc
   

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

   NAME              TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
   kubernetes        ClusterIP   10.64.0.1            443/TCP   58m
   win-webserver-1   ClusterIP   10.64.6.20           80/TCP    3m35s
   

5. מריצים את הפקודה describe עבור kubectl כדי לוודא שנוצרו קבוצות NEG תואמות עבור שירות Kubernetes בכל אחד מהאזורים שבהם האפליקציה פועלת:

   $ kubectl describe service win-webserver-1
   

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

   Name:              win-webserver-1
   Namespace:         default
   Labels:            
   Annotations:       cloud.google.com/neg: {"exposed_ports": {"80":{"name": "win-webserver-1"}}}
                      cloud.google.com/neg-status: {"network_endpoint_groups":{"80":"win-webserver-1"},"zones":["us-central1-a","us-central1-b","us-central1-c"]}
   Selector:          app=win-webserver-1
   Type:              ClusterIP
   IP Family Policy:  SingleStack
   IP Families:       IPv4
   IP:                10.64.6.20
   IPs:               10.64.6.20
   Port:              http  80/TCP
   TargetPort:        80/TCP
   Endpoints:         10.60.3.5:80,10.60.4.5:80,10.60.5.5:80
   Session Affinity:  None
   Events:
     Type    Reason  Age    From            Message
     ----    ------  ----   ----            -------
     Normal  Create  4m25s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-a".
     Normal  Create  4m18s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-b".
     Normal  Create  4m11s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-c".
     Normal  Attach  4m9s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-a")
     Normal  Attach  4m8s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-c")
     Normal  Attach  4m8s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-b")
   

   הפלט מהפקודה הקודמת מראה שנוצר NEG לכל אזור.

6. אופציונלי: משתמשים ב-CLI של gcloud כדי לוודא שנוצרו קבוצות ה-NEG:

   gcloud compute network-endpoint-groups list
   

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

   NAME                                                        LOCATION            ENDPOINT_TYPE     SIZE
   win-webserver-1                                us-central1-a  GCE_VM_IP_PORT  1
   win-webserver-1                                us-central1-b  GCE_VM_IP_PORT  1
   win-webserver-1                                us-central1-c  GCE_VM_IP_PORT  1
   

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

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       app: win-webserver-2
     name: win-webserver-2
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: win-webserver-2
     template:
       metadata:
         labels:
           app: win-webserver-2
         name: win-webserver-2
       spec:
        containers:
         - name: windowswebserver
           image: k8s.gcr.io/e2e-test-images/agnhost:2.36
           command: ["/agnhost"]
           args: ["netexec", "--http-port", "80"]
        topologySpreadConstraints:
         - maxSkew: 1
           topologyKey: kubernetes.io/hostname
           whenUnsatisfiable: DoNotSchedule
           labelSelector:
             matchLabels:
               app: win-webserver-2
        nodeSelector:
         kubernetes.io/os: windows
   

8. יוצרים את שירות Kubernetes המתאים:

   apiVersion: v1
   kind: Service
   metadata:
     name: win-webserver-2
     annotations:
       cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "win-webserver-2"}}}'
   spec:
     type: ClusterIP
     selector:
       app: win-webserver-2
     ports:
     - name: http
       protocol: TCP
       port: 80
       targetPort: 80
   

9. מאמתים את פריסת האפליקציה:

   kubectl get pods
   

   בודקים את הפלט ומוודאים שיש שלושה Pods שפועלים.

10. מוודאים שנוצרו שירות Kubernetes ושלוש קבוצות NEG:

    kubectl describe service win-webserver-2
    

הגדרת Cloud Service Mesh

בקטע הזה, Cloud Service Mesh מוגדר כמישור הבקרה עבור שערים של Envoy.

כדי למפות את שער Envoy להגדרת הניתוב הרלוונטית של Cloud Service Mesh, מציינים את הפרמטר scope_name. הפרמטר scope_name מאפשר להגדיר כללי ניתוב שונים לשערי Envoy שונים.

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

   gcloud compute firewall-rules create allow-health-checks \
     --network=default \
     --direction=INGRESS \
     --action=ALLOW \
     --rules=tcp \
     --source-ranges="35.191.0.0/16,130.211.0.0/22,209.85.152.0/22,209.85.204.0/22"
   

2. בודקים את הרספונסיביות של האפליקציה הראשונה:

   gcloud compute health-checks create http win-app-1-health-check \
     --enable-logging \
     --request-path="/healthz" \
     --use-serving-port
   

3. בודקים את התגובה של האפליקציה השנייה:

   gcloud compute health-checks create http win-app-2-health-check \
     --enable-logging \
     --request-path="/healthz" \
     --use-serving-port
   

4. יוצרים שירות לקצה העורפי של Cloud Service Mesh לאפליקציה הראשונה:

   gcloud compute backend-services create win-app-1-service \
    --global \
    --load-balancing-scheme=INTERNAL_SELF_MANAGED \
    --port-name=http \
    --health-checks win-app-1-health-check
   

5. יוצרים שירות לקצה העורפי של Cloud Service Mesh לאפליקציה השנייה:

   gcloud compute backend-services create win-app-2-service \
    --global \
    --load-balancing-scheme=INTERNAL_SELF_MANAGED \
    --port-name=http \
    --health-checks win-app-2-health-check
   

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

   BACKEND_SERVICE=win-app-1-service
   APP1_NEG_NAME=win-webserver-1
   MAX_RATE_PER_ENDPOINT=10
   
   gcloud compute backend-services add-backend $BACKEND_SERVICE \
     --global \
     --network-endpoint-group $APP1_NEG_NAME \
     --network-endpoint-group-zone us-central1-b \
     --balancing-mode RATE \
     --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
   
   gcloud compute backend-services add-backend $BACKEND_SERVICE \
     --global \
     --network-endpoint-group $APP1_NEG_NAME \
     --network-endpoint-group-zone us-central1-a \
     --balancing-mode RATE \
     --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
   
   gcloud compute backend-services add-backend $BACKEND_SERVICE \
     --global \
     --network-endpoint-group $APP1_NEG_NAME \
     --network-endpoint-group-zone us-central1-c \
     --balancing-mode RATE \
     --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
   

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

   BACKEND_SERVICE=win-app-2-service
   APP2_NEG_NAME=win-webserver-2
   
   gcloud compute backend-services add-backend $BACKEND_SERVICE \
     --global \
     --network-endpoint-group $APP2_NEG_NAME \
     --network-endpoint-group-zone us-central1-b \
     --balancing-mode RATE \
     --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
   
   gcloud compute backend-services add-backend $BACKEND_SERVICE \
     --global \
     --network-endpoint-group $APP2_NEG_NAME \
     --network-endpoint-group-zone us-central1-a \
     --balancing-mode RATE \
     --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
   
   gcloud compute backend-services add-backend $BACKEND_SERVICE \
     --global \
     --network-endpoint-group $APP2_NEG_NAME \
     --network-endpoint-group-zone us-central1-c \
     --balancing-mode RATE \
     --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
   

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

אחרי שמגדירים את השירותים של Cloud Service Mesh, צריך להגדיר עוד שני משאבים כדי להשלים את ההגדרה של Cloud Service Mesh.

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

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

1. ב-Cloud Shell, יוצרים קובץ YAML בשם gateway.yaml שמגדיר את המשאב Gateway:

   cat <<EOF> gateway.yaml
   name: gateway80
   scope: gateway-proxy
   ports:
   - 8080
   type: OPEN_MESH
   EOF
   

2. יוצרים את המשאב Gateway על ידי הפעלת הקובץ gateway.yaml:

   gcloud network-services gateways import gateway80 \
     --source=gateway.yaml \
     --location=global
   

   השם של Gateway יהיה projects/$PROJECT_ID/locations/global/gateways/gateway80.

   משתמשים בשם של Gateway כשיוצרים HTTPRoutes לכל שירות לקצה העורפי.

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

1. ב-Cloud Shell, מאחסנים את מזהה הפרויקט Google Cloud במשתנה סביבה:

   export PROJECT_ID=$(gcloud config get project)
   

2. יוצרים את קובץ ה-YAML‏ HTTPRoute עבור האפליקציה הראשונה:

   cat <<EOF> win-app-1-route.yaml
   name: win-app-1-http-route
   hostnames:
   - win-app-1
   gateways:
   - projects/$PROJECT_ID/locations/global/gateways/gateway80
   rules:
   - action:
      destinations:
      - serviceName: "projects/$PROJECT_ID/locations/global/backendServices/win-app-1-service"
   EOF
   

3. יוצרים את משאב HTTPRoute לאפליקציה הראשונה:

   gcloud network-services http-routes import win-app-1-http-route \
     --source=win-app-1-route.yaml \
     --location=global
   

4. יוצרים את קובץ ה-YAML של HTTPRoute לאפליקציה השנייה:

   cat <<EOF> win-app-2-route.yaml
   name: win-app-2-http-route
   hostnames:
   - win-app-2
   gateways:
   - projects/$PROJECT_ID/locations/global/gateways/gateway80
   rules:
   - action:
      destinations:
    - serviceName: "projects/$PROJECT_ID/locations/global/backendServices/win-app-2-service"
   EOF
   

5. יוצרים את משאב HTTPRoute עבור האפליקציה השנייה:

   gcloud network-services http-routes import win-app-2-http-route \
     --source=win-app-2-route.yaml \
     --location=global
   

פריסה וחשיפה של שערי Envoy

אחרי שיוצרים את שתי האפליקציות לבדיקה שמבוססות על Windows ואת Cloud Service Mesh, פורסים את שערי Envoy באמצעות יצירת קובץ YAML לפריסה. קובץ ה-YAML של הפריסה מבצע את המשימות הבאות:

• מפעיל את שערי Envoy.
• מגדיר את שערי Envoy כך שישתמשו ב-Cloud Service Mesh בתור מישור הבקרה שלהם.
• המדיניות מגדירה את שערי Envoy כך שישתמשו ב-HTTPRoutes עבור השער שנקרא Gateway80.

פריסת שני שערי Envoy משוכפלים. הגישה הזו עוזרת להפוך את השערים לסובלניים לכשלים ומספקת יתירות. כדי לבצע התאמה אוטומטית לעומס של שערי Envoy על סמך העומס, אפשר להגדיר Horizontal Pod Autoscaler (HPA). אם מחליטים להגדיר Horizontal Pod Autoscaler (HPA), צריך לפעול לפי ההוראות במאמר התאמה אופקית של קבוצות Pod לעומס.

1. ב-Cloud Shell, יוצרים קובץ YAML:

   apiVersion: apps/v1
   kind: Deployment
       metadata:
     creationTimestamp: null
     labels:
       app: td-envoy-gateway
     name: td-envoy-gateway
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: td-envoy-gateway
     template:
       metadata:
         creationTimestamp: null
         labels:
           app: td-envoy-gateway
       spec:
         containers:
         - name: envoy
           image: envoyproxy/envoy:v1.21.6
           imagePullPolicy: Always
           resources:
             limits:
               cpu: "2"
               memory: 1Gi
             requests:
               cpu: 100m
               memory: 128Mi
           env:
           - name: ENVOY_UID
             value: "1337"
           volumeMounts:
             - mountPath: /etc/envoy
               name: envoy-bootstrap
         initContainers:
         - name: td-bootstrap-writer
           image: gcr.io/trafficdirector-prod/xds-client-bootstrap-generator
           imagePullPolicy: Always
           args:
             - --project_number='my_project_number'
             - --scope_name='gateway-proxy'
             - --envoy_port=8080
             - --bootstrap_file_output_path=/var/lib/data/envoy.yaml
             - --traffic_director_url=trafficdirector.googleapis.com:443
             - --expose_stats_port=15005
           volumeMounts:
             - mountPath: /var/lib/data
               name: envoy-bootstrap
         volumes:
           - name: envoy-bootstrap
             emptyDir: {}
   

   • מחליפים את my_project_number במספר הפרויקט.

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

     gcloud projects describe $(gcloud config get project)
      --format="value(projectNumber)"
     

   יציאה 15005 משמשת לחשיפת נקודת הקצה של Envoy Admin בשם /stats. אנחנו משתמשים במידע הזה גם למטרות הבאות:

   • כנקודת קצה של תגובה ממאזן העומסים הפנימי של אפליקציות (ALB).
   • כדי לצרוך מדדים של השירות המנוהל של Google Cloud ל-Prometheus מ-Envoy.

   כשה-Pods של Envoy Gateway פועלים, יוצרים שירות מסוג ClusterIP כדי לחשוף אותם. צריך גם ליצור קובץ YAML בשם BackendConfig. ‫BackendConfig מגדיר בדיקה לא סטנדרטית של מהירות התגובה. הבדיקה הזו משמשת לאימות התגובה של שערים מסוג Envoy.

2. כדי ליצור את הגדרת הקצה העורפי עם בדיקת תגובה לא סטנדרטית, יוצרים קובץ YAML בשם envoy-backendconfig:

   apiVersion: cloud.google.com/v1
   kind: BackendConfig
   metadata:
     name: envoy-backendconfig
   spec:
     healthCheck:
       checkIntervalSec: 5
       timeoutSec: 5
       healthyThreshold: 2
       unhealthyThreshold: 3
       type: HTTP
       requestPath: /stats
       port: 15005
   

   בבדיקת התגובה נעשה שימוש בנקודת הקצה /stats ביציאה 15005 כדי לבדוק באופן רציף את התגובה של שערים מסוג Envoy.

3. יוצרים את שירות שערי Envoy:

   apiVersion: v1
   kind: Service
   metadata:
     name: td-envoy-gateway
     annotations:
       cloud.google.com/backend-config: '{"default": "envoy-backendconfig"}'
   spec:
     type: ClusterIP
     selector:
       app: td-envoy-gateway
     ports:
     - name: http
       protocol: TCP
       port: 8080
       targetPort: 8080
     - name: stats
       protocol: TCP
       port: 15005
       targetPort: 15005
   

4. בודקים את שירות שער Envoy שיצרתם:

   kubectl get svc td-envoy-gateway
   

יצירת המשאב של שער Kubernetes

יצירת המשאב Kubernetes Gateway מקצה את מאזן העומסים של אפליקציות (ALB) הפנימי כדי לחשוף את שערי Envoy.

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

• כל אפליקציה מוצגת באמצעות HTTPS.
• כל אפליקציה משתמשת באישור ייעודי.

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

כדי ליצור את האישורים, משתמשים ב-openssl.

1. ב-Cloud Shell, יוצרים קובץ תצורה עבור האישור הראשון:

   cat <<EOF >CONFIG_FILE
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   [extension_requirements]
   basicConstraints          = CA:FALSE
   keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName            = @sans_list
   [dn_requirements]
   0.organizationName        = example
   commonName                = win-webserver-1.example.com
   [sans_list]
   DNS.1                     = win-webserver-1.example.com
   EOF
   

2. יוצרים מפתח פרטי לאישור הראשון:

   openssl genrsa -out sample_private_key 2048
   

3. יוצרים בקשה לאישור:

   openssl req -new -key sample_private_key -out CSR_FILE -config CONFIG_FILE
   

4. חותמים ומפיקים את האישור הראשון:

   openssl x509 -req -signkey sample_private_key -in CSR_FILE -out sample.crt     -extfile CONFIG_FILE -extensions extension_requirements -days 90
   

5. יוצרים קובץ תצורה לאישור השני:

   cat <<EOF >CONFIG_FILE2
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   [extension_requirements]
   basicConstraints          = CA:FALSE
   keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName            = @sans_list
   [dn_requirements]
   0.organizationName        = example
   commonName                = win-webserver-2.example.com
   [sans_list]
   DNS.1                     = win-webserver-2.example.com
   EOF
   

6. יוצרים מפתח פרטי לאישור השני:

   openssl genrsa -out sample_private_key2 2048
   

7. יוצרים בקשה לאישור:

   openssl req -new -key sample_private_key2 -out CSR_FILE2 -config CONFIG_FILE2
   

8. חותמים על האישור השני ויוצרים אותו:

   openssl x509 -req -signkey sample_private_key2 -in CSR_FILE2 -out sample2.crt     -extfile CONFIG_FILE2 -extensions extension_requirements -days 90
   

ייבוא אישורים כסודות של Kubernetes

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

• מייבאים את האישורים בחתימה עצמית לאשכול GKE בתור סודות של Kubernetes.
• יוצרים כתובת IP סטטית לרשת VPC פנימית.
• יוצרים את משאב Kubernetes Gateway API.
• מוודאים שהאישורים פועלים.

1. ב-Cloud Shell, מייבאים את האישור הראשון כסוד של Kubernetes:

   kubectl create secret tls sample-cert --cert sample.crt --key sample_private_key
   

2. מייבאים את האישור השני כסוד של Kubernetes:

   kubectl create secret tls sample-cert-2 --cert sample2.crt --key sample_private_key2
   

3. כדי להפעיל מאזן עומסים פנימי של אפליקציות (ALB), צריך ליצור כתובת IP סטטית ב-VPC הפנימי:

   gcloud compute addresses create sample-ingress-ip --region us-central1 --subnet default
   

4. יוצרים קובץ YAML של משאב Kubernetes Gateway API:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: internal-https
   spec:
     gatewayClassName: gke-l7-rilb
     addresses:
       - type: NamedAddress
         value: sample-ingress-ip
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
       tls:
         mode: Terminate
         certificateRefs:
         - name: sample-cert
         - name: sample-cert-2
   

   כברירת מחדל, לשער Kubernetes אין נתיבים שמוגדרים כברירת מחדל. השער מחזיר שגיאה מסוג 'הדף לא נמצא' (404) כשנשלחות אליו בקשות.

5. מגדירים קובץ YAML של route שמוגדר כברירת מחדל לשער של Kubernetes, שמעביר את כל הבקשות הנכנסות לשערי Envoy:

     kind: HTTPRoute
     apiVersion: gateway.networking.k8s.io/v1beta1
     metadata:
       name: envoy-default-backend
     spec:
       parentRefs:
       - kind: Gateway
         name: internal-https
       rules:
       - backendRefs:
         - name: td-envoy-gateway
           port: 8080
   

   כדי לוודא שהזרימה מלאה, שולחים בקשות HTTP לשתי האפליקציות. כדי לוודא ששערי Envoy מעבירים תנועה אל ה-Pods של האפליקציה הנכונה, בודקים את כותרת המארח של ה-HTTP.

6. מאתרים את כתובת ה-IP של שער Kubernetes ושומרים אותה במשתנה סביבה:

   export EXTERNAL_IP=$(kubectl get gateway internal-https -o json | jq .status.addresses[0].value -r)
   

7. שליחת בקשה לאפליקציה הראשונה:

   curl --insecure -H "Host: win-app-1" https://$EXTERNAL_IP/hostName
   

8. שולחים בקשה לאפליקציה השנייה:

   curl --insecure -H "Host: win-app-2" https://$EXTERNAL_IP/hostName
   

9. מוודאים ששם המארח שמוחזר מהבקשה תואם ל-Pods שמופעלים ב-win-app-1 וב-win-app-2:

   kubectl get pods
   

   הפלט צריך להציג את win-app-1 ואת win-app-2.

מעקב אחרי שערי Envoy

מעקב אחרי שערי Envoy באמצעות השירות המנוהל של Google Cloud ל-Prometheus.

השירות המנוהל של Google Cloud ל-Prometheus אמור להיות מופעל כברירת מחדל באשכול שיצרתם קודם.

1. ב-Cloud Shell, יוצרים משאב PodMonitoring באמצעות קובץ ה-YAML הבא:

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: prom-envoy
   spec:
     selector:
       matchLabels:
         app: td-envoy-gateway
     endpoints:
     - port: 15005
       interval: 30s
       path: /stats/prometheus
   

   אחרי שמחילים את קובץ ה-YAML, המערכת מתחילה לאסוף מדדים של השירות המנוהל של Google Cloud ל-Prometheus בלוח בקרה.

2. כדי ליצור את לוח הבקרה של המדדים של השירות המנוהל של Google Cloud ל-Prometheus, פועלים לפי ההוראות הבאות:

   1. נכנסים למסוף Google Cloud .
   2. פותחים את התפריט .
   3. לוחצים על פעולות > מעקב > לוחות בקרה.

3. כדי לייבא את לוח הבקרה, פועלים לפי ההוראות הבאות:

   1. במסך מרכזי הבקרה, לוחצים על ספריית דוגמאות.
   2. מזינים envoy בתיבת המסנן.
   3. לוחצים על Istio Envoy Prometheus Overview (סקירה כללית של Istio Envoy Prometheus).
   4. מסמנים את תיבת הסימון.
   5. לוחצים על ייבוא ואז על אישור כדי לייבא את מרכז הבקרה.

4. כדי להציג את לוח הבקרה, פועלים לפי ההוראות הבאות:

   1. לוחצים על רשימת מרכזי הבקרה.
   2. בוחרים באפשרות שילובים.
   3. כדי לראות את לוח הבקרה, לוחצים על Istio Envoy Prometheus Overview.

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

הסרת המשאבים

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

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

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

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

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

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

   כניסה לדף Manage resources

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

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

• מידע נוסף על Google Cloud המוצרים שבהם נעשה שימוש במדריך הפריסה הזה:
  • שיטות מומלצות לרישות ב-GKE
  • שיטות מומלצות להרצה של אפליקציות Kubernetes חסכוניות ב-GKE
  • יכולת הצפייה במישור הבקרה של Cloud Service Mesh
  • שימוש באישורי SSL בניהול עצמי עם מאזני עומסים
• לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.

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

Author: Eitan Eibschutz | Staff Technical Solutions Consultant

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

• John Laham | Solutions Architect
• Kaslin Fields | Developer Advocate
• מרידי (ראג'ו) מקאראג'ו | ראש צוות טכני לתמיכה
• Valavan Rajakumar | Key Enterprise Architect
• ויקטור מורנו | מנהל מוצר, Cloud Networking