GPU Kubernetes-ში და 2 GB-იანი სერვერი: რატომ ჰყოფნის მცირე ბიზნესს Docker Compose

ამ კვირაში CNCF-მა და Netflix-მა Kubernetes-ზე ოთხი ტექნიკური განხილვა გამოაქვეყნეს: როგორ გავყოთ GPU მოიჯარეებს შორის, რატომ კამათობენ ავტოსკეილერი და დამგეგმავი (scheduler) კვანძის ფორმაზე, როგორ ამცირებს Netflix კონტეინერების ზომას ავტომატურად და როგორ გადადის Kyverno Linux-ის ბირთვში. ეს ყველაფერი ასობით გუნდის მქონე კომპანიების ამოცანებს წყვეტს. მცირე ბიზნესის მფლობელისთვის აქედან სხვა რამ არის სასარგებლო: გაიგოს, ამ პრობლემებიდან რომელი აქვს საერთოდ, და დანარჩენის გადაწყვეტაში ფული არ გადაიხადოს.

რა გამოვიდა

CNCF-მა 23 ოქტომბერს აჩვენა ლაბორატორია ორი ღია პროექტისგან. Kamaji თითოეული მოიჯარის Kubernetes-ის მმართველ ფენას პოდებად უშვებს ერთი საერთო კლასტერის შიგნით, HAMi კი პოდს საშუალებას აძლევს, GPU-ს ნაწილი მოითხოვოს: მეხსიერება მეგაბაიტებში და გამოთვლების წილი პროცენტებში. პრობლემას ავტორი პირველივე აბზაცში აღწერს: Kubernetes GPU-ს მთლიანად გასცემს, და პოდი, რომელსაც 80-დან 4 GB სჭირდება, მთელ ბარათს იკავებს. ავტორმა ყველაფერი ერთ მანქანაზე ააწყო ფიზიკური GPU-ს გარეშე, HAMi-ს mock-პლაგინით, 4 ბირთვსა და 8 GB მეხსიერებაზე.

CNCF-მა 19 ოქტომბერს ახსნა, რატომ შეიძლება GPU-იანი პოდი ლოდინში ეკიდოს, როცა რეგიონში სიმძლავრე არის. დამგეგმავი პოდს არსებულ კვანძზე სვამს, ავტოსკეილერი კვანძებს ამატებს, და ათი წლის განმავლობაში ამ ორ ციკლს შეთანხმება არ სჭირდებოდა. ამაჩქარებლებთან ავტოსკეილერი არასწორი ფორმის კვანძს ამატებს, და დამგეგმავი მასზე პოდს არ სვამს. Kubernetes-ის საზოგადოების პასუხს Dynamic Resource Allocation ჰქვია: რიცხვის „საჭიროა 2 GPU“ ნაცვლად პოდი სტრუქტურირებულ მოთხოვნას აღწერს.

Netflix-მა 14 ოქტომბერს ისაუბრა Stratum Resource Tuner-ზე. ვიდეოს დამუშავების პლატფორმა დღეში ასობით ათას კონტეინერს უშვებს, ყოველი ფუნქციის ლიმიტებს კი მისი მფლობელები YAML-ში წერენ: 8 CPU, 18 000 MB მეხსიერება, 50 000 MB დისკი. ამ ციფრებს ჩვეულებრივ მეზობელი ფუნქციიდან აკოპირებენ და ყოველი შემთხვევისთვის ზრდიან. ტიუნერი ფაქტობრივ მოხმარებას აგროვებს, რეკომენდაციას იძლევა, მას ექსპერიმენტით ამოწმებს, იყენებს ან უარყოფს და შემდეგ ფუნქციას აკვირდება. დაიწყეს დატვირთვებით, რომლებსაც დაყოვნება არ აშინებს: მათზე მოდის მოხმარების 70–80%.

