🥇 Ruajtja e të dhënave në klasterin Kubernetes

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.

Sistemet e ruajtjes së të dhënave, me të cilat Kubernetes punon nga kutia, 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ë.

Dokumentacioni mbi Container Storage Interface.

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 në pjesën praktike të leksionit të shkollës së mbrëmjes Slëurm. Po ashtu mund të abonoheni në kursin video Ceph, 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 Baza Kubernetes 28-30 shtator dhe të avancuar Kubernetes Mega 14–16 tetor.