Konfigurimi i ruajtjes së të dhënave të aplikacioneve në një klaster Kubernetes mund të bëhet në disa mënyra. Disa prej tyre janë të vjetra, ndërsa të tjera sapo kanë dalë. Në këtë artikull do të shqyrtojmë konceptin e tri mundësive për të lidhur ruajtjen përkatëse, duke përfshirë edhe mundësinë më të fundit - lidhjen përmes Container Storage Interface.
Mënyra 1. Përcaktimi i PV në manifestin e pods
Një manifest tipik që përshkruan një pod në klasterin Kubernetes:
Pjesët e manifestit, të theksuara me ngjyrë, tregojnë se cilin volum po e lidhim dhe ku.
Në seksionin volumeMounts përcaktojnë pikët e montimit (mountPath) - në cilin katalog brenda kontejnerit do të montohet volumi i qëndrueshëm, si dhe emri i volumit.
Në seksionin x elencojnë të gjitha volumat që përdoren në pod. Të japin emrin e secilit volum, si dhe llojin (në rastin tonë: awsElasticBlockStore) dhe parametrat e lidhjes. Cilat saktësisht parametrat i përmenden në manifest varet nga lloji i volumit.
I njëjti volum mund të montohet njëkohësisht në disa kontejnerë të pod-it. Kështu, procese të ndryshme të aplikacionit mund të kenë akses në të dhëna të njëjta.
Kjo mënyrë lidhjeje u krijua në fillim, kur Kubernetes sapo kishte nisur, dhe sot është e vjetruar.
PĂ«rdorimi i tij sjell disa probleme:
- të gjitha volumet duhet të krijohen manualisht, Kubernetes nuk do të jetë në gjendje të krijojë asgjë për ne;
- parametrat e aksesit për çdo volum janë unikë dhe duhet t'i specifikojmë në manefestet e të gjitha pod-ëve që përdorin volumet;
- për të ndryshuar sistemin e ruajtjes (p.sh., për t'u transferuar nga AWS në Google Cloud), duhet të ndryshoni konfigurimet dhe llojin e volumet të lidhura në të gjitha manefestet.
E gjithë kjo është shumë e pakëndshme, ndaj në realitet, një metodë e tillë përdoret vetëm për lidhjen e disa llojeve të veçanta të volumet: configMap, secret, emptyDir, hostPath:
configMap dhe secret â volumi shĂ«rbimi, lejojnĂ« krijimin e njĂ« volumi me skedarĂ« nĂ« kontejner nga manefestet Kubernetes.
emptyDir â njĂ« volum pĂ«rkohĂ«sor, krijohet vetĂ«m pĂ«r gjatĂ« jetĂ«s sĂ« pod-it. ĂshtĂ« e pĂ«rshtatshme pĂ«r tĂ« testuar ose pĂ«r ruajtjen e tĂ« dhĂ«nave pĂ«rkohĂ«sore. Kur pod-i fshihet, volumi emptyDir gjithashtu fshihet dhe tĂ« dhĂ«nat e gjitha humbasin.
hostPath â ndihmon pĂ«r tĂ« montuar çdo katalog tĂ« diskut lokal tĂ« serverit brenda kontejnerit tĂ« aplikacionit, duke pĂ«rfshirĂ« /etc/kubernetes. Kjo Ă«shtĂ« njĂ« mundĂ«si e pasigurt, prandaj zakonisht politikat e sigurisĂ« ndalojnĂ« pĂ«rdorimin e llojeve tĂ« tilla tĂ« volumit. PĂ«rndryshe, aplikacioni i njĂ« sulmuesi mund tĂ« ketĂ« akses nĂ« katalogun HTC Kubernetes dhe tĂ« vjedhĂ« tĂ« gjitha certifikatave tĂ« klasterit. NĂ« pĂ«rgjithĂ«si, volumet hostPath lejohen tĂ« pĂ«rdoren vetĂ«m nga aplikacione sistemike qĂ« lĂ«vizin nĂ« namespace kube-system.
shkruhen në dokumentacion.
Metoda 2. Lidhja me pods SC/PVC/PV
NjĂ« mĂ«nyrĂ« alternative e lidhjes â koncepti i Storage class, PersistentVolumeClaim, PersistentVolume.
Storage class ruan parametrat e lidhjes me sistemin e ruajtjes së të dhënave.
PersistentVolumeClaim përshkruan kërkesat për volumet që i nevojiten aplikacionit.
PersistentVolume ruan parametrat e aksesit dhe statusin e volumit.
Në thelb, ideja është: në manifestin e pod-it, shënohet volume i tipit PersistentVolumeClaim dhe emri i kësaj entiteti në parametrin claimName.
Në manifestin e PersistentVolumeClaim përshkruhen kërkesat për të dhënat që janë të nevojshme për aplikacionin. Përfshihen:
- madhësia e diskut;
- metoda e aksesit: ReadWriteOnce ose ReadWriteMany;
- referenca në Storage class - në cilin sistem ruajtjeje dëshirojmë të krijojmë volumin.
Në manifestin e Storage class ruhen lloji dhe parametrat e lidhjes me sistemin e ruajtjes. Këto janë të nevojshme për kubeletin për të montuar volumin në nodin e tij.
Në manifestet e PersistentVolume specifikohet Storage class dhe parametrat e aksesit në volumin e caktuar (ID e volumin, rruga, etj.).
Duke krijuar PVC, Kubernetes shqyrton se çfarë madhësie dhe nga cili Storage class kërkohet volumi, dhe përshtat një PersistentVolume të lirë.
NĂ«se nuk ka PV tĂ« tillĂ« nĂ« dispozitĂ«, Kubernetes mund tĂ« nisĂ« njĂ« program tĂ« veçantĂ« - Provisioner (emri i tij shpĂ«rndahet nĂ« Storage class). Ky program lidhet me SĂH, krijon volumin e nevojshĂ«m, merr identifikuesin dhe krijon nĂ« klasterin Kubernetes njĂ« manifest PersistentVolume qĂ« lidhet me PersistentVolumeClaim.
KĂ«to abstraksione e lejojnĂ« largimin e informacionit mbi cilin SĂH punon aplikacioni nga niveli i manifestit tĂ« aplikacioneve nĂ« nivelin e administratĂ«s.
Të gjitha parametrat e lidhjes me sistemin e ruajtjes së dhënash ndodhen në Storage class, për të cilin janë përgjegjës administratorët e klasterit. E gjithë ajo që duhet të bëni kur kaloni nga AWS në Google Cloud është të ndryshoni emrin e Storage class në PVC në manifestet e aplikacionit. Volume i Përshtatshëm për ruajtjen e të dhënave do të krijohen automatikisht në klaster me ndihmën e programit Provisioner.
Metoda 3. Container Storage Interface
I gjithë kodi që interakton me sistemet e ndryshme të ruajtjes së të dhënave është pjesë e kernelit të Kubernetes. Lëshimi i korrigjimeve të defekteve ose funksionaliteteve të reja është i lidhur me lëshimet e reja; kodi duhet ndryshuar për të gjitha versionet e mbështetura të Kubernetes. E gjithë kjo është e vështirë për t'u mbajtur dhe për të shtuar funksionalitete të reja.
PĂ«r tĂ« zgjidhur problemin, zhvilluesit nga Cloud Foundry, Kubernetes, Mesos dhe Docker krijuan Container Storage Interface (CSI) â njĂ« ndĂ«rfaqe e thjeshtĂ« e standardizuar qĂ« pĂ«rshkruan ndĂ«rveprimin midis sistemit tĂ« menaxhimit tĂ« kontejnerĂ«ve dhe njĂ« drejtuesi tĂ« veçantĂ« (CSI Driver) qĂ« punon me njĂ« SHTD specifike. TĂ« gjithĂ« kodin pĂ«r ndĂ«rveprimin me SHTD e transferuan nga kernelit i Kubernetes nĂ« njĂ« sistem tĂ« veçantĂ«.
.
Në përgjithësi, CSI Driver përbëhet nga dy komponente: Node Plugin dhe Controller plugin.
Node Plugin niset çdo node dhe pĂ«rgjegjĂ«s pĂ«r montimin e volumeve dhe operacionet pĂ«rkatĂ«se mbi to. Controller plugin ndĂ«rvepron me SĐĐ: krijon ose fshin volume, cakton tĂ« drejtat e aksesit etj.
Ndërsa në kernelin e Kubernetes mbeten drejtues të vjetër, përdorimi i tyre nuk rekomandohet më dhe të gjithëve u sugjerohet të instalojnë CSI Driver specifikisht për sistemin me të cilin do të punojnë.
Kjo novatoritet mund tĂ« frikĂ«sojĂ« ata qĂ« janĂ« mĂ«suar tĂ« konfiguroni ruajtjen e tĂ« dhĂ«nave pĂ«rmes Storage class, por nĂ« tĂ« vĂ«rtetĂ«, nuk ka ndodhur asgjĂ« e tmerrshme. PĂ«r programuesit, asgjĂ« nuk ka ndryshuar â ata vazhdojnĂ« tĂ« punojnĂ« me emrin Storage class. PĂ«r administratorĂ«t, Ă«shtĂ« shtuar instalimi i helm chart dhe Ă«shtĂ« ndryshuar struktura e konfigurimeve. NĂ«se mĂ« parĂ« konfigurimet konsideroheshin drejtpĂ«rdrejt nĂ« Storage class, tani duhet fillimisht tĂ« definohen nĂ« helm chart dhe pastaj nĂ« Storage class. NĂ«se e shqyrtojmĂ« mirĂ«, nuk Ă«shtĂ« ndodhur asgjĂ« e tmerrshme.
Le tĂ« shqyrtojmĂ«, me njĂ« shembull, se çfarĂ« avantazhe mund tĂ« fitojmĂ« duke kaluar nĂ« lidhjen me SĐĐ Ceph pĂ«rmes CSI driver.
Duke punuar me Ceph, plugini CSI ofron mĂ« shumĂ« mundĂ«si pĂ«r tĂ« punuar me SĐĐ se sa drejtuesit e integruar.
- Krijimi dinamik i disqeve. Disket RBD zakonisht pĂ«rdoren vetĂ«m nĂ« modalitetin RWO, ndĂ«rsa CSI pĂ«r Ceph lejon pĂ«rdorimin e tyre nĂ« modalitetin RWX. Disa pod'e nĂ« nodĂ« tĂ« ndryshme mund tĂ« montojnĂ« tĂ« njĂ«jtin disk RDB nĂ« nodet e tyre dhe tĂ« punojnĂ« me to paralelisht. Nga ana tjetĂ«r, nuk Ă«shtĂ« gjithçka kaq e lehtĂ« â ky disk mund tĂ« lidhet vetĂ«m si njĂ« pajisje blloku, domethĂ«nĂ« do tĂ« duhet tĂ« adaptohet aplikacioni pĂ«r tĂ« punuar me tĂ« nĂ« modalitetin e qasjes sĂ« shumĂ«fishtĂ«.
- Krijimi i snapshoteve. Në klasterin Kubernetes, mund të krijoni një manifest me një kërkesë për të krijuar një snapshot. Plugini CSI do ta shohë atë dhe do të krijojë një snapshot nga disku. Në bazën e tij do të jetë e mundur të bëni ose një kopje rezervë, ose një kopje të PersistentVolume.
- Rritja e madhësisë së diskut në SAN dhe PersistentVolume në klasterin Kubernetes.
- Kota. Drejtorët e integruar në Kubernetes të CephFS nuk mbështesin kota, ndërsa pluginët e rinj CSI me Ceph Nautilus të freskët dinë të aktivizojnë kota në seksionet CephFS.
- Metrika. Plugin CSI mund të ofrojë në Prometheus një sasi të madhe metrikash në lidhje me cilat volume janë të lidhura, cilat janë ndërveprimet dhe të tjera.
- Të njohura për topologjinë. Lejon në manifestet si është gjeografikisht i shpërndarë klasteri, dhe evito lidhjen me pod-et që janë ndezur në Londër të sistemit të ruajtjes së të dhënave, të vendosur në Amsterdam.
Si të lidhni Ceph me klasterin Kubernetes përmes CSI, shihni . Po ashtu mund të abonoheni në , i cili do të fillojë më 15 tetor.
Autori i artikullit: Sergey Bondarev, arkitekt praktikues në Southbridge, Administrator i Certifikuar Kubernetes, një nga zhvilluesit e kubespray.
Pak Post Scriptum jo pĂ«r reklamĂ«, por pĂ«r dobiâŠ
P.S. Sergey Bondarev organizon dy intensive: e pĂ«rditĂ«suar 28-30 shtator dhe tĂ« avancuar 14â16 tetor.
Burimi: habr.com
