Kubernetes-ის საუკეთესო პრაქტიკა. Kubernetes-ის ორგანიზაცია სახელთა სივრცით

Kubernetes-ის საუკეთესო პრაქტიკა. პატარა კონტეინერების შექმნა

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

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

Kubernetes-ის უმეტეს დისტრიბუციაზე, კლასტერი გამოდის ყუთიდან სახელთა სივრცით სახელწოდებით "default". რეალურად არის სამი სახელთა სივრცე, რომლებთანაც Kubernetes ეხება: ნაგულისხმევი, kube-system და kube-public. ამჟამად Kube-public არც თუ ისე ხშირად გამოიყენება.

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

ამიტომ, თქვენ უნდა შექმნათ მრავალი სახელთა სივრცე და გამოიყენოთ ისინი თქვენი სერვისების მართვადი ერთეულებად სეგმენტირებისთვის. სახელთა სივრცე შეიძლება შეიქმნას ერთი ბრძანებით. თუ გსურთ შექმნათ სახელთა სივრცის ტესტი, გამოიყენეთ ბრძანება $ kubectl create namespace test ან უბრალოდ შექმენით YAML ფაილი და გამოიყენეთ იგი Kubernetes-ის ნებისმიერი სხვა რესურსის მსგავსად.

თქვენ შეგიძლიათ ნახოთ ყველა სახელთა სივრცე $ kubectl get namespace ბრძანების გამოყენებით.

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

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

მეორე გზა არის სახელთა სივრცის მითითება YAML დეკლარაციაში.

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

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

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

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

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

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

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

საბედნიეროდ, ამის მიღწევა მარტივია DNS მისამართის გაფართოებული ფორმის გამოყენებით. Kubernetes-ის სერვისები ავლენს მათ საბოლოო წერტილებს საერთო DNS შაბლონის გამოყენებით. ეს დაახლოებით ასე გამოიყურება:

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

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

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

თუ გსურთ სერვისების მონაცემთა ბაზასთან დაკავშირება prod namespace-ში, იყენებთ database.prod-ს.

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

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

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

წარმოიდგინეთ, რომ თქვენ ხართ მცირე გუნდის ნაწილი, რომელიც მუშაობს 5-10 მიკროსერვისის შემუშავებაზე და თქვენ შეგიძლიათ მარტივად შეაგროვოთ ყველა დეველოპერი ერთ ოთახში. ამ სიტუაციაში, აზრი აქვს ყველა prod სერვისის გაშვებას ნაგულისხმევ სახელთა სივრცეში. რა თქმა უნდა, მეტი მოქნილობისთვის, შეგიძლიათ გამოიყენოთ 2 სახელთა სივრცე - ცალკე prod და dev. და, სავარაუდოდ, თქვენ ამოწმებთ თქვენს განვითარებას თქვენს ადგილობრივ კომპიუტერზე Minikube-ის მსგავსი რაღაცის გამოყენებით.

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

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

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

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

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

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

Kubernetes-ის საუკეთესო პრაქტიკა. Kubernetes Liveness-ის დადასტურება მზადყოფნისა და სიცოცხლისუნარიანობის ტესტებით

რამდენიმე რეკლამა 🙂

გმადლობთ, რომ დარჩით ჩვენთან. მოგწონთ ჩვენი სტატიები? გსურთ ნახოთ უფრო საინტერესო შინაარსი? მხარი დაგვიჭირეთ შეკვეთის განთავსებით ან მეგობრებისთვის რეკომენდაციით, ღრუბელი VPS დეველოპერებისთვის 4.99 დოლარიდან, საწყისი დონის სერვერების უნიკალური ანალოგი, რომელიც ჩვენ მიერ გამოგონილია თქვენთვის: მთელი სიმართლე VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps 19$-დან ან როგორ გავაზიარო სერვერი? (ხელმისაწვდომია RAID1 და RAID10-ით, 24 ბირთვამდე და 40 გბ-მდე DDR4).

Dell R730xd 2-ჯერ იაფია Equinix Tier IV მონაცემთა ცენტრში ამსტერდამში? Მხოლოდ აქ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ტელევიზორი $199-დან ნიდერლანდებში! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-დან! Წაიკითხო რაღაცის შესახებ როგორ ავაშენოთ ინფრასტრუქტურის კორპუსი. კლასი Dell R730xd E5-2650 v4 სერვერების გამოყენებით 9000 ევროს ღირებულების პენი?

წყარო: www.habr.com