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

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

რაც შეეხება მიკროსერვისებს Red Hat OpenShift-ის პლატფორმაზე (და მუშაობს Kubernetes-ზე), შესაბამისი ღია კოდის პროგრამული უზრუნველყოფის წყალობით, მათ შეუძლიათ ერთდროულად შეატყობინონ თავიანთი მუშაობისა და ჯანმრთელობის შესახებ. ეს, რა თქმა უნდა, არ უარყოფს ძველ ჰაიზენბერგს, მაგრამ გამორიცხავს გაურკვევლობას ღრუბელ აპლიკაციებთან მუშაობისას. Istio ამარტივებს ამ აპლიკაციების თვალყურის დევნებას და მონიტორინგს, რათა ყველაფერი კონტროლის ქვეშ იყოს.

ტერმინოლოგიაზე გადაწყვეტილების მიღება

ქვეშ მიკვლევა (ტრასინგი) ჩვენ გვესმის სისტემის აქტივობის აღრიცხვა. ეს საკმაოდ ზოგადად ჟღერს, მაგრამ სინამდვილეში ერთ-ერთი ძირითადი წესი აქ არის კვალის მონაცემების გადაყრა შესაბამის საცავში, ფორმატირების შესახებ ფიქრის გარეშე. და მონაცემების ძიებისა და ანალიზის მთელი სამუშაო ეკისრება მომხმარებელს. Istio იყენებს Jaeger Tracing სისტემას, რომელიც ახორციელებს OpenTracing მონაცემთა მოდელს.

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

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

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

კვალს ვტოვებთ

იმისთვის, რომ მიკვლევა შესაძლებელი იყოს, აპლიკაციამ უნდა შექმნას სპანების კოლექცია. შემდეგ ისინი უნდა გაიტანონ Jaeger-ში, რათა მან თავის მხრივ შექმნას კვალის ვიზუალური წარმოდგენა. სხვა საკითხებთან ერთად, ეს ინტერვალი აღნიშნავს ოპერაციის სახელს, ასევე მის დაწყების და დასრულების დროის ნიშანს. სპანების გადაცემა ხორციელდება Jaeger-ის სპეციფიკური HTTP მოთხოვნის სათაურების გადაგზავნით შემომავალი მოთხოვნებიდან გამავალ მოთხოვნებზე. გამოყენებული პროგრამირების ენიდან გამომდინარე, ამან შეიძლება მოითხოვოს მცირე ცვლილებები აპლიკაციის წყაროს კოდში. ქვემოთ მოცემულია კოდის ნიმუში Java-ში (Spring Boot Framework-ის გამოყენებით), რომელიც ამატებს B3 (Zipkin-ის სტილის) სათაურებს თქვენს მოთხოვნას Spring კონფიგურაციის კლასში:

გამოიყენება შემდეგი სათაურის პარამეტრები:

თუ იყენებთ Java-ს, მაშინ შეგიძლიათ დატოვოთ კოდი მარტო და უბრალოდ დაამატოთ რამდენიმე ხაზი Maven POM ფაილში და დააყენოთ გარემოს ცვლადები. აქ არის ხაზები, რომლებიც უნდა დაამატოთ თქვენს POM.XML ფაილს Jaeger Tracer Resolver-ის განსახორციელებლად:

და შესაბამისი გარემოს ცვლადები დაყენებულია Dockerfile-ში:

ესე იგი, ახლა ყველაფერი კონფიგურირებულია და ჩვენი მიკროსერვისები დაიწყებენ კვალი მონაცემების გენერირებას.

განვიხილოთ ზოგადი თვალსაზრისით

Istio მოიცავს მარტივ მართვის პანელს, რომელიც დაფუძნებულია Grafana-ზე. მას შემდეგ რაც ყველაფერი კონფიგურირებულია და მუშაობს Red Hat OpenShift PaaS პლატფორმაზე (ჩვენს მაგალითში Red Hat OpenShift და Kubernetes განლაგებულია minishift-ზე), ეს პანელი ამოქმედდება შემდეგი ბრძანებით:

open "$(minishift openshift service grafana -u)/d/1/istio-dashboard?refresh=5⩝Id=1"

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

