העברה של Istio ServiceEntry ל-GCPBackend למכונות וירטואליות ב-Compute Engine

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. מידע נוסף זמין בקטע תיאור שלבי ההשקה.

הערה: המדריך הזה תומך רק ב-Cloud Service Mesh עם ממשקי Istio API, ולא תומך בממשקי Google Cloud API. מידע נוסף זמין במאמר סקירה כללית על Cloud Service Mesh.

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

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

1. גילוי נקודות קצה (Endpoint) – נקודות קצה של מכונות וירטואליות בשירות Backend מתעדכנות אוטומטית כשמוסיפים או מסירים מופעים של מכונות וירטואליות.
2. בדיקת תקינות מרכזית – נקודות קצה של מכונות וירטואליות נבדקות, והתעבורה מנותבת אוטומטית משרתי קצה עורפיים לא תקינים לשרתי קצה עורפיים תקינים.
3. איזון עומסים גלובלי ואלגוריתמים מתקדמים לאיזון עומסים – אפשר לפרוס נקודות קצה של מכונות וירטואליות בכמה אזורים. אפשר להשתמש באלגוריתמים שלנו לאיזון עומסים כדי להגדיר את התנהגות איזון העומסים באזורים האלה. פרטים נוספים זמינים בכתובות https://cloud.google.com/service-mesh/v1.24/docs/service-routing/advanced-load-balancing-overview ו-https://cloud.google.com/service-mesh/v1.24/docs/service-routing/advanced-load-balancing-overview.
4. העברה חלקה: אפשר להשתמש בפיצול תנועה ובשיקוף כדי להעביר תנועה בצורה בטוחה בלי לשבש את האפליקציה.
5. יכולות ניהול משופרות: תהליך ההגדרה והניהול יעיל יותר.

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

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

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

יוצרים או משנים את 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. אם הבקשה מנותבת לשימוש ב-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.