CNCF-მა 15 ოქტომბერს აღწერა Nirmata Runtime Kyverno-სთვის. ჩვეულებრივი Kyverno მანიფესტს შესასვლელშივე ამოწმებს: სწორად არის თუ არა პოდი აღწერილი. ახალი ნაწილი ბირთვში მუშაობს eBPF-ითა და LSM-ით და სხვა კითხვას პასუხობს: აკეთებს თუ არა პოდი იმას, რასაც დაჰპირდა. ყოველი პოლიტიკა ჯერ დაკვირვების რეჟიმში მუშაობს და აჩვენებს, რას აკრძალავდა. სტატიის მაგალითი სწორედ აგენტებზეა: პოდს მხოლოდ მოდელის შიდა შლუზზე აქვს წვდომა, ავტორიზაციის მონაცემების ფაილების წაკითხვა კი აკრძალულია. პრომპტ-ინექცია აგენტის შიგნით ამ აკრძალვას გვერდს ვერ აუვლის, რადგან აკრძალვა აგენტის პროცესში არ ცხოვრობს.

ამ პრობლემებიდან რომელი აქვს მცირე ბიზნესს

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

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

როგორ მაქვს ეს მოწყობილი

შიდა სერვისი „ყავა ერთად“, რომელიც 2026 წლის სექტემბერსა და ოქტომბერში დავაპროექტე და გავაკეთე, და ჩემი საიტი kononov.dev საერთო სერვერზე მუშაობს 2 GB მეხსიერებით, Docker-ში Nginx-ის უკან. სერვერი პატარაა, ამიტომ კონტეინერებს მეხსიერების მკაცრი ლიმიტები აქვს, განახლებისას კი ძველი ეგზემპლარი ახლის გაშვებამდე ჩერდება. თუ აწყობას მეხსიერება არ ჰყოფნის, იმიჯი სერვერის გარეთ იწყობა და მზა სახით იტვირთება. სერვისი თანამშრომლებსა და ადმინისტრატორებს თვეში 100 საათზე მეტს უზოგავს, და ამისთვის ორკესტრატორი არ დამჭირდა.

აშშ-ის PDR-კომპანიაში ამოცანა უფრო დიდია: 2022 წლიდან საკუთარ Debian სერვერზე Google Cloud-ში მუშაობს MariaDB, API, საიტი და ტელეფონია საკუთარ PBX-ზე, კომპანიაში კი 30-ზე მეტი ადამიანია. Kubernetes ამ სტეკში არ არის, და 2022 წლიდან სერიოზული ჩავარდნა, რომელიც აღდგენას მოითხოვდა, არ ყოფილა. ასეთ მასშტაბზე რესურსების ხელით განაწილება უფრო მარტივია, ავტომატური ტიუნერი აქ საჭირო არ არის.

რას გავაკეთებდი

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

ყოველ კონტეინერს მეხსიერების ლიმიტს დავუყენებდი და დატვირთვის ქვეშ შევამოწმებდი. ნახევარი წლის შემდეგ გადავხედავდი: ეს Netflix-ის ტიუნერის ხელით ვერსიაა.

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

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

კონტეინერს ქსელსა და საიდუმლოებს შევუზღუდავდი Nirmata-ს სტატიის პრინციპით: მხოლოდ ის მისამართები და ფაილები, რომლებიც სამუშაოდ სჭირდება. ამისთვის eBPF საჭირო არ არის, Docker-ის ქსელი და გარემოს ცვლადები საკმარისია.

დაკავშირებული მასალები

სერვერზე, როგორც სისტემის ცენტრზე, ვწერდი სტატიაში სერვერი: მონაცემი, წვდომა და პროცესის კოორდინაცია. მიმართულება: ინფრასტრუქტურა, რომლის გამოშვება და აღდგენა შეიძლება. ქეისები: ყავის საერთო შეკვეთის სერვისი 2 GB-იან სერვერზე და PDR-კომპანიის ტექნიკური პარტნიორი 2021 წლიდან. სხვა მიმოხილვებიდან: როდის ჯობია ბექენდი საკუთარ სერვერზე იყოს, zero trust 30-კაციანი კომპანიისთვის და რამდენი დაკვირვებადობა სჭირდება სისტემას ერთ სერვერზე. ადრე ვწერდი GPU-ს საერთო პულსა და მის რიგზე. თუ სამი კონტეინერისთვის Kubernetes-ს გთავაზობენ, მომიყევით, რა მუშაობს ახლა და რამდენი ადამიანი უვლის ამას. ამოცანის განხილვა.