🥇Shranjevanje podatkov v Kubernetes grozdu

Shranjevanje podatkov aplikacij, ki delujejo v Kubernetes klastru, lahko nastavite na več načinov. Nekateri so že zastareli, drugi pa so se pojavili zelo nedavno. V tem članku bomo obravnavali koncept treh načinov povezovanja shranjevanja, vključno z najnovejšim — povezovanjem preko Container Storage Interface.

Način 1. Določanje PV v manifestu poda

Tipičen manifest, ki opisuje pod v Kubernetes klastru:

V dokumentu so z barvo označeni deli, kjer je opisana povezava do katerega volumna in kam.

V razdelku volumeMounts so določene točke montaže (mountPath) — v katero mapsko mesto znotraj kontejnerja bo povezan trajni volumen ter ime volumna.

V razdelku x so našteti vsi volumni, ki se uporabljajo v podu. Določeno je ime vsakega volumna, njegova vrsta (v našem primeru: awsElasticBlockStore) in parametri povezave. Kateri natančni parametri se omenjajo v manifestu, je odvisno od vrste volumna.

Isti volumen je lahko hkrati povezan v več kontejnerjih poda. Tako imajo različni procesi aplikacije dostop do istih podatkov.

Ta način povezovanja so izmislili na začetku, ko je Kubernetes šele zaživel, in je danes zastarel.

Pri njegovi uporabi nastane več težav:

vse volumne je treba ustvariti ročno, Kubernetes ne more ustvariti ničesar namesto nas;
dostopni parametri za vsak volumen so edinstveni, in jih je potrebno navesti v manifestih vseh podov, ki uporabljajo ta volumen;
če želite spremeniti sistem shranjevanja (na primer, preseliti se iz AWS v Google Cloud), je treba spremeniti nastavitve in vrsto povezanih volumov v vseh manifestih.

Vse to je zelo neprijetno, zato se v resnici tovrstna povezava uporablja samo za nekatere posebne vrste volumov: configMap, secret, emptyDir, hostPath:

configMap in secret — službena volumna, ki omogočata ustvarjanje volumna s datotekami iz manifestov Kubernetes v kontejnerju.
emptyDir — začasni volumen, ki se ustvari le za čas življenja poda. Udobno je uporabljati za testiranje ali shranjevanje začasnih podatkov. Ko se pod izbriše, se volumen emptyDir prav tako izbriše in vsi podatki izginejo.
hostPath — omogoča, da se kateri koli imenik lokalnega diska strežnika, na katerem deluje aplikacija, vključno z /etc/kubernetes, montira znotraj kontejnerja z aplikacijo. To je nevarna možnost, zato varnostne politike običajno prepovedujejo uporabo takšnih volumenov. V nasprotnem primeru lahko zlonamerna aplikacija v svoj kontejner montira imenik HTC Kubernetes in ukrade vse certifikate gruče. Na splošno je dovoljena uporaba hostPath volumnov samo sistemskim aplikacijam, ki se izvajajo v namespace kube-system.

Shranjevalni sistemi, s katerimi Kubernetes deluje iz škatle so navedeni v dokumentaciji.

Način 2. Povezovanje z pods SC/PVC/PV

Alternativni način povezovanja — koncept Storage class, PersistentVolumeClaim, PersistentVolume.

Storage class shranjuje parametre za povezavo s shranjevalnim sistemom.

PersistentVolumeClaim opisuje zahteve za prostornino, ki jo potrebuje aplikacija.
PersistentVolume shranjuje parametre dostopa in status volumna.

Osnovna zamisel je, da v manifestu poda navedete volumen tipa PersistentVolumeClaim in navedete ime te entitete v parametru claimName.

V manifestu PersistentVolumeClaim opisujete zahteve za podatkovno prostornino, ki jo potrebujete za aplikacijo. Med drugim:

velikost diska;
način dostopa: ReadWriteOnce ali ReadWriteMany;
povezava na Storage class — v katerem shranjevalnem sistemu želimo ustvariti volumen.

V manifestu Storage class so shranjeni tip in parametri povezave s shranjevalnim sistemom. Potrebni so kubeletu, da montira volumen na svoj vozlišče.

V manifestih PersistentVolume je navedena Storage class in parametri dostopa do konkretnega volumna (ID volumna, pot itd.).

Ko ustvarite PVC, Kubernetes pregleda, kakšne velikosti in iz katere Storage class bo potreboval volumen, in izbere prosti PersistentVolume.

Če takšnih PV ni na voljo, lahko Kubernetes zažene posebno aplikacijo - Provisioner (njeno ime je navedeno v Storage class). Ta program se poveže s shranjevalnim sistemom, ustvari volumen potrebne velikosti, pridobi identifikator in v gruči Kubernetes ustvari manifest PersistentVolume, ki je povezan s PersistentVolumeClaim.

Na te številne abstrakcije omogočajo odstranitev informacij o tem, s katerim shranjevalnim sistemom deluje aplikacija, z nivoja manifestov aplikacij na nivo upravljanja.

