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

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

ისტიო — ღია კოდის პროექტი შემუშავებული Google-ის, IBM-ისა და Lyft-ის გუნდებთან თანამშრომლობით. ის აგვარებს სირთულეებს, რომლებიც წარმოიქმნება მიკროსერვისებზე დაფუძნებულ აპლიკაციებში, როგორიცაა:

• მოძრაობის მართვა: ვადები, განმეორებითი ცდები, დატვირთვის დაბალანსება;
• უსაფრთხოების: საბოლოო მომხმარებლის ავტორიზაცია და ავტორიზაცია;
• დაკვირვებადობა: მიკვლევა, მონიტორინგი, ხე-ტყე.

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

პროექტის მენეჯერი: რამდენი დრო სჭირდება გამოხმაურების ფუნქციის დამატებას?
შემქმნელი: ორი სპრინტი.

დეპუტატი: რა?.. ეს უბრალოდ უხეშია!
R: CRUD-ის გაკეთება ამოცანის მარტივი ნაწილია, მაგრამ ჩვენ მაინც გვჭირდება მომხმარებლებისა და სერვისების ავთენტიფიკაცია და ავტორიზაცია. ვინაიდან ქსელი არასანდოა, მოგიწევთ განმეორებითი მოთხოვნების განხორციელება, ასევე ამომრთველის ნიმუში კლიენტებში. ასევე, იმისათვის, რომ დარწმუნდეთ, რომ მთელი სისტემა არ გაფუჭდა, ტაიმაუტი და შუასადებები (დაწვრილებითი ორივე აღნიშნული ნიმუშის შესახებ იხილეთ სტატიაში - დაახლ. თარგმანი.)და პრობლემების აღმოსაჩენად, მონიტორინგი, მიკვლევა, […]

დეპუტატი: ოჰ, მოდით, ეს ფუნქცია მოვათავსოთ პროდუქტის სერვისში.

ვფიქრობ, იდეა ნათელია: ერთი სერვისის დასამატებლად საჭირო ნაბიჯებისა და ძალისხმევის რაოდენობა უზარმაზარია. ამ სტატიაში ჩვენ გადავხედავთ, თუ როგორ აშორებს Istio ყველა ზემოთ ნახსენებ სირთულეს (არ არის მიზანმიმართული ბიზნეს ლოგიკით) სერვისებიდან.

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

ისტიოს იდეა

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

ქსელური ტრაფიკი Kubernetes-ში

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

• შეცდომის ტოლერანტობა: პასუხში არსებული სტატუსის კოდიდან გამომდინარე, ხვდება, ვერ მოხერხდა თუ არა მოთხოვნა და ხელახლა ახორციელებს მას.
• Canary Rollouts: გადამისამართებს მოთხოვნის მხოლოდ ფიქსირებულ პროცენტს სერვისის ახალ ვერსიაზე.
• მონიტორინგი და მეტრიკა: რამდენი დრო დასჭირდა სერვისის რეაგირებას?
• მიკვლევა და დაკვირვება: ამატებს სპეციალურ სათაურებს თითოეულ მოთხოვნას და აკონტროლებს მათ კლასტერში.
• უსაფრთხოების: იღებს JWT ჟეტონს, ამოწმებს და ავტორიზაციას აძლევს მომხმარებლებს.

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

ისტიოს არქიტექტურა

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

მონაცემთა თვითმფრინავი

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

როგორ ხორციელდება განმეორებითი ცდები და მიკროსქემის გაწყვეტა Envoy-ში

შეავსოთ:

1. დესპანი (საუბარია გვერდითი კარის კონტეინერში მდებარე პროქსიზე, რომელიც ნაწილდება და როგორ ცალკე პროდუქტი - დაახლ. თარგმანი.) აგზავნის მოთხოვნას B სერვისის პირველ ინსტანციაში და ვერ ხერხდება.
2. ელჩი საიდკარი ისევ ცდის (ხელახლა სცადეთ). (1)
3. წარუმატებელი მოთხოვნა უბრუნდება პროქსის, რომელმაც მას დაურეკა.
4. ეს ხსნის Circuit Breaker-ს და გამოიძახებს შემდეგ სერვისს შემდგომი მოთხოვნებისთვის. (2)

