استقرار قناری در Kubernetes #3: Istio

استفاده از ایستیو + کیالی برای راه اندازی و تجسم استقرار قناری

مقالات این مجموعه

1. استقرار Canary در Kubernetes #1: Gitlab CI
2. استقرار Canary در Kubernetes #2: Argo Rollouts
3. (این مقاله)
4. استقرار قناری با استفاده از Jenkins-X Istio Flagger

استقرار قناری

امیدواریم مطالعه کرده باشید قسمت اول، جایی که به طور خلاصه توضیح دادیم که استقرار Canary چیست و نحوه پیاده سازی آنها را با استفاده از منابع استاندارد Kubernetes نشان دادیم.

ایستیو

و ما فرض می کنیم که با خواندن این مقاله از قبل می دانید ایستیو چیست. اگر نه، پس می توانید در مورد آن بخوانید اینجا.

درخواست برای آزمایش

هر پاد شامل دو ظرف است: برنامه ما و istio-proxy.

ما از یک برنامه آزمایشی ساده با غلاف های frontend-nginx و python backend استفاده خواهیم کرد. پاد nginx به سادگی هر درخواست را به غلاف باطن هدایت می کند و به عنوان یک پروکسی کار می کند. جزئیات را می توان در یامل های زیر یافت:

• frontend.yaml
• backend.yaml
• isio.yaml

خودتان برنامه آزمایشی را اجرا کنید

اگر می خواهید از من الگو بگیرید و خودتان از این برنامه آزمایشی استفاده کنید، ببینید پروژه readme.

استقرار اولیه

وقتی اولین Deployment را راه اندازی می کنیم، می بینیم که پادهای برنامه ما فقط 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 به فایل میزبان ما.

مش را از طریق کیالی مشاهده کنید

ما برنامه آزمایشی و Istio را به همراه Tracing، Grafana، Prometheus و Kiali نصب کردیم (برای جزئیات به زیر مراجعه کنید). پروژه readme). بنابراین می توانیم از Kiali از طریق زیر استفاده کنیم:

istioctl dashboard kiali # admin:admin

کیالی ترافیک فعلی را از طریق مش تجسم می کند

همانطور که می بینیم، 100٪ از ترافیک به سرویس frontend و سپس به پادهای frontend با برچسب v1 می رود، زیرا ما از یک پروکسی ساده nginx استفاده می کنیم که درخواست ها را به سرویس باطن هدایت می کند، که به نوبه خود آنها را به پادهای باطن هدایت می کند. با برچسب v1.

کیالی با ایستیو عالی کار می کند و راه حل رندر مش جعبه ای را ارائه می دهد. عالیه.

استقرار قناری

باطن ما در حال حاضر دو استقرار k8s دارد، یکی برای v1 و دیگری برای v2. اکنون فقط باید به Istio بگوییم که درصد مشخصی از درخواست ها را به v2 ارسال کند.

مرحله 1: 10٪

و تنها کاری که باید انجام دهیم این است که وزن VirtualService را در آن تنظیم کنیم isio.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 را کامل در نظر گرفت و تمام ترافیک به v2 هدایت می شود:

تست قناری به صورت دستی

فرض کنید اکنون 2٪ از تمام درخواست ها را به باطن v10 ارسال می کنیم. اگر بخواهیم نسخه 2 را به صورت دستی آزمایش کنیم تا مطمئن شویم همه چیز همانطور که انتظار داریم کار می کند چه؟

می‌توانیم یک قانون تطبیق ویژه بر اساس هدرهای 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 را هم برای frontend و هم برای backend داریم. برای هر دو، ما مشخص کردیم که 10٪ از ترافیک باید به v2 برود:

می بینیم که frontend v1 و v2 هر دو ترافیک رو به جلو با نسبت 1/10 به backend v1 و v2 دارند.

اگر لازم بود ترافیک را فقط از frontend-v2 به backend-v2 منتقل کنیم، زیرا با v1 سازگار نیست؟ برای انجام این کار، نسبت 1/10 را برای فرانت‌اند تعیین می‌کنیم که با استفاده از مذاکره، میزان ترافیکی که به 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. در آنجا با تغییر تعداد کپی‌ها، نسبت درخواست‌ها را کنترل کردیم. این روش کار می کند، اما دارای اشکالات جدی است.

ایستیو امکان تعیین نسبت درخواست ها را بدون توجه به تعداد کپی ها ممکن می سازد. به عنوان مثال، این بدان معناست که ما می توانیم از HPA ها (Horizontal Pod Autoscalers) استفاده کنیم و نیازی به پیکربندی بر اساس وضعیت فعلی استقرار Canary نداریم.

مجموع

ایستیو عالی عمل می کند و استفاده از آن در کنار کیالی ترکیبی بسیار قدرتمند را ایجاد می کند. بعدی در لیست علایق من، ترکیب Spinnaker با Istio برای اتوماسیون و تجزیه و تحلیل قناری است.

منبع: www.habr.com