🥇חזרה לשירותי מיקרו עם Istio. חלק 2

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

אנו גם מזכירים לך שהמאמר משתמש בתצורות (מניפסטים עבור Kubernetes ו-Istio) מהמאגר istio-mastery.

ניהול תעבורה

עם Istio, יכולות חדשות מופיעות באשכול כדי לספק:

ניתוב בקשות דינמיות: השקות קנריות, בדיקות A/B;
איזון עומסים: פשוט ועקבי, מבוסס על hashes;
התאוששות לאחר נפילות: פסק זמן, ניסיונות חוזרים, מפסקים;
הכנסת תקלות: עיכובים, ביטול בקשות וכו'.

בהמשך המאמר, יכולות אלו יומחשו באמצעות האפליקציה שנבחרה כדוגמה ומושגים חדשים יוצגו לאורך הדרך. הרעיון הראשון כזה יהיה DestinationRules (כלומר כללים לגבי הנמען של תעבורה/בקשות - תרגום בקירוב), בעזרתם אנו מפעילים בדיקות A/B.

בדיקת A/B: DestinationRules בפועל

בדיקת A/B משמשת במקרים בהם קיימות שתי גרסאות של אפליקציה (בדרך כלל הן שונות מבחינה ויזואלית) ואנחנו לא בטוחים ב-100% איזו מהן תשפר את חווית המשתמש. לכן, אנו מריצים את שתי הגרסאות בו זמנית ואוספים מדדים.

כדי לפרוס את הגרסה השנייה של ה-frontend, הנדרשת להדגמת בדיקות A/B, הפעל את הפקודה הבאה:

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created

מניפסט הפריסה של הגרסה הירוקה שונה בשני מקומות:

התמונה מבוססת על תג אחר - istio-green,
לתרמילים יש תווית version: green.

מכיוון שלשתי הפריסות יש תווית app: sa-frontend,בקשות מנותבות על ידי שירות וירטואלי sa-external-services לשירות sa-frontend, יופנה לכל המופעים שלו והעומס יופץ דרך אלגוריתם עגול, מה שיוביל למצב הבא:

הקבצים המבוקשים לא נמצאו

קבצים אלה לא נמצאו מכיוון שהם נקראים בצורה שונה בגרסאות שונות של היישום. בואו נוודא את זה:

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

משמעות הדבר הוא כי index.html, המבקש גרסה אחת של קבצים סטטיים, יכול להישלח על ידי מאזן העומס ל-pods שיש להם גרסה אחרת, שבהם, מסיבות ברורות, קבצים כאלה אינם קיימים. לכן, על מנת שהאפליקציה תעבוד, עלינו להגדיר הגבלה: "אותה גרסה של האפליקציה ששירתה index.html צריכה לשרת בקשות עוקבות".

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

חוקי יעד

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

ניהול תנועה עם משאבי Istio

שים לב: ההשפעה של משאבי Istio על תעבורת הרשת מוצגת כאן בצורה קלה להבנה. ליתר דיוק, ההחלטה לאיזה מופע לשלוח את הבקשה מתקבלת על ידי השליח ב-Ingress Gateway המוגדר ב-CRD.

