Kubernetes კლასტერების დიზაინი: რამდენი უნდა იყოს?

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

TL; DR: სამუშაო დატვირთვების ერთი და იგივე ნაკრები შეიძლება განხორციელდეს რამდენიმე დიდ კლასტერზე (თითოეულ კლასტერს ექნება დიდი რაოდენობის დატვირთვა) ან ბევრ მცირეზე (თითოეულ კლასტერში მცირე რაოდენობის დატვირთვით).

ქვემოთ მოცემულია ცხრილი, რომელიც აფასებს თითოეული მიდგომის დადებით და უარყოფით მხარეებს:

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

• რამდენი კლასტერი უნდა გამოვიყენო?
• რამდენად დიდი უნდა გავხადო ისინი?
• რას უნდა შეიცავდეს თითოეული კლასტერი?

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

კითხვის განცხადება

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

გარდა ამისა, ამ აპლიკაციების მრავალი მაგალითი, სავარაუდოდ, მუშაობს სხვადასხვა გარემოში - მაგალითად, ეს შეიძლება იყოს Dev, ტესტი и პროდიდი.

შედეგი არის აპლიკაციებისა და გარემოს მთელი მატრიცა:

აპლიკაციები და გარემო

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

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

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

შედეგად, Kubernetes მომხმარებლებს აქვთ რამდენიმე კითხვა:

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

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

აქ არის რამდენიმე შესაძლო გზა:

• ერთი დიდი საერთო კლასტერი;
• ბევრი მცირე მაღალი სპეციალიზებული კლასტერი;
• თითო კლასტერი თითო აპლიკაციაზე;
• თითო კლასტერი თითო გარემოში.

როგორც ქვემოთ მოცემულია, პირველი ორი მიდგომა არის ვარიანტების მასშტაბის საპირისპირო ბოლოებში:

რამდენიმე დიდი მტევანიდან (მარცხნივ) ბევრ პატარამდე (მარჯვნივ)

ზოგადად, ერთი კლასტერი განიხილება "უფრო დიდი", ვიდრე მეორე, თუ მას აქვს კვანძებისა და კვანძების უფრო დიდი ჯამი. მაგალითად, კლასტერი 10 კვანძით და 100 კვანძით უფრო დიდია ვიდრე კლასტერი 1 კვანძით და 10 კვანძით.

აბა, დავიწყოთ!

1. ერთი დიდი საერთო მტევანი

პირველი ვარიანტი არის ყველა დატვირთვის ერთ კლასტერში მოთავსება:

ერთი დიდი მტევანი

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

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

მოდით შევხედოთ ამ მიდგომის დადებით და უარყოფით მხარეებს.

+ რესურსების ეფექტური გამოყენება

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

მაგალითად, ეს მართალია სამაგისტრო კვანძებისთვის. როგორც წესი, კუბერნეტის თითოეულ კლასტერს აქვს 3 ძირითადი კვანძი, ასე რომ, ერთი კლასტერისთვის მათი რიცხვი ასე დარჩება (შედარებისთვის, 10 კლასტერს დასჭირდება 30 ძირითადი კვანძი).

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

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

+ იაფად

ზემოაღნიშნულის შედეგად, ნაკლები კლასტერი ჩვეულებრივ უფრო იაფია, რადგან არ არსებობს ზედნადები ხარჯები.

ეს განსაკუთრებით ეხება სამაგისტრო კვანძებს, რომლებიც შეიძლება დაჯდეს მნიშვნელოვანი თანხა, მიუხედავად იმისა, თუ როგორ არის მათი ჰოსტინგი (შენობებში თუ ღრუბელში).

ზოგიერთი მართავდა Kubernetes სერვისებს, როგორიცაა Google Kubernetes Engine (GKE) ან Azure Kubernetes Service (AKS), უზრუნველყოს საკონტროლო ფენა უფასოდ. ამ შემთხვევაში ხარჯების საკითხი ნაკლებად მწვავეა.

ასევე არსებობს მართული სერვისები, რომლებიც იღებენ ფიქსირებულ საფასურს თითოეული Kubernetes კლასტერის მუშაობისთვის (მაგალითად, Amazon Elastic Kubernetes Service, EKS).

+ ეფექტური ადმინისტრირება

ერთი კლასტერის მართვა უფრო ადვილია, ვიდრე რამდენიმე.

ადმინისტრაცია შეიძლება შეიცავდეს შემდეგ ამოცანებს:

• Kubernetes ვერსიის განახლება;
• CI/CD მილსადენის დაყენება;
• CNI მოდულის დაყენება;
• მომხმარებლის ავთენტიფიკაციის სისტემის დაყენება;
• წვდომის კონტროლერის დაყენება;

და მრავალი სხვა…

ერთი კლასტერის შემთხვევაში ამ ყველაფრის გაკეთება მხოლოდ ერთხელ მოგიწევთ.

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

ახლა კი რამდენიმე სიტყვა უარყოფითი მხარეების შესახებ.

− წარუმატებლობის ერთი წერტილი

უარის შემთხვევაში ერთადერთი კლასტერი დაუყოვნებლივ შეწყვეტს მუშაობას ყველა დატვირთვები!

