Kubernetese klastris töötavate rakenduste andmesalvestuse konfigureerimiseks on mitu võimalust. Mõned neist on juba aegunud, teised ilmusid üsna hiljuti. Selles artiklis vaatleme kolme salvestussüsteemide ühendamise võimaluse kontseptsiooni, sealhulgas viimast – ühendamist konteineri salvestusliidese kaudu.
1. meetod: määrake PV podmanifestis
Tüüpiline manifest, mis kirjeldab Kubernetese klastris olevat kauna:
Manifesti osad, mis kirjeldavad, milline köide on ühendatud ja kus, on värviliselt esile tõstetud.
Jaotises mahtMounts märkige ühenduspunktid (mountPath) - millisesse konteineri sees olevasse kataloogi püsiköide ühendatakse, samuti köite nimi.
Jaotises x loetleb kõik kaustas kasutatavad köited. Määrake iga köite nimi, tüüp (meie puhul: awsElasticBlockStore) ja ühenduse parameetrid. Millised parameetrid manifestis on loetletud, sõltuvad köite tüübist.
Sama mahu saab paigaldada samaaegselt mitmesse kaunamahutisse. Nii pääsevad samadele andmetele juurde erinevad rakendusprotsessid.
See ühendamisviis leiutati päris alguses, kui Kubernetes oli alles lapsekingades, ja tänapäeval on see meetod aegunud.
Selle kasutamisel on mitmeid probleeme:
- kõik köited tuleb luua käsitsi; Kubernetes ei saa meie jaoks midagi luua;
- iga köite juurdepääsuparameetrid on kordumatud ja need tuleb täpsustada kõigi helitugevust kasutavate kaustade manifestides;
- salvestussüsteemi muutmiseks (näiteks AWS-ist Google Cloudi kolimiseks) peate muutma kõigis manifestides sätteid ja ühendatud köidete tüüpi.
Kõik see on väga ebamugav, nii et tegelikult kasutatakse seda meetodit ainult teatud tüüpi köite ühendamiseks: configMap, secret, emptyDir, hostPath:
-
configMap ja secret on teenusemahud, mis võimaldavad teil luua mahuti Kubernetese manifestide failidega köite.
-
emptyDir on ajutine köide, mis on loodud ainult podi eluea jooksul. Mugav kasutada ajutiste andmete testimiseks või salvestamiseks. Kui kausta kustutatakse, kustutatakse ka tühjad kaustad ja kõik andmed lähevad kaotsi.
-
hostPath – võimaldab ühendada mis tahes kataloogi selle serveri kohalikule kettale, millel rakendus töötab, rakendusega konteinerisse, sealhulgas /etc/kubernetes. See on ebaturvaline funktsioon, mistõttu turbepoliitikad keelavad tavaliselt seda tüüpi köidete kasutamise. Vastasel juhul saab ründaja rakendus ühendada HTC Kubernetesi kataloogi oma konteinerisse ja varastada kõik klastri sertifikaadid. Tavaliselt lubatakse hostPathi köiteid kasutada ainult süsteemirakendustel, mis töötavad kube-süsteemi nimeruumis.
on toodud dokumentatsioonis.
Meetod 2. Ühendus SC/PVC/PV koldega
Alternatiivne ühendusmeetod on Storage class, PersistentVolumeClaim, PersistentVolume kontseptsioon.
Ladustamisklass salvestab andmesalvestussüsteemi ühenduse parameetrid.
Püsiv maht Nõue kirjeldab nõudeid, mida rakendus vajab.
Püsiv maht salvestab juurdepääsu parameetrid ja helitugevuse oleku.
Idee olemus: podmanifestis näitavad nad PersistentVolumeClaim tüüpi köidet ja näitavad selle olemi nime parameetris requestName.
Manifest PersistentVolumeClaim kirjeldab nõudeid andmemahule, mida rakendus nõuab. Kaasa arvatud:
- ketta suurus;
- juurdepääsumeetod: ReadWriteOnce või ReadWriteMany;
- link Storage class - millisesse andmesalvestussüsteemi tahame köite luua.
Salvestusklassi manifest salvestab salvestussüsteemiga ühenduse tüübi ja parameetrid. Kuubik vajab neid helitugevuse paigaldamiseks oma sõlme.
PersistentVolume'i manifestid näitavad konkreetse köite salvestusklassi ja juurdepääsu parameetreid (köite ID, tee jne).
PVC loomisel vaatab Kubernetes, mis mahus ja mis salvestusklassi on vaja, ning valib tasuta püsiva helitugevuse.
Kui sellised PV-d pole saadaval, saab Kubernetes käivitada spetsiaalse programmi - Provisioner (selle nimi on märgitud salvestusklassis). See programm loob ühenduse salvestussüsteemiga, loob vajaliku suurusega köite, saab identifikaatori ja loob Kubernetese klastris PersistentVolumeClaimiga seotud manifesti PersistentVolume.
Kõik need abstraktsioonid võimaldavad teil eemaldada teavet selle kohta, millise salvestussüsteemiga rakendus töötab, alates rakenduse manifesti tasemelt kuni haldustasemeni.
Kõik andmesalvestussüsteemiga ühenduse loomise parameetrid asuvad Storage klassis, mille eest vastutavad klastri administraatorid. AWS-ist Google Cloudi üleminekul pole vaja muud teha, kui muuta rakenduse manifestides salvestusklassi nimi PVC-ks. Püsivusmaht andmete salvestamiseks luuakse klastris automaatselt, kasutades programmi Provisioner.
3. meetod: konteineri salvestusliides
Kogu kood, mis suhtleb erinevate salvestussüsteemidega, on osa Kubernetese tuumast. Veaparanduste või uute funktsioonide väljaandmine on seotud uute väljalasetega; kõigi Kubernetese toetatud versioonide koodi tuleb muuta. Seda kõike on keeruline hooldada ja uusi funktsioone lisada.
Probleemi lahendamiseks lõid arendajad ettevõtetest Cloud Foundry, Kubernetes, Mesos ja Docker Container Storage Interface (CSI) – lihtsa ühtse liidese, mis kirjeldab konteinerihaldussüsteemi ja spetsiaalse draiveri (CSI draiveri) koostoimet, mis töötab konkreetse konkreetsega. salvestussüsteem. Kogu salvestussüsteemidega suhtlemise kood viidi Kubernetese tuumast eraldi süsteemi.
.
Tavaliselt koosneb CSI draiver kahest komponendist: Node Plugin ja Controller plugin.
Node Plugin töötab igas sõlmes ja vastutab mahtude paigaldamise ja nendega toimingute tegemise eest. Controlleri pistikprogramm suhtleb salvestussüsteemiga: loob või kustutab köiteid, määrab juurdepääsuõigused jne.
Praegu jäävad vanad draiverid Kubernetese tuumasse, kuid neid ei soovitata enam kasutada ja kõigil soovitatakse installida CSI draiver spetsiaalselt selle süsteemi jaoks, millega nad töötavad.
Uuendus võib ehmatada neid, kes on juba harjunud andmesalvestust läbi Storage klassi seadistama, kuid tegelikult pole midagi hirmsat juhtunud. Programmeerijate jaoks ei muutu tegelikult midagi – nad on töötanud ainult nimega Storage class ja teevad seda ka edaspidi. Administraatorite jaoks on lisatud tüürikaardi installimine ja muudetud seadistuste struktuuri. Kui varem sisestati sätted otse salvestusklassi, siis nüüd tuleb need esmalt määrata tüürikaardis ja seejärel salvestusklassis. Kui vaadata, siis midagi hullu ei juhtunud.
Toome näite, et vaadata eeliseid, mida saate Cephi salvestussüsteemide ühendamisel CSI draiveri abil.
Cephiga töötamisel pakub CSI-plugin salvestussüsteemidega töötamiseks rohkem võimalusi kui sisseehitatud draiverid.
- Dünaamiline ketta loomine. Tavaliselt kasutatakse RBD-kettaid ainult RWO-režiimis, kuid CSI for Ceph võimaldab neid kasutada RWX-režiimis. Mitmed erinevatel sõlmedel olevad kaustad võivad oma sõlmedesse ühendada sama RDB-ketta ja töötada nendega paralleelselt. Ausalt öeldes pole kõik nii särav - seda ketast saab ühendada ainult plokkseadmena, mis tähendab, et peate rakenduse kohandama, et sellega mitme juurdepääsu režiimis töötada.
- Piltide loomine. Kubernetese klastris saate luua manifesti koos hetktõmmise loomise nõudega. CSI pistikprogramm näeb seda ja teeb kettalt hetktõmmise. Selle põhjal saate teha PersistentVolume'ist kas varukoopia või koopia.
- Ketta suuruse suurendamine salvestusruumi ja PersistentVolume'i kohta Kubernetese klastris.
- Kvoodid. Kubernetesisse sisseehitatud CephFS-draiverid ei toeta kvoote, kuid värsked CSI-pluginad koos uusima Ceph Nautilusega võivad lubada kvoote CephFS-i partitsioonidel.
- Mõõdikud. CSI pistikprogramm võib pakkuda Prometheusele mitmesuguseid mõõdikuid selle kohta, millised köidud on ühendatud, milline side toimub jne.
- Topoloogiateadlik. Võimaldab määrata manifestides, kuidas klaster on geograafiliselt jaotatud, ja vältida Amsterdamis asuva salvestussüsteemi ühendamist Londonis töötavate kaustadega.
Kuidas ühendada Ceph CSI kaudu Kubernetese klastriga, vt . Saate ka tellida , mis käivitatakse 15. oktoobril.
Artikli autor: Sergey Bondarev, Southbridge'i praktiseeriv arhitekt, Kubernetese sertifitseeritud administraator, üks kubespray arendajatest.
Väike Post Scriptum mitte reklaamiks, vaid kasuks...
PS Sergei Bondarev juhib kahte intensiivset kursust: uuendatud 28-30 september ja edasijõudnutele 14.–16. oktoober.
Allikas: www.habr.com