Shranjevanje podatkov v gručo Kubernetes

Obstaja več načinov za konfiguriranje shranjevanja podatkov za aplikacije, ki se izvajajo v gruči Kubernetes. Nekateri so že zastareli, drugi so se pojavili pred kratkim. V tem članku si bomo ogledali koncept treh možnosti povezovanja sistemov za shranjevanje, vključno z najnovejšo - povezavo prek vmesnika za shranjevanje vsebnikov.

1. način: Določite PV v manifestu sklopa

Tipičen manifest, ki opisuje pod v gruči Kubernetes:

Deli manifesta, ki opisujejo, kateri nosilec je povezan in kje, so označeni z barvo.

V oddelku volumeMounts navedite točke priklopa (mountPath) - v kateri imenik znotraj vsebnika bo nameščen stalni nosilec, kot tudi ime nosilca.

V oddelku x navaja vse nosilce, ki se uporabljajo v pod. Določite ime vsakega nosilca ter vrsto (v našem primeru: awsElasticBlockStore) in parametre povezave. Kateri parametri so navedeni v manifestu, je odvisno od vrste nosilca.

Isto prostornino je mogoče hkrati namestiti v več posod za stroke. Tako lahko različni procesi aplikacij dostopajo do istih podatkov.

Ta način povezovanja je bil izumljen na samem začetku, ko je bil Kubernetes šele v povojih, danes pa je način zastarel.

Pri uporabi je več težav:

1. vse količine je treba ustvariti ročno; Kubernetes ne more ustvariti ničesar namesto nas;
2. parametri dostopa za vsak nosilec so edinstveni in morajo biti navedeni v manifestih vseh podov, ki uporabljajo nosilec;
3. če želite spremeniti sistem za shranjevanje (na primer premik iz AWS v Google Cloud), morate spremeniti nastavitve in vrsto nameščenih nosilcev v vseh manifestih.

Vse to je zelo neprijetno, zato se v resnici ta metoda uporablja za povezovanje le nekaterih posebnih vrst nosilcev: configMap, secret, emptyDir, hostPath:

• configMap in secret sta storitvena nosilca, ki vam omogočata ustvarjanje nosilca z datotekami iz manifestov Kubernetes v vsebniku.

• prazniDir je začasni nosilec, ustvarjen samo za življenjsko dobo sklopa. Priročen za uporabo za testiranje ali shranjevanje začasnih podatkov. Ko se sklop izbriše, se izbriše tudi nosilec emptyDir in izgubijo se vsi podatki.

• hostPath - omogoča namestitev katerega koli imenika na lokalnem disku strežnika, na katerem se izvaja aplikacija, znotraj vsebnika z aplikacijo, vključno z /etc/kubernetes. To ni varna funkcija, zato varnostni pravilniki običajno prepovedujejo uporabo nosilcev te vrste. V nasprotnem primeru bo napadalčeva aplikacija lahko namestila imenik HTC Kubernetes v svoj vsebnik in ukradla vsa potrdila gruče. Običajno lahko nosilce hostPath uporabljajo samo sistemske aplikacije, ki se izvajajo v imenskem prostoru kube-system.

Sistemi za shranjevanje, s katerimi Kubernetes deluje takoj po namestitvi so navedeni v dokumentaciji.

Metoda 2. Povezava s kurišči SC/PVC/PV

Alternativni način povezovanja je koncept razreda Storage, PersistentVolumeClaim, PersistentVolume.

Razred shranjevanja shrani parametre povezave v sistem za shranjevanje podatkov.

PersistentVolumeClaim opisuje zahteve za to, kar aplikacija potrebuje.
Persistent Volume shrani parametre dostopa in stanje nosilca.

Bistvo ideje: v manifestu stroka navedejo nosilec tipa PersistentVolumeClaim in navedejo ime te entitete v parametru claimName.

Manifest PersistentVolumeClaim opisuje zahteve glede količine podatkov, ki jih zahteva aplikacija. Vključno z:

• velikost diska;
• način dostopa: ReadWriteOnce ali ReadWriteMany;
• link to Storage class - v katerem sistemu za shranjevanje podatkov želimo ustvariti nosilec.

Manifest razreda Storage shranjuje vrsto in parametre povezave s sistemom za shranjevanje. Cubelet jih potrebuje za namestitev nosilca na svoje vozlišče.

Manifesti PersistentVolume kažejo razred shranjevanja in parametre dostopa za določen nosilec (ID nosilca, pot itd.).

Ko ustvarja PVC, Kubernetes pogleda, kakšna velikost nosilca in kateri razred shranjevanja je zahtevan, ter izbere brezplačni PersistentVolume.

Če takšni PV-ji niso na voljo, lahko Kubernetes zažene poseben program - Provisioner (njegovo ime je navedeno v razredu Storage). Ta program se poveže s sistemom za shranjevanje, ustvari nosilec zahtevane velikosti, prejme identifikator in ustvari manifest PersistentVolume v gruči Kubernetes, ki je povezan s PersistentVolumeClaim.

Vsa ta množica abstrakcij vam omogoča, da odstranite informacije o tem, s katerim sistemom za shranjevanje aplikacija deluje, z ravni manifesta aplikacije na raven administracije.