ეს ნიშნავს, რომ თქვენ არ გჭირდებათ სხვა ხელახლა სცადეთ ბიბლიოთეკის გამოყენება, თქვენ არ უნდა გააკეთოთ Circuit Breaking და Service Discovery პროგრამირების ენაზე X, Y ან Z. ეს ყველაფერი და კიდევ ბევრი სხვა ხელმისაწვდომია ყუთში. ისტიოში და არ საჭიროებს არარის ცვლილებები კოდში.

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

და ბოლოს თქვენ ჰკითხავთ: "მორგებადია?"

ახლა თქვენ მზად ხართ საზღვაო მოგზაურობისთვის - და მოდით გავეცნოთ საკონტროლო თვითმფრინავს.

საკონტროლო თვითმფრინავი

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

საკონტროლო სიბრტყის ურთიერთქმედება მონაცემთა სიბრტყესთან

დესპანები (ანუ მონაცემთა თვითმფრინავი) კონფიგურირებულია გამოყენებით Kubernetes CRD (Custom Resource Definitions) განსაზღვრული Istio-ს მიერ და სპეციალურად შექმნილი ამ მიზნით. რას ნიშნავს ეს თქვენთვის არის ის, რომ ისინი უბრალოდ კიდევ ერთი რესურსია Kubernetes-ში ნაცნობი სინტაქსით. შექმნის შემდეგ, ამ რესურსს აიღებს საკონტროლო თვითმფრინავი და გამოიყენებს Envoys-ს.

სერვისების ურთიერთობა ისტიოსთან

ჩვენ აღვწერეთ ისტიოს ურთიერთობა სერვისებთან, მაგრამ არა პირიქით: როგორ უკავშირდება სერვისები ისტიოს?

მართალი გითხრათ, სამსახურებმა ისე იციან ისტიოს არსებობა, როგორც თევზები წყლისა, როცა საკუთარ თავს ეკითხებიან: "რა არის წყალი მაინც?"

ილუსტრაცია ვიქტორია დიმიტრაკოპულოსი: როგორ მოგწონს წყალი? - მაინც რა არის წყალი?

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

საკმარისია თეორია - მოდით ეს ცოდნა პრაქტიკაში გამოვიყენოთ!

ისტიო პრაქტიკაში

Istio მოითხოვს Kubernetes კლასტერს მინიმუმ 4 vCPU და 8 GB ოპერატიული მეხსიერება. კლასტერის სწრაფად დასაყენებლად და სტატიის ინსტრუქციების შესრულებისთვის, გირჩევთ გამოიყენოთ Google Cloud Platform, რომელიც ახალ მომხმარებლებს სთავაზობს უფასო $300.

კლასტერის შექმნისა და Kubernetes-ზე წვდომის კონფიგურაციის შემდეგ კონსოლის უტილიტის საშუალებით, შეგიძლიათ დააინსტალიროთ Istio Helm პაკეტის მენეჯერის მეშვეობით.

ჩაფხუტის მონტაჟი

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

ინსტალაცია

ჩამოტვირთეთ Istio რესურსები უახლესი გამოშვება (ორიგინალური ავტორის ბმული 1.0.5 ვერსიაზე შეიცვალა ახლანდელით, ანუ 1.0.6 - დაახლ. თარგმანი), ამოიღეთ შიგთავსი ერთ დირექტორიაში, რომელსაც ამიერიდან მოვუწოდებ [istio-resources].

Istio რესურსების ადვილად იდენტიფიცირებისთვის, შექმენით სახელთა სივრცე K8s კლასტერში istio-system:

$ kubectl create namespace istio-system

დაასრულეთ ინსტალაცია დირექტორიაში ნავიგაციით [istio-resources] და გაუშვით ბრძანება:

$ helm template install/kubernetes/helm/istio 
  --set global.mtls.enabled=false 
  --set tracing.enabled=true 
  --set kiali.enabled=true 
  --set grafana.enabled=true 
  --namespace istio-system > istio.yaml

ეს ბრძანება გამოსცემს Istio-ს ძირითად კომპონენტებს ფაილში istio.yaml. ჩვენ შევცვალეთ სტანდარტული შაბლონი ჩვენთვის შემდეგი პარამეტრების მითითებით:

