Kubernetes'i klastris käivitatavate rakenduste andmete salvestamise seadistamine on võimalik mitmel erineval viisil. Mõni neist on juba aegunud, teised on ilmnesid alles hiljuti. Selles artiklis käsitleme kolme erineva salvestuslahenduse kontseptsiooni, sealhulgas kõige uuemat - ühendust läbi Container Storage Interface.
Meetod 1. PV määramine pod'i manifestis
Tüüpiline manifest, mis kirjeldab pod'i Kubernetes'i klastris:
Manifesti osad, kus on kirjas, milline maht ühildub ja kuhu, on esitatud värviga.
Jaotises volumeMounts määravad mountPath'i - kust kausta konteineri sees ühendatakse püsiv maht, ning ka mahuti nime.
Jaotises x loetletakse kõik pod'is kasutatavad mahud. Määratakse iga mahu nimi, samuti tüüp (meie puhul: awsElasticBlockStore) ja ühendamise parameetrid. Millised täpselt parameetrid manifestis loetletakse, sõltub mahu tüübist.
Sama mahtu saab samaaegselt ühendada mitmesse konteinerisse pod'is. Seeläbi saavad rakenduse erinevad protsessid juurdepääsu samadele andmetele.
See ühendusmeetod loodi alguses, kui Kubernetes alles arenes, ja tänaseks on see aegunud.
Selle kasutamisel tekib mitmeid probleeme:
- kõik mahud tuleb luua käsitsi, Kubernetes ei saa meie eest midagi luua;
- iga mahu juurdepääsu parameetrid on unikaalsed ning need tuleb määrata kõigi pod'ide manifestides, mis kasutavad mahtu;
- salvestussüsteemi muutmiseks (nt AWS-st Google Cloudi liikumiseks) tuleb muuta kõigi manifestide ühendatud mahutite seadistusi ja tüüpe.
Kõik see on väga ebamugav, seetõttu kasutatakse reaalsuses sarnasel viisil ainult mõningate eriliikide mahutite ühendamiseks: configMap, secret, emptyDir, hostPath:
configMap ja secret - teenusmahud, võimaldavad konteineris luua mahu manifeetide failidega Kubernetes'ist.
emptyDir - ajutine maht, luuakse ainult pod'i eluaja jooksul. Mugav kasutada testimiseks või ajutiste andmete hoidmiseks. Kui pod kustutatakse, kustutatakse ka emptyDir tüüpi maht ning kõik andmed kaovad.
hostPath — võimaldab monteerida konteineri sisse mis tahes kohaliku ketta katalooge serveris, kus rakendus töötab, sealhulgas /etc/kubernetes. See on ebaturvaline võimalus, seega keelavad tavaliselt turvapoliitikad selliste tüüpide mahutite kasutamise. Vastasel juhul võib kurjategija rakendus monteerida oma konteinerisse HTC Kubernetes katalooge ja varastada kõik klastrisertifikaadid. Üldjuhul lubatakse hostPath mahuteid kasutada ainult süsteemirakendustel, mis töötavad kube-system nimede ruumis.
on toodud dokumentatsioonis.
Meetod 2. Ühendamine SC/PVC/PV-ga
Alternatiivne ühendusmeetod on Storage class, PersistentVolumeClaim, PersistentVolume kontseptsioon.
Storage class salvestab andmed andmesalvestussüsteemi ühenduse kohta.
PersistentVolumeClaim kirjeldab nõudmisi mahutile, mida rakendus vajab.
PersistentVolume salvestab juurdepääsu parameetrid ja mahuti staatuse.
Idee on see: podi manifestis määratakse volume tüüpi PersistentVolumeClaim ja selle üksuse nimi parameetris claimName.
PersistentVolumeClaim manifestis kirjeldatakse nõudmisi andmete mahutile, mis rakendusele vajalikud. Need hõlmavad:
- keta suurust;
- juurdepääsu tüüpi: ReadWriteOnce või ReadWriteMany;
- viitet Storage class'ile — millises andmesalvestussüsteemis soovime mahutit luua.
Storage class manifestis hoitakse tüüpi ja andmesalvestussüsteemi ühenduse parameetreid. Need on vajalikud kubletile, et monteerida mahuti oma sõlme.
PersistentVolume manifestides määratakse Storage class ja juurdepääsu parameetrid konkreetsele mahutile (mahuti ID, tee jne).
PVC-d luues vaatab Kubernetes, millisest suurusest ja millisest Storage class'ist mahuti on vajalik ning valib vaba PersistentVolume.
Kui selliseid PV-sid pole saadaval, võib Kubernetes käivitada spetsiaalse programmi — Provisioner (selle nimi määratakse Storage class'is). See programm ühendub andmesalvestussüsteemiga, loob vajaliku suurusega mahuti, saadab identifikaatori ja loob Kubernetes klasteris PersistentVolume manifesti, mis seondub PersistentVolumeClaim'iga.
Kogu see abstraktsioonide hulk võimaldab eemaldada teabe selle kohta, millise andmesalvestussüsteemiga rakendus töötab, rakenduste manifestide tasandilt haldamise tasandile.
Kõik andmetallikate ühendamise parameetrid asuvad Storage class'is, mille eest vastutavad klastrihaldurid. Kõik, mida tuleb teha, kui liikuda AWS-ilt Google Cloudi, on muuta rakenduse manifestides Storage class'i nime PVC-s. Persistence Volume'it andmete hoidmiseks luuakse klastris automaatselt Provisioneri programmi abil.
Meetod 3. Container Storage Interface
Kood, mis suhtleb erinevate andmesalvestussüsteemidega, on osa Kubernetes'i tuumast. Veaparanduste või uue funktsionaalsuse väljalaskmine on seotud uute versioonidega, koodi tuleb muuta kõigi toetatud Kubernetes'i versioonide jaoks. Kõike seda on keeruline toetada ja uut funktsionaalsust lisada.
Probleemi lahendamiseks lõid Cloud Foundry, Kubernetes, Mesos ja Docker'i arendajad Container Storage Interface (CSI) — lihtne ühtne liides, mis kirjeldab konteinerihaldussüsteemi ja spetsiaalse draiveri (CSI Driver) vahelist suhtlust, mis töötab konkreetse andmesalvestussüsteemiga. Kõik andmesalvestussüsteemiga suhtlemise kood viidi Kubernetes'i tuumast eraldi süsteemi.
.
Tavaliselt koosneb CSI Driver kahest komponendist: Node Plugin ja Controller plugin.
Node Plugin käivitatakse igas sõlmes ning see vastutab mahtude mountimise ja nende operatsioonide eest. Controller plugin suhtleb andmesalvestussüsteemiga: loob või kustutab mahud, määrab ligipääsu õigused jne.
Kuni Kubernetes'i tuumas jäävad vanad draiverid, kuid nende kasutamist ei soovitata enam ning kõigile soovitatakse installida CSI Driver just selle süsteemi jaoks, millega kavatsetakse töötada.
Uus muudatus võib hirmutada neid, kes on harjunud andmete salvestamist seadistama läbi Storage class'i, kuid tegelikult pole midagi hullu juhtunud. Programmatuuride jaoks ei muutu tõeliselt midagi — nad jätkavad töötamist ainult Storage class'i nimega. Halduritele lisandus helm chart'i installimine ja parandus seadete struktuuris. Kui varem sisestati seaded otse Storage class'i, siis nüüd tuleb need esmalt määrata helm chart'is ja alles seejärel Storage class'is. Kui süveneda, ei ole midagi hullu juhtunud.
Vaatame näite abil, milliseid eeliseid saab saavutada, minnes Andmesalvestussüsteemi Ceph ühendamisele läbi CSI draiveri.
Ceph'i töötamisel annab CSI plugin rohkem võimalusi Andmesalvestussüsteemiga töötamiseks kui sisseehitatud draiverid.
- Dünaamiline ketaste loomine. Tavaliselt kasutatakse RBD kettaid ainult RWO režiimis, kuid CSI Ceph jaoks võimaldab neid kasutada RWX režiimis. Mitmed pod'id erinevates sõlmedes saavad sama RDB-ketta oma sõlmede külge mountida ja töötada sellega samal ajal. Õiguse nimel, mitte kõik ei ole nii roosiline — seda ketast saab ühendada ainult kui plokiseadet, mis tähendab, et rakendus tuleb kohandada sellega töötamiseks mitme juurdepääsu režiimis.
- Snapshotide loomine. Kubernetes klastris saab luua manifesti, mis nõuab snapshoti loomist. CSI plugin näeb seda ja loob ketta snapshoti. Selle põhjal saab luua kas varukoopia või koopia PersistentVolume'ist.
- Ketta suuruse suurendamine SAN-is ja PersistentVolume'is Kubernetes klastris.
- Kvoodid. Kubernetes'i sisse ehitatud CephFS draiverid ei toeta kvoote, kuid uued CSI-pluginad koos värske Ceph Nautilus'ega oskavad CephFS jaotustes kvoote aktiveerida.
- Metrika. CSI-plugin saab Prometheusesse edastada hulga mõõdikuid selle kohta, millised mahud on ühendatud, millised interaktsioonid toimuvad jne.
- Topoloogia teadlik. Lubab näidata manifestides, kui geograafiliselt jaotatud klaster on, ja vältida ühendamist podidega, mis töötab Londonis, andmehoidla jaoks, mis asub Amsterdamis.
Kuidas ühendada Ceph Kubernetes klastriga läbi CSI, vaadake . Samuti on võimalik registreeruda , mis algab 15. oktoobril.
Artikli autor: Sergei Bondarev, praktiseeriv arhitekt Southbridge, Certified Kubernetes Administrator, üks kubespray arendajatest.
Veidi Post Scriptum mitte reklaami, vaid kasu nimel…
P.S. Sergei Bondarev viib läbi kaks intensiivset kursust: uuendatud 28-30 septembril ja edasijõudnud 14–16 oktoobril.
Allikas: habr.com
