დაუბრუნდით მიკროსერვისებს Istio-სთან ერთად. Მე -2 ნაწილი

Შენიშვნა. თარგმნა: პირველი ნაწილი ეს სერია მიეძღვნა Istio-ს შესაძლებლობების დანერგვას და მათ მოქმედებაში დემონსტრირებას. ახლა ჩვენ ვისაუბრებთ ამ სერვისის ქსელის კონფიგურაციისა და გამოყენების უფრო რთულ ასპექტებზე და, კერძოდ, დახვეწილი მარშრუტიზაციისა და ქსელის ტრაფიკის მართვის შესახებ.

ასევე შეგახსენებთ, რომ სტატიაში გამოყენებულია კონფიგურაციები (მანიფესტები Kubernetes-ისთვის და Istio-სთვის) საცავიდან ისტიო-ოსტატობა.

მოძრაობის მართვა

Istio-სთან ერთად, ახალი შესაძლებლობები ჩნდება კლასტერში, რათა უზრუნველყოს:

• დინამიური მოთხოვნის მარშრუტიზაცია: კანარის გაშვება, A/B ტესტირება;
• Დატვირთვის დაბალანსება: მარტივი და თანმიმდევრული, ჰეშებზე დაფუძნებული;
• აღდგენა დაცემის შემდეგ: ვადები, განმეორებითი ცდები, ამომრთველები;
• ხარვეზების ჩასმა: დაგვიანებები, მოთხოვნილების გაუქმება და ა.შ.

როგორც სტატია გრძელდება, ეს შესაძლებლობები ილუსტრირებული იქნება შერჩეული აპლიკაციის მაგალითის გამოყენებით და გზად დაინერგება ახალი ცნებები. პირველი ასეთი კონცეფცია იქნება DestinationRules (ანუ წესები ტრაფიკის/მოთხოვნის მიმღების შესახებ - დაახლ. თარგმანი.), რომლის დახმარებით ვააქტიურებთ A/B ტესტირებას.

A/B ტესტირება: DestinationRules პრაქტიკაში

A/B ტესტირება გამოიყენება იმ შემთხვევებში, როდესაც არსებობს აპლიკაციის ორი ვერსია (ჩვეულებრივ, ისინი ვიზუალურად განსხვავებულია) და ჩვენ არ ვართ 100% დარწმუნებული, რომელი გააუმჯობესებს მომხმარებლის გამოცდილებას. ამიტომ, ჩვენ ორივე ვერსიას ერთდროულად ვატარებთ და ვაგროვებთ მეტრიკას.

A/B ტესტირების დემონსტრირებისთვის საჭირო ფრონტენტის მეორე ვერსიის გამოსაყენებლად, შეასრულეთ შემდეგი ბრძანება:

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

განლაგების მანიფესტი მწვანე ვერსიისთვის განსხვავდება ორ ადგილას:

1. სურათი დაფუძნებულია სხვა ტეგზე - istio-green,
2. პოდებს აქვს ეტიკეტი 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სტატიკური ფაილების ერთი ვერსიის მოთხოვნით, დატვირთვის ბალანსერი შეიძლება გაიგზავნოს პოდებში, რომლებსაც აქვთ განსხვავებული ვერსია, სადაც, გასაგები მიზეზების გამო, ასეთი ფაილები არ არსებობს. ამიტომ, იმისთვის, რომ აპლიკაციამ იმუშაოს, ჩვენ უნდა დავაწესოთ შეზღუდვა: ”აპლიკაციის იგივე ვერსია, რომელიც ემსახურებოდა index.html, უნდა მოემსახუროს შემდგომ მოთხოვნებს".

ჩვენ მივაღწევთ თანმიმდევრული ჰეშზე დაფუძნებული დატვირთვის დაბალანსებით (ჰაშის თანმიმდევრული დატვირთვის ბალანსირება). ამ შემთხვევაში მოთხოვნები ერთი და იგივე კლიენტისგან იგზავნება იმავე backend ინსტანციაზე, რისთვისაც გამოიყენება წინასწარ განსაზღვრული თვისება - მაგალითად, HTTP სათაური. განხორციელებულია DestinationRules-ის გამოყენებით.

დანიშნულების წესები

