Pohranjivanje podataka u Kubernetes klaster

Postoji nekoliko načina da se konfiguriše skladištenje podataka za aplikacije koje rade na Kubernetes klasteru. Neki od njih su već zastarjeli, drugi su se pojavili sasvim nedavno. U ovom članku ćemo pogledati koncept tri opcije za povezivanje sistema za skladištenje podataka, uključujući najnoviju - povezivanje preko interfejsa za skladištenje kontejnera.

Metoda 1: Navedite PV u manifestu pod

Tipičan manifest koji opisuje pod u Kubernetes klasteru:

Dijelovi manifesta koji opisuju koji je volumen povezan i gdje su istaknuti bojom.

odjeljak volumeMounts označite tačke montiranja (mountPath) - u koji direktorijum unutar kontejnera će biti montiran trajni volumen, kao i naziv volumena.

odjeljak x navodi sve volumene koji se koriste u pod. Navedite naziv svakog volumena, kao i tip (u našem slučaju: awsElasticBlockStore) i parametre veze. Koji su parametri navedeni u manifestu zavisi od tipa volumena.

Ista zapremina se može montirati istovremeno u više kontejnera. Na ovaj način različiti procesi aplikacije mogu pristupiti istim podacima.

Ova metoda povezivanja je izmišljena na samom početku, kada je Kubernetes bio tek u povojima, a danas je metoda zastarjela.

Postoji nekoliko problema prilikom upotrebe:

1. svi volumeni se moraju kreirati ručno; Kubernetes ne može ništa kreirati za nas;
2. pristupni parametri za svaki volumen su jedinstveni i moraju biti specificirani u manifestima svih podova koji koriste volumen;
3. da promijenite sistem pohrane (na primjer, pređite sa AWS-a na Google Cloud), morate promijeniti postavke i tip montiranih volumena u svim manifestima.

Sve je to vrlo nezgodno, pa se u stvarnosti ova metoda koristi za povezivanje samo nekih posebnih tipova volumena: configMap, secret, emptyDir, hostPath:

• configMap i secret su servisni volumeni koji vam omogućavaju da kreirate volumen sa datotekama iz Kubernetes manifesta u kontejneru.

• emptyDir je privremeni volumen, kreiran samo za vrijeme trajanja modula. Pogodan za korištenje za testiranje ili pohranjivanje privremenih podataka. Kada se pod izbriše, volumen prazniDir se također briše i svi podaci se gube.

• hostPath - omogućava vam da montirate bilo koji direktorij na lokalni disk servera na kojem se aplikacija izvodi unutar kontejnera s aplikacijom, uključujući /etc/kubernetes. Ovo je nesigurna funkcija, tako da sigurnosna pravila obično zabranjuju korištenje volumena ovog tipa. U suprotnom, aplikacija napadača će moći montirati HTC Kubernetes direktorij unutar svog kontejnera i ukrasti sve certifikate klastera. Obično je hostPath volumene dozvoljeno koristiti samo sistemskim aplikacijama koje se pokreću u kube-system imenskom prostoru.

Sistemi za skladištenje sa kojima Kubernetes radi bez upotrebe date su u dokumentaciji.

Metoda 2. Spajanje na SC/PVC/PV ognjišta

Alternativni način povezivanja je koncept klase Storage, PersistentVolumeClaim, PersistentVolume.

Klasa skladištenja pohranjuje parametre veze sa sistemom za pohranu podataka.

PersistentVolumeClaim opisuje zahtjeve za ono što je potrebno aplikaciji.
PersistentVolume pohranjuje parametre pristupa i status volumena.

Suština ideje: u manifestu pod označavaju volumen tipa PersistentVolumeClaim i ukazuju na ime ovog entiteta u parametru claimName.

Manifest PersistentVolumeClaim opisuje zahtjeve za količinu podataka koju aplikacija zahtijeva. Uključujući:

• veličina diska;
• metoda pristupa: ReadWriteOnce ili ReadWriteMany;
• link do Storage class - u kojem sistemu za skladištenje podataka želimo da kreiramo volumen.

Manifest klase Storage pohranjuje tip i parametre veze sa sistemom skladištenja. Kubelet ih treba da montira volumen na svoj čvor.

Manifesti PersistentVolume ukazuju na klasu pohrane i parametre pristupa za određeni volumen (ID volumena, staza, itd.).

Prilikom kreiranja PVC-a, Kubernetes gleda koju veličinu volumena i koja klasa pohrane je potrebna, te odabire besplatni PersistentVolume.

Ako takvi PV-ovi nisu dostupni, Kubernetes može pokrenuti poseban program - Provisioner (njegov naziv je naznačen u klasi Storage). Ovaj program se povezuje sa sistemom skladištenja, kreira volumen potrebne veličine, prima identifikator i kreira manifest PersistentVolume u Kubernetes klasteru, koji je povezan sa PersistentVolumeClaim.

