როგორ გამოიწვია პოდ პრიორიტეტებმა Kubernetes-ში Grafana Labs-ის შეფერხება

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

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

წინაისტორია

Grafana Cloud Hosted Prometheus სერვისი ეფუძნება Cortex — CNCF პროექტი ჰორიზონტალურად მასშტაბირებადი, ხელმისაწვდომად ხელმისაწვდომი პრომეთეს სერვისის შესაქმნელად. Cortex არქიტექტურა შედგება ინდივიდუალური მიკროსერვისების ნაკრებისგან, რომელთაგან თითოეული ასრულებს თავის ფუნქციას: რეპლიკაცია, შენახვა, მოთხოვნები და ა.შ. Cortex აქტიური განვითარების პროცესშია და მუდმივად ამატებს ახალ ფუნქციებს და აუმჯობესებს შესრულებას. ჩვენ რეგულარულად ვაყენებთ Cortex-ის ახალ გამოშვებებს კლასტერებში, რათა მომხმარებლებმა ისარგებლონ ამ ფუნქციებით - საბედნიეროდ, Cortex შეიძლება განახლდეს შეფერხების გარეშე.

უწყვეტი განახლებისთვის, Ingester Cortex სერვისი საჭიროებს დამატებით Ingester ასლს განახლების პროცესში. (Შენიშვნა. თარგმნა: ინგესტერი - ქერქის ძირითადი კომპონენტი. მისი ამოცანაა შეაგროვოს ნიმუშების მუდმივი ნაკადი, დააჯგუფოს ისინი პრომეთეს ნაწილებად და შეინახოს ისინი მონაცემთა ბაზაში, როგორიცაა DynamoDB, BigTable ან Cassandra.) ეს საშუალებას აძლევს ძველ ინგესტერებს გადაუგზავნონ მიმდინარე მონაცემები ახალ მომხმარებლებზე. აღსანიშნავია, რომ ინგესტერები რესურსების მომთხოვნი არიან. იმისთვის, რომ მათ იმუშაონ, თქვენ უნდა გქონდეთ 4 ბირთვი და 15 GB მეხსიერება თითო პოდზე, ე.ი. ბაზის აპარატის დამუშავების სიმძლავრის და მეხსიერების 25% ჩვენი Kubernetes კლასტერების შემთხვევაში. ზოგადად, ჩვენ ჩვეულებრივ კლასტერში გაცილებით მეტი გამოუყენებელი რესურსი გვაქვს, ვიდრე 4 ბირთვი და 15 გბაიტი მეხსიერება, ასე რომ, ჩვენ შეგვიძლია მარტივად დავატრიალოთ ეს დამატებითი ინგესტერები განახლებების დროს.

თუმცა, ხშირად ხდება, რომ ნორმალური მუშაობის დროს არცერთ მანქანას არ აქვს გამოუყენებელი რესურსების ეს 25%. დიახ, ჩვენ არც კი ვცდილობთ: CPU და მეხსიერება ყოველთვის სასარგებლო იქნება სხვა პროცესებისთვის. ამ პრობლემის გადასაჭრელად, ჩვენ გადავწყვიტეთ გამოვიყენოთ Kubernetes Pod Priorities. იდეა მდგომარეობს იმაში, რომ ინგესტერებს უფრო მეტი პრიორიტეტი მივცეთ, ვიდრე სხვა (მაქალაქო) მიკროსერვისებს. როდესაც ჩვენ გვჭირდება დამატებითი (N+1) ინგესტერის გაშვება, ჩვენ დროებით ვცვლით სხვა, უფრო პატარა პოდებს. ეს ხვრელები გადადის სხვა აპარატების თავისუფალ რესურსებზე, ტოვებს საკმარისად დიდ „ხვრელს“ დამატებითი ინგესტერის გასაშვებად.

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

უბედური შემთხვევა

პარასკევს, 19 ივლისს, ერთ-ერთმა ინჟინერმა გამოუშვა ახალი გამოყოფილი Cortex კლასტერი დიდი კლიენტისთვის. ამ კლასტერის კონფიგურაცია არ მოიცავდა ახალ პოდ პრიორიტეტებს, ამიტომ ყველა ახალ პოდს მიენიჭა ნაგულისხმევი პრიორიტეტი - საშუალოდ.

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

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

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

გამოვლენა და გამოსწორება

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

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

კიდევ 10 წუთი დაიხარჯა Cortex-ის წინ მდებარე ავთენტიფიკაციის საპირისპირო პროქსიებიდან შეცდომების დიაგნოსტიკასა და გამოსწორებას. OOM შეცდომები გამოწვეული იყო QPS-ის ათჯერ გაზრდით (მიგვაჩნია, რომ კლიენტის პრომეთეს სერვერების ზედმეტად აგრესიული მოთხოვნების გამო).

Aftermath

მთლიანი შესვენება იყო 26 წუთი. მონაცემები არ დაიკარგა. მომხმარებლებმა წარმატებით ჩატვირთეს მეხსიერების ყველა მონაცემი გრძელვადიან საცავში. გამორთვის დროს, კლიენტის პრომეთეს სერვერები ბუფერულად წაიშალა (დისტანციური) ჩანაწერების გამოყენებით ახალი API remote_write WAL-ზე დაფუძნებული (ავტორი კალუმ სტიანი Grafana Labs-დან) და გაიმეორა წარუმატებელი ჩანაწერები ავარიის შემდეგ.

წარმოების კლასტერული ჩაწერის ოპერაციები

დასკვნები

მნიშვნელოვანია ამ ინციდენტიდან სწავლა და აუცილებელი ზომების მიღება მისი განმეორების თავიდან ასაცილებლად.

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

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

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

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

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «ავტომატური მასშტაბირება და რესურსების მართვა Kubernetes-ში (მიმოხილვა და ვიდეო ანგარიში)";
• «Kubernetes სათავგადასავლო Dailymotion: ინფრასტრუქტურის შექმნა ღრუბლებში + შიდა შენობაში";
• «Tinder გადასვლა Kubernetes-ზე";
• «Kubernetes-ის წარმატების ისტორიები წარმოებაში. ნაწილი 10: Reddit".

წყარო: www.habr.com