აქ ხედავთ, რომ მომხმარებლის მიკროსერვისი უწოდებს უპირატესობას v1 მიკროსერვისს, რომელიც თავის მხრივ რეკომენდაციას უწოდებს v1 და v2 მიკროსერვისებს. Grafana პანელს აქვს Dashboard Row ბლოკი მაღალი დონის მეტრიკებისთვის, როგორიცაა მოთხოვნების მთლიანი რაოდენობა (გლობალური მოთხოვნის მოცულობა), წარმატების მაჩვენებელი, 4xx შეცდომები. გარდა ამისა, არსებობს Server Mesh ხედი გრაფიკებით თითოეული სერვისისთვის და Services Row ბლოკი თითოეული სერვისისთვის თითოეული კონტეინერის შესახებ დეტალური ინფორმაციის სანახავად.

ახლა უფრო ღრმად ჩავუღრმავდეთ

სწორად კონფიგურირებული მოკვლევით, ისტიო, როგორც ამბობენ, ყუთიდან პირდაპირ საშუალებას გაძლევთ ღრმად ჩაღრმავდეთ სისტემის მუშაობის ანალიზში. Jaeger's UI-ში შეგიძლიათ ნახოთ კვალი და ნახოთ, რამდენად შორს და ღრმად მიდიან ისინი, ასევე ვიზუალურად ლოკალიზებული მუშაობის შეფერხებები. Red Hat OpenShift-ის გამოყენებისას minishift პლატფორმაზე, გაუშვით Jaeger UI შემდეგი ბრძანებით:

minishift openshift service jaeger-query --in-browser

რას იტყვით ამ ეკრანზე მიკვლევის შესახებ:

• იგი დაყოფილია 7 ღერძად.
• შესრულების მთლიანი დროა 6.99 ms.
• სარეკომენდაციო მიკროსერვისი, რომელიც ბოლოა ჯაჭვში, ხარჯავს 0.69 ms.

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

ახლა გავართულოთ დავალება და გავააქტიუროთ რეკომენდაციის ორი ინსტანცია: v2 მიკროსერვისი ბრძანებით oc scale —replicas=2 განლაგება/რეკომენდაცია-v2. აქ არის ღვეზელები, რომლებიც გვექნება ამის შემდეგ:

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

სად და როგორ მიდის ყველაფერი

ახლა ჩვენ მივდივართ პრომეთეს ინტერფეისზე და საკმაოდ მოსალოდნელია, რომ იქ ვნახავთ, რომ მოთხოვნები სარეკომენდაციო სერვისის მეორე და პირველ ვერსიებს შორის იყოფა 2:1 თანაფარდობით, მკაცრად სამუშაო რგოლების რაოდენობის მიხედვით. უფრო მეტიც, ეს დიაგრამა დინამიურად შეიცვლება, როგორც კი პოდნები მაღლა და ქვევით იზრდებიან, რაც განსაკუთრებით სასარგებლო იქნება Canary Deployment-ისთვის (ამჯერად განლაგების ამ სქემას უფრო დეტალურად განვიხილავთ).

ეს მხოლოდ დასაწყისია

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

და გახსოვდეთ, ეს ყველაფერი უკვე ჩაშენებულია ისტიოში. გარკვეული პროგრამირების ენების (მაგალითად, Java) და ჩარჩოების (მაგალითად, Spring Boot) გამოყენებისას, ეს ყველაფერი შეიძლება განხორციელდეს აპლიკაციის კოდის საერთოდ შეხების გარეშე. დიახ, კოდი ოდნავ უნდა შეიცვალოს, თუ იყენებთ სხვა ენებს, პირველ რიგში ნიშნავს Nodejs ან C#. მაგრამ იმის გამო, რომ მიკვლევადობა (წაიკითხეთ: „ტრასინგი“) ერთ-ერთი წინაპირობაა საიმედო ღრუბლოვანი სისტემების შესაქმნელად, თქვენ მოგიწევთ კოდის რედაქტირება, მიუხედავად იმისა, გაქვთ ისტიო თუ არა. მაშ, რატომ არ უნდა გამოიყენოთ თქვენი ძალისხმევა უკეთესად?