• global.mtls.enabled დაინსტალირებული false (ანუ mTLS ავთენტიფიკაცია გამორთულია - დაახლ.)ჩვენი გაცნობის პროცესის გამარტივება;
• tracing.enabled მოიცავს მოთხოვნის მიკვლევას Jaeger-ის გამოყენებით;
• kiali.enabled დააინსტალირებს Kiali-ს კლასტერში სერვისებისა და ტრაფიკის ვიზუალიზაციისთვის;
• grafana.enabled აინსტალირებს Grafana-ს შეგროვებული მეტრიკის ვიზუალიზაციისთვის.

გამოვიყენოთ გენერირებული რესურსები ბრძანებით:

$ kubectl apply -f istio.yaml

Istio-ს ინსტალაცია კლასტერზე დასრულებულია! დაელოდეთ სანამ ყველა ბლოკი იქნება სახელთა სივრცეში istio-system შეძლებს Running ან Completedქვემოთ მოცემული ბრძანების გაშვებით:

$ kubectl get pods -n istio-system

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

განწყობის ანალიზის აპლიკაციის არქიტექტურა

გამოვიყენოთ უკვე აღნიშნულში გამოყენებული Sentiment Analysis მიკროსერვისის აპლიკაციის მაგალითი შესავალი სტატია Kubernetes-ში. ის საკმარისად რთულია ისტიოს შესაძლებლობების პრაქტიკაში საჩვენებლად.

აპლიკაცია შედგება ოთხი მიკროსერვისისგან:

1. სამსახურის SA-ფრონტენდი, რომელიც ემსახურება ფრონტ-ენდის აპლიკაციას Reactjs-ზე;
2. სამსახურის SA WebApp, რომელიც ემსახურება სენტიმენტური ანალიზის შეკითხვებს;
3. სამსახურის SA-ლოგიკარომელიც თავად ასრულებს განწყობის ანალიზი;
4. სამსახურის SA კავშირი, რომელიც იღებს უკუკავშირს მომხმარებლებისგან ანალიზის სიზუსტის შესახებ.

ამ დიაგრამაში, სერვისების გარდა, ჩვენ ასევე ვხედავთ Ingress Controller-ს, რომელიც Kubernetes-ში აგზავნის შემომავალ მოთხოვნებს შესაბამის სერვისებზე. Istio იყენებს მსგავს კონცეფციას Ingress Gateway-ში, რომლის მეტი დეტალი მოჰყვება.

აპლიკაციის გაშვება პროქსით ისტიოდან

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

გვერდითი კარების ჩასმა

ჩასმა შეიძლება ავტომატურად ან ხელით. გვერდითი კარის კონტეინერების ავტომატურად ჩასართავად, თქვენ უნდა დააყენოთ ეტიკეტი სახელთა სივრცეში istio-injection=enabled, რომელიც კეთდება შემდეგი ბრძანებით:

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

ახლა თითოეული პოდი, რომელიც განლაგდება ნაგულისხმევ სახელთა სივრცეში (default) მიიღებს თავის გვერდითა კონტეინერს. ამის შესამოწმებლად, მოდით განვათავსოთ სატესტო აპლიკაცია საცავის root დირექტორიაში გადასვლით [istio-mastery] და გაუშვით შემდეგი ბრძანება:

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

სერვისების განლაგების შემდეგ, ბრძანების გაშვებით შევამოწმოთ, რომ პოდებს აქვთ ორი კონტეინერი (თავად სერვისით და მისი გვერდითი კარით). kubectl get pods და დარწმუნდით, რომ სვეტის ქვეშ READY მითითებული ღირებულება 2/2, სიმბოლოა, რომ ორივე კონტეინერი მუშაობს:

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-2sjwj      2/2       Running   0          12m
sa-logic-568498cb4d-p4f8c      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

ვიზუალურად ასე გამოიყურება:

დესპანის მარიონეტული წარმომადგენელი ერთ-ერთ პოდში

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

Ingress Gateway

ამის მისაღწევად საუკეთესო პრაქტიკა (კლასტერში ტრაფიკის დაშვება) გადის Ingress Gateway Istio-ში, რომელიც მდებარეობს კლასტერის „კიდეზე“ და საშუალებას გაძლევთ ჩართოთ Istio ისეთი ფუნქციები, როგორიცაა მარშრუტირება, დატვირთვის დაბალანსება, უსაფრთხოება და შემომავალი ტრაფიკის მონიტორინგი.

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

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

