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

დეველოპერებს Kubernetes-ის გარემო მაშინ სჭირდებათ, როცა საჭიროა, და არა კვირიანი ლოდინის შემდეგ. პლატფორმის გუნდები კი პასუხს აგებენ იმაზე, რა ჯდება ეს გარემოები, ვის აქვს მათზე წვდომა და შეესაბამება თუ არა კომპანიის პოლიტიკას. The New Stack-მა ამ დაძაბულობაზე HPE-ის პროდუქტ-მენეჯერებს, Marius Bogoevici-ს და Karthik Subramanian-ს ესაუბრა.

ღია კოდის Kubernetes ორკესტრაციასა და დეკლარაციულ API-ებს გვაძლევს, მაგრამ სრულ საოპერაციო მოდელს არა. Subramanian-ის თქმით, თუ გუნდები თვითმომსახურების ფენას თავად აშენებენ, ორი განმეორებადი პრობლემა გარდაუვალია. პირველი ინსტრუმენტების გაბნევაა: Kubernetes-ის საწარმოო გარემოსთვის მზადყოფნა ქსელის (CNI), საცავის (CSI), ingress-ის, იდენტიფიკაციისა და პოლიტიკის CNCF-ის პროექტების მოვლას მოითხოვს.

რა ფუჭდება, როცა თვითმომსახურებას თავად აშენებენ

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

მომზადებული გზა და პასუხისმგებლობის გაყოფა

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

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

სიჩქარეს საკუთარი რისკებიც აქვს

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

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