ყოველ შემთხვევაში იმისთვის, რომ ყოველთვის უპასუხო კითხვებს "სად?" და "რამდენად სწრაფად?" 100% დარწმუნებით.

ქაოსის ინჟინერია ისტიოში: ასე იყო განკუთვნილი

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

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

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

როგორ გამოიყურება ყველაფერი, როცა ყველაფერი მშვენიერია?

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

(სხვათა შორის, ნომერი მარჯვნივ არის მხოლოდ ზარის მრიცხველი თითოეული პოდისთვის)

მაგრამ ეს არ არის ის, რაც ჩვენ გვჭირდება, არა? კარგი, მოდით ვცადოთ ყველაფერი დავარღვიოთ წყაროს კოდის შეხების გარეშე.

ვაწყობთ შეფერხებებს მიკროსერვისის მუშაობაში

ქვემოთ მოცემულია Istio მარშრუტიზაციის წესის yaml ფაილი, რომელიც ნახევარ შემთხვევაში ვერ ხერხდება (შეცდომას იძლევა). სერვერი 503):

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

და აი, როგორ გამოიყურება ციკლში გაშვებული curl ბრძანების ეკრანის სურათი მას შემდეგ, რაც გავააქტიურებთ ამ წესს წარუმატებლობის სიმულაციისთვის. როგორც ხედავთ, მოთხოვნის ნახევარი უბრუნებს შეცდომას 503, მიუხედავად იმისა, რომელ პოდზე – v1 თუ v2 – მიდიან:

ნორმალური მუშაობის აღსადგენად საკმარისია ამ წესის წაშლა, ჩვენს შემთხვევაში istioctl delete routerule rekomandation-503 -n tutorial ბრძანებით. აქ, Tutorial არის Red Hat OpenShift პროექტის სახელი, რომელიც ატარებს ჩვენს Istio გაკვეთილს.

ხელოვნური შეფერხებების დანერგვა

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

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

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

ნახევარ დროს ჩვენ განვიცდით 7 წამის დაგვიანებას. და ეს სულაც არ არის იგივე, თუ ჩვენ ჩავდეთ ძილის ბრძანება წყაროს კოდში, რადგან ისტიო რეალურად აყოვნებს მოთხოვნას 7 წამით. ვინაიდან Istio მხარს უჭერს Jaeger Tracing-ს, ეს შეფერხება შესამჩნევია Jaeger UI-ში, როგორც ეს ნაჩვენებია ქვემოთ მოცემულ ეკრანის სურათზე. ყურადღება მიაქციეთ დიაგრამის ზედა მარჯვენა კუთხეში არსებულ გრძელ მოთხოვნას - მისი ხანგრძლივობაა 7.02 წამი:

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

არ დაიხიოთ და არ დანებდეთ

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

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

გაჩერდი, დაელოდე! ჩვენ უბრალოდ გავაკეთეთ.

ეს ფაილი გახდის ისე, რომ რეკომენდაცია-v2 სერვისი გამოსცემს 503 შეცდომას ნახევარ დროს:

ცხადია, ზოგიერთი მოთხოვნა წარუმატებელი იქნება:

ახლა გამოვიყენოთ Istio Retry ფუნქცია:

მარშრუტის ეს წესი მეორდება სამჯერ ორი წამის ინტერვალით და უნდა შეამციროს (და იდეალურად ამოიღოს რადარიდან) 503 შეცდომები:

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

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

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

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

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

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

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

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

ახლა კი ყველაფერი ერთადაა

Istio-სთან მცირე ქაოსის შეყვანა შესანიშნავი გზაა თქვენი კოდისა და მთლიანად თქვენი სისტემის საიმედოობის შესამოწმებლად. სარეზერვო, ნაყარი და ამომრთველის შაბლონები, ხელოვნური შეფერხებებისა და შეფერხებების შექმნის მექანიზმები, ასევე განმეორებითი ზარები და ვადები ძალიან სასარგებლო იქნება ხარვეზების ტოლერანტული ღრუბლოვანი სისტემების შექმნისას. Kubernetes-თან და Red Hat OpenShift-თან ერთად, ეს ხელსაწყოები დაგეხმარებათ მომავლის თავდაჯერებულად შეხედვაში.

წყარო: www.habr.com