ჩვენ გავაგრძელებთ აპლიკაციაზე წვდომას ამ IP-ის გამოყენებით (მე მას მოვიხსენიებ როგორც EXTERNAL-IP), ასე რომ, მოხერხებულობისთვის ჩვენ ჩავწერთ მნიშვნელობას ცვლადში:

$ EXTERNAL_IP=$(kubectl get svc -n istio-system 
  -l app=istio-ingressgateway 
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

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

კარიბჭის რესურსი

Gateway არის CRD (Custom Resource Definition) Kubernetes-ში, რომელიც განისაზღვრება Istio-ს კლასტერში დაინსტალირების შემდეგ და იძლევა შესაძლებლობას მიუთითოთ პორტები, პროტოკოლი და ჰოსტები, რომლებისთვისაც გვინდა შემომავალი ტრაფიკის დაშვება.

ჩვენს შემთხვევაში, ჩვენ გვსურს დავუშვათ HTTP ტრაფიკი 80 პორტზე ყველა ჰოსტისთვის. პრობლემა რეალიზებულია შემდეგი განმარტებით (http-gateway.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
- "*"

ამ კონფიგურაციას არ სჭირდება ახსნა სელექტორის გარდა istio: ingressgateway. ამ სელექტორის საშუალებით შეგვიძლია განვსაზღვროთ, რომელ Ingress Gateway-ზე მივმართოთ კონფიგურაციას. ჩვენს შემთხვევაში, ეს არის Ingress Gateway კონტროლერი, რომელიც ნაგულისხმევად იყო დაინსტალირებული ისტიოში.

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

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created

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

ვირტუალური სერვისის რესურსი

VirtualService ეუბნება Ingress Gateway-ს, თუ როგორ გაატაროს მოთხოვნები, რომლებიც დაშვებულია კლასტერში.

მოთხოვნები ჩვენს აპლიკაციაზე, რომელიც მოდის http-gateway-ით, უნდა გაიგზავნოს sa-frontend, sa-web-app და sa-feedback სერვისებს:

მარშრუტები, რომლებიც უნდა იყოს კონფიგურირებული VirtualServices-ით

მოდით შევხედოთ მოთხოვნებს, რომლებიც უნდა გაიგზავნოს SA-Frontend-ში:

• ზუსტი მატჩი გზაზე / უნდა გაიგზავნოს SA-Frontend-ზე index.html-ის მისაღებად;
• ბილიკები პრეფიქსით /static/* უნდა გაიგზავნოს SA-Frontend-ში, რათა მიიღოთ სტატიკური ფაილები, რომლებიც გამოიყენება ფრონტენდში, როგორიცაა CSS და JavaScript;
• ბილიკები, რომლებიც შეესაბამება რეგულარულ გამოხატულებას '^.*.(ico|png|jpg)$', უნდა გაიგზავნოს SA-Frontend-ში, რადგან ეს არის გვერდზე ნაჩვენები სურათები.

განხორციელება მიიღწევა შემდეგი კონფიგურაციით (sa-virtualservice-external.yaml):

kind: VirtualService
metadata:
  name: sa-external-services
spec:
  hosts:
  - "*"
  gateways:
  - http-gateway                      # 1
  http:
  - match:
    - uri:
        exact: /
    - uri:
        exact: /callback
    - uri:
        prefix: /static
    - uri:
        regex: '^.*.(ico|png|jpg)$'
    route:
    - destination:
        host: sa-frontend             # 2
        port:
number: 80

მნიშვნელოვანი რაოდენობა:

1. ეს ვირტუალური სერვისი ეხება შემოსულ მოთხოვნებს http- კარიბჭე;
2. В destination განსაზღვრავს სერვისს, რომელზეც იგზავნება მოთხოვნები.

შენიშვნა: ზემოთ მოცემული კონფიგურაცია ინახება ფაილში sa-virtualservice-external.yaml, რომელიც ასევე შეიცავს SA-WebApp-ში და SA-Feedback-ში მარშრუტიზაციის პარამეტრებს, მაგრამ მოკლედ შემცირდა აქ სტატიაში.

მოდით გამოვიყენოთ VirtualService დარეკვით:

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services created

შენიშვნა: როდესაც ჩვენ ვიყენებთ Istio რესურსებს, Kubernetes API სერვერი ქმნის მოვლენას, რომელიც მიიღება Istio Control Plane-ის მიერ და ამის შემდეგ ახალი კონფიგურაცია გამოიყენება თითოეული pod-ის Envoy მარიონეტებისთვის. და Ingress Gateway კონტროლერი, როგორც ჩანს, არის კიდევ ერთი დესპანი, რომელიც კონფიგურირებულია საკონტროლო სიბრტყეში. ეს ყველაფერი ასე გამოიყურება დიაგრამაზე:

Istio-IngressGateway-ის კონფიგურაცია მოთხოვნის მარშრუტიზაციისთვის

განწყობის ანალიზი ახლა ხელმისაწვდომია http://{EXTERNAL-IP}/. არ ინერვიულოთ, თუ მიიღებთ Not Found სტატუსს: ზოგჯერ ცოტა მეტი დრო სჭირდება კონფიგურაციის ამოქმედებას და Envoy-ის ქეშის განახლებას.

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

კიალი: დაკვირვებადობა

Kiali-ს ადმინისტრაციულ ინტერფეისამდე მისასვლელად, შეასრულეთ შემდეგი ბრძანება:

$ kubectl port-forward 
    $(kubectl get pod -n istio-system -l app=kiali 
    -o jsonpath='{.items[0].metadata.name}') 
    -n istio-system 20001

... და გახსენი http://localhost:20001/, შესვლა როგორც ადმინი/ადმინისტრატორი. აქ ნახავთ ბევრ სასარგებლო ფუნქციას, მაგალითად, Istio-ს კომპონენტების კონფიგურაციის შესამოწმებლად, სერვისების ვიზუალიზაციისთვის, ქსელის მოთხოვნიდან შეგროვებული ინფორმაციის გამოყენებით, მიიღოთ პასუხები კითხვებზე „ვინ ვის უკავშირდება?“, „სერვისის რომელ ვერსიას განიცდის“. წარუმატებლობა?” და ასე შემდეგ. ზოგადად, გამოიკვლიეთ Kiali-ს შესაძლებლობები, სანამ გადახვალთ მეტრიკის ვიზუალიზაციაზე Grafana-სთან ერთად.

გრაფანა: მეტრიკის ვიზუალიზაცია

ისტიოში შეგროვებული მეტრიკა მთავრდება პრომეთეში და ვიზუალიზდება გრაფანასთან. Grafana ადმინისტრატორის ინტერფეისში მოსახვედრად, გაუშვით ქვემოთ მოცემული ბრძანება, შემდეგ გახსენით http://localhost:3000/:

$ kubectl -n istio-system port-forward 
    $(kubectl -n istio-system get pod -l app=grafana 
    -o jsonpath={.items[0].metadata.name}) 3000

მენიუზე დაჭერით მთავარი ზედა მარცხენა და აირჩიეთ ისტიოს სერვისის დაფა ზედა მარცხენა კუთხეში დაიწყეთ სერვისით სა-ვებ-აპიშეგროვებული მეტრიკის დასათვალიერებლად:

რაც აქ გველოდება ცარიელი და სრულიად მოსაწყენი შესრულებაა - მენეჯმენტი ამას არასოდეს დაამტკიცებს. მოდით შევქმნათ მცირე დატვირთვა შემდეგი ბრძანებით:

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

ახლა ჩვენ გვაქვს ბევრად უფრო ლამაზი გრაფიკები და მათ გარდა, მშვენიერი ხელსაწყოები Prometheus მონიტორინგისთვის და Grafana მეტრიკის ვიზუალიზაციისთვის, რაც საშუალებას მოგვცემს გავიგოთ მუშაობის, ჯანმრთელობის მდგომარეობის, სერვისების გაუმჯობესება/დეგრადაცია დროთა განმავლობაში.

დაბოლოს, მოდით გადავხედოთ მოთხოვნებს სერვისებში.

იეგერი: მიკვლევა

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

შემთხვევითი წარუმატებელი მოთხოვნის ტიპიური მაგალითი

მოთხოვნა მოდის, ეცემა - რა არის მიზეზი? პირველი სერვისი? ან მეორე? ორივეში არის გამონაკლისები - მოდით გადავხედოთ თითოეულის ჟურნალს. რამდენად ხშირად დაიჭირეთ საკუთარი თავი ამის კეთებაში? ჩვენი მუშაობა უფრო ჰგავს პროგრამულ დეტექტივებს, ვიდრე დეველოპერებს...

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

TraceId გამოიყენება მოთხოვნის იდენტიფიცირებისთვის

Istio იყენებს Jaeger Tracer-ს, რომელიც ახორციელებს გამყიდველისგან დამოუკიდებელ OpenTracing API ჩარჩოს. თქვენ შეგიძლიათ შეხვიდეთ Jaeger-ის მომხმარებლის ინტერფეისზე შემდეგი ბრძანებით:

$ kubectl port-forward -n istio-system 
    $(kubectl get pod -n istio-system -l app=jaeger 
    -o jsonpath='{.items[0].metadata.name}') 16686

ახლა გადადით http://localhost:16686/ და აირჩიეთ სერვისი სა-ვებ-აპი. თუ სერვისი არ არის ნაჩვენები ჩამოსაშლელ მენიუში, აჩვენეთ/შექმენით აქტივობა გვერდზე და განაახლეთ ინტერფეისი. ამის შემდეგ დააჭირეთ ღილაკს იპოვნეთ კვალი, რომელიც აჩვენებს უახლეს კვალს - აირჩიეთ ნებისმიერი - გამოჩნდება დეტალური ინფორმაცია ყველა კვალის შესახებ:

ეს კვალი აჩვენებს:

1. მოთხოვნა შემოდის istio-ingressgateway (ეს არის პირველი ურთიერთქმედება ერთ-ერთ სერვისთან და მოთხოვნისთვის იქმნება Trace ID), რის შემდეგაც კარიბჭე აგზავნის მოთხოვნას სერვისს სა-ვებ-აპი.
2. სამსახურში სა-ვებ-აპი თხოვნას აიღებს Envoy sidecar-ი, იქმნება "ბავშვი" დიაპაზონში (ამიტომ ვხედავთ მას კვალში) და გადამისამართებულია კონტეინერში. სა-ვებ-აპი. (Span - იაგერში მუშაობის ლოგიკური ერთეული, რომელსაც აქვს სახელი, ოპერაციის დაწყების დრო და ხანგრძლივობა. სპანების მოწყობა და შეკვეთა შესაძლებელია. სპანების მიმართული აციკლური გრაფიკი ქმნის კვალს. - დაახლ. თარგმანი.)
3. აქ მოთხოვნა მუშავდება მეთოდით სენტიმენტალური ანალიზი. ეს კვალი უკვე გენერირებულია აპლიკაციის მიერ, ე.ი. მათ მოითხოვეს კოდის ცვლილებები.
4. ამ მომენტიდან იწყება POST მოთხოვნა სა-ლოგიკა. Trace ID უნდა იყოს გადაგზავნილი სა-ვებ-აპი.
5. ...

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

(ა) ისტიო პასუხისმგებელია სათაურების გადაგზავნაზე; (B) სერვისები პასუხისმგებელნი არიან სათაურებზე

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

გასათვალისწინებელია შემდეგი სათაურები:

x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context

ეს არ არის რთული ამოცანა, მაგრამ მისი განხორციელების გამარტივება უკვე არსებობს ბევრი ბიბლიოთეკა - მაგალითად, sa-web-app სერვისში RestTemplate კლიენტი გადასცემს ამ სათაურებს, თუ თქვენ უბრალოდ დაამატებთ Jaeger და OpenTracing ბიბლიოთეკებს მისი დამოკიდებულებები.

გაითვალისწინეთ, რომ Sentiment Analysis აპლიკაცია აჩვენებს განხორციელებებს Flask, Spring და ASP.NET Core-ში.

ახლა, როცა უკვე ნათელია, რას ვიღებთ ყუთიდან (ან თითქმის გარედან), მოდით გადავხედოთ მარშრუტის დაზუსტებას, ქსელური ტრაფიკის მართვას, უსაფრთხოებას და სხვას!

Შენიშვნა. თარგმნა: ამის შესახებ წაიკითხეთ Istio-ს მასალების შემდეგ ნაწილში Rinor Maloku-დან, რომლის თარგმანებიც უახლოეს მომავალში შემოგთავაზებთ ჩვენს ბლოგზე. განახლების (14 მარტი): მეორე ნაწილი უკვე გამოქვეყნებულია.

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

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

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

წყარო: www.habr.com