კანარის განლაგება კუბერნეტესში #3: ისტიო

Istio+Kiali-ის გამოყენება კანარის განლაგების დასაწყებად და ვიზუალიზაციისთვის

სტატიები ამ სერიის

1. კანარის განლაგება Kubernetes #1-ში: Gitlab CI
2. კანარის განლაგება Kubernetes #2: Argo Rollouts
3. (Ეს არტიკლი)
4. კანარის განლაგება Jenkins-X Istio Flagger-ის გამოყენებით

კანარის განლაგება

ვიმედოვნებთ, რომ წაიკითხავთ პირველი ნაწილი, სადაც მოკლედ ავუხსენით რა არის Canary-ის განლაგება და ვაჩვენეთ როგორ განხორციელდეს ისინი Kubernetes-ის სტანდარტული რესურსების გამოყენებით.

ისტიო

და ჩვენ ვვარაუდობთ, რომ ამ სტატიის წაკითხვით თქვენ უკვე იცით რა არის ისტიო. თუ არა, მაშინ შეგიძლიათ წაიკითხოთ ამის შესახებ აქ.

განაცხადი ტესტებისთვის

თითოეული პოდი შეიცავს ორ კონტეინერს: ჩვენს აპლიკაციას და istio-proxy-ს.

ჩვენ გამოვიყენებთ მარტივ სატესტო აპლიკაციას frontend-nginx და backend python pods-ით. nginx pod უბრალოდ გადამისამართებს თითოეულ მოთხოვნას backend pod-ზე და იმუშავებს როგორც პროქსი. დეტალები შეგიძლიათ იხილოთ შემდეგ იამლებში:

• წინა ნაწილი.yaml
• backend.yaml
• istio.yaml

თავად გაუშვით სატესტო აპლიკაცია

თუ გსურთ მიბაძოთ ჩემს მაგალითს და თავად გამოიყენოთ ეს სატესტო აპლიკაცია, იხილეთ პროექტი წაიკითხე.

საწყისი განლაგება

როდესაც ჩვენ ვიწყებთ პირველ განლაგებას, ვხედავთ, რომ ჩვენი აპლიკაციის პოდებს მხოლოდ 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 ჩვენს მასპინძლების ფაილში.

ბადის ნახვა კიალის გავლით

ჩვენ დავაინსტალირეთ სატესტო აპლიკაცია და ისტიო Tracing-თან, Grafana-სთან, Prometheus-თან და Kiali-სთან ერთად (დაწვრილებით იხილეთ ქვემოთ). პროექტი წაიკითხე). ამიტომ ჩვენ შეგვიძლია გამოვიყენოთ Kiali შემდეგი გზით:

istioctl dashboard kiali # admin:admin

Kiali ასახავს მიმდინარე ტრაფიკს Mesh-ის მეშვეობით

როგორც ვხედავთ, ტრაფიკის 100% მიდის ფრონტენდის სერვისზე, შემდეგ ფრონტენდის პოდებზე ლეიბლით v1, რადგან ჩვენ ვიყენებთ მარტივ nginx პროქსის, რომელიც გადამისამართებს მოთხოვნებს backend სერვისზე, რაც თავის მხრივ გადამისამართებს მათ backend-ის პოდებზე. ლეიბლით v1.

Kiali მშვენივრად მუშაობს Istio-სთან და უზრუნველყოფს ყუთში Mesh-ის რენდერირების გადაწყვეტას. უბრალოდ დიდი.

კანარის განლაგება

ჩვენს backend-ს უკვე აქვს ორი k8s განლაგება, ერთი v1-ისთვის და ერთი v2-ისთვის. ახლა ჩვენ უბრალოდ უნდა ვუთხრათ Istio-ს, რომ გადააგზავნოს მოთხოვნების გარკვეული პროცენტი v2-ზე.

ნაბიჯი 1: 10%

და ყველაფერი რაც ჩვენ უნდა გავაკეთოთ არის ვირტუალური სერვისის წონის კორექტირება 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% გადამისამართებულია v2-ზე.

ნაბიჯი 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-ზე:

Canary ტესტირება ხელით

ვთქვათ, ჩვენ ახლა ყველა მოთხოვნის 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% უნდა წავიდეს 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 განლაგება ხელით, ასევე ორი k8-ის განლაგების გამოყენებით. იქ ჩვენ ვაკონტროლებდით მოთხოვნების თანაფარდობას რეპლიკების რაოდენობის შეცვლით. ეს მიდგომა მუშაობს, მაგრამ აქვს სერიოზული ნაკლოვანებები.

Istio შესაძლებელს ხდის მოთხოვნის თანაფარდობის განსაზღვრას რეპლიკების რაოდენობის მიუხედავად. ეს ნიშნავს, მაგალითად, რომ ჩვენ შეგვიძლია გამოვიყენოთ HPA (Horizontal Pod Autoscalers) და არ გვჭირდება კონფიგურაცია კანარის განლაგების ამჟამინდელი მდგომარეობის მიხედვით.

სულ

Istio მშვენივრად მუშაობს და მისი Kiali-თან ერთად გამოყენება ქმნის ძალიან ძლიერ კომბინაციას. შემდეგი ჩემი ინტერესების სიაში არის Spinnaker-ის გაერთიანება Istio-სთან ავტომატიზაციისთვის და კანარის ანალიტიკისთვის.

წყარო: www.habr.com