Vsi parametri za povezavo s sistemom hrambe podatkov se nahajajo v razredu Storage, za katerega so odgovorni skrbniki gruče. Vse, kar morate storiti pri prehodu iz AWS v Google Cloud, je spremeniti ime razreda Storage v PVC v manifestih aplikacije. Vztrajnostni nosilec za shranjevanje podatkov bo samodejno ustvarjen v gruči s programom Provisioner.

Metoda 3: Vmesnik za shranjevanje vsebnika

Vsa koda, ki je v interakciji z različnimi sistemi za shranjevanje, je del jedra Kubernetes. Izdaja popravkov napak ali nove funkcionalnosti je vezana na nove izdaje; kodo je treba spremeniti za vse podprte različice Kubernetesa. Vse to je težko vzdrževati in dodajati nove funkcionalnosti.

Za rešitev težave so razvijalci iz Cloud Foundry, Kubernetes, Mesos in Docker ustvarili Container Storage Interface (CSI) – preprost enoten vmesnik, ki opisuje interakcijo sistema za upravljanje vsebnikov in posebnega gonilnika (CSI Driver), ki deluje z določeno sistem za shranjevanje. Vsa koda za interakcijo s sistemi za shranjevanje je bila premaknjena iz jedra Kubernetes v ločen sistem.

Dokumentacija vmesnika za shranjevanje vsebnikov.

Običajno je gonilnik CSI sestavljen iz dveh komponent: vtičnika vozlišča in vtičnika krmilnika.

Node Plugin se izvaja na vsakem vozlišču in je odgovoren za pripenjanje nosilcev in izvajanje operacij na njih. Vtičnik Controller sodeluje s sistemom za shranjevanje: ustvarja ali briše nosilce, dodeljuje pravice dostopa itd.

Za zdaj stari gonilniki ostajajo v jedru Kubernetes, vendar jih ni več priporočljivo uporabljati in vsem svetujemo, da namestijo gonilnik CSI posebej za sistem, s katerim bodo delali.

Novost lahko prestraši tiste, ki so že navajeni vzpostaviti shranjevanje podatkov prek razreda Storage, a v resnici se ni zgodilo nič strašnega. Za programerje se v resnici nič ne spremeni - delali so samo z imenom Storage class in bodo tako še naprej. Za skrbnike je bila dodana namestitev krmilne karte in spremenjena struktura nastavitev. Če so bile prej nastavitve vnesene neposredno v razred Skladiščenje, jih je treba sedaj najprej nastaviti v krmilni karti, nato pa še v razredu Skladiščenje. Če pogledate v to, se ni zgodilo nič slabega.

Vzemimo primer, da si ogledamo prednosti, ki jih lahko dobite s prehodom na povezovanje sistemov za shranjevanje Ceph z uporabo gonilnika CSI.

Pri delu s Cephom ponuja vtičnik CSI več možnosti za delo s sistemi za shranjevanje kot vgrajeni gonilniki.

1. Izdelava dinamičnega diska. Običajno se diski RBD uporabljajo samo v načinu RWO, vendar CSI za Ceph omogoča njihovo uporabo v načinu RWX. Več podov na različnih vozliščih lahko namesti isti disk RDB na svoja vozlišča in z njimi dela vzporedno. Po pravici povedano ni vse tako svetlo - ta disk je mogoče povezati le kot blokovno napravo, kar pomeni, da boste morali aplikacijo prilagoditi za delo z njim v načinu večkratnega dostopa.
2. Ustvarjanje posnetkov. V gruči Kubernetes lahko ustvarite manifest z zahtevo po ustvarjanju posnetka. Vtičnik CSI ga bo videl in naredil posnetek z diska. Na njegovi podlagi lahko naredite varnostno kopijo ali kopijo PersistentVolume.
3. Povečanje velikosti diska o pomnilniku in PersistentVolume v gruči Kubernetes.
4. Kvote. Gonilniki CephFS, vgrajeni v Kubernetes, ne podpirajo kvot, vendar lahko novi vtičniki CSI z najnovejšo različico Ceph Nautilus omogočijo kvote na particijah CephFS.
5. Metrike. Vtičnik CSI lahko Prometheusu zagotovi različne meritve o tem, kateri nosilci so povezani, kakšne komunikacije potekajo itd.
6. Poznavanje topologije. Omogoča vam, da v manifestih določite, kako je gruča geografsko porazdeljena, in se izognete povezovanju sistema za shranjevanje, ki se nahaja v Amsterdamu, s podi, ki se izvajajo v Londonu.

Kako povezati Ceph z gručo Kubernetes prek CSI, glejte v praktičnem delu predavanja večerne šole Slurm. Lahko se tudi naročite na Ceph video tečaj, ki se bo začela 15. oktobra.

Avtor članka: Sergey Bondarev, aktivni arhitekt pri Southbridgeu, certificirani skrbnik Kubernetes, eden od razvijalcev kubespray.

Majhen Post Scriptum ne za reklamo, ampak za dobro...

PS Sergej Bondarev vodi dva intenzivna tečaja: posodobljen Baza Kubernetes 28. – 30. september in napredno Kubernetes Mega 14.–16. oktober.

Vir: www.habr.com