Datu glabāŔana Kubernetes klasterī

Ir vairāki veidi, kā konfigurēt datu krātuvi lietojumprogrammām, kas darbojas Kubernetes klasterÄ«. Daži no tiem jau ir novecojuÅ”i, citi parādÄ«jās pavisam nesen. Å ajā rakstā mēs aplÅ«kosim trÄ«s uzglabāŔanas sistēmu savienoÅ”anas iespēju koncepciju, tostarp visjaunāko ā€” savienojumu, izmantojot konteineru krātuves interfeisu.

Datu glabāŔana Kubernetes klasterī

1. metode: norādiet PV pod manifestā

Tipisks manifests, kas apraksta pāksti Kubernetes klasterī:

Datu glabāŔana Kubernetes klasterī

Manifesta daļas, kas apraksta, kurÅ” sējums ir savienots un kur ir izceltas ar krāsu.

Iedaļā tilpumsMounts norādiet piestiprināŔanas punktus (mountPath) - kurā konteinera iekÅ”ienē direktorijā tiks uzstādÄ«ts pastāvÄ«gais sējums, kā arÄ« sējuma nosaukumu.

Iedaļā x uzskaitīti visi sējumi, kas tiek izmantoti podā. Norādiet katra sējuma nosaukumu, kā arī veidu (mūsu gadījumā: awsElasticBlockStore) un savienojuma parametrus. Kuri parametri ir norādīti manifestā, ir atkarīgi no sējuma veida.

Vienu un to paŔu tilpumu var uzstādīt vienlaicīgi vairākos pod konteineros. Tādā veidā dažādi lietojumprogrammu procesi var piekļūt vieniem un tiem paŔiem datiem.

Šī savienojuma metode tika izgudrota paŔā sākumā, kad Kubernetes bija tikai sākuma stadijā, un Ŕodien Ŕī metode ir novecojusi.

Lietojot to, rodas vairākas problēmas:

  1. visi sējumi jāveido manuāli; Kubernetes mums neko nevar izveidot;
  2. piekļuves parametri katram sējumam ir unikāli, un tie ir jānorāda visu sējumu izmantojoÅ”o podiņu manifestos;
  3. lai mainītu krātuves sistēmu (piemēram, pārietu no AWS uz Google Cloud), visos manifestos ir jāmaina uzstādīto sējumu iestatījumi un veids.

Tas viss ir ļoti neērti, tāpēc patiesÄ«bā Ŕī metode tiek izmantota, lai savienotu tikai dažus Ä«paÅ”us sējumu veidus: configMap, secret, emptyDir, hostPath:

  • configMap un secret ir pakalpojumu sējumi, kas ļauj izveidot sējumu ar failiem no Kubernetes manifestiem konteinerā.

  • emptyDir ir pagaidu sējums, kas izveidots tikai podziņas darbÄ«bas laikā. Ērti lietojams pagaidu datu testÄ“Å”anai vai glabāŔanai. DzÄ“Å”ot podziņu, tiek izdzēsts arÄ« tukÅ”ais direktorijas sējums un tiek zaudēti visi dati.

  • hostPath ā€” ļauj uzstādÄ«t jebkuru direktoriju tā servera lokālajā diskā, kurā darbojas lietojumprogramma, konteinerā ar lietojumprogrammu, tostarp /etc/kubernetes. Tas ir nedroÅ”s lÄ«dzeklis, tāpēc droŔības politikas parasti aizliedz izmantot Ŕāda veida sējumus. Pretējā gadÄ«jumā uzbrucēja lietojumprogramma varēs ievietot HTC Kubernetes direktoriju savā konteinerā un nozagt visus klastera sertifikātus. Parasti hostPath sējumus ir atļauts izmantot tikai sistēmas lietojumprogrammām, kas darbojas kube-system nosaukumvietā.

UzglabāŔanas sistēmas, ar kurām Kubernetes strādā jau no kastes ir norādÄ«ti dokumentācijā.

2. metode. Savienojums ar SC/PVC/PV pavardiem

Alternatīva savienojuma metode ir krātuves klases, PersistentVolumeClaim, PersistentVolume jēdziens.

