Kubernetes: დააჩქარეთ თქვენი სერვისები CPU ლიმიტების მოხსნით

2016 წელს ჩვენ ბუფერში ვართ კუბერნეტესზე გადავიდადა ახლა დაახლოებით 60 კვანძი (AWS-ზე) და 1500 კონტეინერი მუშაობს ჩვენს k8s კლასტერზე, რომელსაც მართავს კოპსი. თუმცა, ჩვენ გადავედით მიკროსერვისებზე საცდელი და შეცდომის გზით და k8-ებთან მუშაობის რამდენიმე წლის შემდეგაც კი კვლავ ახალი პრობლემების წინაშე ვდგავართ. ამ პოსტში ვისაუბრებთ პროცესორის შეზღუდვები: რატომ გვეგონა, რომ ისინი კარგი პრაქტიკა იყო და რატომ აღმოჩნდა არც ისე კარგი.

პროცესორის შეზღუდვები და შეფერხება

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

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

რა შეიძლება მოხდეს, თუ არ დავაწესოთ პროცესორის ლიმიტები?

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

ჩახშობის და რეაგირების პრობლემის გამოვლინება

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

როგორც ქვემოთ ხედავთ, ჩვენ დავაწესეთ ლიმიტი 800m (0.8 ან 80% ბირთვი) და პიკური მნიშვნელობები საუკეთესო მიღწევაში 200m (20% ბირთვი). როგორც ჩანს, სერვისის ჩახშობამდე ჯერ კიდევ გვაქვს პროცესორის დიდი სიმძლავრე, თუმცა...

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

ამის წინაშე მალევე აღმოვაჩინეთ რამდენიმე რესურსი (პრობლემა github-ზე, პრეზენტაცია zadano-ზე, პოსტი omio-ზე) შემცირების გამო სერვისების შესრულების და რეაგირების დროის შემცირების შესახებ.

რატომ ვხედავთ throttling დაბალი CPU დატვირთვის? მოკლე ვერსია ასეთია: „ლინუქსის ბირთვში არის ხარვეზი, რომელიც იწვევს კონტეინერების არასაჭირო ჩახშობას პროცესორის განსაზღვრული ლიმიტებით“. თუ გაინტერესებთ პრობლემის ბუნება, შეგიძლიათ წაიკითხოთ პრეზენტაცია (ვიდეო и ტექსტი პარამეტრები) დეივ ჩილუკის მიერ.

CPU შეზღუდვების მოხსნა (უკიდურესი სიფრთხილით)

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

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

საქმიანი მიმოწერა აქტუალურ საკითხზე.

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

„შეუზღუდავი“ სერვისების იზოლაცია:

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

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

სწორი პროცესორისა და მეხსიერების მოთხოვნის მინიჭება:

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

როგორც გრაფიკზე ხედავთ, პროცესორზე მაქსიმალურ დატვირთვას მიაღწია 242m CPU ბირთვები (0.242 პროცესორის ბირთვი). პროცესორის მოთხოვნისთვის საკმარისია ამ მნიშვნელობაზე ოდნავ დიდი რიცხვის აღება. გთხოვთ გაითვალისწინოთ, რომ რადგან სერვისები მომხმარებელზეა ორიენტირებული, პიკური დატვირთვის მნიშვნელობები ემთხვევა ტრაფიკს.

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

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

დასკვნები

მოხარული ვარ გამოვაქვეყნო ეს შესანიშნავი შედეგები ექსპერიმენტებიდან ბოლო რამდენიმე კვირის განმავლობაში; ჩვენ უკვე ვნახეთ მნიშვნელოვანი გაუმჯობესება ყველა შეცვლილ სერვისში:

ჩვენ მივაღწიეთ საუკეთესო შედეგებს ჩვენს მთავარ გვერდზე (buffer.com), იქ სერვისი დაჩქარდა ოცდაორჯერ!

გამოსწორებულია ლინუქსის ბირთვის შეცდომა?

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

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

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

• Debian: შესწორება ინტეგრირებულია განაწილების უახლეს ვერსიაში, ბასტერიდა გამოიყურება საკმაოდ სუფთა (2020 წლის აგვისტო). ზოგიერთი წინა ვერსია ასევე შეიძლება დაფიქსირდეს.
• Ubuntu: შესწორება ინტეგრირებულია უახლეს ვერსიაში Ubuntu Focal Fossa 20.04
• EKS-ს ჯერ კიდევ აქვს გამოსწორება 2019 წლის დეკემბერში. თუ თქვენი ვერსია ამაზე დაბალია, უნდა განაახლოთ AMI.
• კოპები: 2020 წლის ივნისიდან у kops 1.18+ მთავარი ჰოსტის სურათი იქნება Ubuntu 20.04. თუ კოპების თქვენი ვერსია უფრო ძველია, შეიძლება დაგჭირდეთ გამოსწორების მოლოდინი. ჩვენ თვითონ ველოდებით ახლა.
• GKE (Google Cloud): ინტეგრირებული შესწორება 2020 წლის იანვარში, თუმცა არის პრობლემები სტრესთან დაკავშირებით ჯერ კიდევ შეინიშნება.

რა უნდა გააკეთოს, თუ გამოსწორებამ მოაგვარა დაძაბვის პრობლემა?

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

დასკვნა

• თუ თქვენ მუშაობთ Docker კონტეინერებთან Linux-ის ქვეშ (არ აქვს მნიშვნელობა Kubernetes, Mesos, Swarm თუ სხვა), თქვენმა კონტეინერებმა შეიძლება დაკარგოს შესრულება გათიშვის გამო;
• სცადეთ თქვენი განაწილების უახლესი ვერსიის განახლება იმ იმედით, რომ შეცდომა უკვე გამოსწორებულია;
• პროცესორის ლიმიტების მოხსნა პრობლემას მოაგვარებს, მაგრამ ეს არის სახიფათო ტექნიკა, რომელიც უნდა იქნას გამოყენებული უკიდურესი სიფრთხილით (უმჯობესია ჯერ განაახლოთ ბირთვი და შევადაროთ შედეგები);
• თუ თქვენ ამოიღეთ CPU-ს ლიმიტები, ყურადღებით აკონტროლეთ თქვენი CPU და მეხსიერების გამოყენება და დარწმუნდით, რომ თქვენი CPU რესურსები აღემატება თქვენს მოხმარებას;
• უსაფრთხო ვარიანტი იქნება პოდების ავტომატური მასშტაბირება, რათა შეიქმნას ახალი ბლოკები მაღალი ტექნიკის დატვირთვის შემთხვევაში, რათა kubernetes-მა მიაკუთვნოს ისინი თავისუფალ კვანძებს.

იმედი მაქვს, რომ ეს პოსტი დაგეხმარებათ გააუმჯობესოთ თქვენი კონტეინერის სისტემების მუშაობა.

PS აქ ავტორი მიმოწერას უწევს მკითხველებსა და კომენტატორებს (ინგლისურად).


წყარო: www.habr.com