Postoji nekoliko načina za konfiguriranje pohrane podataka za aplikacije koje se izvode na Kubernetes klasteru. Neki od njih su već zastarjeli, drugi su se pojavili nedavno. U ovom članku ćemo pogledati koncept tri opcije za povezivanje sustava za pohranu, uključujući najnoviju - povezivanje preko sučelja za pohranu kontejnera.
1. metoda: navedite PV u manifestu kapsule
Tipičan manifest koji opisuje pod u Kubernetes klasteru:
Bojom su istaknuti dijelovi manifesta koji opisuju koji je svezak povezan i gdje.
U odjeljku volumenMounts navedite točke montiranja (mountPath) - u koji direktorij unutar spremnika će biti montiran trajni volumen, kao i naziv volumena.
U odjeljku 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 ovisi o vrsti volumena.
Isti volumen može se montirati istovremeno u više kontejnera mahuna. Na taj način različiti aplikacijski procesi mogu pristupiti istim podacima.
Ova metoda povezivanja je izmišljena na samom početku, kada je Kubernetes tek bio u povojima, a danas je metoda zastarjela.
Postoji nekoliko problema prilikom korištenja:
- svi se volumeni moraju kreirati ručno; Kubernetes ne može ništa stvoriti umjesto nas;
- parametri pristupa za svaki volumen su jedinstveni i moraju biti navedeni u manifestima svih podova koji koriste volumen;
- da biste promijenili sustav pohrane (na primjer, prešli s AWS-a na Google Cloud), trebate promijeniti postavke i vrstu montiranih volumena u svim manifestima.
Sve je to vrlo nezgodno, tako da se u stvarnosti ova metoda koristi za povezivanje samo nekih posebnih vrsta volumena: configMap, secret, emptyDir, hostPath:
-
configMap i secret su servisni volumeni koji vam omogućuju stvaranje volumena s datotekama iz Kubernetes manifesta u spremniku.
-
emptyDir je privremeni volumen, kreiran samo za životni vijek grupe. Zgodan za korištenje za testiranje ili pohranjivanje privremenih podataka. Kada se pod izbriše, volumen emptyDir se također briše i svi podaci se gube.
-
hostPath - omogućuje montiranje bilo kojeg direktorija na lokalnom disku poslužitelja na kojem se aplikacija izvodi unutar spremnika s aplikacijom, uključujući /etc/kubernetes. Ovo je nesigurna značajka, pa sigurnosna pravila obično zabranjuju korištenje volumena ove vrste. U protivnom će napadačeva aplikacija moći montirati HTC Kubernetes direktorij unutar njegovog spremnika i ukrasti sve certifikate klastera. Tipično, hostPath volumene smiju koristiti samo sistemske aplikacije koje se izvode u prostoru naziva kube-system.
dati su u dokumentaciji.
Metoda 2. Spajanje na SC/PVC/PV ognjišta
Alternativna metoda povezivanja je koncept klase za pohranu, PersistentVolumeClaim, PersistentVolume.
Klasa skladištenja pohranjuje parametre veze sa sustavom za pohranu podataka.
Trajni VolumeClaim opisuje zahtjeve za ono što aplikacija treba.
Trajni volumen pohranjuje pristupne parametre i status volumena.
Bit ideje: u manifestu pod-a oni označavaju volumen tipa PersistentVolumeClaim i označavaju naziv ovog entiteta u parametru claimName.
Manifest PersistentVolumeClaim opisuje zahtjeve za količinu podataka koju aplikacija zahtijeva. Uključujući:
- veličina diska;
- način pristupa: ReadWriteOnce ili ReadWriteMany;
- link to Storage class - u kojem sustavu za pohranu podataka želimo kreirati volumen.
Manifest klase Storage pohranjuje vrstu i parametre veze sa sustavom za pohranu. Cubelet ih treba za montiranje volumena na svoj čvor.
Manifesti PersistentVolume pokazuju klasu pohrane i pristupne parametre za određeni volumen (ID volumena, put itd.).
Prilikom izrade PVC-a, Kubernetes gleda koja je veličina volumena i koja je klasa pohrane potrebna te odabire besplatni PersistentVolume.
Ako takvi PV-ovi nisu dostupni, Kubernetes može pokrenuti poseban program - Provisioner (ime mu je navedeno u klasi Storage). Ovaj se program povezuje sa sustavom za pohranu, stvara volumen potrebne veličine, prima identifikator i stvara manifest PersistentVolume u Kubernetes klasteru, koji je povezan s PersistentVolumeClaim.
Sav ovaj skup apstrakcija omogućuje vam uklanjanje informacija o tome s kojim sustavom za pohranu aplikacija radi s razine manifesta aplikacije na razinu administracije.
Svi parametri za povezivanje sa sustavom za pohranu podataka nalaze se u klasi Storage za koju su odgovorni administratori klastera. Sve što trebate učiniti kada prijeđete s AWS-a na Google Cloud je promijeniti naziv klase Storage u PVC u manifestima aplikacije. Volumen postojanosti za pohranu podataka automatski će se stvoriti u klasteru pomoću programa Provisioner.
Metoda 3: Sučelje za pohranu spremnika
Sav kod koji je u interakciji s različitim sustavima za pohranu dio je Kubernetes jezgre. Izdanje ispravaka grešaka ili nove funkcionalnosti vezano je za nova izdanja; kôd se mora promijeniti za sve podržane verzije Kubernetesa. Sve je to teško održavati i dodavati nove funkcionalnosti.
Kako bi riješili problem, programeri iz Cloud Foundryja, Kubernetesa, Mesosa i Dockera stvorili su Container Storage Interface (CSI) - jednostavno objedinjeno sučelje koje opisuje interakciju sustava za upravljanje spremnikom i posebnog upravljačkog programa (CSI Driver) koji radi s određenim sustav skladištenja. Sav kod za interakciju sa sustavima za pohranu premješten je iz Kubernetes jezgre u zasebni sustav.
.
Obično se CSI upravljački program sastoji od dvije komponente: dodatka čvora i dodatka kontrolera.
Node Plugin radi na svakom čvoru i odgovoran je za montiranje jedinica i izvođenje operacija na njima. Dodatak Controller komunicira sa sustavom za pohranu: stvara ili briše volumene, dodjeljuje prava pristupa itd.
Za sada stari drajveri ostaju u Kubernetes kernelu, ali se više ne preporuča njihovo korištenje i svima se savjetuje da instaliraju CSI Driver posebno za sustav s kojim će raditi.
Inovacija može uplašiti one koji su već navikli postavljati pohranu podataka kroz klasu Storage, ali zapravo se nije dogodilo ništa strašno. Za programere se zapravo ništa ne mijenja - radili su samo s imenom Storage class i nastavit će tako raditi. Za administratore je dodana instalacija helm charta i promijenjena je struktura postavki. Ako su se prije postavke unosile izravno u klasu Skladištenje, sada se prvo moraju postaviti u karti kormila, a zatim u klasi Skladištenje. Ako pogledate u to, ništa se loše nije dogodilo.
Uzmimo primjer da pogledamo prednosti koje možete dobiti prelaskom na povezivanje Ceph sustava za pohranu pomoću CSI drajvera.
Kada radite s Cephom, dodatak CSI pruža više mogućnosti za rad sa sustavima za pohranu od ugrađenih upravljačkih programa.
- Izrada dinamičkog diska. Tipično se RBD diskovi koriste samo u RWO modu, ali CSI za Ceph dopušta njihovu upotrebu u RWX modu. Nekoliko podova na različitim čvorovima može montirati isti RDB disk na svoje čvorove i raditi s njima paralelno. Da budemo pošteni, nije sve tako sjajno - ovaj disk se može spojiti samo kao blok uređaj, što znači da ćete morati prilagoditi aplikaciju za rad s njim u načinu višestrukog pristupa.
- Stvaranje snimaka. U Kubernetes klasteru možete stvoriti manifest sa zahtjevom za stvaranjem snimke. CSI plugin će to vidjeti i napraviti snimku s diska. Na temelju toga možete napraviti sigurnosnu kopiju ili kopiju PersistentVolume.
- Povećanje veličine diska na pohranu i PersistentVolume u Kubernetes klasteru.
- Kvote. CephFS upravljački programi ugrađeni u Kubernetes ne podržavaju kvote, ali novi CSI dodaci s najnovijim Ceph Nautilusom mogu omogućiti kvote na CephFS particijama.
- Metrika. Dodatak CSI može pružiti Prometheusu razne metrike o tome koji su volumeni povezani, koja se komunikacija odvija itd.
- Svjestan topologije. Omogućuje vam da u manifestima navedete kako je klaster geografski raspoređen i izbjegavate povezivanje sustava za pohranu koji se nalazi u Amsterdamu s jedinicama koje rade u Londonu.
Kako povezati Ceph s Kubernetes klasterom putem CSI-ja, pogledajte . Također se možete pretplatiti na , koji će krenuti 15. listopada.
Autor članka: Sergey Bondarev, aktivni arhitekt u Southbridgeu, certificirani Kubernetes administrator, jedan od programera kubespray.
Mali Post Scriptum ne za reklamu, već za dobrobit...
PS Sergey Bondarev vodi dva intenzivna tečaja: ažurirani 28-30 rujna i napredni 14.–16. listopada.
Izvor: www.habr.com