Istio ამომრთველი: გაუმართავი კონტეინერების გამორთვა

არდადეგები დასრულდა და ჩვენ დავბრუნდით ჩვენი მეორე პოსტით Istio Service Mesh-ის სერიაში.

დღევანდელი თემაა ამომრთველი, რომელიც რუსულ ელექტროინჟინერიაში ითარგმნება როგორც „გამრთველი“, საერთო ენაზე – „გამრთველი“. მხოლოდ ისტიოში ეს მანქანა არ წყვეტს შეკუმშულ ან გადატვირთულ წრეს, არამედ გაუმართავ კონტეინერებს.

როგორ უნდა იმუშაოს იდეალურად

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

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

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

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

რა არის აუზის განდევნა ისტიოში

და აი, Istio მოდის სამაშველოში თავისი Circuit Breaker დამცავი მანქანებით, რომლებიც დროებით აშორებენ გაუმართავი კონტეინერებს მარშრუტიზაციისა და დატვირთვის დაბალანსების რესურსის აუზიდან, ახორციელებს აუზის ამოღების პროცედურას.

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

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

ემზადება ავარიისთვის

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

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

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

აი, როგორ გამოიყურება ამ წესის შედეგი:

შეიძლება ბრალს აღმოაჩინო ის, რომ ეს ეკრანი არის არა 50/50, არამედ 14:9, მაგრამ დროთა განმავლობაში სიტუაცია გამოსწორდება.

ხარვეზის გაკეთება

ახლა მოდით გამორთოთ ორი v2 კონტეინერიდან ერთი ისე, რომ გვქონდეს ერთი ჯანსაღი v1 კონტეინერი, ერთი ჯანსაღი v2 კონტეინერი და ერთი გაუმართავი v2 კონტეინერი:

ხარვეზის გამოსწორება

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

როგორც ხედავთ, წარუმატებელი v2 კონტეინერი აღარ გამოიყენება მარშრუტიზაციის მოთხოვნებისთვის, რადგან ის ამოღებულია აუზიდან. მაგრამ 15 წამის შემდეგ ის ავტომატურად დაბრუნდება აუზში. სინამდვილეში, ჩვენ უბრალოდ ვაჩვენეთ როგორ მუშაობს Pool Ejection.

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

Pool Ejection, Istio-ს მონიტორინგის შესაძლებლობებთან ერთად, საშუალებას გაძლევთ დაიწყოთ ჩარჩოს შექმნა გაუმართავი კონტეინერების ავტომატურად ჩანაცვლებისთვის, რათა შემცირდეს, თუ არა აღმოფხვრა, გაუმართაობა და წარუმატებლობა.
 
NASA-ს აქვს ერთი ხმამაღალი დევიზი - Failure Is Not An Option, რომლის ავტორად ითვლება ფრენის დირექტორი. ჯინ კრანცი. ეს შეიძლება ითარგმნოს რუსულად, როგორც "მარცხი არ არის ვარიანტი", და აქ მნიშვნელობა ის არის, რომ ყველაფერი შეიძლება იმუშაოს, თუ საკმარისი ნება გაქვთ. თუმცა, რეალურ ცხოვრებაში წარუმატებლობა უბრალოდ არ ხდება, ისინი გარდაუვალია, ყველგან და ყველაფერში. და როგორ მოვიქცეთ მათ მიკროსერვისების შემთხვევაში? ჩვენი აზრით, უმჯობესია დაეყრდნოთ არა ნებისყოფას, არამედ კონტეინერების შესაძლებლობებს, კუბერნეტები, Red Hat OpenShiftდა ისტიო.

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

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

ამომრთველი თეორიულად

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

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

ამომრთველი პრაქტიკაში

მაგალითად, ჩვენ გავუშვით ჩვენი რეკომენდაციის მიკროსერვისის ორ ვერსიას OpenShift-ზე. ვერსია 1 კარგად იმუშავებს, მაგრამ v2-ში ჩვენ ვაშენებთ დაგვიანებით სერვერზე შენელების სიმულაციისთვის. შედეგების სანახავად გამოიყენეთ ინსტრუმენტი ალყის:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

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

ამისათვის ჩვენ გამოვიყენებთ Istio-ს ნელი კონტეინერების ზარების აღმოსაფხვრელად. ასე გამოიყურება შესაბამისი კონფიგურაცია Circuit Breaker-ის გამოყენებით:

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

კარგი, ჩვენ გვაქვს ამომრთველი, რა არის შემდეგი?

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

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

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

წყარო: www.habr.com