მონაცემთა შენახვა Kubernetes კლასტერში

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

მეთოდი 1: მიუთითეთ PV pod manifest-ში

ტიპიური მანიფესტი, რომელიც აღწერს პოდს კუბერნეტის კლასტერში:

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

ნაწილში ხმის სამაგრები მიუთითეთ სამონტაჟო წერტილები (mountPath) - რომელ დირექტორიაში დამონტაჟდება კონტეინერის შიგნით მუდმივი ტომი, ასევე მოცულობის სახელი.

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

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

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

მისი გამოყენებისას რამდენიმე პრობლემაა:

1. ყველა ტომი ხელით უნდა შეიქმნას; Kubernetes ვერაფერს შექმნის ჩვენთვის;
2. თითოეული ტომისთვის წვდომის პარამეტრები უნიკალურია და ისინი უნდა იყოს მითითებული ყველა ტომის მანიფესტებში, რომლებიც იყენებენ მოცულობას;
3. შენახვის სისტემის შესაცვლელად (მაგალითად, AWS-დან Google Cloud-ში გადატანა), თქვენ უნდა შეცვალოთ პარამეტრები და დამონტაჟებული ტომების ტიპი ყველა მანიფესტში.

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

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

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

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

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

მეთოდი 2. კავშირი SC/PVC/PV კერებთან

კავშირის ალტერნატიული მეთოდია Storage კლასის კონცეფცია, PersistentVolumeClaim, PersistentVolume.

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

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

იდეის არსი: pod manifest-ში ისინი მიუთითებენ PersistentVolumeClaim ტიპის ტომს და მიუთითებენ ამ ერთეულის სახელს pretendName პარამეტრში.

PersistentVolumeClaim მანიფესტი აღწერს მოთხოვნებს განაცხადის მოთხოვნილ მონაცემთა მოცულობის შესახებ. მათ შორის:

• დისკის ზომა;
• წვდომის მეთოდი: ReadWriteOnce ან ReadWriteMany;
• ბმული Storage კლასზე - მონაცემთა შენახვის რომელ სისტემაში გვინდა შევქმნათ მოცულობა.

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

PersistentVolume მანიფესტები მიუთითებს Storage კლასს და წვდომის პარამეტრებს კონკრეტული ტომისთვის (მოცულობის ID, გზა და ა.შ.).

PVC-ის შექმნისას Kubernetes უყურებს რა ზომის მოცულობა და რა Storage კლასია საჭირო და ირჩევს უფასო PersistentVolume-ს.

თუ ასეთი PV არ არის ხელმისაწვდომი, Kubernetes-ს შეუძლია გაუშვას სპეციალური პროგრამა - Provisioner (მისი სახელი მითითებულია Storage კლასში). ეს პროგრამა უკავშირდება შენახვის სისტემას, ქმნის საჭირო ზომის მოცულობას, იღებს იდენტიფიკატორს და ქმნის PersistentVolume მანიფესტს Kubernetes კლასტერში, რომელიც ასოცირდება PersistentVolumeClaim-თან.

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

მონაცემთა შენახვის სისტემასთან დაკავშირების ყველა პარამეტრი განლაგებულია Storage კლასში, რაზეც პასუხისმგებელია კლასტერის ადმინისტრატორები. ყველაფერი რაც თქვენ უნდა გააკეთოთ AWS-დან Google Cloud-ზე გადასვლისას არის Storage კლასის სახელის შეცვლა აპლიკაციის მანიფესტებში PVC-ით. მდგრადობის მოცულობა მონაცემთა შენახვისთვის შეიქმნება კლასტერში ავტომატურად Provisioner პროგრამის გამოყენებით.

მეთოდი 3. კონტეინერის შენახვის ინტერფეისი

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

