ავტომატური მასშტაბირება და რესურსების მართვა Kubernetes-ში (მიმოხილვა და ვიდეო ანგარიში)

27 აპრილს კონფერენციაზე გაფიცვა 2019, როგორც "DevOps" განყოფილების ნაწილი, მოცემულია მოხსენება "Autoscaling და რესურსების მართვა Kubernetes-ში". იგი საუბრობს იმაზე, თუ როგორ შეგიძლიათ გამოიყენოთ K8s თქვენი აპლიკაციების მაღალი ხელმისაწვდომობის უზრუნველსაყოფად და მაქსიმალური შესრულების უზრუნველსაყოფად.

ტრადიციულად, სიამოვნებით წარმოგიდგენთ მოხსენების ვიდეო (44 წუთი, სტატიაზე ბევრად უფრო ინფორმაციული) და ძირითადი რეზიუმე ტექსტის სახით. წადი!

მოხსენების თემა სიტყვით გავაანალიზოთ და დავიწყოთ ბოლოდან.

კუბერნეტები

ვთქვათ, გვაქვს Docker კონტეინერები ჩვენს მასპინძელზე. Რისთვის? განმეორებადობისა და იზოლაციის უზრუნველსაყოფად, რაც თავის მხრივ იძლევა მარტივი და კარგი განლაგების საშუალებას, CI/CD. ჩვენ გვაქვს ბევრი ასეთი მანქანა კონტეინერებით.

რას გვთავაზობს Kubernetes ამ შემთხვევაში?

1. ჩვენ ვწყვეტთ ფიქრს ამ მანქანებზე და ვიწყებთ მუშაობას "ღრუბელთან" კონტეინერების კასეტური ან წიპწები (კონტეინერების ჯგუფები).
2. უფრო მეტიც, ჩვენ არც კი ვფიქრობთ ცალკეულ პოდებზე, არამედ უფრო მეტს ვმართავთоუფრო დიდი ჯგუფები. ასეთი მაღალი დონის პრიმიტივები საშუალებას გვაძლევს ვთქვათ, რომ არსებობს შაბლონი გარკვეული დატვირთვის გასაშვებად და აქ არის საჭირო რაოდენობის ინსტანციები მის გასაშვებად. თუ ჩვენ შემდგომში შევცვლით შაბლონს, ყველა ინსტანცია შეიცვლება.
3. ერთად დეკლარაციული API კონკრეტული ბრძანებების თანმიმდევრობის შესრულების ნაცვლად, ჩვენ აღვწერთ "სამყაროს სტრუქტურას" (YAML-ში), რომელიც შექმნილია Kubernetes-ის მიერ. და კიდევ: როდესაც აღწერა იცვლება, მისი რეალური ჩვენებაც შეიცვლება.

Რესურსების მართვა

CPU

მოდით გავუშვათ nginx, php-fpm და mysql სერვერზე. ამ სერვისებს რეალურად ექნებათ კიდევ უფრო მეტი პროცესი გაშვებული, რომელთაგან თითოეული მოითხოვს გამოთვლით რესურსებს:

(სლაიდზე ნომრები არის "თუთიყუშები", თითოეული პროცესის აბსტრაქტული საჭიროება გამოთვლითი სიმძლავრისთვის)

ამით მუშაობის გასაადვილებლად, ლოგიკურია პროცესების ჯგუფებად გაერთიანება (მაგალითად, ყველა nginx პროცესი ერთ ჯგუფში "nginx"). ამის გაკეთების მარტივი და აშკარა გზაა თითოეული ჯგუფის კონტეინერში მოთავსება:

გასაგრძელებლად, თქვენ უნდა გახსოვდეთ რა არის კონტეინერი (Linux-ში). მათი გამოჩენა შესაძლებელი გახდა ბირთვში სამი ძირითადი მახასიათებლის წყალობით, რომლებიც საკმაოდ დიდი ხნის წინ იქნა დანერგილი: შესაძლებლობები, სახელთა სივრცე и ჯგუფები. და შემდგომ განვითარებას ხელი შეუწყო სხვა ტექნოლოგიებმა (მათ შორის მოსახერხებელი "ჭურვები", როგორიცაა Docker):

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

მოდით დავუბრუნდეთ CPU-ს მოთხოვნებს ამ პროცესებისთვის, ახლა კი პროცესების ჯგუფებისთვის:

(ვიმეორებ, რომ ყველა რიცხვი არის რესურსების საჭიროების აბსტრაქტული გამოხატულება)

ამავდროულად, თავად პროცესორს აქვს გარკვეული სასრული რესურსი (მაგალითში ეს არის 1000), რომელიც შეიძლება ყველას აკლდეს (ყველა ჯგუფის საჭიროებების ჯამია 150+850+460=1460). რა მოხდება ამ შემთხვევაში?

