ავტოსკალირების სამი დონე Kubernetes-ში: როგორ გამოვიყენოთ ისინი ეფექტურად

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

სტატია Kubernetes Autoscaling 101: Cluster Autoscaler, Horizontal Autoscaler და Vertical Pod Autoscaler თარგმნა გუნდის მიერ, რომელმაც განახორციელა ავტოსკალირება Kubernetes aaS Mail.ru-დან.

რატომ არის მნიშვნელოვანი ვიფიქროთ სკალირებაზე

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

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

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

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

Kubernetes autoscaling დონეები

ეფექტური ავტოსკალირება მოითხოვს ორ დონეს შორის კოორდინაციას:

1. პოდის დონე, მათ შორის ჰორიზონტალური (Horizontal Pod Autoscaler, HPA) და ვერტიკალური autoscaler (Vertical Pod Autoscaler, VPA). ეს არის თქვენი კონტეინერებისთვის ხელმისაწვდომი რესურსების მასშტაბირება.
2. კლასტერის დონე, რომელსაც მართავს Cluster Autoscaler (CA), რომელიც ზრდის ან ამცირებს კვანძების რაოდენობას კლასტერში.

ჰორიზონტალური Autoscaler (HPA) მოდული

როგორც სახელი გვთავაზობს, HPA ადიდებს პოდ რეპლიკების რაოდენობას. დევოპების უმეტესობა იყენებს CPU-ს და მეხსიერების დატვირთვას, როგორც ტრიგერები რეპლიკების რაოდენობის შესაცვლელად. თუმცა, შესაძლებელია სისტემის მასშტაბირება დაფუძნებული მორგებული მეტრიკა, მათ მოედანზე или даже გარე მეტრიკა.

მაღალი დონის HPA ოპერაციული დიაგრამა:

1. HPA მუდმივად ამოწმებს ინსტალაციის დროს მითითებულ მეტრულ მნიშვნელობებს ნაგულისხმევი ინტერვალით 30 წამი.
2. HPA ცდილობს გაზარდოს მოდულების რაოდენობა, თუ მითითებულ ზღვარს მიაღწევს.
3. HPA განაახლებს ასლების რაოდენობას განლაგების/განმეორების კონტროლერში.
4. განლაგების/განმეორების კონტროლერი ახორციელებს ნებისმიერ საჭირო დამატებით მოდულს.

HPA იწყებს მოდულის განლაგების პროცესს, როდესაც მეტრულ ზღვარს მიაღწევს

HPA-ს გამოყენებისას გაითვალისწინეთ შემდეგი:

• ნაგულისხმევი HPA შემოწმების ინტერვალი არის 30 წამი. იგი დაწესებულია დროშით horizontal-pod-autoscaler-sync-period კონტროლერის მენეჯერში.
• ნაგულისხმევი შედარებითი შეცდომა არის 10%.
• მოდულების რაოდენობის ბოლო გაზრდის შემდეგ, HPA მოელის, რომ მეტრიკა დასტაბილურდება სამი წუთის განმავლობაში. ეს ინტერვალი მითითებულია დროშით horizontal-pod-autoscaler-upscale-delay.
• მოდულების რაოდენობის ბოლო შემცირების შემდეგ, HPA ელოდება ხუთი წუთის განმავლობაში სტაბილიზაციას. ეს ინტერვალი მითითებულია დროშით horizontal-pod-autoscaler-downscale-delay.
• HPA საუკეთესოდ მუშაობს განლაგების ობიექტებთან, ვიდრე რეპლიკაციის კონტროლერებთან. ჰორიზონტალური ავტომატური მასშტაბირება შეუთავსებელია მოძრავი განახლებასთან, რომელიც პირდაპირ მანიპულირებს რეპლიკაციის კონტროლერებთან. განლაგებისას, ასლების რაოდენობა პირდაპირ დამოკიდებულია განლაგების ობიექტებზე.

ბუჩქების ვერტიკალური ავტოსკალირება

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

VPA ასევე პასუხობს OOM (მეხსიერების გარეშე) მოვლენებს. CPU-ის დროისა და მეხსიერების შეცვლა მოითხოვს პოდების გადატვირთვას. გადატვირთვისას, VPA პატივს სცემს გამოყოფის ბიუჯეტს (pods განაწილების ბიუჯეტი, PDB) უზრუნველყოს მოდულების მინიმალური საჭირო რაოდენობა.

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

გარდა ამისა, VPA-ს აქვს საინტერესო სარეკომენდაციო ფუნქცია (VPA Recommender). ის აკონტროლებს რესურსების გამოყენებას და ყველა მოდულის OOM მოვლენებს, რათა შესთავაზოს ახალი მეხსიერების და CPU დროის მნიშვნელობები ინტელექტუალურ ალგორითმზე დაფუძნებული ისტორიულ მეტრიკაზე. ასევე არსებობს API, რომელიც იღებს pod სახელურს და აბრუნებს შემოთავაზებულ რესურს მნიშვნელობებს.

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

