🥇Pohrana podataka u Kubernetes klasteru

Postavljanje pohrane podataka aplikacija pokrenutih u Kubernetes klasteru može se izvršiti na nekoliko načina. Neki od njih su već zastarjeli, dok su drugi nedavno uvedeni. U ovom članku razmotrit ćemo koncept tri opcije povezivanja sustava za pohranu podataka, uključujući najnoviju — povezanost putem Container Storage Interface-a.

Način 1. Naveo PV u manifestu poda

Tipični manifest koji opisuje pod u Kubernetes klasteru:

Dijelovi manifesta označeni bojom pokazuju koji volumen se povezuje i gdje.

U odjeljku volumeMounts navode točke montiranja (mountPath) — u kojem katalogu unutar kontejnera će se postaviti trajni volumen, kao i naziv volumena.

U odjeljku x navode sve volumene koji se koriste u podu. Navode naziv svakog volumena, kao i tip (u našem slučaju: awsElasticBlockStore) i parametre povezivanja. Koji točno parametri se navode u manifestu, ovisi o tipu volumena.

Isti volumen može biti montiran istovremeno u nekoliko kontejnera poda. Tako različiti procesi aplikacije mogu imati pristup istim podacima.

Ova metoda povezivanja smišljena je na samom početku, kada se Kubernetes tek počeo razvijati, i danas je zastarjela.

Korištenje ove metode donosi nekoliko problema:

svi se volumeni moraju ručno stvarati, Kubernetes neće moći stvoriti ništa umjesto nas;
parametri pristupa svakom od volumena su jedinstveni i moraju se navesti u manifestima svih podova koji koriste volumen;
da bi se promijenila sustav pohrane (na primjer, prešla iz AWS-a u Google Cloud), potrebno je promijeniti postavke i tip povezanih volumena u svim manifestima.

Sve ovo je vrlo neudobno, stoga se u stvarnosti ovom metodom koriste samo za povezivanje nekih posebnih tipova volumena: configMap, secret, emptyDir, hostPath:

configMap i secret — pomoćni volumeni, omogućuju stvaranje volumena s datotekama iz Kubernetes manifesta unutar kontejnera.
emptyDir — privremeni volumen, stvara se samo za vrijeme trajanja poda. Prikladno je koristiti za testiranje ili čuvanje privremenih podataka. Kada se pod ukloni, emptyDir tip volumena se također uklanja i svi podaci nestaju.
hostPath — omogućava montažu bilo kojeg direktorija s lokalnog diska poslužitelja koji pokreće aplikaciju unutar kontejnera aplikacije, uključujući /etc/kubernetes. Ovo je nesigurna mogućnost, pa obično sigurnosne politike zabranjuju korištenje volumena ovog tipa. Inače, zlonamjerna aplikacija može montirati direktorij HTC Kubernetes unutar svog kontejnera i ukrasti sve ključeve klastera. Obično, hostPath volumeni dopuštaju korištenje samo sistemskim aplikacijama koje se pokreću u namespace kube-system.

Sustavi pohrane podataka s kojima Kubernetes radi iz kutije navedeni su u dokumentaciji.

Način 2. Povezivanje s podovima SC/PVC/PV

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

Storage class čuva parametre za povezivanje sa sustavom pohrane podataka.

PersistentVolumeClaim opisuje zahtjeve za volumem koji je potreban aplikaciji.
PersistentVolume čuva parametre pristupa i status volumena.

Bit ideje: u manifestu poda navode volume tipa PersistentVolumeClaim i naziv te entitete u parametru claimName.

U manifestu PersistentVolumeClaim opisuju se zahtjevi za volumom podataka koji su potrebni aplikaciji. Između ostalog:

veličina diska;
način pristupa: ReadWriteOnce ili ReadWriteMany;
link na Storage class — u kojem sustavu pohrane podataka želimo kreirati volumen.

U manifestima Storage class čuvaju se tip i parametri za povezivanje sa sustavom pohrane podataka. Oni su potrebni kubeletu da montira volumen na čvor.

U manifestima PersistentVolume navode se Storage class i parametri pristupa određenom volumenu (ID volumena, put, itd.).

Kada se kreira PVC, Kubernetes gleda koju veličinu i iz kojega Storage classa je potreban volumen, i bira slobodan PersistentVolume.

Ako takvi PV ne postoje, Kubernetes može pokrenuti posebnu aplikaciju — Provisioner (njezino ime navodi se u Storage class). Ova aplikacija povezuje se s sustavom pohrane podataka, stvara volumen potrebne veličine, dobija identifikator i kreira u klasteru Kubernetes manifest PersistentVolume koji se povezuje s PersistentVolumeClaim.

Sav taj niz apstrakcija omogućuje uklanjanje informacije o sustavu pohrane s kojim aplikacija radi s razine manifestacije aplikacija na razinu administracije.