ბირთვი იწყებს რესურსების განაწილებას და ამას აკეთებს "სამართლიანად", რაც თითოეულ ჯგუფს აძლევს იგივე რაოდენობის რესურსებს. მაგრამ პირველ შემთხვევაში საჭიროზე მეტია (333>150), ამიტომ ჭარბი (333-150=183) რჩება რეზერვში, რომელიც ასევე თანაბრად ნაწილდება ორ სხვა კონტეინერს შორის:

შედეგად: პირველ კონტეინერს ჰქონდა საკმარისი რესურსი, მეორეს - არ გააჩნდა საკმარისი რესურსი, მესამეს - არ გააჩნდა საკმარისი რესურსი. ეს არის ქმედებების შედეგი "პატიოსანი" გრაფიკი Linux-ში - CFS. მისი მოქმედების რეგულირება შესაძლებელია დავალების გამოყენებით წონა თითოეული კონტეინერი. მაგალითად, ასე:

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

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

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

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

მოდით დავუბრუნდეთ Linux-ის ბირთვს და მის ინტერაქციას CPU-სთან - საერთო სურათი ასეთია:

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

1. წონა კონტეინერის (მოთხოვნის) არის აქციების;
2. მთლიანი CPU დროის პროცენტი კონტეინერის ამოცანებზე მუშაობისთვის (ლიმიტები) არის კვოტის.

როგორ გავზომოთ CPU?

არსებობს სხვადასხვა გზები:

1. რა არის თუთიყუში, არავინ იცის - თქვენ უნდა მოლაპარაკება ყოველ ჯერზე.
2. ინტერესი უფრო ნათელი, მაგრამ შედარებითი: სერვერის 50% 4 ბირთვით და 20 ბირთვით არის სრულიად განსხვავებული რამ.
3. შეგიძლიათ გამოიყენოთ უკვე ნახსენები წონა, რაც ლინუქსმა იცის, მაგრამ ისინიც ნათესავია.
4. ყველაზე ადეკვატური ვარიანტია გამოთვლითი რესურსების გაზომვა წამი. იმათ. პროცესორის დროის წამებში რეალურ დროში წამებთან შედარებით: პროცესორის დროის 1 წამი იყო მოცემული 1 რეალურ წამზე - ეს არის მთელი CPU ბირთვი.

ლაპარაკის გასაადვილებლად, მათ პირდაპირ დაიწყეს გაზომვა ბირთვები, რაც ნიშნავს მათ იგივე პროცესორის დროს რეალურთან შედარებით. ვინაიდან Linux-ს ესმის წონა, მაგრამ არა იმდენად CPU-ის დრო/ბირთვები, საჭირო იყო მექანიზმი ერთიდან მეორეზე გადასათარგმნად.

განვიხილოთ მარტივი მაგალითი სერვერის 3 CPU ბირთვით, სადაც სამ პოდს მიენიჭება წონა (500, 1000 და 1500), რომლებიც ადვილად გარდაიქმნება მათთვის გამოყოფილი ბირთვების შესაბამის ნაწილებზე (0,5, 1 და 1,5).

თუ თქვენ აიღებთ მეორე სერვერს, სადაც იქნება ორჯერ მეტი ბირთვი (6) და განათავსებთ იქ იგივე პოდებს, ბირთვების განაწილება მარტივად შეიძლება გამოითვალოს უბრალოდ 2-ზე გამრავლებით (1, 2 და 3, შესაბამისად). მაგრამ მნიშვნელოვანი მომენტი დგება, როდესაც ამ სერვერზე გამოჩნდება მეოთხე პოდი, რომლის წონა, მოხერხებულობისთვის, იქნება 3000. ის ართმევს CPU რესურსების ნაწილს (ნახევარ ბირთვს), ხოლო დარჩენილი პოდებისთვის ისინი ხელახლა გამოითვლება (განახევრდება):

Kubernetes და CPU რესურსები

Kubernetes-ში CPU რესურსები ჩვეულებრივ იზომება მილიადრაქსი, ე.ი. 0,001 ბირთვი აღებულია, როგორც ძირითადი წონა. (იგივეს Linux/cgroups ტერმინოლოგიაში ეწოდება CPU share, თუმცა, უფრო ზუსტად, 1000 millicore = 1024 CPU shares.) K8s უზრუნველყოფს, რომ სერვერზე არ განათავსებს უფრო მეტ პოდს, ვიდრე არის CPU რესურსები ყველა პოდის წონის ჯამისთვის.

როგორ ხდება ეს? როდესაც თქვენ დაამატებთ სერვერს Kubernetes კლასტერში, იტყობინება, რამდენი CPU ბირთვი აქვს მას. ახალი პოდის შექმნისას კი კუბერნეტის დამგეგმავმა იცის რამდენი ბირთვი დასჭირდება ამ პოდს. ამრიგად, pod გადაეცემა სერვერს, სადაც არის საკმარისი ბირთვი.