მაღალი დონის VPA ოპერაციის სქემა:

1. VPA მუდმივად ამოწმებს ინსტალაციის დროს მითითებულ მეტრულ მნიშვნელობებს ნაგულისხმევი ინტერვალით 10 წამით.
2. თუ მითითებულ ზღვარს მიაღწევს, VPA ცდილობს შეცვალოს რესურსების გამოყოფილი რაოდენობა.
3. VPA განაახლებს რესურსების რაოდენობას განლაგების/განმეორების კონტროლერში.
4. როდესაც მოდულები გადატვირთულია, ყველა ახალი რესურსი გამოიყენება შექმნილ ინსტანციებზე.

VPA ამატებს რესურსების საჭირო რაოდენობას

გთხოვთ, გაითვალისწინოთ შემდეგი პუნქტები VPA-ს გამოყენებისას:

• სკალირება მოითხოვს ღობის სავალდებულო გადატვირთვას. ეს აუცილებელია ცვლილებების შეტანის შემდეგ არასტაბილური ოპერაციის თავიდან ასაცილებლად. საიმედოობისთვის, მოდულები გადატვირთეთ და ნაწილდება კვანძებში ახლად გამოყოფილი რესურსების საფუძველზე.
• VPA და HPA ჯერ კიდევ არ არის თავსებადი ერთმანეთთან და არ შეიძლება იმუშაონ ერთსა და იმავე პოდებზე. თუ თქვენ იყენებთ სკალირების ორივე მექანიზმს იმავე კლასტერში, დარწმუნდით, რომ თქვენი პარამეტრები ხელს უშლის მათ გააქტიურებას იმავე ობიექტებზე.
• VPA არეგულირებს კონტეინერების მოთხოვნებს რესურსებზე მხოლოდ წარსული და მიმდინარე გამოყენების საფუძველზე. ის არ ადგენს რესურსების გამოყენების ლიმიტებს. შეიძლება იყოს პრობლემები აპლიკაციების არასწორად მუშაობასთან დაკავშირებით და დაიწყება უფრო და უფრო მეტი რესურსის აღება, ეს გამოიწვევს Kubernetes-ის გამორთვას ამ pod.
• VPA ჯერ კიდევ განვითარების ადრეულ ეტაპზეა. მოემზადეთ, რომ სისტემამ შესაძლოა გარკვეული ცვლილებები განიცადოს უახლოეს მომავალში. შეგიძლიათ წაიკითხოთ ცნობილი შეზღუდვები и განვითარების გეგმები. ამდენად, იგეგმება VPA-სა და HPA-ის ერთობლივი ფუნქციონირების განხორციელება, ასევე მოდულების განთავსება მათთვის ვერტიკალური ავტოსკალირების პოლიტიკასთან ერთად (მაგალითად, სპეციალური ეტიკეტი "საჭიროებს VPA").

Kubernetes კლასტერის ავტომატური მასშტაბირება

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

SA-ს მუშაობის მაღალი დონის სქემა:

1. CA ამოწმებს მომლოდინე მოდულებს ნაგულისხმევი ინტერვალით 10 წამით.
2. თუ ერთი ან მეტი პოდი ლოდინის მდგომარეობაშია, რადგან კლასტერს არ აქვს საკმარისი რესურსი მათი გამოსაყოფად, ის ცდილობს უზრუნველყოს ერთი ან მეტი დამატებითი კვანძი.
3. როდესაც ღრუბლოვანი სერვისის პროვაიდერი გამოყოფს საჭირო კვანძს, ის უერთდება კლასტერს და მზადაა მოემსახუროს პოდებს.
4. Kubernetes-ის დამგეგმავი ანაწილებს მომლოდინე პოდებს ახალ კვანძზე. თუ ამის შემდეგ ზოგიერთი მოდული კვლავ რჩება მოლოდინის მდგომარეობაში, პროცესი მეორდება და ახალი კვანძები დაემატება კლასტერს.

ღრუბელში კასეტური კვანძების ავტომატური უზრუნველყოფა

CA-ს გამოყენებისას გაითვალისწინეთ შემდეგი:

