ניתוב תעבורה משירותי Cloud Run לעומסי עבודה של Cloud Service Mesh ב-GKE

בדף הזה מוסבר איך לנתב בצורה מאובטחת תעבורת רשת משירותי Cloud Run לעומסי עבודה של Cloud Service Mesh ב-GKE, כדי להשתמש בממשקי Istio API וליהנות מ-Envoy sidecar בניהול מלא.

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

בקטעים הבאים מניחים שיש לכם אשכול GKE עם Cloud Service Mesh מופעל.

אם לא פרסתם שירות GKE, תוכלו להשתמש בפקודה הבאה כדי לפרוס שירות לדוגמה:

cat <<EOF > /tmp/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: ads
spec:
  ports:
  - port: 9999
    targetPort: 8000
  selector:
    run: ads
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ads
spec:
  replicas: 1
  selector:
    matchLabels:
      run: ads
  template:
    metadata:
      labels:
        run: ads
    spec:
      containers:
      - image: docker.io/waip/simple-http:v1.0.1
        name: my-http2-svc
        ports:
        - protocol: TCP
          containerPort: 8000
      securityContext:
        fsGroup: 1337
EOF
kubectl apply -f /tmp/service.yaml

הגדרת דומיין מותאם אישית למארחי VirtualService

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

  1. יוצרים אזור מנוהל חדש:

    gcloud dns managed-zones create ZONE_NAME \
  --description="zone for service mesh routes" \
  --dns-name=DNS_SUFFIX. \
  --networks=default \
  --visibility=private

    where:

    • ‫ZONE_NAME הוא שם האזור (לדוגמה: prod).
    • ‫DNS_SUFFIX הוא כל מארח DNS תקין (לדוגמה: mesh.private).

  2. יצירת קבוצת רשומות משאבים:

    IP=10.0.0.1
gcloud dns record-sets create '*.'"DNS_SUFFIX." --type=A --zone="ZONE_NAME" \
  --rrdatas=10.0.0.1 --ttl 3600

    מוודאים שכתובת ה-IP (נדרש RFC 1918) לא נמצאת בשימוש. אפשר גם לשמור כתובת IP פנימית סטטית.

  3. ייצוא של VirtualService ללקוחות חיצוניים של Cloud Run:

    cat <<EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: VIRTUAL_SERVICE_NAME
  namespace: NAMESPACE
spec:
  hosts:
  - GKE_SERVICE_NAME.DNS_SUFFIX
  gateways:
  - external-mesh
  http:
  - route:
    - destination:
        host: GKE_SERVICE_NAME
EOF
kubectl apply -f virtual-service.yaml

    where:

    • VIRTUAL_SERVICE_NAME הוא שם של VirtualService.
    • ‫NAMESPACE הוא default אם אתם משתמשים בדוגמה שסיפקנו לשירות, אחרת מחליפים את NAMESPACE בשם מרחב השמות.
    • ‫GKE_SERVICE_NAME הוא ads אם משתמשים בשירות לדוגמה שצוין, אחרת מחליפים את GKE_SERVICE_NAME בשם של שירות GKE.

אפשר להוסיף שער external-mesh כיעד ל-VirtualService קיים, אבל מומלץ ליצור VirtualService נפרד כדי לייצא שירות Kubernetes ללקוחות חיצוניים של Cloud Run. שימוש ב-VirtualService נפרד מאפשר לנהל את השירותים המיוצאים ואת ההגדרות שלהם בלי להשפיע על לקוחות GKE קיימים. בנוסף, חלק מהשדות ב-VirtualServices לא רלוונטיים ל-VirtualServices חיצוני של רשת משנה, אבל ממשיכים לפעול כמצופה בשירותי GKE. לכן, יכול להיות שיהיה יתרון בניהול ובפתרון בעיות של VirtualServices בנפרד.

כדי שגם לקוחות GKE יקבלו את ההגדרה VirtualService, צריך להוסיף את שער mesh או mesh/default.

צריך להגדיר את רשת ה-mesh החיצונית VirtualService באותו מרחב שמות כמו שירות Kubernetes ביעד VirtualService.

הגדרת שירות Cloud Run להצטרפות ל-Service mesh

כדי להוסיף שירות Cloud Run לרשת שירותים:

  1. קובעים את מזהה ה-mesh שתומך באשכול Cloud Service Mesh GKE:

    MESH=$(kubectl get controlplanerevision --namespace istio-system -o json | jq -r '.items[0].metadata.annotations["mesh.cloud.google.com/external-mesh"]')

  2. פורסים שירות Cloud Run באמצעות מזהה הרשת, ומוודאים שמתחברים גם לרשת ה-VPC של האשכול:

    gcloud alpha run deploy --mesh "$MESH" --network default \
  mesh-svc --image=fortio/fortio \
  --region=REGION --project=PROJECT_ID --no-allow-unauthenticated

  3. מוודאים ששירות Cloud Run יכול לשלוח בקשה לעומס העבודה של GKE:

    TEST_SERVICE_URL=$(gcloud run services describe mesh-svc --region REGION --format="value(status.url)" --project=PROJECT_ID)

curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" "$TEST_SERVICE_URL/fortio/fetch/GKE_SERVICE_NAME.DNS_SUFFIX"

    הפלט צריך להיות תגובה תקינה מסוג HTTP 200.

פתרון בעיות

בקטע הזה מוסבר איך לפתור בעיות נפוצות ב-Cloud Service Mesh וב-Cloud Run.

יומנים של Cloud Run Sidecar

שגיאות ב-Envoy מתועדות ב-Cloud Logging.

לדוגמה, אם לחשבון השירות של Cloud Run לא ניתן התפקיד trafficdirector client בפרויקט של רשת ה-mesh, השגיאה הבאה תתועד ביומן:

StreamAggregatedResources gRPC config stream to trafficdirector.googleapis.com:443 closed: 7, Permission 'trafficdirector.networks.getConfigs' denied on resource '//trafficdirector.googleapis.com/projects/525300120045/networks/mesh:test-mesh/nodes/003fb3e0c8927482de85f052444d5e1cd4b3956e82b00f255fbea1e114e1c0208dbd6a19cc41694d2a271d1ab04b63ce7439492672de4499a92bb979853935b03d0ad0' (or it may not exist).

CSDS

אפשר לאחזר את מצב הלקוח של Traffic Director באמצעות CSDS:

gcloud alpha container fleet mesh debug proxy-status --membership=<CLUSTER_MEMBERSHIP> --location=<CLUSTER_LOCATION>
External Clients:
....

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