მოთხოვნები აპლიკაციის შემუშავებისთვის Kubernetes-ში

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

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

მე მქვია პაველ სელივანოვი, ამჟამად ვარ წამყვანი DevOps ინჟინერი Mail.ru Cloud Solutions-ში, ჩვენ ვქმნით ღრუბლებს, ვქმნით მართვის კუბერნეტებს და ა.შ. ჩემი ამოცანები ახლა მოიცავს დახმარებას განვითარებაში, ამ ღრუბლების გაშლას, აპლიკაციების გაშვებას, რომლებსაც ჩვენ ვწერთ და უშუალოდ იმ ინსტრუმენტების შემუშავებას, რომლებსაც ჩვენ ვუზრუნველვყოფთ ჩვენი მომხმარებლებისთვის.

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

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

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

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

იმის გამო, რომ, ზოგადად, ეს ინფორმაცია არის „ctrl+c, ctrl+v“, სხვა საკითხებთან ერთად, ჩვენი ვიკიდან DevOps განყოფილებაში, სადაც ჩვენ გვაქვს წერილობითი მოთხოვნები დეველოპერებისთვის: „ბიჭებო, რომ თქვენი აპლიკაცია გავუშვათ კუბერნეტეს, ეს ასე უნდა იყოს."

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

რას ვაპირებთ ახლა შევხედოთ:

• ეს არის, პირველ რიგში, ჟურნალები (აპლიკაციის ჟურნალები?), რა უნდა გავაკეთოთ მათთან Kubernetes-ში, რა ვუყოთ მათ, როგორი უნდა იყოს ისინი;
• რა უნდა გააკეთოს Kubernetes-ის კონფიგურაციებთან, რა არის საუკეთესო და ყველაზე ცუდი გზები Kubernetes-ისთვის აპლიკაციის კონფიგურაციისთვის;
• მოდით ვისაუბროთ იმაზე, თუ როგორია ზოგადად ხელმისაწვდომობის შემოწმებები, როგორი უნდა იყოს ისინი;
• მოდით ვისაუბროთ იმაზე, თუ რა არის მოხდენილი გამორთვა;
• ისევ ვისაუბროთ რესურსებზე;
• კიდევ ერთხელ შევეხოთ მონაცემთა შენახვის თემას;
• და ბოლოს გეტყვით რა ტერმინია ეს იდუმალი ღრუბლოვანი აპლიკაცია. ღრუბლიანობა, როგორც ამ ტერმინის ზედსართავი სახელი.

ჟურნალები

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

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

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

გამოდის, რომ თუ ვსაუბრობთ Kubernetes-ზე, დოკერის კონტეინერიდან სადღაც ჟურნალების ჩასაწერად სწორი ადგილია მათი უბრალოდ ჩაწერა აპლიკაციიდან ეგრეთ წოდებულ Stdout/Stderr-ზე, ანუ ოპერაციული სისტემის სტანდარტულ გამომავალ ნაკადებზე. სტანდარტული შეცდომის გამომავალი. ეს არის ყველაზე სწორი, უმარტივესი და ყველაზე ლოგიკური გზა ლოგების პრინციპში დასაყენებლად Docker-ში და კონკრეტულად Kubernetis-ში. იმის გამო, რომ თუ თქვენი აპლიკაცია წერს ჟურნალებს Stdout/Stderr-ში, მაშინ Docker-ისა და Kubernetes-ის დანამატის გადასაწყვეტია, რა უნდა გააკეთოს ამ ჟურნალებთან. Docker ნაგულისხმევად ააშენებს თავის სპეციალურ ფაილებს JSON ფორმატში.

აქ ჩნდება კითხვა, რას გააკეთებ შემდეგ ამ ლოგინებთან? უმარტივესი გზა ნათელია, ჩვენ გვაქვს ამის შესაძლებლობა kubectl logs და შეხედეთ ამ "პოდების" ამ ჟურნალებს. მაგრამ, ალბათ, ეს არ არის ძალიან კარგი ვარიანტი - სხვა რამის გაკეთებაა საჭირო ჟურნალებთან.

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

