פריסה קנרית ב-Kubernetes #3: Istio

שימוש ב-Istio+Kiali כדי להפעיל ולהמחיש פריסה קנרית

מאמרים בסדרה זו

1. פריסה קנרית ב-Kubernetes #1: Gitlab CI
2. פריסה קנרית ב-Kubernetes #2: השקות ארגו
3. (המאמר הזה)
4. פריסה קנרית באמצעות Jenkins-X Istio Flagger

פריסה קנרית

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

Istio

ואנחנו מניחים שבקריאת המאמר הזה אתה כבר יודע מה זה Istio. אם לא, אז אתה יכול לקרוא על זה כאן.

בקשה למבחנים

כל תרמיל מכיל שני מיכלים: האפליקציה שלנו ו- istio-proxy.

נשתמש באפליקציית בדיקה פשוטה עם frontend-nginx ו-backend python pods. הפוד nginx פשוט יפנה כל בקשה לתרמיל הקצה האחורי ויעבוד כפרוקסי. פרטים ניתן למצוא ב-yamls הבאים:

• frontend.yaml
• backend.yaml
• istio.yaml

הפעלת יישום הבדיקה בעצמך

אם אתה רוצה ללכת בעקבות הדוגמה שלי ולהשתמש ביישום הבדיקה הזה בעצמך, ראה פרויקט readme.

פריסה ראשונית

כאשר אנו משיקים את הפריסה הראשונה, אנו רואים שבתרמילים של האפליקציה שלנו יש רק 2 מכולות, כלומר, Istio Sidecar בדיוק מיושם:

ואנחנו גם רואים את Istio Gateway Loadbalancer במרחב השמות istio-system:

ייצור תנועה

אנו נשתמש ב-IP הבא כדי ליצור תנועה שתתקבל על ידי הפודים הקדמיים ותועבר אל הפודים האחוריים:

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

נוסיף גם frontend.istio-test לקובץ המארחים שלנו.

הצג Mesh דרך Kiali

התקנו את אפליקציית הבדיקה ואת Istio יחד עם Tracing, Grafana, Prometheus וקיאלי (ראה למטה לפרטים). פרויקט readme). לכן אנו יכולים להשתמש בקיאלי באמצעות:

istioctl dashboard kiali # admin:admin

קיאלי מדמיינת את התנועה הנוכחית דרך Mesh

כפי שאנו יכולים לראות, 100% מהתנועה עוברת לשירות ה-frontend, ולאחר מכן ל-frontend pods עם התווית v1, מכיוון שאנו משתמשים בפרוקסי nginx פשוט שמנתב בקשות לשירות ה-backend, אשר בתורו מפנה אותן ל-backend pods עם תווית v1.

Kiali עובד מצוין עם Istio ומספק פתרון עיבוד Mesh בקופסה. פשוט נהדר.

פריסה קנרית

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

שלב 1: 10%

וכל מה שאנחנו צריכים לעשות הוא להתאים את המשקל של ה-VirtualService פנימה istio.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

אנו רואים ש-10% מהבקשות מנותבות לגרסה 2.

שלב 2: 50%

ועכשיו זה מספיק רק להגדיל אותו ל-50%:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50

שלב 3: 100%

כעת הפריסה של Canary יכולה להיחשב כשלמה וכל התעבורה מופנית לגרסה 2:

בדיקת קנרי באופן ידני

נניח שאנו שולחים כעת 2% מכל הבקשות ל-v10 backend. מה אם נרצה לבדוק ידנית את v2 כדי לוודא שהכל עובד כפי שאנו מצפים?

אנו יכולים להוסיף כלל התאמה מיוחד המבוסס על כותרות HTTP:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

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

בקשות ללא כותרת עדיין יונעו על ידי היחס של 1/10:

קנרי לשתי גרסאות תלויות

כעת נשקול את האפשרות שבה יש לנו גרסה v2 הן עבור החזית והן עבור הקצה האחורי. עבור שניהם, ציינו ש-10% מהתנועה צריכים לעבור לגרסה 2:

אנו רואים ש-frontend v1 ו-v2 שניהם תעבורה קדימה ביחס של 1/10 ל-backend v1 ו-v2.

מה אם היינו צריכים להעביר תעבורה מ-frontend-v2 רק ל-backend-v2 כי זה לא תואם ל-v1? לשם כך, נגדיר יחס של 1/10 ל-frontend, השולט באיזו תנועה מגיעה ל-backend-v2 באמצעות משא ומתן sourceLabels :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

כתוצאה מכך, אנחנו מקבלים את מה שאנחנו צריכים:

הבדלים מהגישה הקנרית הידנית

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

Istio מאפשר לקבוע את יחס הבקשות ללא קשר למספר ההעתקים. משמעות הדבר היא, למשל, שאנו יכולים להשתמש ב-HPAs (Horizontal Pod Autoscalers) ואין צורך להגדיר אותם בהתאם למצב הנוכחי של הפריסה הקנרית.

סך הכל

Istio עובד מצוין והשימוש בו יחד עם קיאלי יוצר שילוב חזק מאוד. הבא ברשימת תחומי העניין שלי הוא שילוב של Spinnaker עם Istio לאוטומציה וניתוח קנרי.

מקור: www.habr.com