UzglabāŔanas klase saglabā savienojuma parametrus datu uzglabāŔanas sistēmai.

Pastāvīgā apjoma prasība apraksta prasības attiecībā uz to, kas lietojumprogrammai nepiecieŔams.
Pastāvīgs apjoms saglabā piekļuves parametrus un skaļuma statusu.

Idejas bÅ«tÄ«ba: pod manifestā tie norāda PersistentVolumeClaim tipa sējumu un norāda Ŕīs entÄ«tijas nosaukumu parametrā requestName.

Datu glabāŔana Kubernetes klasterī

Manifestā PersistentVolumeClaim ir aprakstītas prasības attiecībā uz lietojumprogrammai nepiecieŔamo datu apjomu. Tostarp:

  • diska izmērs;
  • piekļuves metode: ReadWriteOnce vai ReadWriteMany;
  • saite uz Storage class - kurā datu glabāŔanas sistēmā vēlamies izveidot sējumu.

Krātuves klases manifests saglabā savienojuma ar krātuves sistēmu veidu un parametrus. Kubeletam tie ir nepiecieÅ”ami, lai uzstādÄ«tu skaļumu savā mezglā.

PersistentVolume manifesti norāda krātuves klasi un piekļuves parametrus konkrētam sējumam (sējuma ID, ceļŔ utt.).

Veidojot PVC, Kubernetes aplÅ«ko, kāda izmēra apjoms un kāda uzglabāŔanas klase ir nepiecieÅ”ama, un izvēlas bezmaksas PersistentVolume.

Ja Ŕādi PV nav pieejami, Kubernetes var palaist Ä«paÅ”u programmu - Provisioner (tās nosaukums ir norādÄ«ts krātuves klasē). Å Ä« programma izveido savienojumu ar krātuves sistēmu, izveido vajadzÄ«gā izmēra sējumu, saņem identifikatoru un izveido PersistentVolume manifestu Kubernetes klasterÄ«, kas ir saistÄ«ts ar PersistentVolumeClaim.

Visa Ŕī abstrakciju kopa ļauj noņemt informāciju par to, ar kuru krātuves sistēmu lietojumprogramma strādā, no lietojumprogrammas manifesta lÄ«meņa uz administrÄ“Å”anas lÄ«meni.

Visi parametri pieslēgÅ”anai datu glabāŔanas sistēmai atrodas Storage klasē, par ko ir atbildÄ«gi klasteru administratori. Viss, kas jums jādara, pārejot no AWS uz Google Cloud, ir jāmaina krātuves klases nosaukums uz PVC lietojumprogrammas manifestos. NoturÄ«bas apjoms datu glabāŔanai tiks izveidots klasterÄ« automātiski, izmantojot programmu Provisioner.

3. metode. Konteinera glabāŔanas interfeiss

Viss kods, kas mijiedarbojas ar dažādām uzglabāŔanas sistēmām, ir daļa no Kubernetes kodola. Kļūdu labojumu vai jaunu funkcionalitātes izlaiÅ”ana ir saistÄ«ta ar jauniem laidieniem; kods ir jāmaina visām atbalstÄ«tajām Kubernetes versijām. To visu ir grÅ«ti uzturēt un pievienot jaunas funkcijas.

Lai atrisinātu problēmu, izstrādātāji no Cloud Foundry, Kubernetes, Mesos un Docker izveidoja Container Storage Interface (CSI) - vienkārÅ”u vienotu saskarni, kas apraksta konteineru pārvaldÄ«bas sistēmas un Ä«paÅ”a draivera (CSI Driver) mijiedarbÄ«bu, kas darbojas ar noteiktu uzglabāŔanas sistēma. Viss kods mijiedarbÄ«bai ar uzglabāŔanas sistēmām tika pārvietots no Kubernetes kodola uz atseviŔķu sistēmu.

Konteinera glabāŔanas saskarnes dokumentācija.

Parasti CSI draiveris sastāv no diviem komponentiem: Node Plugin un Controller spraudnis.

Node Plugin darbojas katrā mezglā un ir atbildÄ«gs par apjomu montāžu un darbÄ«bu veikÅ”anu ar tiem. Controller spraudnis mijiedarbojas ar krātuves sistēmu: izveido vai dzÄ“Å” sējumus, pieŔķir piekļuves tiesÄ«bas utt.