ჩვენ გვჭირდება რაიმე სახის ხელსაწყო, მეგობრული გზით, რომელიც აიღებს ამ ჟურნალებს, რომლებსაც ჩვენი დოკერი ათავსებს თავის ფაილებში და გაგზავნის მათ სადმე. ზოგადად, ჩვენ ჩვეულებრივ ვაწარმოებთ რაიმე სახის აგენტს Kubernetes-ის შიგნით DaemonSet-ის სახით - ჟურნალის კოლექციონერი, რომელსაც უბრალოდ ეუბნება სად არის განთავსებული ჟურნალები, რომლებსაც Docker აგროვებს. და ეს შემგროვებელი აგენტი უბრალოდ იღებს მათ, შესაძლოა როგორღაც აანალიზებს მათ გზაზე, შესაძლოა ამდიდრებს მათ დამატებითი მეტა-ინფორმაციით და, საბოლოოდ, სადმე შესანახად აგზავნის. იქ უკვე შესაძლებელია ვარიაციები. ყველაზე გავრცელებული არის ალბათ Elasticsearch, სადაც შეგიძლიათ შეინახოთ ჟურნალები და მოხერხებულად მიიღოთ ისინი იქიდან. შემდეგ, მოთხოვნის გამოყენებით, Kibana-ს გამოყენებით, მაგალითად, შექმენით გრაფიკები მათზე დაყრდნობით, შექმენით სიგნალები მათზე და ა.შ.

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

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

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

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

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

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

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

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

ეს არის პროგრამული უზრუნველყოფა (იგივე Sentry), რომელიც შექმნილია სპეციალურად stack trace-თან მუშაობისთვის. მას შეუძლია დაუყოვნებლივ შექმნას ავტომატური ამოცანები, დაავალოს ისინი ვინმეს, გააფრთხილოს, როდესაც ხდება stacttraces, დაჯგუფდეს ეს stacttraces ერთი ტიპის მიხედვით და ა.შ. პრინციპში, დიდი აზრი არ აქვს სტატრაკებზე ლაპარაკს, როდესაც ვსაუბრობთ ლოგინებზე, რადგან ეს არის, ბოლოს და ბოლოს, სხვადასხვა რამ, სხვადასხვა დანიშნულებით.

კონფიგურაცია

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

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

და ეს ნივთი - ადრეც ვიყენებდით, უბრალოდ განსაკუთრებით პოპულარული გახდა კონტეინერების გამოჩენით - ამ ნივთს ჰქვია ENV (გარემო) ცვლადები, ანუ გარემოს ცვლადები, რომლებიც თქვენს ოპერაციულ სისტემაშია. ეს ზოგადად იდეალური გზაა თქვენი აპლიკაციის კონფიგურაციისთვის, რადგან თუ თქვენ გაქვთ აპლიკაციები JAVA, Python, Go, Perl, ღმერთმა ქნას, და მათ შეუძლიათ წაიკითხონ მონაცემთა ბაზის ჰოსტი, მონაცემთა ბაზის მომხმარებელი, მონაცემთა ბაზის პაროლის ცვლადები, მაშინ ეს იდეალურია. თქვენ გაქვთ აპლიკაციები ოთხ სხვადასხვა ენაზე, რომლებიც კონფიგურირებულია მონაცემთა ბაზის გეგმაში იმავე გზით. მეტი განსხვავებული კონფიგურაცია არ არის.