რა მოხდება თუ არარის მითითებულია მოთხოვნა (ანუ პოდს არ აქვს მისთვის საჭირო ბირთვების განსაზღვრული რაოდენობა)? მოდით გაერკვნენ, თუ როგორ ითვლის Kubernetes ზოგადად რესურსებს.

პოდისთვის შეგიძლიათ მიუთითოთ ორივე მოთხოვნა (CFS განრიგი) და ლიმიტები (გახსოვთ შუქნიშანი?):

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

მეხსიერება

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

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

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

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

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

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

საერთო ჯამში

კუბერნეტესში თითოეული პოდი მოცემულია requests и limits - ორივე პარამეტრი CPU-სთვის და მეხსიერებისთვის:

1. მოთხოვნიდან გამომდინარე, მუშაობს Kubernetes scheduler, რომელიც ანაწილებს პოდებს სერვერებს შორის;
2. ყველა პარამეტრზე დაფუძნებული, pod-ის QoS კლასი განისაზღვრება;
3. შედარებითი წონები გამოითვლება CPU მოთხოვნის საფუძველზე;
4. CFS განრიგის კონფიგურაცია ხდება CPU მოთხოვნის საფუძველზე;
5. OOM მკვლელი კონფიგურებულია მეხსიერების მოთხოვნების საფუძველზე;
6. "შუქნიშანი" კონფიგურებულია CPU-ს ლიმიტების საფუძველზე;
7. მეხსიერების ლიმიტებზე დაყრდნობით, ლიმიტი კონფიგურებულია cჯგუფისთვის.

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

ავტოსკალირება

K8s კლასტერ-ავტოსკალერი

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

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

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

განვიხილოთ 3 სერვერის კლასტერი, რომელსაც აქვს Deployment. მას აქვს 6 პოდი: ახლა არის 2 თითოეული სერვერისთვის. რატომღაც გვინდოდა ერთ-ერთი სერვერის გამორთვა. ამისათვის ჩვენ გამოვიყენებთ ბრძანებას kubectl drain, რომელიც:

• აკრძალავს ამ სერვერზე ახალი პოდების გაგზავნას;
• წაშლის სერვერზე არსებულ პოდებს.

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

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

MongoDB შეეძლო იღუპება, რადგან მას სჭირდება კვორუმი: სამი ინსტალაციის კლასტერისთვის, მინიმუმ ორი უნდა ფუნქციონირებდეს. თუმცა, ეს არ ხდება - მადლობა PodDisruptionBudget. ეს პარამეტრი განსაზღვრავს სამუშაო რგოლების მინიმალურ საჭირო რაოდენობას. იმის ცოდნა, რომ ერთ-ერთი MongoDB pod აღარ მუშაობს და დაინახავთ, რომ PodDisruptionBudget დაყენებულია MongoDB-სთვის minAvailable: 2, Kubernetes არ მოგცემთ უფლებას წაშალოთ pod.

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

ჰორიზონტალური მასშტაბირება

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

დღეს Kubernetes-ში ამის გაკეთება არ არის საჭირო ხელით: ბლოკების რაოდენობის ავტომატური ზრდა/კლება კონფიგურირებულია გაზომილი დატვირთვის ინდიკატორების მნიშვნელობების მიხედვით.

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

როგორ გავაკეთოთ ეს ტექნიკურად - შეაგროვეთ მეტრიკა და ა.შ. - ამის შესახებ ანგარიშში დეტალურად ვისაუბრე მონიტორინგი და კუბერნეტები. და მთავარი რჩევა ოპტიმალური პარამეტრების არჩევისთვის არის ექსპერიმენტი!

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

იმის ნაცვლად, რომ დასკვნა

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

ვიდეოები და სლაიდები

ვიდეო სპექტაკლიდან (44 წუთი):

ანგარიშის პრეზენტაცია:

PS

სხვა მოხსენებები Kubernetes-ის შესახებ ჩვენს ბლოგზე:

• «Kubernetes-ის გაფართოება და შევსება» (ანდრეი პოლოვოვი; 8 წლის 2019 აპრილი Saint HighLoad++-ზე);
• «მონაცემთა ბაზები და კუბერნეტები» (დმიტრი სტოლიაროვი; 8 წლის 2018 ნოემბერი HighLoad++-ზე);
• «მონიტორინგი და კუბერნეტები» (დმიტრი სტოლიაროვი; 28 წლის 2018 მაისი RootConf-ზე);
• «CI/CD საუკეთესო პრაქტიკა Kubernetes-თან და GitLab-თან» (დმიტრი სტოლიაროვი; 7 წლის 2017 ნოემბერი HighLoad++-ზე);
• «ჩვენი გამოცდილება Kubernetes-თან მცირე პროექტებში» (დმიტრი სტოლიაროვი; 6 წლის 2017 ივნისი RootConf-ზე).

წყარო: www.habr.com