Pagaidām vecie draiveri paliek Kubernetes kodolā, taču tos vairs nav ieteicams lietot un ikvienam ir ieteicams instalēt CSI draiveri tieÅ”i sistēmai, ar kuru viņi strādās.

Inovācija var biedēt tos, kuri jau ir pieraduÅ”i izveidot datu glabātuvi caur Storage klasi, taču patiesÄ«bā nekas briesmÄ«gs nav noticis. Programmētājiem nekas Ä«sti nemainās ā€“ viņi ir strādājuÅ”i tikai ar nosaukumu Storage class, un turpinās to darÄ«t. Administratoriem ir pievienota stÅ«res diagrammas instalācija un mainÄ«ta iestatÄ«jumu struktÅ«ra. Ja iepriekÅ” iestatÄ«jumi tika ievadÄ«ti tieÅ”i krātuves klasē, tagad tie vispirms jāiestata stÅ«res diagrammā un pēc tam krātuves klasē. Ja paskatās, nekas slikts nav noticis.

Ņemsim piemēru, lai apskatÄ«tu priekÅ”rocÄ«bas, ko varat iegÅ«t, pārejot uz Ceph uzglabāŔanas sistēmu pievienoÅ”anu, izmantojot CSI draiveri.

Strādājot ar Ceph, CSI spraudnis nodroÅ”ina vairāk iespēju darbam ar uzglabāŔanas sistēmām nekā iebÅ«vētie draiveri.

  1. Dinamiskā diska izveide. Parasti RBD diski tiek izmantoti tikai RWO režīmā, bet CSI for Ceph ļauj tos izmantot RWX režīmā. Vairāki podi dažādos mezglos var uzstādÄ«t vienu un to paÅ”u RDB disku savos mezglos un strādāt ar tiem paralēli. TaisnÄ«bas labad jāsaka, ka ne viss ir tik spilgti ā€“ Å”o disku var pieslēgt tikai kā blokierÄ«ci, kas nozÄ«mē, ka bÅ«s jāpielāgo aplikācija darbam ar to vairākkārtējas piekļuves režīmā.
  2. Momentuzņēmumu izveide. Kubernetes klasterī varat izveidot manifestu ar prasību izveidot momentuzņēmumu. CSI spraudnis to redzēs un veiks momentuzņēmumu no diska. Pamatojoties uz to, varat izveidot PersistentVolume dublējumu vai kopiju.
  3. Diska izmēra palielināŔana par krātuvi un PersistentVolume Kubernetes klasterÄ«.
  4. Kvotas. Kubernetes iebūvētie CephFS draiveri neatbalsta kvotas, taču jauni CSI spraudņi ar jaunāko Ceph Nautilus var iespējot kvotas CephFS nodalījumos.
  5. Metrika. CSI spraudnis var nodroÅ”ināt Prometheus dažādus rādÄ«tājus par to, kuri sējumi ir pievienoti, kādi sakari notiek utt.
  6. Apzinās topoloÄ£iju. Ä»auj manifestos norādÄ«t, kā klasteris ir Ä£eogrāfiski sadalÄ«ts, un izvairÄ«ties no Amsterdamā esoŔās krātuves sistēmas savienoÅ”anas ar aplikācijām, kas darbojas Londonā.

Kā savienot Ceph ar Kubernetes klasteru, izmantojot CSI, skatiet Slurm vakarskolas lekcijas praktiskajā daļā. Varat arī abonēt Ceph video kurss, kas sāksies 15. oktobrī.

Raksta autors: Sergejs Bondarevs, praktizējoÅ”ais arhitekts Southbridge, sertificēts Kubernetes administrators, viens no kubespray izstrādātājiem.

Nedaudz Post Scriptum nevis reklāmai, bet labumam...

PS Sergejs Bondarevs vada divus intensÄ«vus kursus: atjaunināts Kubernetes bāze 28.-30.septembris un padziļināti Kubernetes Mega 14.ā€“16.oktobris.

Datu glabāŔana Kubernetes klasterī

Avots: www.habr.com

Pievieno komentāru