ყველაფრის კონფიგურაცია შესაძლებელია ENV ცვლადების გამოყენებით. როდესაც ვსაუბრობთ Kubernetes-ზე, არსებობს შესანიშნავი გზა ENV ცვლადების გამოცხადების პირდაპირ Deployment-ში. შესაბამისად, თუ ჩვენ ვსაუბრობთ საიდუმლო მონაცემებზე, მაშინ ჩვენ შეგვიძლია დაუყოვნებლივ გადავიტანოთ საიდუმლო მონაცემები ENV ცვლადებიდან (პაროლები მონაცემთა ბაზებში და ა. ამ ცვლადის მნიშვნელობა და მონაცემთა ბაზის პაროლის ცვლადის მნიშვნელობა წაიკითხება საიდუმლოდან. ეს არის სტანდარტული Kubernetes ქცევა. და ეს არის ყველაზე იდეალური ვარიანტი თქვენი აპლიკაციების კონფიგურაციისთვის. მხოლოდ კოდის დონეზე, ისევ ეს ეხება დეველოპერებს. თუ თქვენ ხართ DevOps, შეგიძლიათ იკითხოთ: „ბიჭებო, გთხოვთ, ასწავლეთ თქვენს აპლიკაციას გარემოს ცვლადების წაკითხვა. და ჩვენ ყველანი ბედნიერები ვიქნებით."

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

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

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

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

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

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

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

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

Ჯანმრთელობის შემოწმება

შემდეგი პუნქტი არის ეს, რასაც ჰქვია ჯანმრთელობის შემოწმება. ზოგადად, ჯანმრთელობის შემოწმება უბრალოდ ამოწმებს, რომ თქვენი აპლიკაცია მუშაობს. ამავდროულად, ჩვენ ყველაზე ხშირად ვსაუბრობთ გარკვეულ ვებ აპლიკაციებზე, რომლებისთვისაც, შესაბამისად, ჯანმრთელობის შემოწმების თვალსაზრისით (უმჯობესია არ თარგმნოთ აქ და შემდგომ) ეს იქნება რაიმე სპეციალური URL, რომელსაც ისინი ამუშავებენ როგორც სტანდარტი, როგორც წესი /health.

ამ URL-ზე წვდომისას, შესაბამისად, ჩვენი აპლიკაცია ამბობს: „დიახ, კარგი, ჩემთან ყველაფერი კარგადაა, 200“ ან „არა, ჩემთან ყველაფერი კარგად არ არის, დაახლოებით 500“. შესაბამისად, თუ ჩვენი აპლიკაცია არ არის http და არა ვებ აპლიკაცია, ჩვენ ახლა ვსაუბრობთ რაიმე სახის დემონზე, შეგვიძლია გავარკვიოთ, როგორ გავაკეთოთ ჯანმრთელობის შემოწმება. ანუ არ არის აუცილებელი, თუ აპლიკაცია არ არის http, მაშინ ყველაფერი მუშაობს ჯანმრთელობის შემოწმების გარეშე და ეს არანაირად არ შეიძლება გაკეთდეს. თქვენ შეგიძლიათ პერიოდულად განაახლოთ ფაილში არსებული გარკვეული ინფორმაცია, შეგიძლიათ შექმნათ სპეციალური ბრძანება თქვენი დემონისთვის, მაგალითად, daemon status, რომელიც იტყვის "დიახ, ყველაფერი კარგადაა, დემონი მუშაობს, ის ცოცხალია".

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

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

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

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

და აქ არის მნიშვნელოვანი პუნქტი, რომელიც მინდა აღვნიშნო: პრაქტიკული თვალსაზრისით, მზადყოფნის ტესტი ჩვეულებრივ უფრო ხშირად გამოიყენება და უფრო ხშირად საჭიროა, ვიდრე სიცოცხლისუნარიანობის ტესტი. ანუ, უბრალოდ დაუფიქრებლად გამოაცხადოთ როგორც მზადყოფნა, ასევე სიცოცხლისუნარიანობა, რადგან კუბერნეტესს შეუძლია ამის გაკეთება და მოდით გამოვიყენოთ ყველაფერი, რისი გაკეთებაც მას შეუძლია, არ არის ძალიან კარგი იდეა. აგიხსნით რატომ. იმის გამო, რომ ტესტირების მეორე წერტილი არის კარგი იდეა, რომ შეამოწმოთ ძირითადი სერვისი თქვენს ჯანმრთელობის შემოწმებებში. ეს ნიშნავს, რომ თუ თქვენ გაქვთ ვებ აპლიკაცია, რომელიც იძლევა გარკვეულ ინფორმაციას, რაც თავის მხრივ, ბუნებრივია, სადღაც უნდა აიღოს. მაგალითად, მონაცემთა ბაზაში. კარგად, ის ინახავს ინფორმაციას, რომელიც შედის ამ REST API-ში, იმავე მონაცემთა ბაზაში. შემდეგ, შესაბამისად, თუ თქვენი ჯანმრთელობის შემოწმება პასუხობს ისევე, როგორც დაკავშირებულ slashhealth-ს, აპლიკაცია ამბობს „200, კარგი, ყველაფერი კარგადაა“ და ამავდროულად თქვენი აპლიკაციის მონაცემთა ბაზა მიუწვდომელია, ხოლო ჯანმრთელობის შემოწმების აპლიკაცია ამბობს „200, კარგი, ყველაფერი კარგადაა. ” - ეს არის ჯანმრთელობის ცუდი შემოწმება. ასე არ უნდა იმუშაოს.

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

ამიტომ, ამ მხრივ, კვლავ ვუბრუნდები მზადყოფნის/სიცოცხლის ტესტებს - რატომ გჭირდებათ დიდი ალბათობით მზაობის ტესტი, მაგრამ სიცოცხლისუნარიანობის ტესტი კითხვის ნიშნის ქვეშ დგას. რადგან თუ თქვენ აღწერთ ჯანმრთელობის შემოწმებებს ზუსტად ისე, როგორც მე ვთქვი, მაშინ აღმოჩნდება, რომ ის არ არის ხელმისაწვდომი ინსტანციის ნაწილშიв или со всех instanceმონაცემთა ბაზაში, მაგალითად. როდესაც თქვენ გამოაცხადეთ მზადყოფნის ტესტი, ჩვენი ჯანმრთელობის შემოწმება დაიწყო მარცხი და, შესაბამისად, ყველა აპლიკაცია, საიდანაც მონაცემთა ბაზა მიუწვდომელია, ისინი უბრალოდ გამორთულია დაბალანსებისგან და ფაქტობრივად "ჩაკიდებული" უბრალოდ უგულებელყოფილი მდგომარეობაშია და ელოდება მათ მონაცემთა ბაზებს. მუშაობა.

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

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

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

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

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

რაც შეეხება იმას, თუ რა უნდა უპასუხო ტესტის გაკეთებისას, ჯანმრთელობის შემოწმების დროს. უბრალოდ მართლა ტკივილია. ვინც ამას იცნობს, ალბათ გაიცინებს - მაგრამ სერიოზულად, ცხოვრებაში მინახავს სერვისები, რომლებიც 200% შემთხვევაში პასუხობენ "XNUMX". ანუ ვინ არის წარმატებული. მაგრამ ამავე დროს პასუხის სხეულში ისინი წერენ "ასეთი და ასეთი შეცდომა".

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

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

თუ ყველაფერი კარგად იყო, მაშინ უპასუხეთ ორასი პასუხით. პრინციპში, ნებისმიერი ორასიანი პასუხი მოგეწონებათ. თუ ძალიან კარგად კითხულობთ ragsy-ს და იცით, რომ ზოგიერთი პასუხის სტატუსი განსხვავდება სხვებისგან, უპასუხეთ შესაბამისი პირობით: 204, 5, 10, 15, რაც არ უნდა იყოს. თუ ეს არ არის ძალიან კარგი, მაშინ უბრალოდ "ორი ნული ნული". თუ ყველაფერი ცუდად წავიდა და ჯანმრთელობის შემოწმება არ პასუხობს, მაშინ უპასუხეთ ნებისმიერი ხუთასედით. კიდევ ერთხელ, თუ გესმით, როგორ უნდა უპასუხოთ, რამდენად განსხვავდება პასუხის სხვადასხვა სტატუსი ერთმანეთისგან. თუ არ გესმით, მაშინ 502 არის თქვენი ვარიანტი, უპასუხოთ ჯანმრთელობის შემოწმებებს, თუ რამე არასწორედ მოხდება.

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

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

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

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

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

მოხდენილი გამორთვა

ზოგადად, რა არის Graceful Shutdown და რატომ არის საჭირო? ეს არის დაახლოებით, როდესაც თქვენი აპლიკაცია რაიმე მიზეზით იშლება, თქვენ უნდა გააკეთოთ app stop - ან თქვენ მიიღებთ, მაგალითად, სიგნალს ოპერაციული სისტემიდან, თქვენმა აპლიკაციამ უნდა გაიგოს ეს და გააკეთოს რაიმე ამის შესახებ. ყველაზე უარესი სცენარი, რა თქმა უნდა, არის, როდესაც თქვენი აპლიკაცია მიიღებს SIGTERM-ს და მსგავსია „SIGTERM, მოდი ვიყოთ, ვიმუშაოთ, არაფერი გავაკეთოთ“. ეს აბსოლუტურად ცუდი ვარიანტია.

თითქმის არანაკლებ ცუდი ვარიანტია, როდესაც თქვენი აპლიკაცია იღებს SIGTERM-ს და მსგავსია „მათ თქვეს segterm, ეს ნიშნავს, რომ ჩვენ ვამთავრებთ, მე არ მინახავს, ​​არ ვიცი მომხმარებლის მოთხოვნა, არ ვიცი როგორი მოთხოვნები, რომლებზეც ახლა ვმუშაობ, მათ თქვეს SIGTERM, ეს ნიშნავს, რომ ჩვენ ვასრულებთ " ესეც ცუდი ვარიანტია.

რომელი ვარიანტია კარგი? პირველი პუნქტი არის ოპერაციების დასრულების გათვალისწინება. კარგი ვარიანტია, რომ თქვენმა სერვერმა მაინც გაითვალისწინოს რას აკეთებს, თუ ის მიიღებს SIGTERM-ს.

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

კუბერნეტის პერსპექტივიდან ასე გამოიყურება. როდესაც ჩვენ ვეუბნებით პოდს, რომელიც მუშაობს Kubernetes კლასტერში, „გთხოვთ გაჩერდით, წადით“, ან ჩვენ ხელახლა ჩართავთ, ან ხდება განახლება, როდესაც Kubernetes ხელახლა ქმნის პოდებს, Kubernetes აგზავნის იგივე SIGTERM შეტყობინებას პოდში, ელოდება გარკვეული დრო და, ეს ის დროა, რომელსაც ის ელოდება, ის ასევე კონფიგურირებულია, დიპლომებში არის ასეთი სპეციალური პარამეტრი და მას Graceful ShutdownTimeout ჰქვია. როგორც გესმით, ამას ტყუილად არ ეძახიან და ტყუილად არ ვსაუბრობთ ახლა ამაზე.

აქ შეგვიძლია კონკრეტულად ვთქვათ, რამდენი ხანი უნდა ველოდოთ SIGTERM-ს აპლიკაციაში გაგზავნას და როცა გავიგებთ, რომ აპლიკაცია რაღაცაზე გაგიჟდა ან „გაჭედილია“ და არ აპირებს დასრულებას - და ჩვენ გვჭირდება გაუგზავნე მას SIGKILL, ანუ ძნელად დაასრულე მისი სამუშაო. ანუ, შესაბამისად, ჩვენ გვაქვს რაიმე სახის დემონი გაშვებული, ის ამუშავებს ოპერაციებს. ჩვენ გვესმის, რომ საშუალოდ ჩვენი ოპერაციები, რომლებზეც დემონი მუშაობს, ერთდროულად არ გრძელდება 30 წამზე მეტს. შესაბამისად, როდესაც SIGTERM მოვა, ჩვენ გვესმის, რომ ჩვენს დემონს შეუძლია SIGTERM-ის შემდეგ მაქსიმუმ 30 წამის დასრულება. ჩვენ ვწერთ, მაგალითად, 45 წამში ყოველი შემთხვევისთვის და ვამბობთ, რომ SIGTERM. ამის შემდეგ ველოდებით 45 წამს. თეორიულად, ამ ხნის განმავლობაში დემონს უნდა დაესრულებინა თავისი საქმე და დასრულებულიყო. მაგრამ თუ მოულოდნელად ეს ვერ მოხერხდა, ეს ნიშნავს, რომ ის დიდი ალბათობით გაჩერდა - ის აღარ ამუშავებს ჩვენს მოთხოვნებს ჩვეულებრივად. და 45 წამში შეგიძლიათ უსაფრთხოდ, ფაქტობრივად, დაარტყით მას.

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

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

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

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

რესურსები

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

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

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

ლიმიტი აყენებს ზედა ზღვარს, თუ როგორ შეიძლება რესურსის გამოყენება თქვენს აპლიკაციაში. ანუ, შესაბამისად, თუ ლიმიტებში იტყვით 1 GB ოპერატიული მეხსიერება, მაშინ თქვენი აპლიკაცია ვერ გამოიყენებს 1 GB RAM-ზე მეტს. და თუ მას მოულოდნელად მოუნდება და ეცდება ამის გაკეთებას, მაშინ პროცესი, რომელსაც ეწოდება oom killer, მეხსიერების გარეშე, ანუ მოვა და მოკლავს თქვენს აპლიკაციას - ანუ ის უბრალოდ გადაიტვირთება. აპლიკაციები არ გადაიტვირთება CPU-ზე დაყრდნობით. CPU-ს თვალსაზრისით, თუ აპლიკაცია ცდილობს გამოიყენოს ბევრი, მეტი, ვიდრე მითითებულია ლიმიტებში, CPU უბრალოდ მკაცრად შეირჩევა. ეს არ იწვევს გადატვირთვას. ეს არის ზღვარი - ეს არის ზედა ზღვარი.

და არის თხოვნა. მოთხოვნაა, როგორ გაიგოს Kubernetes-მა, თუ როგორ არის აპლიკაციებით სავსე კვანძები თქვენს Kubernetes კლასტერში. ანუ მოთხოვნა არის თქვენი განაცხადის ერთგვარი ვალდებულება. ის ამბობს, რისი გამოყენებაც მსურს: ”მინდა, რომ ამდენი CPU და ამდენი მეხსიერება დამიჯავშნოთ.” ასეთი მარტივი ანალოგია. რა მოხდება, თუ ჩვენ გვაქვს კვანძი, რომელსაც აქვს, არ ვიცი, სულ 8 CPU. და იქ მოდის პოდი, რომლის თხოვნაში ნათქვამია 1 CPU, რაც ნიშნავს, რომ კვანძს დარჩა 7 CPU. ანუ, როგორც კი ამ კვანძში მოვა 8 პოდი, რომელთაგან თითოეულს აქვს 1 CPU მოთხოვნებში, კვანძს, თითქოს Kubernetes-ის თვალსაზრისით, ამოიწურა CPU და მეტი პოდი მოთხოვნით ვერ იქნება. გაშვებული ამ კვანძზე. თუ ყველა კვანძს ამოიწურება CPU, მაშინ Kubernetes დაიწყებს იმის თქმას, რომ კლასტერში არ არის შესაფერისი კვანძები თქვენი განყოფილებების გასაშვებად, რადგან CPU ამოიწურა.

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

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

Მონაცემთა საცავი

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ღრუბლიანობა

და ბოლო ქვეთემა არის რა არის Cloudnative. რატომ არის საჭირო? ღრუბლიანობა და ასე შემდეგ.

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

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

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

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

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

მაგრამ ჩემი გამოცდილებიდან, კიდევ ერთხელ, ეს არის ყველაზე მაგარი რამ, რაც კი ოდესმე მინახავს. როდესაც Cloudnative კლასტერი მასშტაბირებულია დღის დროის მიხედვით. ეს იყო backend სერვისი, რომელსაც იყენებდნენ ხალხი უკანა ოფისში. ანუ, ისინი მოდიან სამსახურში დილის 9 საათზე, იწყებენ სისტემაში შესვლას და შესაბამისად, Cloudnative კლასტერი, სადაც ეს ყველაფერი მუშაობს, იწყებს შეშუპებას, უშვებს ახალ პოდებს, რათა ყველა, ვინც სამსახურში მოდის, შეძლოს აპლიკაციასთან მუშაობა. როდესაც ისინი ტოვებენ სამუშაოს საღამოს 8 საათზე ან საღამოს 6 საათზე, Kubernetes კლასტერები ამჩნევენ, რომ არავინ აღარ იყენებს აპლიკაციას და იწყებს შემცირებას. 30 პროცენტამდე დანაზოგი გარანტირებულია. იმ დროს ამაზონში მუშაობდა, იმ დროს რუსეთში არავინ იყო ასე კარგად.

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

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

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

ყველა ეს საკითხი უფრო დეტალურად არის განხილული აქ Kubernetes ვიდეო კურსები: Junior, Basic, Mega. ბმულზე გადასვლით შეგიძლიათ გაეცნოთ პროგრამას და პირობებს. მოსახერხებელი ის არის, რომ კუბერნეტის ათვისება შეგიძლიათ სახლიდან ან სამუშაოდ დღეში 1-2 საათის განმავლობაში სწავლით.

წყარო: www.habr.com