• CA უზრუნველყოფს, რომ კლასტერში ყველა პოდს ჰქონდეს ადგილი გასაშვებად, CPU დატვირთვის მიუხედავად. ის ასევე ცდილობს უზრუნველყოს, რომ კლასტერში არ იყოს ზედმეტი კვანძები.
• CA აღრიცხავს მასშტაბის საჭიროებას დაახლოებით 30 წამის შემდეგ.
• მას შემდეგ, რაც კვანძი აღარ არის საჭირო, CA ნაგულისხმევად ელოდება 10 წუთს, სანამ სისტემის სკალირებას მოაკლდება.
• ავტოსკალირების სისტემას აქვს ექსპანდერების კონცეფცია. ეს არის სხვადასხვა სტრატეგია კვანძების ჯგუფის არჩევისთვის, რომლებსაც დაემატება ახალი კვანძები.
• გამოიყენეთ ვარიანტი პასუხისმგებლობით cluster-autoscaler.kubernetes.io/safe-to-evict (true). თუ თქვენ დააინსტალირებთ უამრავ პოდს, ან თუ ბევრი მათგანი მიმოფანტულია ყველა კვანძში, თქვენ დიდწილად დაკარგავთ კლასტერის მასშტაბის უნარს.
• გამოიყენეთ PodDisruptionBudgetsრათა თავიდან აიცილოთ pod-ების წაშლა, რამაც შეიძლება გამოიწვიოს თქვენი აპლიკაციის ნაწილების სრული გატეხვა.

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

სრულყოფილი ჰარმონიისთვის, ავტომატური მასშტაბირება უნდა იქნას გამოყენებული როგორც pod დონეზე (HPA/VPA) და კლასტერის დონეზე. ისინი ერთმანეთთან შედარებით მარტივად ურთიერთობენ:

1. HPA-ები ან VPA-ები განაახლებს პოდ რეპლიკებს ან არსებულ პოდებზე გამოყოფილ რესურსებს.
2. თუ არ არის საკმარისი კვანძები დაგეგმილი სკალირებისთვის, CA შენიშნავს ბლოკების არსებობას მოლოდინის მდგომარეობაში.
3. CA გამოყოფს ახალ კვანძებს.
4. მოდულები ნაწილდება ახალ კვანძებზე.

Kubernetes-ის თანამშრომლობითი მასშტაბის სისტემა

გავრცელებული შეცდომები Kubernetes-ის ავტოსკალირებაში

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

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

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

იდეალური სცენარი - 4 წუთი:

1. 30 წამი. სამიზნე მეტრიკის განახლება: 30−60 წამი.
2. 30 წამი. HPA ამოწმებს მეტრულ მნიშვნელობებს: 30 წამი.
3. 2 წამზე ნაკლები. იქმნება პოდები და გადადის მოლოდინის მდგომარეობაში: 1 წამი.
4. 2 წამზე ნაკლები. CA ხედავს მოლოდინის მოდულებს და აგზავნის ზარებს პროვაიდერ კვანძებში: 1 წამი.
5. 3 წუთი. ღრუბლოვანი პროვაიდერი გამოყოფს კვანძებს. K8 ელოდება, სანამ ისინი მზად იქნებიან: 10 წუთამდე (დამოკიდებულია რამდენიმე ფაქტორზე).

ყველაზე უარესი (უფრო რეალური) სცენარი - 12 წუთი:

1. 30 წამი. განაახლეთ სამიზნე მეტრიკა.
2. 30 წამი. HPA ამოწმებს მეტრულ მნიშვნელობებს.
3. 2 წამზე ნაკლები. ხალიჩები იქმნება და შედიან ლოდინის მდგომარეობაში.
4. 2 წამზე ნაკლები. CA ხედავს ლოდინის მოდულებს და აკეთებს ზარებს კვანძების უზრუნველსაყოფად.
5. 10 წუთი. ღრუბლოვანი პროვაიდერი გამოყოფს კვანძებს. K8 ელოდება სანამ ისინი მზად იქნებიან. ლოდინის დრო დამოკიდებულია რამდენიმე ფაქტორზე, როგორიცაა გამყიდველის დაგვიანება, OS-ის დაგვიანება და დამხმარე ინსტრუმენტები.

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

როგორ მართოთ სკალირება Kubernetes-ში

1. Kubernetes არის რესურსების მართვისა და ორკესტრირების ინსტრუმენტი. პოდებისა და კლასტერული რესურსების მართვის ოპერაციები საკვანძო ეტაპია Kubernetes-ის დაუფლებაში.
2. გაიგეთ pod მასშტაბურობის ლოგიკა HPA და VPA-ს გათვალისწინებით.
3. CA უნდა იქნას გამოყენებული მხოლოდ იმ შემთხვევაში, თუ კარგად გესმით თქვენი ბოთლებისა და კონტეინერების საჭიროებები.
4. კლასტერის ოპტიმალური კონფიგურაციისთვის, თქვენ უნდა გესმოდეთ, თუ როგორ მუშაობს სხვადასხვა სკალირების სისტემები ერთად.
5. სკალირების დროის შეფასებისას გაითვალისწინეთ უარესი და საუკეთესო შემთხვევის სცენარები.

წყარო: www.habr.com