העברת Istio ServiceEntry ל-GCPBackend ל-Cloud Run

בדף הזה מוסבר איך לבצע מיגרציה מ-ServiceEntry ל-GCPBackend, ומוצגות היכולות של Istio לניהול תנועה, שיכולות להבטיח מעבר חלק ובטוח.

למעבר ל-GCPBackend יש יתרונות רבים:

1. קוד אפליקציה פשוט יותר: אפשר לבטל את הצורך בהחדרת JWT של IAM לאפליקציה באופן ידני, וכך לצמצם את המורכבות ואת הסיכוי לשגיאות.
2. אבטחה משופרת: אפשר לנצל את היתרונות של הזרקת JWT של IAM באופן אוטומטי כדי לשפר את האבטחה של התקשורת בין GKE לבין Cloud Run.
3. העברה חלקה: אפשר להשתמש בפיצול תנועה ובשיקוף כדי להעביר תנועה בצורה בטוחה בלי לשבש את האפליקציה.
4. יכולות ניהול משופרות: תהליך ההגדרה והניהול יעיל יותר.

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

בקטעים הבאים אנחנו מניחים:

1. אשכול GKE עם Cloud Service Mesh מופעל.
2. רשומה של שירות Istio.
3. הוגדר משאב GCPBackend עבור שירות Cloud Run.

יוצרים או משנים את VirtualService הקיים כך שיכלול את ServiceEntry ואת GCPBackend כיעדים

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

בדוגמה הבאה מתואר מעבר של 10% מהבקשות אל GCPBackend.

cat <<EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: gcpbackend-migration
  namespace: NAMESPACE
spec:
  hosts:
  - service-entry.com
  http:
  - route:
    - destination:
        host: gcpbackend.com
      weight: 10 # 10% traffic to gcp backend.
    - destination:
        host: service-entry.com
      weight: 90 # 90% traffic to service entry
EOF
kubectl apply -f virtual-service.yaml

כאשר:

• ‫NAMESPACE הוא שם מרחב השמות.

בדוגמה הזו:

• VIRTUAL_SERVICE הוא gcpbackend-migration.
• SERVICE_ENTRY_HOSTNAME הוא service-entry.com.
• GCP_BACKEND_HOSTNAME הוא gcpbackend.com.

(אופציונלי) הגדרת VirtualService לשיקוף תנועה

כדי להבטיח מעבר חלק, אפשר להגדיר שיקוף תעבורה כדי לשלוח עותק של התעבורה אל GCPBackend, תוך המשך ניהול התעבורה בעיקר אל ServiceEntry. כך אפשר לבדוק ולאמת את ההגדרה של GCPBackend בלי להשפיע על זרימת התנועה הראשית. מידע נוסף זמין במאמר בנושא Istio Virtual Service API.

אימות הפונקציונליות

כדי לבדוק את שיעור השגיאות של הבקשות אל $SERVICE_ENTRY_HOSTNAME, אפשר לעיין ביומני האפליקציה או במדדים של Cloud Service Mesh. לא אמורות להיות שגיאות.

כדי לבצע בדיקה מחוץ לאפליקציה, אפשר לפרוס לקוח curl. אם הבקשה מנותבת ל-CloudRun באמצעות GCPBackend API, לא צריך לצרף אליה באופן מפורש אסימון IAM כי Cloud Service Mesh מצרף אותו אוטומטית.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: testcurl
  namespace: default
spec:
  containers:
  - name: curl
    image: curlimages/curl
    command: ["sleep", "3000"]
EOF

kubectl exec testcurl -c curl -- curl "$SERVICE_ENTRY_HOSTNAME"

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