Geymsla gagna í Kubernetes klasa

Það eru nokkrar leiðir til að stilla gagnageymslu fyrir forrit sem keyra á Kubernetes klasa. Sum þeirra eru þegar gamaldags, önnur birtust nokkuð nýlega. Í þessari grein munum við skoða hugmyndina um þrjá valkosti til að tengja geymslukerfi, þar á meðal þann nýjasta - tengingu í gegnum gámageymsluviðmótið.

Aðferð 1: Tilgreindu PV í belgskránni

Dæmigerð upplýsingaskrá sem lýsir fræbelg í Kubernetes klasa:

Þeir hlutar upplýsingaskránnar sem lýsa hvaða bindi er tengt og hvar eru auðkenndir í lit.

Í kafla bindiFæringar tilgreindu festingarpunktana (mountPath) - í hvaða möppu inni í gámnum verður varanlegt bindi sett upp, sem og nafn bindisins.

Í kafla x listar öll bindi sem eru notuð í hólfinu. Tilgreindu nafn hvers bindis, svo og gerð (í okkar tilfelli: awsElasticBlockStore) og tengibreytur. Hvaða færibreytur eru skráðar í upplýsingaskránni fer eftir hljóðstyrksgerðinni.

Hægt er að setja sama rúmmál samtímis í marga belgílát. Þannig geta mismunandi umsóknarferli nálgast sömu gögnin.

Þessi tengingaraðferð var fundin upp strax í upphafi, þegar Kubernetes var rétt á frumstigi og í dag er aðferðin úrelt.

Það eru nokkur vandamál þegar þú notar það:

1. öll bindi verða að vera búin til handvirkt; Kubernetes getur ekki búið til neitt fyrir okkur;
2. aðgangsbreytur fyrir hvert bindi eru einstakar og þær verða að vera tilgreindar í upplýsingaskrá allra belg sem nota hljóðstyrkinn;
3. til að breyta geymslukerfinu (td færa úr AWS yfir í Google Cloud) þarftu að breyta stillingum og gerð uppsettra bindi í öllum upplýsingaskrám.

Allt þetta er mjög óþægilegt, svo í raun er þessi aðferð notuð til að tengja aðeins nokkrar sérstakar gerðir af bindi: configMap, secret, emptyDir, hostPath:

• configMap og secret eru þjónustumagn sem gerir þér kleift að búa til bindi með skrám úr Kubernetes birtingaskrám í ílátinu.

• emptyDir er tímabundið bindi, aðeins búið til fyrir líftíma belgsins. Þægilegt í notkun til að prófa eða geyma tímabundin gögn. Þegar belg er eytt er tómiDir hljóðstyrknum einnig eytt og öll gögn glatast.

• hostPath - gerir þér kleift að tengja hvaða möppu sem er á staðbundnum diski þjónsins sem forritið keyrir á inni í gámnum með forritinu, þar á meðal /etc/kubernetes. Þetta er óöruggur eiginleiki, þannig að öryggisreglur banna venjulega notkun á bindi af þessari gerð. Annars mun árásarforrit geta fest HTC Kubernetes skrána inni í ílátinu sínu og stolið öllum klasaskírteinum. Venjulega er hostPath bindi aðeins leyfilegt að nota af kerfisforritum sem keyra í kube-system nafnrýminu.

Geymslukerfi sem Kubernetes vinnur með úr kassanum eru gefnar upp í skjölunum.

Aðferð 2. Tenging við SC/PVC/PV aflinn

Önnur tengingaraðferð er hugmyndin um geymsluflokk, PersistentVolumeClaim, PersistentVolume.

Geymsluflokkur geymir tengibreytur við gagnageymslukerfið.

ViðvarandiVolumeClaim lýsir kröfum um það sem umsóknin þarfnast.
Viðvarandi bindi geymir aðgangsbreytur og hljóðstyrkstöðu.

Kjarninn í hugmyndinni: í belgskránni gefa þeir til kynna rúmmál af gerðinni PersistentVolumeClaim og gefa til kynna nafn þessarar einingar í færibreytunni claimName.

PersistentVolumeClaim upplýsingaskráin lýsir kröfum um magn gagna sem forritið krefst. Þar á meðal:

• stærð disks;
• aðgangsaðferð: ReadWriteOnce eða ReadWriteMany;
• hlekkur á Geymsluflokk - í hvaða gagnageymslukerfi við viljum búa til magnið.

Geymsluflokksskráin geymir gerð og færibreytur tengingarinnar við geymslukerfið. Kúlan þarf þá til að festa rúmmálið á hnútinn sinn.

PersistentVolume birtingarmyndir gefa til kynna geymsluflokkinn og aðgangsbreytur fyrir tiltekið magn (auðkenni bindis, slóð osfrv.).

Þegar PVC er búið til, skoðar Kubernetes hvaða stærð rúmmáls og hvaða geymsluflokks er krafist og velur ókeypis PersistentVolume.

Ef slík PV eru ekki tiltæk, getur Kubernetes sett af stað sérstakt forrit - Provisioner (nafn þess er tilgreint í Geymsluflokknum). Þetta forrit tengist geymslukerfinu, býr til rúmmál af tilskildri stærð, fær auðkenni og býr til PersistentVolume upplýsingaskrá í Kubernetes þyrpingunni, sem tengist PersistentVolumeClaim.

