Ka disa mënyra për të konfiguruar ruajtjen e të dhënave për aplikacionet që ekzekutohen në një grupim Kubernetes. Disa prej tyre tashmë janë të vjetëruara, të tjerët u shfaqën mjaft kohët e fundit. Në këtë artikull, ne do të shikojmë konceptin e tre opsioneve për lidhjen e sistemeve të ruajtjes, duke përfshirë atë më të fundit - lidhjen përmes Ndërfaqes së ruajtjes së kontejnerëve.
Metoda 1: Specifikoni PV në manifestin e pod
Një manifest tipik që përshkruan një pod në një grup Kubernetes:
Pjesët e manifestit që përshkruajnë se cili vëllim është i lidhur dhe ku janë të theksuara me ngjyra.
Në seksionin volumiMbledhjet tregoni pikat e montimit (mountPath) - në cilën direktori brenda kontejnerit do të montohet vëllimi i përhershëm, si dhe emri i vëllimit.
Në seksionin x liston të gjithë vëllimet që përdoren në pod. Specifikoni emrin e secilit vëllim, si dhe llojin (në rastin tonë: awsElasticBlockStore) dhe parametrat e lidhjes. Cilat parametra renditen në manifest varet nga lloji i volumit.
I njëjti vëllim mund të montohet njëkohësisht në kontejnerë të shumtë pod. Në këtë mënyrë, procese të ndryshme aplikimi mund të aksesojnë të njëjtat të dhëna.
Kjo metodë e lidhjes u shpik që në fillim, kur Kubernetes ishte vetëm në fillimet e saj, dhe sot metoda është e vjetëruar.
Ka disa probleme gjatë përdorimit:
- të gjitha vëllimet duhet të krijohen manualisht; Kubernetes nuk mund të krijojë asgjë për ne;
- parametrat e aksesit për secilin vëllim janë unikë dhe ato duhet të specifikohen në manifestet e të gjitha grupeve që përdorin volumin;
- për të ndryshuar sistemin e ruajtjes (për shembull, lëvizni nga AWS në Google Cloud), duhet të ndryshoni cilësimet dhe llojin e vëllimeve të montuara në të gjitha manifestet.
E gjithë kjo është shumë e papërshtatshme, kështu që në realitet kjo metodë përdoret për të lidhur vetëm disa lloje të veçanta vëllimesh: configMap, sekret, boshDir, hostPath:
-
configMap dhe sekret janë vëllime shërbimi që ju lejojnë të krijoni një vëllim me skedarë nga manifestet Kubernetes në kontejner.
-
valaDir është një vëllim i përkohshëm, i krijuar vetëm për jetëgjatësinë e pod. I përshtatshëm për t'u përdorur për testimin ose ruajtjen e të dhënave të përkohshme. Kur një pod fshihet, vëllimi i zbrazëtDir gjithashtu fshihet dhe të gjitha të dhënat humbasin.
-
hostPath - ju lejon të montoni çdo direktori në diskun lokal të serverit në të cilin aplikacioni po ekzekutohet brenda kontejnerit me aplikacionin, duke përfshirë /etc/kubernetes. Ky është një veçori e pasigurt, kështu që politikat e sigurisë zakonisht ndalojnë përdorimin e vëllimeve të këtij lloji. Përndryshe, aplikacioni i një sulmuesi do të jetë në gjendje të montojë direktoriumin HTC Kubernetes brenda kontejnerit të tij dhe të vjedhë të gjitha certifikatat e grupit. Në mënyrë tipike, vëllimet e hostPath lejohen të përdoren vetëm nga aplikacionet e sistemit që funksionojnë në hapësirën e emrave të sistemit kube.
jepen në dokumentacion.
Metoda 2. Lidhja me vatrat SC/PVC/PV
Një metodë alternative e lidhjes është koncepti i klasës Storage, PersistentVolumeClaim, PersistentVolume.
Klasa e ruajtjes ruan parametrat e lidhjes me sistemin e ruajtjes së të dhënave.
PersistentVëllimiKërkesë përshkruan kërkesat për atë që aplikacioni ka nevojë.
Vëllimi i vazhdueshëm ruan parametrat e aksesit dhe statusin e volumit.
Thelbi i idesë: në manifestin e pod ata tregojnë një vëllim të tipit PersistentVolumeClaim dhe tregojnë emrin e këtij entiteti në parametrin pretendimName.
Manifesti PersistentVolumeClaim përshkruan kërkesat për vëllimin e të dhënave që kërkon aplikacioni. Duke përfshirë:
- madhësia e diskut;
- metoda e hyrjes: ReadWriteOnce ose ReadWriteMany;
- lidhje me klasën Storage - në cilin sistem të ruajtjes së të dhënave duam të krijojmë vëllimin.
Manifesti i klasës Storage ruan llojin dhe parametrat e lidhjes me sistemin e ruajtjes. Kubeleti ka nevojë për ta për të montuar volumin në nyjen e tij.
Manifestet PersistentVolume tregojnë klasën e ruajtjes dhe parametrat e aksesit për një vëllim specifik (ID-ja e vëllimit, shtegu, etj.).
Kur krijon një PVC, Kubernetes shikon se çfarë madhësie vëllimi dhe çfarë klase Storage kërkohet, dhe zgjedh një Vëllim të vazhdueshëm të lirë.
Nëse PV të tilla nuk janë të disponueshme, Kubernetes mund të nisë një program të veçantë - Provisioner (emri i tij tregohet në klasën Storage). Ky program lidhet me sistemin e ruajtjes, krijon një vëllim të madhësisë së kërkuar, merr një identifikues dhe krijon një manifest të Përhershëm Volume në grupin Kubernetes, i cili shoqërohet me PersistentVolumeClaim.
I gjithë ky grup abstraksionesh ju lejon të hiqni informacionin se me cilin sistem ruajtjeje po punon aplikacioni nga niveli i manifestit të aplikacionit në nivelin e administrimit.
Të gjithë parametrat për lidhjen me sistemin e ruajtjes së të dhënave ndodhen në klasën Storage, për të cilën janë përgjegjës administratorët e grupimeve. Gjithçka që duhet të bëni kur lëvizni nga AWS në Google Cloud është të ndryshoni emrin e klasës Storage në PVC në manifestet e aplikacionit. Vëllimi i qëndrueshmërisë për ruajtjen e të dhënave do të krijohet në grup automatikisht duke përdorur programin Provisioner.
Metoda 3: Ndërfaqja e ruajtjes së kontejnerit
I gjithë kodi që ndërvepron me sisteme të ndryshme ruajtjeje është pjesë e bërthamës së Kubernetes. Lëshimi i rregullimeve të gabimeve ose funksionaliteti i ri është i lidhur me publikimet e reja; kodi duhet të ndryshohet për të gjitha versionet e mbështetura të Kubernetes. E gjithë kjo është e vështirë të ruhet dhe të shtohet funksionalitet i ri.
Për të zgjidhur problemin, zhvilluesit nga Cloud Foundry, Kubernetes, Mesos dhe Docker krijuan Ndërfaqen e ruajtjes së kontejnerëve (CSI) - një ndërfaqe e thjeshtë e unifikuar që përshkruan ndërveprimin e sistemit të menaxhimit të kontejnerëve dhe një drejtues të veçantë (CSI Driver) që funksionon me një specifikë. sistemi i ruajtjes. I gjithë kodi për ndërveprimin me sistemet e ruajtjes u zhvendos nga thelbi Kubernetes në një sistem të veçantë.
.
Në mënyrë tipike, CSI Driver përbëhet nga dy komponentë: Node Plugin dhe Controller plugin.
Node Plugin funksionon në çdo nyje dhe është përgjegjës për montimin e vëllimeve dhe kryerjen e operacioneve mbi to. Shtojca Controller ndërvepron me sistemin e ruajtjes: krijon ose fshin vëllime, cakton të drejta aksesi, etj.
Tani për tani, drejtuesit e vjetër mbeten në kernelin Kubernetes, por ata nuk rekomandohen më për t'u përdorur dhe të gjithë këshillohen të instalojnë Driver CSI posaçërisht për sistemin me të cilin do të punojnë.
Inovacioni mund të trembë ata që tashmë janë mësuar të konfigurojnë ruajtjen e të dhënave përmes klasës Storage, por në fakt asgjë e tmerrshme nuk ka ndodhur. Për programuesit, asgjë nuk ndryshon vërtet - ata kanë punuar vetëm me emrin Storage class dhe do të vazhdojnë ta bëjnë këtë. Për administratorët, instalimi i grafikut të timonit është shtuar dhe struktura e cilësimeve ka ndryshuar. Nëse më parë cilësimet futeshin direkt në klasën Storage, tani ato fillimisht duhet të vendosen në tabelën e drejtimit dhe më pas në klasën Storage. Nëse e shikoni, asgjë e keqe nuk ka ndodhur.
Le të marrim një shembull për të parë përfitimet që mund të merrni duke kaluar në lidhjen e sistemeve të ruajtjes Ceph duke përdorur drejtuesin CSI.
Kur punoni me Ceph, shtojca CSI ofron më shumë mundësi për të punuar me sistemet e ruajtjes sesa drejtuesit e integruar.
- Krijimi dinamik i diskut. Zakonisht disqet RBD përdoren vetëm në modalitetin RWO, por CSI për Ceph i lejon ato të përdoren në modalitetin RWX. Disa pods në nyje të ndryshme mund të montojnë të njëjtin disk RDB në nyjet e tyre dhe të punojnë me to paralelisht. Për të qenë të drejtë, jo gjithçka është aq e ndritshme - ky disk mund të lidhet vetëm si një pajisje bllok, që do të thotë se do të duhet të përshtatni aplikacionin për të punuar me të në modalitetin e aksesit të shumëfishtë.
- Krijimi i fotografive. Në një grup Kubernetes, mund të krijoni një manifest me kërkesën për të krijuar një fotografi. Shtojca CSI do ta shohë atë dhe do të marrë një fotografi nga disku. Bazuar në të, mund të bëni ose një kopje rezervë ose një kopje të PersistentVolume.
- Rritja e madhësisë së diskut mbi ruajtjen dhe Vëllimin e Përhershëm në grupin Kubernetes.
- Kuotat. Drejtuesit e CephFS të integruara në Kubernetes nuk mbështesin kuotat, por shtojcat e reja CSI me Ceph Nautilus-in më të fundit mund të mundësojnë kuota në ndarjet CephFS.
- Metrikë. Shtojca CSI mund t'i sigurojë Prometheus një larmi metrikash se cilat vëllime janë të lidhura, çfarë komunikimesh po ndodhin, etj.
- I vetëdijshëm për topologjinë. Ju lejon të specifikoni në manifeste se si grupi shpërndahet gjeografikisht dhe të shmangni lidhjen e një sistemi ruajtjeje të vendosur në Amsterdam me podat që funksionojnë në Londër.
Si të lidhni Ceph me një grup Kubernetes përmes CSI, shihni . Ju gjithashtu mund të abonoheni në , i cili do të nisë më 15 tetor.
Autori i artikullit: Sergey Bondarev, arkitekt praktik në Southbridge, Administrator i Certifikuar i Kubernetes, një nga zhvilluesit e kubespray.
Pak Post Scriptum jo për reklamim, por për përfitim...
PS Sergej Bondarev drejton dy kurse intensive: të përditësuara 28-30 shtator dhe avancuar 14–16 tetor.
Burimi: www.habr.com