Sve konfiguracijske informacije za vezu s sustavom za pohranu podataka nalaze se u klasi pohrane, za koju su odgovorni administratori klastera. Sve što trebate učiniti prilikom prelaska s AWS-a na Google Cloud je promijeniti naziv klase pohrane u PVC manifestima aplikacije. Postojajući volumen za pohranu podataka će se automatski stvoriti u klasteru pomoću Provisioner programa.

Metoda 3. Sučelje za pohranu kontejnera

Sav kod koji komunicira s različitim sustavima za pohranu podataka dio je jezgre Kubernetes-a. Izdavanje zakrpa ili novih funkcionalnosti vezano je uz nove verzije, a kod se mora mijenjati za sve podržane verzije Kubernetes-a. Sve to je teško održavati i dodavati nove funkcije.

Kako bi riješili problem, developeri iz Cloud Foundry, Kubernetes, Mesos i Docker-a stvorili su Sučelje za pohranu kontejnera (CSI) — jednostavno jedinstveno sučelje koje opisuje interakciju sustava upravljanja kontejnerima i specifičnog drajvera (CSI Driver) koji radi s određenim sustavom za pohranu podataka. Sav kod za interakciju s sustavima za pohranu podataka je premješten iz jezgre Kubernetes-a u zasebni sustav.

Dokumentacija za Sučelje za pohranu kontejnera.

CSI Driver obično se sastoji od dva komponente: Node Plugin i Controller Plugin.

Node Plugin se pokreće na svakom čvoru i odgovoran je za montiranje volumena i operacije na njima. Controller Plugin komunicira sa sustavom za pohranu podataka: stvara ili uklanja volumene, dodjeljuje prava pristupa itd.

Dok u jezgri Kubernetes-a ostaju stari drajveri, njihova upotreba se više ne preporučuje, a svima se savjetuje da instaliraju CSI Driver posebno za sustav s kojim će raditi.

Nova promjena može uplašiti one koji su se već navikli konfigurirati pohranu podataka putem klase pohrane, ali zapravo se nije dogodilo ništa strašno. Programeri se neće suočiti s promjenom — i dalje će raditi samo s imenom klase pohrane. Za administratore, dodana je instalacija helm chart-a i promijenila se struktura postavki. Ako su se ranije postavke unosile izravno u klasu pohrane, sada ih prvo treba definirati u helm chart-u, a zatim u klasi pohrane. Ako se pogleda, nije se dogodilo ništa strašno.

Pogledajmo na primjeru koje prednosti možemo dobiti prelaskom na povezivanje s pohranom podataka Ceph putem CSI drajvera.

Prilikom rada s Ceph, CSI plugin nudi više mogućnosti za rad s pohranom podataka od ugrađenih drajvera.

Dinamičko stvaranje diskova. Obično se RBD diskovi koriste samo u RWO modu, dok CSI za Ceph omogućuje njihovu upotrebu u RWX modu. Više podova na različitim čvorovima može montirati isti RBD disk na svoje čvorove i raditi s njima paralelno. Ipak, nije sve tako sjajno — ovaj disk se može povezati samo kao blok uređaj, tj. bit će potrebno prilagoditi aplikaciju za rad s njim u režimu višestrukog pristupa.
Izrada snimaka. U Kubernetes klasteru može se izraditi manifest s zahtjevom za izradu snimka. CSI plugin će ga primijetiti i napraviti snimak s diska. Na temelju toga bit će moguće napraviti ili backup ili kopiju PersistentVolume.
Povećanje veličine diska na SAN-u i PersistentVolume u Kubernetes klasteru.
Kvota. Ugrađeni Kubernetes CephFS driveri ne podržavaju kvote, dok novi CSI pluginovi s novim Ceph Nautilusom mogu uključiti kvote na CephFS particijama.
Metrike. CSI plugin može slati brojne metrike u Prometheus o tome koji su volumeni povezani, koje interakcije se odvijaju itd.
Svijest o topologiji. Omogućuje određivanje geografske raspodjele klastera u manifestima i izbjegavanje povezivanja s podovima koji su pokrenuti u Londonu na sustav za pohranu podataka koji se nalazi u Amsterdamu.

Kako povezati Ceph s Kubernetes klasterom putem CSI, pogledajte u praktičnom dijelu predavanja večernje škole Sljurm. Također se možete prijaviti na video tečaj Ceph, koji će krenuti 15. listopada.

Autor članka: Sergey Bondarev, praktični arhitekt u Southbridgeu, Certified Kubernetes Administrator, jedan od developera kubespray.

Malo Post Scriptum – ne reklame, već u svrhu korisnosti...

P.S. Sergey Bondarev vodi dva intenziva: ažurirani Kubernetes Osnovna 28-30 rujna i napredni Kubernetes Mega 14–16. listopada.