Allt þetta sett af útdrætti gerir þér kleift að fjarlægja upplýsingar um hvaða geymslukerfi forritið er að vinna með frá upplýsingaskrá forritsstigi til stjórnunarstigs.

Allar færibreytur fyrir tengingu við gagnageymslukerfið eru staðsettar í Geymsluflokknum, sem klasastjórnendur bera ábyrgð á. Allt sem þú þarft að gera þegar þú ferð frá AWS yfir í Google Cloud er að breyta nafni geymsluflokks í PVC í umsóknarskránni. Persistance Volume fyrir gagnageymslu verður sjálfkrafa búið til í klasanum með því að nota Provisioner forritið.

Aðferð 3: Gámageymsluviðmót

Allur kóði sem hefur samskipti við ýmis geymslukerfi er hluti af Kubernetes kjarnanum. Útgáfa villuleiðréttinga eða nýrrar virkni er tengd nýjum útgáfum; breyta þarf kóðanum fyrir allar studdar útgáfur af Kubernetes. Allt þetta er erfitt að viðhalda og bæta við nýjum virkni.

Til að leysa vandamálið bjuggu forritarar frá Cloud Foundry, Kubernetes, Mesos og Docker til Container Storage Interface (CSI) - einfalt sameinað viðmót sem lýsir samspili gámastjórnunarkerfisins og sérstaks rekla (CSI Driver) sem vinnur með tilteknum geymslukerfi. Allur kóði fyrir samskipti við geymslukerfi var færður úr Kubernetes kjarnanum í sérstakt kerfi.

Gámageymsluviðmótsskjöl.

Venjulega samanstendur CSI Driver af tveimur hlutum: Node Plugin og Controller plugin.

Node Plugin keyrir á hverjum hnút og ber ábyrgð á að setja upp bindi og framkvæma aðgerðir á þeim. Controller viðbótin hefur samskipti við geymslukerfið: býr til eða eyðir bindum, úthlutar aðgangsrétti o.s.frv.

Í bili eru gömlu reklarnir áfram í Kubernetes kjarnanum, en ekki er lengur mælt með því að nota þá og öllum er bent á að setja upp CSI Driver sérstaklega fyrir kerfið sem þeir munu vinna með.

Nýjungin kann að hræða þá sem þegar eru vanir að setja upp gagnageymslu í gegnum Storage bekkinn, en í rauninni hefur ekkert hræðilegt gerst. Fyrir forritara breytist ekkert í raun - þeir hafa aðeins unnið með nafninu Storage class og munu halda því áfram. Fyrir stjórnendur hefur uppsetning stýrikorta verið bætt við og uppbygging stillinganna hefur breyst. Ef stillingarnar voru áður færðar beint inn í Geymsluflokkinn, verður nú fyrst að stilla þær í stýritöflunni og síðan í Geymsluflokknum. Ef þú skoðar það, gerðist ekkert slæmt.

Tökum dæmi til að skoða ávinninginn sem þú getur fengið með því að skipta yfir í að tengja Ceph geymslukerfi með því að nota CSI rekilinn.

Þegar unnið er með Ceph býður CSI viðbótin upp á fleiri möguleika til að vinna með geymslukerfi en innbyggða rekla.

1. Dynamic diskur sköpun. Venjulega eru RBD diskar aðeins notaðir í RWO ham, en CSI fyrir Ceph gerir þeim kleift að nota í RWX ham. Nokkrir fræbelgir á mismunandi hnútum geta fest sama RDB diskinn á hnúta sína og unnið með þá samhliða. Til að vera sanngjarn, er ekki allt svo bjart - þennan disk er aðeins hægt að tengja sem blokkartæki, sem þýðir að þú verður að laga forritið til að vinna með það í margfeldisaðgangsham.
2. Að búa til skyndimyndir. Í Kubernetes klasa geturðu búið til upplýsingaskrá með kröfunni um að búa til skyndimynd. CSI viðbótin mun sjá það og taka mynd af disknum. Byggt á því geturðu gert annað hvort öryggisafrit eða afrit af PersistentVolume.
3. Stækkandi diskur um geymslu og PersistentVolume í Kubernetes klasanum.
4. Kvótar. CephFS reklarnir sem eru innbyggðir í Kubernetes styðja ekki kvóta, en ný CSI viðbætur með nýjustu Ceph Nautilus geta virkjað kvóta á CephFS skiptingum.
5. Mælingar. CSI viðbótin getur veitt Prometheus margvíslega mælikvarða um hvaða bindi eru tengd, hvaða samskipti eiga sér stað o.s.frv.
6. Topology meðvituð. Gerir þér kleift að tilgreina í upplýsingaskrám hvernig þyrpingin dreifist landfræðilega og forðast að tengja geymslukerfi staðsett í Amsterdam við belg sem keyra í London.

Hvernig á að tengja Ceph við Kubernetes þyrping í gegnum CSI, sjá í verklega hluta Slurm kvöldskólafyrirlestrar. Þú getur líka gerst áskrifandi að Ceph myndbandsnámskeið, sem hefst 15. október.

Höfundur greinarinnar: Sergey Bondarev, starfandi arkitekt hjá Southbridge, Certified Kubernetes Administrator, einn af hönnuðum kubespray.

Smá Post Scriptum ekki til að auglýsa, heldur til gagns...

PS Sergey Bondarev leiðir tvö öflug námskeið: uppfærð Kubernetes stöð 28.-30. september og lengra komnir Kubernetes Mega 14.–16. október.

Heimild: www.habr.com