შემდეგ ვირტუალური სერვისი გაუგზავნა მოთხოვნა სასურველ სერვისს, DestinationRules-ის გამოყენებით ჩვენ შეგვიძლია განვსაზღვროთ პოლიტიკები, რომლებიც გამოყენებული იქნება ტრაფიკზე, რომელიც განკუთვნილია ამ სერვისისთვის:

ტრაფიკის მართვა ისტიოს რესურსებით

შენიშვნა: Istio-ს რესურსების გავლენა ქსელის ტრაფიკზე აქ წარმოდგენილია ისე, რომ გასაგები იყოს. უფრო ზუსტად, გადაწყვეტილებას, თუ რომელ ინსტანციაზე უნდა გაგზავნოს მოთხოვნა, იღებს დესპანი CRD-ში კონფიგურირებული Ingress Gateway-ში.

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

შენიშვნა: სათაურში სხვადასხვა მნიშვნელობების დასამატებლად და შედეგების პირდაპირ ბრაუზერში შესამოწმებლად შეგიძლიათ გამოიყენოთ ეს გაფართოება Chrome-ზე (ან ამით 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

Mirroring: ვირტუალური სერვისები პრაქტიკაში

ჩრდილი ("დაფარვა") ან Mirroring ("სარკე") გამოიყენება იმ შემთხვევებში, როდესაც გვსურს შევამოწმოთ წარმოებაში ცვლილება საბოლოო მომხმარებლებზე გავლენის გარეშე: ამისათვის ჩვენ ვამეორებთ („სარკე“) მოთხოვნებს მეორე ინსტანციაში, სადაც განხორციელდა სასურველი ცვლილებები და ვუყურებთ შედეგებს. მარტივად რომ ვთქვათ, ეს ის შემთხვევაა, როცა თქვენი კოლეგა ირჩევს ყველაზე კრიტიკულ საკითხს და აკეთებს მოთხოვნას ჭუჭყის ისეთი უზარმაზარი ნაჭრის სახით, რომ რეალურად ვერავინ შეძლებს მის გადახედვას.

ამ სცენარის მოქმედებაში შესამოწმებლად, მოდით შევქმნათ 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

1. მასპინძელი (host) განსაზღვრავს, რომ ეს წესი ვრცელდება მხოლოდ იმ შემთხვევებზე, როდესაც მარშრუტი მიდის სერვისისკენ sa-logic;
2. სათაურები (name) ქვესიმრავლეები გამოიყენება ქვეჯგუფების ინსტანციებზე მარშრუტიზაციისას;
3. ლეიბლი (label) განსაზღვრავს გასაღები-მნიშვნელობის წყვილებს, რომლებსაც ინსტანციები უნდა ემთხვეოდეს, რომ გახდნენ ქვეჯგუფის ნაწილი.

გამოიყენეთ კონფიგურაცია შემდეგი ბრძანებით:

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

ახლა, როდესაც ქვეჯგუფები განსაზღვრულია, ჩვენ შეგვიძლია გადავიდეთ და დავაკონფიგურიროთ VirtualService, რათა გამოიყენოს წესები sa-logic-ის მოთხოვნებზე ისე, რომ ისინი:

1. მარშრუტირებულია ქვეჯგუფზე v1,
2. ასახულია ქვეჯგუფში 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

მოდით შევხედოთ შედეგებს Grafana-ში, სადაც შეგიძლიათ ნახოთ, რომ ვერსია შეცდომებით (buggy) იწვევს მოთხოვნის ~60%-ს წარუმატებლობას, მაგრამ არცერთი ეს წარუმატებლობა არ მოქმედებს საბოლოო მომხმარებლებზე, რადგან მათ პასუხობენ გაშვებული სერვისი.

სა-ლოგიკის სერვისის სხვადასხვა ვერსიის წარმატებული პასუხები

აქ ჩვენ პირველად ვნახეთ, თუ როგორ გამოიყენება VirtualService ჩვენი სერვისების ელჩებზე: როდის sa-web-app მიმართავს თხოვნას sa-logic, ის გადის sidecar Envoy-ს, რომელიც - VirtualService-ის საშუალებით - კონფიგურირებულია მოთხოვნის გადასატანად v1 ქვეჯგუფში და ასახავს მოთხოვნას სერვისის v2 ქვეჯგუფში. sa-logic.

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

Canary Rollouts

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%-მდე. მშვენიერია! ახლა, ყველა შემთხვევაში, როდესაც ჩვენ არ ვართ დარწმუნებული ჩვენს კოდში (სხვა სიტყვებით - ყოველთვის...), შეგვიძლია გამოვიყენოთ mirroring და canary rollouts.

ვადები და ხელახალი ცდები

მაგრამ შეცდომები ყოველთვის არ მთავრდება კოდში. სიაში "8 მცდარი წარმოდგენა განაწილებული გამოთვლის შესახებ”პირველ რიგში არის მცდარი რწმენა, რომ ”ქსელი საიმედოა”. რეალურად ქსელი არარის სანდოა და ამ მიზეზით ჩვენ გვჭირდება ვადები (ტაიმაუტი) და ხელახლა ცდილობს (ხელახლა ცდილობს).

დემონსტრირებისთვის ჩვენ გავაგრძელებთ იგივე პრობლემის ვერსიის გამოყენებას sa-logic (buggy), და ჩვენ მოვახდენთ ქსელის არასანდოობის სიმულაციას შემთხვევითი ჩავარდნებით.

ნება მიეცით ჩვენს შეცდომით სერვისს ჰქონდეს 1/3 შანსი, რომ ძალიან დიდი დრო დასჭირდეს პასუხის გაცემას, 1/3 შანსი დასრულდეს შიდა სერვერის შეცდომით და 1/3 შანსი გვერდი წარმატებით დაბრუნდეს.

ასეთი პრობლემების ზემოქმედების შესამცირებლად და მომხმარებლებისთვის ცხოვრების გასაუმჯობესებლად, ჩვენ შეგვიძლია:

1. დაამატეთ ვადა, თუ სერვისს 8 წამზე მეტი დრო სჭირდება პასუხის გასაცემად,
2. სცადეთ ხელახლა, თუ მოთხოვნა ვერ მოხერხდა.

განსახორციელებლად, ჩვენ გამოვიყენებთ რესურსის შემდეგ განმარტებას (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

1. მოთხოვნის ვადა დაყენებულია 8 წამზე;
2. მოთხოვნები განმეორდება 3-ჯერ;
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

ამომრთველისა და ნაყარის ნიმუშები

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

Circuit Breaker ("ჩართვა ამომრთველი") გამოიყენება სერვისის ისეთ მაგალითზე მოთხოვნის შესაწყვეტად, რომელიც ითვლება არაჯანსაღად და აღადგენს მას, ხოლო კლიენტის მოთხოვნები გადამისამართებულია ამ სერვისის ჯანსაღ ეგზემპლარებზე (რაც ზრდის წარმატებული პასუხების პროცენტს). (შენიშვნა: ნიმუშის უფრო დეტალური აღწერა შეგიძლიათ იხილოთ, მაგალითად, აქ.)

ნაყარი ("დანაყოფი") იზოლირებს სერვისის წარუმატებლობას მთელ სისტემაზე ზემოქმედებისგან. მაგალითად, სერვისი B გატეხილია და სხვა სერვისი (სერვის B-ის კლიენტი) მიმართავს თხოვნას სერვისს B, რის შედეგადაც ის ამოიწურება ძაფების აუზი და ვერ შეძლებს სხვა მოთხოვნების მომსახურებას (მაშინაც კი, თუ ისინი არ არიან B სერვისიდან). (შენიშვნა: ნიმუშის უფრო დეტალური აღწერა შეგიძლიათ იხილოთ, მაგალითად, აქ.)

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

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• "უბრუნდი მიკროსერვისებს Istio-სთან ერთად": ნაწილი 1 (ძირითადი მახასიათებლების შესავალი), ნაწილი 3 (ავთენტიფიკაცია და ავტორიზაცია);
• «კონდუიტი - მსუბუქი სერვისის ბადე Kubernetes-ისთვის";
• «რა არის სერვისული ქსელი და რატომ მჭირდება ის [მიკრსერვისებით ღრუბლოვანი აპლიკაციისთვის]?".

წყარო: www.habr.com