עם Destination Rules, אנו יכולים להגדיר איזון עומסים לשימוש ב-hash עקבי ולהבטיח שאותו מופע שירות מגיב לאותו משתמש. התצורה הבאה מאפשרת לך להשיג זאת (destinationrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - Hash ייווצר על סמך התוכן של כותרת ה-HTTP version.

החל את התצורה עם הפקודה הבאה:

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created

כעת הפעל את הפקודה למטה וודא שאתה מקבל את הקבצים הנכונים כאשר אתה מציין את הכותרת version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

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

באופן כללי, ל-DestinationRules יש יותר יכולות בתחום איזון עומסים - בדוק לפרטים ב תיעוד רשמי.

לפני שנלמד יותר את VirtualService, בואו נמחק את "הגרסה הירוקה" של האפליקציה ואת כלל כיוון התנועה המתאים על ידי הפעלת הפקודות הבאות:

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” deleted
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” deleted

שיקוף: שירותים וירטואליים בפועל

הַצלָלָה ("מגן") או שיקוף ("שיקוף") משמש במקרים בהם אנו רוצים לבדוק שינוי בייצור מבלי להשפיע על משתמשי הקצה: לשם כך, אנו משכפלים ("שיקוף") בקשות למקרה שני שבו בוצעו השינויים הרצויים, ובוחנים את ההשלכות. במילים פשוטות, זה כאשר הקולגה שלך בוחר את הנושא הקריטי ביותר ומגיש בקשה למשוך בצורה של גוש עפר כל כך ענק שאף אחד לא באמת יכול לבדוק אותו.

כדי לבדוק את התרחיש הזה בפעולה, בואו ניצור מופע שני של SA-Logic עם באגים (buggy) על ידי הפעלת הפקודה הבאה:

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created

ועכשיו בואו נריץ את הפקודה כדי לוודא שכל המופעים עם app=sa-logic יש להם גם תוויות עם הגרסאות המתאימות:

$ kubectl get pods -l app=sa-logic --show-labels
NAME                              READY   LABELS
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

שירות sa-logic ממקד לתרמילים עם תווית app=sa-logic, כך שכל הבקשות יחולקו בין כל המופעים:

... אבל אנחנו רוצים שבקשות יישלחו למופעי v1 וישוקפו למופעי v2:

נשיג זאת באמצעות VirtualService בשילוב עם DestinationRule, כאשר הכללים יקבעו את קבוצות המשנה והמסלולים של ה-VirtualService לקבוצת משנה ספציפית.

הגדרת קבוצות משנה בכללי יעד

קבוצות משנה (קבוצות משנה) נקבעים על ידי התצורה הבאה (sa-logic-subsets-destinationrule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

מנחה (host) מגדיר שכלל זה חל רק על מקרים שבהם המסלול הולך לכיוון השירות sa-logic;
כותרות (name) ערכות משנה משמשות בעת ניתוב למופעי משנה;
תווית (label) מגדיר את צמדי המפתח-ערך שמופעים חייבים להתאים כדי להפוך לחלק מקבוצת המשנה.

החל את התצורה עם הפקודה הבאה:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic created

כעת, לאחר שקבוצות המשנה מוגדרות, אנו יכולים להמשיך ולהגדיר את ה-VirtualService להחיל כללים על בקשות ל-sa-logic כך שהם:

מנותב לקבוצת משנה v1,
שיקוף לקבוצת משנה v2.

המניפסט הבא מאפשר לך להשיג את התוכניות שלך (sa-logic-subsets-shadowing-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

אין צורך בהסבר כאן, אז בוא נראה את זה בפעולה:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic created

בואו נוסיף את העומס על ידי קריאה לפקודה הבאה:

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done

בואו נסתכל על התוצאות בגראפאנה, שם תוכלו לראות שהגרסה עם באגים (buggy) גורם לכישלון של ~60% מהבקשות, אך אף אחד מהכשלים הללו לא משפיע על משתמשי הקצה מכיוון שהם נענים על ידי שירות פועל.

תגובות מוצלחות של גרסאות שונות של שירות sa-logic

כאן ראינו לראשונה כיצד VirtualService מוחל על שליחי השירותים שלנו: מתי sa-web-app מגיש בקשה ל sa-logic, הוא עובר דרך ה-sidecar Envoy, אשר - באמצעות VirtualService - מוגדר לנתב את הבקשה לתת-ה-v1 ולשקף את הבקשה לתת-ה-v2 של השירות sa-logic.

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

השקות קנריות

Canary Deployment הוא תהליך של השקת גרסה חדשה של אפליקציה למספר קטן של משתמשים. הוא משמש כדי לוודא שאין בעיות במהדורה ורק לאחר מכן, כבר בהיותם בטוחים באיכותו (של ההפצה), להפיץ אותו למשתמשים אחרים.оקהל גדול יותר.

כדי להדגים השקות קנריות, נמשיך לעבוד עם תת-קבוצה buggy у sa-logic.

בואו לא נבזבז זמן על זוטות ונשלח מיד 20% מהמשתמשים לגרסה עם באגים (זה יייצג את ההפצה הקנרית שלנו), ואת 80% הנותרים לשירות הרגיל. כדי לעשות זאת, השתמש בשירות הווירטואלי הבא (sa-logic-subsets-canary-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1 זה המשקל (weight), המציין את אחוז הבקשות שיופנו לנמען או לקבוצת משנה של הנמען.

בואו נעדכן את התצורה הקודמת של VirtualService עבור sa-logic עם הפקודה הבאה:

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

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

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

VirtualServices מאפשרים השקות קנריות: במקרה זה, צמצמנו את ההשפעה הפוטנציאלית של הבעיות ל-20% מבסיס המשתמשים. נִפלָא! כעת, בכל מקרה שבו איננו בטוחים בקוד שלנו (במילים אחרות - תמיד...), נוכל להשתמש בשיקוף וב-Canary rollouts.

פסקי זמן וניסיונות חוזרים

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

לצורך הדגמה נמשיך להשתמש באותה גרסת בעיה sa-logic (buggy), ונדמות את חוסר האמינות של הרשת עם כשלים אקראיים.

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

כדי למתן את ההשפעה של בעיות כאלה ולשפר את החיים עבור המשתמשים, אנו יכולים:

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

לצורך יישום, נשתמש בהגדרת המשאב הבאה (sa-logic-retries-timeouts-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

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

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

החל את התצורה המעודכנת באמצעות הפקודה הבאה:

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

ובדקו בגרפים של Grafana שמספר התגובות המוצלחות גדל למעלה:

שיפורים בסטטיסטיקה של תגובה מוצלחת לאחר הוספת פסקי זמן וניסיונות חוזרים

לפני שנעבור לסעיף הבא (או ליתר דיוק, לחלק הבא של המאמר, כי בזה לא יהיו יותר ניסויים מעשיים - בערך תרגום), למחוק sa-logic-buggy ו- VirtualService על ידי הפעלת הפקודות הבאות:

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deleted

דפוסי מפסק ודפוסי מחיצה

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

מַפְסֵק ("מפסק") משמש כדי לסיים בקשות המגיעות למופע של שירות שנחשב לא בריא ולשחזר אותו בזמן שבקשות לקוח מופנות למופעים בריאים של אותו שירות (מה שמגדיל את אחוז התגובות המוצלחות). (הערה: ניתן למצוא תיאור מפורט יותר של התבנית, למשל, כאן.)

ראש גדול ("חֲלוּקָה") מבודד כשלי שירות מלהשפיע על המערכת כולה. לדוגמה, שירות B מקולקל ושירות אחר (לקוח של שירות ב') מגיש בקשה לשירות ב', מה שגורם לו למצות את מאגר השרשורים שלו ולא להיות מסוגל לתת שירות בבקשות אחרות (גם אם הן לא משירות ב'). (הערה: ניתן למצוא תיאור מפורט יותר של התבנית, למשל, כאן.)

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

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

"חזרה לשירותי מיקרו עם Istio": חלק 1 (מבוא לתכונות העיקריות), חלק 3 (אימות והרשאה);
«Conduit - רשת שירות קלת משקל עבור Kubernetes";
«מהי רשת שירות ולמה אני צריך אותה [עבור אפליקציית ענן עם מיקרו-שירותים]?".

מקור: www.habr.com

חזרה לשירותי מיקרו עם Istio. חלק 2