Konfigurimi i ruajtjes së të dhënave për aplikacionet që janë ekzekutuar në klasterin Kubernetes mund të bëhet në disa mënyra. Disa prej tyre janë të vjetra, të tjera janë shfaqur recently. Në këtë artikull do të shqyrtojmë konceptin e tre mundësive për lidhjen e ruajtjes, duke përfshirë më të fundit - lidhjen përmes Container Storage Interface.
Metoda 1. Caktimi i PV në manifestin e pod-it
Një manifest tipik, i cili përshkruan një pod në klasterin Kubernetes:
Me ngjyrë janë theksuar pjesët e manifestit ku përshkruhet se cili volume lidhet dhe ku.
Në seksionin volumeMounts përcaktojnë pikat e montimit (mountPath) - në cilin katalog brenda kontejnerit do të montohet volumi i qëndrueshëm, si dhe emri i volumit.
NĂ« seksionin x listojnĂ« tĂ« gjitha volumet qĂ« pĂ«rdoren nĂ« pod. PĂ«rcaktojnĂ« emrin e çdo volumi, si dhe tipin (nĂ« rastin tonĂ«: awsElasticBlockStore) dhe parametrat e lidhjes. ĂfarĂ«do parametrash specifikohen nĂ« manifest, varet nga tipi i volumit.
I njëjti volum mund të montohet njëkohësisht në disa kontejnerë të pod-it. kështu që procese të ndryshme të aplikacionit mund të aksesojnë të njëjtat të dhëna.
Kjo metodë lidhjeje u shpik në fillim, kur Kubernetes sapo kishte nisur, dhe sot është e vjetruar.
Kur përdoret ajo gjeneron disa probleme:
- të gjithë volumet duhet të krijohen manualisht, Kubernetes nuk do të mund të krijojë asgjë për ne;
- parametrat e aksesit për çdo volum janë unikë dhe duhet të specifikohen në manifestet e të gjitha pod-eve që përdorin volumët;
- për të ndryshuar sistemin e ruajtjes (për shembull, për të kaluar nga AWS në Google Cloud), duhet të ndryshoni konfigurimet dhe tipin e volumëve të lidhura në të gjithë manifestet.
Të gjitha këto janë shumë të pakëndshme, prandaj në realitet, kështu përdoret për të lidhur vetëm disa tipa specifikë volumesh: configMap, secret, emptyDir, hostPath:
configMap dhe secret - janë volumet shërbyese, lejojnë krijimin e një volumi në konteiner me skedarë nga manifestet e Kubernetes.
emptyDir - Ă«shtĂ« njĂ« volum pĂ«rkohĂ«sor, krijohet vetĂ«m pĂ«r kohĂ«n e jetĂ«s sĂ« pod-it. ĂshtĂ« e dobishme pĂ«r testimin ose pĂ«r ruajtjen e tĂ« dhĂ«nave pĂ«rkohĂ«sore. Kur podi fshihet, volumi i tipit emptyDir gjithashtu fshihet dhe tĂ« gjitha tĂ« dhĂ«nat humbasin.
hostPath â le ĐżĐŸĐ·ĐČĐŸĐ»ŃĐ”Ń tĂ« lidhni brenda konteinerit tĂ« aplikacionit çdo katalog tĂ« diskut lokal tĂ« serverit ku po funksionon aplikacioni, pĂ«rfshirĂ« /etc/kubernetes. Kjo Ă«shtĂ« njĂ« mundĂ«si e pasigurt, prandaj zakonisht politikave tĂ« sigurisĂ« u ndalohet tĂ« pĂ«rdorin volume tĂ« kĂ«tij lloji. PĂ«rndryshe, aplikacioni i njĂ« sulmuesi mund tĂ« lidhet brenda konteinerit tĂ« tij me katalogun HTC Kubernetes dhe tĂ« vjedhĂ« tĂ« gjitha certifikatat e klasterit. Zakonisht, volume tĂ« hostPath lejohen tĂ« pĂ«rdoren vetĂ«m nga aplikacionet sistemore qĂ« ekzekutohen nĂ« hapĂ«sirĂ«n kube-system.
janë përmendur në dokumentacion.
MĂ«nyra 2. Konektimi me pods SC/PVC/PV
Një mënyrë alternative e lidhjes është 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ë nevojiten nga aplikacioni.
PersistentVolume ruan parametrat e qasjes dhe statusin e volumit.
Krahasimi kryesor: në manifestin e podit shënohet volume tipi PersistentVolumeClaim dhe emri i këtij entiteti në parametrin claimName.
Në manifestin e PersistentVolumeClaim përshkruhen kërkesat për volumet e të dhënave që nevojiten nga aplikacioni. Përfshihet:
- mënyra e qasjes: ReadWriteOnce ose ReadWriteMany;
- referenca nĂ« Storage class â nĂ« cilin sistem ruajtjeje duam tĂ« krijojmĂ« volum.
- Në manifestin e Storage class ruhen lloji dhe parametrat e lidhjes me sistemin e ruajtjes së të dhënave. Këto nevojiten për kubeletin që të lidhet me volum në nodin e tij.
Në manifestet e PersistentVolume shënohet Storage class dhe parametrat e qasjes në volumet specifike (ID e volumit, rruga, etj.).
Duke krijuar PVC, Kubernetes sheh se çfarë forme dhe se cilin Storage class do të nevojitet, dhe zgjidh një PersistentVolume të lirë.
NĂ«se nuk ka PV tĂ« tillĂ« nĂ« dispozicion, Kubernetes mund tĂ« aktivizojĂ« njĂ« program special â Provisioner (emri i saj shĂ«nohet nĂ« Storage class). Ky program lidhet me SHT, krijon volum tĂ« nevojshmĂ« tĂ« madhĂ«sisĂ« sĂ« duhur, merr identifikuesin dhe krijon nĂ« klasterin e Kubernetes manifestin PersistentVolume, i cili lidhet me PersistentVolumeClaim.
Kjo shumëllojshmëri abstraksionesh lejon që informatat rreth sistemit me të cilin punon aplikacioni, të hiqen nga niveli i manifestit të aplikacioneve në nivelin e administratës.
Të gjitha këto abstraksione lejojnë që informacioni mbi sistemin e ruajtjes me të cilin punon aplikacioni të hiqet nga niveli i manifestimit të aplikacioneve dhe të kalojë në nivelin e administratës.
Të gjitha parametrat e lidhjes me sistemin e ruajtjes së të dhënave ndodhen në Storage class, për të cilin kujdesen administratorët e klashtër. 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 qëndrueshëm për ruajtjen e të dhënave do të krijohet automatikisht në klashtër, me anë të programit Provisioner.
Metoda 3. Container Storage Interface
I gjithë kodi që ndërvepron me sistemet e ndryshme të ruajtjes së të dhënave është pjesë eKernelit Kubernetes. Lëshimi i korrigjimeve të defekteve ose funksionaliteteve të reja është i lidhur me lëshimet e reja, dhe kodi duhet të ndryshohet për të gjitha versionet e mbështetura të Kubernetes. E gjithë kjo është e vështirë për t'u mbajtur dhe 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 unifikuar qĂ« pĂ«rshkruan ndĂ«rveprimin midis sistemit tĂ« menaxhimit tĂ« kontejnerĂ«ve dhe njĂ« shoferi tĂ« veçantĂ« (CSI Driver) qĂ« punon me SHT. I gjithĂ« kodi pĂ«r ndĂ«rveprimin me SHT u transferua nga Kernel Kubernetes nĂ« njĂ« sistem tĂ« veçantĂ«.
.
Si rregull, CSI Driver përbëhet nga dy komponente: Node Plugin dhe Controller plugin.
Node Plugin ekzekutohet në çdo nod dhe kujdeset për montimin e volumeve dhe për operacionet në to. Controller plugin ndërvepron me SHT: krijon ose fshin volumin, cakton të drejtat e aksesit etj.
Për sa kohë që drejtuesit e vjetër mbeten në Kernel Kubernetes, nuk rekomandohet që t'i përdorni ata dhe të gjithë këshillohet që të instaloni CSI Driver specifik për sistemin me të cilin do të punoni.
Kjo novacion mund tĂ« shqetĂ«sojĂ« ata qĂ« tashmĂ« janĂ« mĂ«suar tĂ« konfigurojnĂ« ruajtjen e tĂ« dhĂ«nave pĂ«rmes Storage class, por nĂ« tĂ« vĂ«rtetĂ« nuk ka ndodhur asgjĂ« shqetĂ«suese. PĂ«r programuesit, asgjĂ« nuk ndryshon â ata do tĂ« vazhdojnĂ« tĂ« punojnĂ« vetĂ«m me emrin e Storage class. PĂ«r administratorĂ«t, Ă«shtĂ« shtuar instalimi i helm chart dhe Ă«shtĂ« ndryshuar struktura e konfigurimeve. NĂ«se mĂ« parĂ« konfigurimet futeshin drejtpĂ«rdrejt nĂ« Storage class, tani fillimisht duhet t'i caktoni ato nĂ« helm chart dhe pastaj nĂ« Storage class. NĂ«se e shqyrtoni nĂ« thellĂ«si, nuk ka ndodhur asgjĂ« shqetĂ«suese.
Le të shqyrtojmë, me një shembull, se cilat përfitime mund të kemi duke kaluar në lidhjen e SHT Ceph me anë të shoferit CSI.
Duke punuar me Ceph, plugin CSI ofron më shumë mundësi për punën me SHT, sesa drejtuesit e ndërtuar.
- Krijimi dinamik i disqeve. Disket RBD zakonisht pĂ«rdoren vetĂ«m nĂ« modin RWO, ndĂ«rsa CSI pĂ«r Ceph lejon qĂ« ato tĂ« pĂ«rdoren nĂ« modin RWX. Disa podĂ« nĂ« nodo tĂ« ndryshme mund tĂ« montojnĂ« tĂ« njĂ«jtin disk RDB dhe tĂ« punojnĂ« me tĂ« paralel. PĂ«r tĂ« qenĂ« tĂ« drejtĂ«, gjĂ«rat nuk janĂ« aq tĂ« lehtaâky disk mund tĂ« lidhet vetĂ«m si njĂ« pajisje bllok, qĂ« do tĂ« thotĂ« se duhet tĂ« adaptohet aplikacioni pĂ«r t'u pĂ«rdorur me tĂ« nĂ« modin e aksesit tĂ« shumĂ«fishtĂ«.
- Krijimi i snapshoteve. Në klasterin Kubernetes, mund të krijoni një manifest me kërkesën për të krijuar një snapshot. Plugin CSI do ta shohë atë dhe do të krijojë një snapshot nga disku. Në bazë të tij mund të bëni ose një rezervë, ose një kopje të PersistentVolume.
- Rritja e madhësisë së disks. në SXYD dhe PersistentVolume në klasterin Kubernetes.
- Kota. Drejtorët e integruar në Kubernetes për CephFS nuk mbështesin kota, ndërsa pluginat e rinj CSI me Ceph Nautilus të rinj mund të aktivizojnë kota në ndarjet CephFS.
- Metrika. Plugin CSI mund të japë në Prometheus shumë metrika për sa i përket volumet të lidhura, ndërveprimeve etj.
- Topologjia e vetëdijes. Lejon që të specifikohet në manifestet si është shpërndarë gjeografikisht klasteri dhe të shmangen lidhjet me podët që aktivizohen 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 . Mund të abonoheni gjithashtu në , që do të startojë më 15 tetor.
Autor i artikullit: Sergey Bondarev, arkitekt praktikant në Southbridge, Administrator i Certifikuar Kubernetes, një nga zhvilluesit e kubespray.
Pak Post Scriptum jo reklame, por pĂ«rdoresiâŠ
P.S. Sergey Bondarev drejton dy intensive: tĂ« rinovuarin 28-30 shtator dhe nivelin e avancuar 14â16 tetor.
Burimi: habr.com