Vsi parametri za povezovanje s sistemom shranjevanja podatkov so v razredu shranjevanja, za katerega so odgovorni skrbniki grozda. Vse, kar morate storiti pri selitvi iz AWS v Google Cloud, je, da v manifestih aplikacije spremenite ime razreda shranjevanja v PVC. Trajni volumen za shranjevanje podatkov bo avtomatsko ustvarjen v grozdu s pomočjo programa Provisioner.

Način 3. Vmesnik za shranjevanje vsebnika

Vsa koda, ki sodeluje z različnimi sistemi shranjevanja podatkov, je del jedra Kubernetes. Izdaja popravkov napak ali nove funkcionalnosti je povezana z novimi različicami, kodo je treba spreminjati za vse podprte različice Kubernetes. Vse to je težko vzdrževati in dodajati novo funkcionalnost.

Da bi rešili težavo, so razvijalci iz Cloud Foundry, Kubernetes, Mesos in Docker ustvarili Vmesnik za shranjevanje vsebnika (CSI) — preprost enoten vmesnik, ki opisuje interakcijo sistema za upravljanje s kontejnerji in posebnega gonilnika (CSI Driver), ki deluje s specifičnim sistemom shranjevanja podatkov. Vso kodo za interakcijo s sistemom shranjevanja so izvzeli iz jedra Kubernetes in jo prenesli v samostojen sistem.

Dokumentacija za Vmesnik za shranjevanje vsebnika.

Kot pravilo, CSI gonilnik sestoji iz dveh komponent: Node Plugin in Controller Plugin.

Node Plugin se izvaja na vsakem vozlišču in je odgovoren za montažo volumov ter operacije na njih. Controller Plugin interagira s sistemom shranjevanja podatkov: ustvarja ali odstranjuje volume, dodeljuje pravice dostopa itd.

Dokler v jedru Kubernetes ostajajo stari gonilniki, jih ni priporočljivo uporabljati, vsi pa se spodbujajo, da namestijo CSI gonilnik posebej za tisti sistem, s katerim morajo delati.

Novost lahko prestraši tiste, ki so se že navadili nastavljati shranjevanje podatkov preko razreda shranjevanja, a v resnici ni nič hujšega. Za programerje se zagotovo nič ne spremeni — delali so samo z imenom razreda shranjevanja in nadaljujejo. Skrbniki so morali dodati namestitev helm chart in se je spremenila struktura nastavitev. Če so bili prej nastavitve vnesene neposredno v razred shranjevanja, jih je zdaj najprej treba določiti v helm chart, nato pa še v razred shranjevanja. Če se o tem pozanimate, ni prišlo do nobenega velikih sprememb.

Poglejmo si na primeru, katere prednosti lahko pridobite z uporabo vmesnika za shranjevanje Ceph s pomočjo CSI gonilnika.

Pri delu s Ceph-om CSI gonilnik ponuja več možnosti za delo s sistemom shranjevanja podatkov kot vgrajeni gonilniki.

Dinamično ustvarjanje diskov. Običajno se RBD diski uporabljajo le v RWO načinu, medtem ko CSI za Ceph omogoča njihovo uporabo v RWX načinu. Več podov na različnih vozliščih lahko istočasno montira enak RDB disk in z njim deluje. V poštenosti je treba omeniti, da to ni vse tako rožnato — ta disk se lahko priključi le kot blok naprava, torej bo potrebno prilagoditi aplikacijo za delo z njim v načinu večkratnega dostopa.
Ustvarjanje posnetkov. V Kubernetes grozdu je mogoče ustvariti manifest, ki zahteva ustvarjanje posnetka. CSI vtičnik ga bo opazil in naredil posnetek z diska. Na njegovi osnovi bo mogoče narediti bodisi varnostno kopijo bodisi kopijo PersistentVolume.
Povečanje velikosti diska na SAN in PersistentVolume v Kubernetes grozdu.
Kvote. Vgrajeni CephFS vtičniki v Kubernetes ne podpirajo kvot, medtem ko novi CSI vtičniki z novim Ceph Nautilus podpirajo aktivacijo kvot na CephFS particijah.
Metrike. CSI vtičnik lahko Prometheusu posreduje veliko meritev o tem, kateri volumni so priključeni, kakšna je interakcija in tako naprej.
Zavedna geologija. Omogoča določitev v manifestih, kako geografsko razporejena je grozda, in se izogniti povezovanju na pode, ki so zagnani v Londonu, z zmogljivostmi za shranjevanje podatkov, ki se nahajajo v Amsterdamu.

Kako povezati Ceph z grozdom Kubernetes preko CSI, si oglejte v praktičnem delu predavanja večerne šole Sljerm. Prav tako se lahko prijavite na video tečaj Ceph, ki se bo začel 15. oktobra.

Avtor članka: Sergej Bondarev, prakticirajoči arhitekt Southbridge, Certificirani Kubernetes Administrator, eden od razvijalcev kubespray.

Malo Post Scriptum ne reklame, ampak zaradi koristi…

P.S. Sergej Bondarev vodi dva intenziva: posodobljen Kubernetes Osnova 28-30 septembra in napreden Kubernetes Mega od 14. do 16. oktobra.