პრობლემის გადასაჭრელად Cloud Foundry-ის, Kubernetes-ის, Mesos-ისა და Docker-ის დეველოპერებმა შექმნეს კონტეინერის შენახვის ინტერფეისი (CSI) - მარტივი ერთიანი ინტერფეისი, რომელიც აღწერს კონტეინერის მართვის სისტემის ურთიერთქმედებას და სპეციალურ დრაივერს (CSI Driver), რომელიც მუშაობს კონკრეტულთან. შენახვის სისტემა. შენახვის სისტემებთან ურთიერთქმედების ყველა კოდი გადავიდა Kubernetes ბირთვიდან ცალკე სისტემაში.

კონტეინერის შენახვის ინტერფეისის დოკუმენტაცია.

როგორც წესი, CSI Driver შედგება ორი კომპონენტისგან: Node Plugin და Controller plugin.

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

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

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

ავიღოთ მაგალითი, რათა შევხედოთ სარგებელს, რომელიც შეგიძლიათ მიიღოთ Ceph-ის შენახვის სისტემებზე CSI დრაივერის გამოყენებით გადართვით.

Ceph-თან მუშაობისას, CSI მოდული უფრო მეტ ვარიანტს იძლევა შენახვის სისტემებთან მუშაობისთვის, ვიდრე ჩაშენებული დრაივერები.

1. დინამიური დისკის შექმნა. როგორც წესი, RBD დისკები გამოიყენება მხოლოდ RWO რეჟიმში, მაგრამ CSI for Ceph საშუალებას აძლევს მათ გამოიყენონ RWX რეჟიმში. რამდენიმე პოდს სხვადასხვა კვანძზე შეუძლია ერთი და იგივე RDB დისკის დამონტაჟება მათ კვანძებზე და მათთან პარალელურად მუშაობა. სამართლიანად რომ ვთქვათ, ყველაფერი ასე არ არის ნათელი - ამ დისკის დაკავშირება შესაძლებელია მხოლოდ როგორც ბლოკის მოწყობილობა, რაც ნიშნავს, რომ თქვენ მოგიწევთ აპლიკაციის ადაპტირება მასთან მუშაობისთვის მრავალჯერადი წვდომის რეჟიმში.
2. სნეპშოტების შექმნა. Kubernetes კლასტერში შეგიძლიათ შექმნათ მანიფესტი სნეპშოტის შექმნის მოთხოვნით. CSI მოდული დაინახავს მას და გადაიღებს სურათს დისკიდან. მასზე დაყრდნობით, შეგიძლიათ გააკეთოთ სარეზერვო ან ასლი PersistentVolume.
3. დისკის ზომის გაზრდა შენახვისა და PersistentVolume-ზე Kubernetes კლასტერში.
4. კვოტები. Kubernetes-ში ჩაშენებული CephFS დრაივერები არ უჭერენ მხარს კვოტებს, მაგრამ ახალ CSI დანამატებს უახლესი Ceph Nautilus-ით შეუძლიათ ჩართონ კვოტები CephFS დანაყოფებზე.
5. მეტრიკა. CSI დანამატს შეუძლია პრომეთეს მიაწოდოს სხვადასხვა მეტრიკა იმის შესახებ, თუ რომელი ტომები არის დაკავშირებული, რა კომუნიკაციები ხდება და ა.შ.
6. ტოპოლოგია იცის. საშუალებას გაძლევთ მანიფესტებში მიუთითოთ, თუ როგორ არის კლასტერი გეოგრაფიულად განაწილებული და თავიდან აიცილოთ ამსტერდამში მდებარე საცავის სისტემის დაკავშირება ლონდონში გაშვებულ პოდებთან.

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

სტატიის ავტორი: სერგეი ბონდარევი, პრაქტიკოსი არქიტექტორი Southbridge-ში, სერტიფიცირებული Kubernetes ადმინისტრატორი, kubespray-ის ერთ-ერთი შემქმნელი.

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

PS სერგეი ბონდარევი უძღვება ორ ინტენსიურ კურსს: განახლებულია კუბერნეტის ბაზა 28-30 სექტემბერი და წინსვლა Kubernetes Mega 14–16 ოქტომბერი.

წყარო: www.habr.com