კუბერნეტესში სიცოცხლისუნარიანობის გამოკვლევები შეიძლება საშიში იყოს

Შენიშვნა. თარგმნა: წამყვანმა ინჟინერმა ზალანდოდან, ჰენინგ ჯეიკობსმა, არაერთხელ შენიშნა პრობლემები Kubernetes-ის მომხმარებლებში სიცოცხლისუნარიანობის (და მზადყოფნის) ზონდების მიზნისა და მათი სწორი გამოყენების გაგებაში. ამიტომ, მან შეაგროვა თავისი აზრები ამ ტევადი ჩანაწერში, რომელიც საბოლოოდ გახდება K8s დოკუმენტაციის ნაწილი.

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

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

არასწორად არის კონფიგურირებული livenessProbe შეუძლია გააუარესოს მაღალი დატვირთვის სიტუაციები (თოვლის ბურთის გამორთვა + პოტენციურად გრძელი კონტეინერის/აპლიკაციის გაშვების დრო) და გამოიწვიოს სხვა უარყოფითი შედეგები, როგორიცაა დამოკიდებულების ვარდნა (იხილეთ ასევე ჩემი ბოლო სტატია K3s+ACME კომბინაციაში მოთხოვნების რაოდენობის შეზღუდვის შესახებ). კიდევ უფრო უარესია, როდესაც სიცოცხლისუნარიანობის ზონდი შერწყმულია ჯანმრთელობის შემოწმებასთან, რომელიც არის გარე მონაცემთა ბაზა: ერთი DB უკმარისობა განაახლებს თქვენს ყველა კონტეინერს!

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

შენიშვნა: ქვემოთ მოცემული ტესტის უმეტესი ნაწილი თავდაპირველად შედიოდა Zalando-ს შიდა დეველოპერის დოკუმენტაციაში.

მზადყოფნისა და სიცოცხლისუნარიანობის შემოწმებები

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

Kubernetes იყენებს მზადყოფნის ზონდებიიმის გასაგებად, როდის არის კონტეინერი მზად ტრაფიკის მისაღებად. პოდი ითვლება გამოსაყენებლად მზად, თუ მისი ყველა კონტეინერი მზად არის. ამ მექანიზმის ერთ-ერთი გამოყენება არის იმის კონტროლი, თუ რომელი პოდი გამოიყენება Kubernetes სერვისებისთვის (და განსაკუთრებით Ingress-ისთვის).

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

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

მაგალითი