ბევრი რამ შეიძლება არასწორად წავიდეს:

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

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

- არ არის მყარი იზოლაცია

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

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

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

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

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

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

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

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

− მკაცრი მრავალქირავნობის არარსებობა

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

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

Kubernetes უზრუნველყოფს სხვადასხვა მექანიზმებს ამ ქცევის გასაკონტროლებლად, მაგ რესურსების მოთხოვნები და ლიმიტები (იხილეთ ასევე სტატია " CPU-ს შეზღუდვები და აგრესიული throttling in Kubernetes " - დაახლ. თარგმანი.), რესურსის კვოტები и Limit Ranges. თუმცა, როგორც უსაფრთხოების შემთხვევაში, მათი კონფიგურაცია საკმაოდ არატრივიალურია და მათ არ შეუძლიათ თავიდან აიცილონ აბსოლუტურად ყველა გაუთვალისწინებელი გვერდითი მოვლენა.

- მომხმარებლების დიდი რაოდენობა

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

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

− კლასტერები განუსაზღვრელი ვადით ვერ იზრდება

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

მაგრამ აქ კიდევ ერთი პრობლემა ჩნდება: კუბერნეტის კლასტერები განუსაზღვრელი ვადით ვერ იზრდება.

არსებობს თეორიული ლიმიტი მტევნის ზომაზე. კუბერნეტში დაახლოებით 5000 კვანძი, 150 ათასი ბუდე და 300 ათასი კონტეინერი.

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

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

ეს საკითხი განხილულია დაკავშირებულ სტატიაში ორიგინალურ ბლოგზე სახელწოდებით "Kubernetes კლასტერების არქიტექტურა - მუშა კვანძის ზომის არჩევა".

მაგრამ მოდით განვიხილოთ საპირისპირო მიდგომა: ბევრი პატარა კლასტერი.

2. ბევრი პატარა, სპეციალიზებული კლასტერი

ამ მიდგომით, თქვენ იყენებთ ცალკეულ კლასტერს თითოეული ელემენტისთვის, რომელსაც განათავსებთ:

ბევრი პატარა მტევანი

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

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

მოდით შევხედოთ ამ მიდგომის დადებით და უარყოფით მხარეებს.

+ შეზღუდული „აფეთქების რადიუსი“

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

+ იზოლაცია

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

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

+ მომხმარებელთა მცირე რაოდენობა

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

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

მოდით შევხედოთ მინუსებს.

− რესურსების არაეფექტური გამოყენება

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

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

- ძვირია

რესურსების არაეფექტური გამოყენება ავტომატურად იწვევს დიდ ხარჯებს.

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

− სირთულეები ადმინისტრაციაში

მრავალი Kubernetes კლასტერის მართვა ბევრად უფრო რთულია, ვიდრე მხოლოდ ერთი.

მაგალითად, თქვენ მოგიწევთ ავთენტიფიკაციისა და ავტორიზაციის კონფიგურაცია თითოეული კლასტერისთვის. Kubernetes ვერსია ასევე რამდენჯერმე უნდა განახლდეს.

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

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

3. ერთი კლასტერი თითო აპლიკაციაზე

ამ მიდგომით, თქვენ ქმნით ცალკეულ კლასტერს კონკრეტული აპლიკაციის ყველა ინსტანციისთვის:

კლასტერი თითო აპლიკაციაზე

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

მოდით შევხედოთ ამ მიდგომის დადებით და უარყოფით მხარეებს.

+ კლასტერის მორგება შესაძლებელია აპლიკაციაზე

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

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

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

− სხვადასხვა გარემო ერთ კლასტერში

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

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

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

და ბოლოს, ბოლო სცენარი ჩვენს სიაში.

4. თითო კლასტერი თითო გარემოში

ეს სცენარი მოიცავს ცალკეული კლასტერის გამოყოფას თითოეული გარემოსთვის:

თითო კლასტერი თითო გარემოში

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

აქ არის ამ მიდგომის დადებითი და უარყოფითი მხარეები.

+ პროდ გარემოს იზოლაცია

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

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

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

+ კლასტერი შეიძლება მოერგოს გარემოს

თითოეული კლასტერი შეიძლება მოერგოს მის გარემოს. მაგალითად, შეგიძლიათ:

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

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

+ წარმოების კლასტერზე წვდომის შეზღუდვა

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

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

ახლა კი რამდენიმე სიტყვა უარყოფითი მხარეების შესახებ.

− არ არის იზოლაცია აპლიკაციებს შორის

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

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

როგორც აღვნიშნეთ, ეს შეიძლება იყოს პოტენციურად საშიში.

− განაცხადის დამოკიდებულების ლოკალიზაციის შეუძლებლობა

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

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

შედეგად, ჩვენ რისკავს უფრო მაღალ ხარჯებს და რესურსების არაეფექტურ გამოყენებას.

დასკვნა

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

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

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

ასე რომ, რა მიდგომა უნდა მიიღოთ?

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

თუმცა არჩევანი არ შემოიფარგლება ზემოთ მოყვანილი მაგალითებით - შეგიძლიათ გამოიყენოთ მათი ნებისმიერი კომბინაცია!

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

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

PS

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

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

წყარო: www.habr.com