Sav ovaj skup apstrakcija vam omogućava da uklonite informacije o tome sa kojim sistemom skladištenja aplikacija radi sa nivoa manifesta aplikacije na nivo administracije.

Svi parametri za povezivanje sa sistemom za skladištenje podataka nalaze se u klasi Storage, za koju su odgovorni administratori klastera. Sve što trebate učiniti kada prelazite s AWS-a na Google Cloud je da promijenite naziv klase Storage u PVC u manifestima aplikacije. Persistance Volume za skladištenje podataka će se automatski kreirati u klasteru pomoću programa Provisioner.

Metoda 3: Interfejs za skladištenje kontejnera

Sav kod koji je u interakciji sa različitim sistemima za skladištenje je deo Kubernetes jezgra. Izdanje ispravki grešaka ili nove funkcionalnosti vezano je za nova izdanja; kod se mora promijeniti za sve podržane verzije Kubernetesa. Sve ovo je teško održavati i dodati nove funkcionalnosti.

Kako bi riješili problem, programeri iz Cloud Foundry, Kubernetes, Mesos i Docker kreirali su Container Storage Interface (CSI) - jednostavno objedinjeno sučelje koje opisuje interakciju sistema za upravljanje kontejnerima i posebnog drajvera (CSI Driver) koji radi sa određenim sistem skladištenja. Sav kod za interakciju sa sistemima za skladištenje prebačen je iz Kubernetes jezgra u poseban sistem.

Dokumentacija o interfejsu za skladištenje kontejnera.

Tipično, CSI Driver se sastoji od dvije komponente: Node Plugin i Controller plugin.

Node Plugin radi na svakom čvoru i odgovoran je za montiranje volumena i izvođenje operacija na njima. Dodatak Controller je u interakciji sa sistemom za skladištenje: kreira ili briše volumene, dodeljuje prava pristupa, itd.

Za sada su stari drajveri ostali u Kubernetes kernelu, ali se više ne preporučuju za korišćenje i svima se savetuje da instaliraju CSI drajver posebno za sistem sa kojim će raditi.

Inovacija može uplašiti one koji su već navikli da postavljaju pohranu podataka kroz klasu Storage, ali u stvari se ništa strašno nije dogodilo. Za programere se ništa zapravo ne mijenja – radili su samo s imenom Storage class, i nastavit će to raditi. Za administratore je dodana instalacija helm charta i promijenjena je struktura postavki. Ako su se prethodno postavke unosile direktno u klasu Storage, sada se prvo moraju postaviti u helm chart, a zatim u klasu Storage. Ako pogledate, ništa se loše nije dogodilo.

Uzmimo primjer da pogledamo prednosti koje možete dobiti prelaskom na povezivanje Ceph sistema za pohranu pomoću CSI drajvera.

Kada radite sa Cephom, CSI dodatak pruža više opcija za rad sa sistemima za skladištenje od ugrađenih drajvera.

1. Kreiranje dinamičkog diska. Obično se RBD diskovi koriste samo u RWO modu, ali CSI za Ceph im omogućava da se koriste u RWX modu. Nekoliko podova na različitim čvorovima može montirati isti RDB disk na svoje čvorove i raditi s njima paralelno. Iskreno govoreći, nije sve tako svijetlo - ovaj disk se može povezati samo kao blok uređaj, što znači da ćete morati prilagoditi aplikaciju da radi s njim u višestrukom pristupu.
2. Kreiranje snimaka. U Kubernetes klasteru možete kreirati manifest sa zahtjevom za kreiranje snimka. CSI dodatak će ga vidjeti i napraviti snimak sa diska. Na osnovu toga možete napraviti rezervnu kopiju ili kopiju PersistentVolume.
3. Povećanje veličine diska na pohranu i PersistentVolume u Kubernetes klasteru.
4. Kvote. CephFS drajveri ugrađeni u Kubernetes ne podržavaju kvote, ali svježi CSI dodaci s najnovijim Ceph Nautilusom mogu omogućiti kvote na CephFS particijama.
5. metrika. CSI dodatak može pružiti Prometheusu razne metrike o tome koji su volumeni povezani, koje komunikacije se odvijaju itd.
6. Svjestan topologije. Omogućava vam da u manifestima navedete kako je klaster geografski raspoređen i izbjegnete povezivanje sistema za skladištenje koji se nalazi u Amsterdamu sa podovima koji rade u Londonu.

Kako povezati Ceph sa Kubernetes klasterom preko CSI, pogledajte u praktičnom dijelu predavanja u večernjoj školi Slurm. Također se možete pretplatiti na Ceph video kurs, koji će pokrenuti 15. oktobra.

Autor članka: Sergej Bondarev, arhitekta u Southbridgeu, sertifikovani Kubernetes administrator, jedan od programera kubespraya.

Malo Post Scriptum ne za reklamu, nego za dobrobit...

PS Sergej Bondarev vodi dva intenzivna kursa: ažurirani Kubernetes Base 28-30. septembra i napredni Kubernetes Mega 14–16. oktobar.

izvor: www.habr.com