აქ მოცემულია მზაობის ზონდის მაგალითი, რომელიც ამოწმებს გზას /health HTTP-ის საშუალებით ნაგულისხმევი პარამეტრებით (ინტერვალი: 10 წამი, დროის ამოწურვა: 1 წამი, წარმატების ბარიერი: ჰიტები, წარუმატებლობის ბარიერი:3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

რეკომენდაციები

1. მიკროსერვისებისთვის HTTP ბოლო წერტილით (REST და ა.შ.) ყოველთვის განსაზღვრეთ მზადყოფნის გამოძიება, რომელიც ამოწმებს არის თუ არა აპლიკაცია (pod) მზად ტრაფიკის მისაღებად.
2. დარწმუნდით, რომ მზადყოფნაა გამოძიება მოიცავს ფაქტობრივი ვებ სერვერის პორტის ხელმისაწვდომობას:
   • პორტების გამოყენება ადმინისტრაციული მიზნებისთვის, სახელწოდებით "ადმინ" ან "მენეჯმენტი" (მაგალითად, 9090), readinessProbe, დარწმუნდით, რომ საბოლოო წერტილი დაბრუნდება OK მხოლოდ იმ შემთხვევაში, თუ პირველადი HTTP პორტი (როგორც 8080) მზად არის ტრაფიკის მისაღებად*;

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

   • მზადყოფნის ზონდის ცალკეულ პორტზე მიმაგრებამ შეიძლება გამოიწვიოს ის ფაქტი, რომ მთავარ პორტზე გადატვირთვა არ აისახება ჯანმრთელობის შემოწმებაზე (ანუ სერვერზე ძაფების აუზი სავსეა, მაგრამ ჯანმრთელობის შემოწმება მაინც აჩვენებს, რომ ყველაფერი წესრიგშია ).
3. Დარწმუნდი, რომ მზადყოფნის ზონდი იძლევა მონაცემთა ბაზის ინიციალიზაციას/მიგრაციას;
   • ამის მისაღწევად უმარტივესი გზაა HTTP სერვერთან დაკავშირება მხოლოდ ინიციალიზაციის დასრულების შემდეგ (მაგალითად, მონაცემთა ბაზის მიგრაცია მფრინავი და ასე შემდეგ.); ანუ ჯანმრთელობის შემოწმების სტატუსის შეცვლის ნაცვლად უბრალოდ არ ჩართოთ ვებ სერვერი, სანამ მონაცემთა ბაზის მიგრაცია არ დასრულდება*.

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

4. გამოიყენეთ httpGet მზადყოფნის შესამოწმებლად ტიპიური ჯანმრთელობის შემოწმების საბოლოო წერტილების მეშვეობით (მაგალითად, /health).
5. გაიგეთ ნაგულისხმევი შემოწმების პარამეტრები (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • ნაგულისხმევი ვარიანტები ნიშნავს, რომ pod გახდება არ არის მზად დაახლოებით 30 წამის შემდეგ (3 წარუმატებელი საღი აზრის შემოწმება).
6. გამოიყენეთ ცალკე პორტი "ადმინისტრატორისთვის" ან "მენეჯმენტისთვის", თუ ტექნოლოგიის დასტა (მაგ. Java/Spring) ამის საშუალებას იძლევა, ჯანმრთელობისა და მეტრიკის მენეჯმენტის გამოყოფა რეგულარული ტრაფიკისგან:
   • მაგრამ არ დაივიწყოთ მე-2 პუნქტი.
7. საჭიროების შემთხვევაში, მზადყოფნის ზონდი შეიძლება გამოყენებულ იქნას ქეშის გასათბობად/ჩატვირთვისთვის და 503 სტატუსის კოდის დასაბრუნებლად, სანამ კონტეინერი არ გაცხელდება:
   • ასევე გირჩევთ წაიკითხოთ ახალი ჩეკი startupProbe, გამოჩნდა 1.16 ვერსიაში (ჩვენ ამის შესახებ რუსულად დავწერეთ აქ - დაახლ. თარგმანი.).

Caveats

1. ნუ დაეყრდნობით გარე დამოკიდებულებებს (როგორიცაა მონაცემთა საწყობები) მზადყოფნის/სიცოცხლის ტესტების გაშვებისას - ამან შეიძლება გამოიწვიოს კასკადური ჩავარდნები:
   • მაგალითად, ავიღოთ სახელმწიფო REST სერვისი 10 პოდებით, რაც დამოკიდებულია Postgres-ის ერთ მონაცემთა ბაზაზე: როდესაც შემოწმება დამოკიდებულია DB-თან სამუშაო კავშირზე, 10-ვე პოდი შეიძლება ჩავარდეს, თუ შეფერხება იქნება ქსელის/DB მხარეს - ჩვეულებრივ ეს ყველაფერი იმაზე ცუდად მთავრდება, ვიდრე შეეძლო;
   • გთხოვთ გაითვალისწინოთ, რომ Spring Data ამოწმებს მონაცემთა ბაზის კავშირს ნაგულისხმევად*;

     * ეს არის Spring Data Redis-ის ნაგულისხმევი ქცევა (ყოველ შემთხვევაში, ეს იყო ბოლოს შევამოწმე), რამაც გამოიწვია „კატასტროფული“ წარუმატებლობა: როდესაც Redis მცირე ხნით მიუწვდომელი იყო, ყველა პოდი „ჩავარდა“.

   • "გარე" ამ გაგებით ასევე შეიძლება ნიშნავდეს იმავე აპლიკაციის სხვა რგოლებს, ანუ, იდეალურ შემთხვევაში, შემოწმება არ უნდა იყოს დამოკიდებული იმავე კლასტერის სხვა ჯიშების მდგომარეობაზე კასკადური ავარიის თავიდან ასაცილებლად:
     • შედეგები შეიძლება განსხვავდებოდეს განაწილებული მდგომარეობის მქონე აპლიკაციებისთვის (მაგალითად, მეხსიერებაში ქეშირება პოდებში).
2. არ გამოიყენოთ სიცოცხლისუნარიანობის ზონდი წიპწებისთვის (გამონაკლისი არის შემთხვევები, როდესაც ისინი ნამდვილად აუცილებელია და თქვენ სრულად იცით მათი გამოყენების სპეციფიკა და შედეგები):
   • სიცოცხლისუნარიანობის ზონდი დაგეხმარებათ ჩამოკიდებული კონტეინერების აღდგენაში, მაგრამ რადგან თქვენ გაქვთ სრული კონტროლი თქვენს აპლიკაციაზე, იდეალურად არ უნდა მოხდეს ისეთი რამ, როგორიცაა ჩამოკიდებული პროცესები და ჩიხები: საუკეთესო ალტერნატივა არის აპლიკაციის განზრახ ავარია და მისი დაბრუნება წინა სტაბილურ მდგომარეობაში;
   • წარუმატებელი სიცოცხლისუნარიანობა გამოიწვევს კონტეინერის გადატვირთვას, რითაც პოტენციურად გაამწვავებს ჩატვირთვასთან დაკავშირებული შეცდომების ეფექტს: კონტეინერის გადატვირთვა გამოიწვევს შეფერხებას (მინიმუმ აპლიკაციის გაშვების ხანგრძლივობისთვის, ვთქვათ 30+ წამი), რაც გამოიწვევს ახალ შეცდომებს. სხვა კონტეინერებზე დატვირთვის გაზრდა და მათი ჩავარდნის ალბათობის გაზრდა და ა.შ.
   • სიცოცხლისუნარიანობის შემოწმებები გარე დამოკიდებულებასთან ერთად არის ყველაზე უარესი კომბინაცია, რომელიც საფრთხეს უქმნის კასკადურ წარუმატებლობებს: მონაცემთა ბაზის მხრიდან მცირე შეფერხება გამოიწვევს თქვენი ყველა კონტეინერის გადატვირთვას!
3. სიცოცხლისუნარიანობის და მზაობის შემოწმების პარამეტრები განსხვავებული უნდა იყოს:
   • შეგიძლიათ გამოიყენოთ სიცოცხლისუნარიანი ზონდი იგივე ჯანმრთელობის შემოწმებით, მაგრამ უფრო მაღალი პასუხის ზღურბლით (failureThreshold), მაგალითად, მიანიჭეთ სტატუსი არ არის მზად 3 მცდელობის შემდეგ და ჩათვალეთ, რომ სიცოცხლისუნარიანობის ზონდი ჩაიშალა 10 მცდელობის შემდეგ;
4. არ გამოიყენოთ exec ჩეკები, რადგან ისინი დაკავშირებულია ცნობილ პრობლემებთან, რომლებიც იწვევს ზომბების პროცესების გაჩენას:
   • დეტალები: იხ Datadog-ის სპეციალისტების პრეზენტაცია.

რეზიუმე

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

დამატებითი მასალები თემაზე

• Kubernetes Docs: Liveness და Readiness Probes-ის კონფიგურაცია;
• Kubernetes-ის სიცოცხლისუნარიანობისა და მზადყოფნის ზონდები ხელახლა განიხილება: როგორ ავიცილოთ თავიდან სროლა სხვა ფეხზე;
• NRE Labs გათიშვის შემდგომი სიკვდილი (ის ასევე საუბრობს livenessProbe-ზე).

განახლება No1 2019-09-29

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

EJ-მა გამახსენა PDB-ის შესახებ: სიცოცხლისუნარიანობის შემოწმების ერთ-ერთი პრობლემა არის კოორდინაციის არარსებობა პოდებს შორის. კუბერნეტესს აქვს Pod Disruption Budgets (PDB) ერთდროული მარცხის რაოდენობის შეზღუდვის მიზნით, რომელიც შეიძლება განიცადოს აპლიკაციამ, თუმცა შემოწმებები არ ითვალისწინებს PDB-ს. იდეალურ შემთხვევაში, ჩვენ შეგვიძლია ვუთხრათ K8-ს: „გადატვირთეთ ერთი პოდი, თუ მისი ტესტი ვერ მოხერხდა, მაგრამ არ გადატვირთოთ ისინი ყველა, რათა თავიდან აიცილოთ სიტუაციის გაუარესება“.

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

განახლება No2 2019-09-29

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

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

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

• «Kubernetes: Pod Life";
• «კონტეინერების გამოყენების 7 საუკეთესო პრაქტიკა Google-ის მიხედვით";
• «კონტეინერზე დაფუძნებული აპლიკაციების დიზაინის 7 პრინციპი".

წყარო: www.habr.com