Hainbat modu daude Kubernetes kluster batean exekutatzen diren aplikazioetarako datu biltegiratzea konfiguratzeko. Horietako batzuk zaharkituta daude jada, beste batzuk duela gutxi agertu dira. Artikulu honetan, biltegiratze-sistemak konektatzeko hiru aukeren kontzeptua aztertuko dugu, azkena barne: edukiontzi biltegiratze-interfazearen bidez konektatzea.
1. metodoa: zehaztu PV pod manifestean
Kubernetes kluster bateko pod bat deskribatzen duen manifest tipiko bat:
Manifestuaren zatiak zein bolumen konektatuta dagoen eta non deskribatzen duten kolorez nabarmentzen dira.
Atalean bolumenaMuntaketak adierazi muntatze-puntuak (mountPath) - edukiontzi barruan zein direktoriotan muntatuko den bolumen iraunkorra, baita bolumenaren izena ere.
Atalean x ontzian erabiltzen diren bolumen guztiak zerrendatzen ditu. Zehaztu bolumen bakoitzaren izena, baita mota (gure kasuan: awsElasticBlockStore) eta konexio-parametroak ere. Manifestuan zerrendatzen diren parametroak bolumen motaren araberakoak dira.
Bolumen bera aldi berean munta daiteke hainbat ontzi ontzietan. Horrela, aplikazio-prozesu ezberdinek datu berdinetara sar daitezke.
Konexio-metodo hau hasiera-hasieran asmatu zen, Kubernetes hastapenetan zegoenean, eta gaur egun metodoa zaharkituta dago.
Hainbat arazo daude erabiltzean:
- bolumen guztiak eskuz sortu behar dira;Kubernetes-ek ezin digu ezer sortu;
- bolumen bakoitzeko sarbide-parametroak bakarrak dira, eta bolumena erabiltzen duten pod guztien manifestuetan zehaztu behar dira;
- biltegiratze sistema aldatzeko (adibidez, AWStik Google Cloud-era pasatzeko), ezarpenak eta muntatutako bolumen mota aldatu behar dituzu manifestu guztietan.
Hori guztia oso deserosoa da, beraz, errealitatean metodo hau bolumen mota berezi batzuk soilik konektatzeko erabiltzen da: configMap, secret, emptyDir, hostPath:
-
configMap eta secret edukiontzian Kubernetes manifestuetako fitxategiekin bolumen bat sortzeko aukera ematen duten zerbitzu-bolumenak dira.
-
emptyDir aldi baterako bolumena da, podaren bizitzarako soilik sortua. Erosoa probatzeko edo aldi baterako datuak gordetzeko erabiltzeko. Pod bat ezabatzen denean, emptyDir bolumena ere ezabatzen da eta datu guztiak galtzen dira.
-
hostPath - aplikazioa exekutatzen ari den zerbitzariaren disko lokalean edozein direktorio muntatzeko aukera ematen du aplikazioarekin edukiontzi barruan, /etc/kubernetes barne. Ezaugarri segurua da hau, beraz, segurtasun-politikek normalean mota honetako bolumenak erabiltzea debekatzen dute. Bestela, erasotzaile baten aplikazioak HTC Kubernetes direktorioa bere edukiontzi barruan muntatu eta kluster ziurtagiri guztiak lapurtu ahal izango ditu. Normalean, hostPath bolumenak kube-system izen-espazioan exekutatzen diren sistema-aplikazioek soilik erabil ditzakete.
dokumentazioan ematen dira.
2. metodoa. SC/PVC/PV sutegietara konektatzea
Konexio-metodo alternatibo bat Storage klasearen kontzeptua da, PersistentVolumeClaim, PersistentVolume.
Biltegiratze klasea datuak biltegiratzeko sistemarako konexio-parametroak gordetzen ditu.
PersistentVolumeClaim aplikazioak behar dituen baldintzak deskribatzen ditu.
Bolumen iraunkorra sarbide-parametroak eta bolumen-egoera gordetzen ditu.
Ideiaren funtsa: pod manifestean PersistentVolumeClaim motako bolumena adierazten dute eta entitate honen izena claimName parametroan adierazten dute.
PersistentVolumeClaim manifestuak aplikazioak behar duen datu-bolumenaren baldintzak deskribatzen ditu. Barne:
- diskoaren tamaina;
- sarbide-metodoa: ReadWriteOnce edo ReadWriteMany;
- esteka Biltegiratze klasera - zein datu biltegiratze sistematan sortu nahi dugun bolumena.
Biltegiratze klasearen manifestuak biltegiratze sistemarako konexio mota eta parametroak gordetzen ditu. Kubeletak bolumena bere nodoan muntatzeko behar ditu.
PersistentVolume manifestek Bolumen jakin baterako Biltegiratze-klasea eta sarbide-parametroak adierazten dituzte (bolumenaren IDa, bidea, etab.).
PVC bat sortzean, Kubernetes-ek zer tamainako bolumena eta zer Biltegiratze-klase behar diren aztertzen du, eta doako PersistentVolume bat hautatzen du.
PV horiek erabilgarri ez badira, Kubernetes-ek programa berezi bat abiarazi dezake - Hornitzailea (bere izena Biltegiratze klasean adierazten da). Programa hau biltegiratze sistemara konektatzen da, behar den tamainako bolumena sortzen du, identifikatzaile bat jasotzen du eta PersistentVolume manifestua sortzen du Kubernetes klusterrean, PersistentVolumeClaim-ekin lotuta dagoena.
Abstrakzio multzo honek guztiak aplikazioak zein biltegiratze sistemarekin lan egiten duen informazioa kentzeko aukera ematen du aplikazioaren manifestu mailatik administrazio mailara.
Datuak biltegiratzeko sistemara konektatzeko parametro guztiak Biltegiratze klasean daude, eta kluster-administratzaileak arduratzen dira. AWS-tik Google Cloud-era pasatzean egin behar duzun guztia aplikazioaren manifestuetan Storage klasearen izena PVC-era aldatzea da. Iraupena Datuak biltegiratzeko bolumena automatikoki sortuko da klusterrean Provisioner programa erabiliz.
3. metodoa: Ontziak biltegiratzeko interfazea
Hainbat biltegiratze-sistemekin elkarreragiten duen kode guztia Kubernetesen nukleoaren parte da. Akatsen konponketak edo funtzionalitate berriak kaleratzea bertsio berriekin lotuta dago; kodea aldatu behar da Kubernetes-en onartzen diren bertsio guztietan. Hori guztia zaila da mantentzea eta funtzionalitate berriak gehitzea.
Arazoa konpontzeko, Cloud Foundry, Kubernetes, Mesos eta Docker-eko garatzaileek Container Storage Interface (CSI) sortu zuten: edukiontzien kudeaketa sistemaren interakzioa eta kontrolatzaile berezi batekin (CSI Driver) funtzionatzen duen interfaze bateratu sinplea. biltegiratze sistema. Biltegiratze-sistemekin elkarreragiteko kode guztia Kubernetesen nukleotik aparteko sistema batera eraman zen.
.
Normalean, CSI Driver-ek bi osagai ditu: Node Plugin eta Controller plugina.
Node Plugin nodo bakoitzean exekutatzen da eta bolumenak muntatzeaz eta horietan eragiketak egiteaz arduratzen da. Controller pluginak biltegiratze sistemarekin elkarreragiten du: bolumenak sortu edo ezabatzen ditu, sarbide-eskubideak esleitzen ditu, etab.
Oraingoz, kontrolatzaile zaharrak Kubernetesen nukleoan jarraitzen dute, baina jada ez dira erabiltzea gomendatzen eta guztiei CSI Driver-a instalatzea gomendatzen zaie berariaz lan egingo duten sistemarako.
Berrikuntzak ikaratu egin ditzake Biltegiratze klasearen bidez datu biltegiratzea konfiguratzera ohituta daudenak, baina egia esan ez da ezer ikaragarririk gertatu. Programatzaileentzat, ez da ezer aldatzen - Biltegiratze klase izenarekin bakarrik lan egin dute, eta horrela jarraituko dute. Administratzaileentzat, lema-diagramaren instalazioa gehitu da eta ezarpenen egitura aldatu da. Lehen ezarpenak zuzenean Biltegiratze klasean sartzen baziren, orain lehenik lema-taulan ezarri behar dira, eta gero Biltegiratze klasean. Begiratzen baduzu, ez da ezer txarrik gertatu.
Har dezagun adibide bat CSI kontrolatzailea erabiliz Ceph biltegiratze sistemak konektatuz lor ditzakezun onurak aztertzeko.
Ceph-ekin lan egiten duzunean, CSI pluginak biltegiratze-sistemekin lan egiteko aukera gehiago eskaintzen ditu integratutako kontrolatzaileak baino.
- Disko dinamikoa sortzea. Normalean RBD diskoak RWO moduan bakarrik erabiltzen dira, baina CSI for Ceph-ek RWX moduan erabiltzeko aukera ematen du. Nodo desberdinetako hainbat podek RDB disko bera munta dezakete beren nodoetan eta haiekin paraleloan lan egin dezakete. Bidezkoa izateko, dena ez da hain distiratsua - disko hau bloke-gailu gisa soilik konekta daiteke, hau da, aplikazioa egokitu beharko duzu sarbide anitzeko moduan lan egiteko.
- Argazkiak sortzea. Kubernetes kluster batean, manifestua sor dezakezu argazki bat sortzeko eskakizunarekin. CSI pluginak ikusiko du eta diskotik argazki bat aterako du. Bertan oinarrituta, PersistentVolume-ren babeskopia edo kopia bat egin dezakezu.
- Diskoaren tamaina handitzea biltegian eta PersistentVolume Kubernetes klusterrean.
- Kuotak. Kubernetes-en integratutako CephFS kontrolatzaileek ez dituzte kuotak onartzen, baina Ceph Nautilus-eko azken Ceph Nautilus duten CSI plugin berriek kuotak gaitu ditzakete CephFS partizioetan.
- Metrikak. CSI pluginak Prometheus-i hainbat neurketa eman diezazkioke zein bolumen konektatuta dauden, zer komunikazio egiten ari diren, etab.
- Topologia jakitun. Manifestuetan klusterra geografikoki nola banatuta dagoen zehazteko eta Amsterdamen kokatutako biltegiratze sistema bat Londresen exekutatzen diren podekin konektatzea saihestu dezakezu.
Nola konektatu Ceph Kubernetes kluster batera CSI bidez, ikus . Harpidetza ere egin dezakezu , urriaren 15ean martxan jarriko dena.
Artikuluaren egilea: Sergey Bondarev, Southbridge-ko arkitekto praktikatzailea, Kubernetes Administratzaile Ziurtagiria, kubesprayren garatzaileetako bat.
Post Scriptum apur bat ez publizitaterako, onurarako baizik...
PS Sergey Bondarev-ek bi ikastaro trinko zuzentzen ditu: eguneratua Irailaren 28tik 30era eta aurreratua Urriaren 14tik 16ra.
Iturria: www.habr.com