Andmete salvestamine Kubernetes klastris

Rakenduste andmete salvestamise seadistamiseks, mis töötavad Kubernetes'i klastris, on mitmeid viise. Mõned neist on juba vananenud, teised on tekkinud alles hiljuti. Käesolevas artiklis käsitleme kolme erinevat võimalust, kuidas ühendada salvestustooted, sealhulgas kõige uuemat - Container Storage Interface'i kaudu ühendumist.

Andmete salvestamine Kubernetes klastris

Viis 1. PV määramine poodi manifestis

Tüüpiline manifest, mis kirjeldab poodi Kubernetes'i klastris:

Andmete salvestamine Kubernetes klastris

Manifesti osad, kus on kirjas, milline maht on ühendatud ja kuhu, on esile tõstetud värviga.

Jaotises volumeMounts määravad mountPath'd, kuhu kausta konteineri sees püsiv formaat monteeritakse, ja samuti vormi nime.

Jaotises x loetleb kõik formaadid, mida poos kasutatakse. Iga formaadi nimi on märgitud, samuti tüüp (meie juhul: awsElasticBlockStore) ja ühenduse parameetrid. Millised täpselt parameetrid manifestis esinevad, sõltub formaadi tüübist.

Ühte ja sama formaati saab korraga monteerida mitmesse konteinerisse poos. Nii saavad erinevad rakenduse protsessid üksikutele andmetele juurde pääseda.

See ühenduse meetod loodi alguses, kui Kubernetes alles algas, ja tänaseks on meetod vananenud.

Selle kasutamisega kaasnevad mitmed probleemid:

  1. kõik mahud tuleb luua käsitsi, Kubernetes ei suuda midagi ise meie eest luua;
  2. iga mahu juurdepääsupäringud on unikaalsed ning need tuleb määrata kõigi podide manifestides, mis mahu kasutavad;
  3. kui soovite salvestussüsteemi muuta (näiteks liikuda AWS-ist Google Cloudi), tuleb muuta seadistusi ja ühendatud mahude tüüpe kõigis manifestides.

Kõik see on väga ebamugav, seetõttu kasutatakse tegelikult sellist meetodit ainult teatud spetsiaalsete mahutüüpide ühendamiseks: configMap, secret, emptyDir, hostPath:

  • configMap ja secret — teenusmahud, võimaldavad konteineris luua mahu, mis sisaldab faile Kubernetes'e manifestidest.

  • emptyDir — ajutine mahut, mis luuakse ainult pode eluajal. Mugav kasutada katsetamiseks või ajutiste andmete salvestamiseks. Kui pod eemaldatakse, eemaldatakse ka emptyDir tüüpi mahut ja kõik andmed kaovad.

  • hostPath — võimaldab monteerida konteinerisse, kus rakendus asub, mis tahes kausta serveri kohaliku ketta, kus rakendus töötab, sealhulgas /etc/kubernetes. See on ohtlik funktsioon, seetõttu keelavad turvapoliitikad tavaliselt selle tüüpi mahtude kasutamise. Vastasel juhul võib ründaja rakendus monteerida oma konteinerisse HTC Kubernetes kausta ja varastada kõik klastrisertifikaadid. Üldiselt lubatakse hostPath mahtude kasutamist ainult süsteemirakendustel, mis töötavad kube-system nimel hästi.

Andmesalvestussüsteemid, millega Kubernetes töötab, on ette nähtud väljundina on toodud dokumentatsioonis.

Meetod 2. Ühendamine podide SC/PVC/PV kaudu

Alternatiivne ühendamise viis on Storage class, PersistentVolumeClaim, PersistentVolume kontseptsioon.

Storage class salvestab ühenduse parameetrid salvestussüsteemiga.

PersistentVolumeClaim kirjeldab rakendusele vajalikku mahtu.
PersistentVolume salvestab juurdepääsu parameetrid ja mahtude oleku.

Idee peamine mõte: podi manifestis näidatakse mahtu tüüpi PersistentVolumeClaim ja selle elemendi nime näidatakse parameetris claimName.

Andmete salvestamine Kubernetes klastris

PersistentVolumeClaim'i manifestis kirjeldatakse andmete nõudeid, mis on rakendusele vajalikud. Nende hulka kuuluvad:

  • ketta suurus;
  • juurdepääsu viis: ReadWriteOnce või ReadWriteMany;
  • viide Storage class'ile — millises andmesalvestuse süsteemis soovime mahtu luua.

Storage class'i manifestis säilivad tüübid ja parameetrid andmesalvestuse süsteemiga ühenduseks. Need on vajalikud kubelet'ile, et mahut mountida oma sõlmele.

PersistentVolume'i manifestides märgitakse Storage class ja ligipääsu parameetrid konkreetse mahu jaoks (mahu ID, tee jne).

PVC loomisel vaatab Kubernetes, millise suurusega mahtu ja millisest Storage class'ist on vaja ning valib vabade PersistentVolume'ite seast sobiva.

Kui selliseid PV'sid pole saadaval, võib Kubernetes käivitada spetsiaalse programmi — Provisioner (tema nimi on märgitud Storage class'is). See programm ühendub andmesalvestussüsteemiga, loob vajaliku suurusega mahu, saab identifikaatori ja loob Kubernetes'i klastrisse PersistentVolume'i manifesti, mis seondub PersistentVolumeClaim'iga.

Kogu see hulk abstraktsioone võimaldab eemaldada teabe selle kohta, millise andmesalvestussüsteemiga rakendus töötab, rakenduste manifesti tasemelt haldustasemele.

Kogu andmed, mis on vajalikud andmesalvestussüsteemi ühendamiseks, asuvad Storage class'is, mille eest vastutavad klastrihaldurid. AWS-ist Google Cloudi ülemineku korral peab rakenduse manifeetides lihtsalt muutma Storage class'i nime PVC-s. Püsiv maht, et andmeid salvestada, luuakse klastris automaatselt Provisioner'i abil.

Meetod 3. Container Storage Interface

Kogu kood, mis suhtleb erinevate andmesalvestussüsteemidega, on osa Kubernetes'i tuumast. Vigade paranduste või uute funktsionaalsuste väljalaskmine on seotud uute versioonide väljaandmisega, mistõttu tuleb koodi muuta kõigi toetatud Kubernetes'i versioonide jaoks. Kõike seda on raske hallata ja uute funktsioonide lisamine on keeruline.

Probleemi lahendamiseks lõid Cloud Foundry, Kubernetes, Mesos ja Docker arendajad Container Storage Interface (CSI) — lihtne ühtne liides, mis kirjeldab konteinerihaldussüsteemi ja konkreetse andmesalvestussüsteemi töökindlate draiverite (CSI Driver) vahelisi seoseid. Kõik andmesalvestussüsteemiga suhtlemise kood viidi Kubernetes'i tuumast eraldi süsteemi.

Container Storage Interface'i dokumentatsioon.

Tavaliselt koosneb CSI Driver kahest komponendist: Node Plugin ja Controller plugin.

Node Plugin käivitub igal sõlmel ja vastutab mahtude monteerimise ning nende operatsioonide eest. Controller plugin suhtleb SСHD-ga: loob või kustutab mahtusid, määrab juurdepääsuõigusi jne.

Kuni Kubernetes'i tuumas jäävad vanad draiverid, kuid nende kasutamist ei soovitata ning kõigile soovitatakse installida CSI draiver konkreetselt selle süsteemi jaoks, millega töötama hakatakse.

Uus muudatus võib hirmutada neid, kes on juba harjunud seadistama andmete salvestamist läbi Storage class'i, kuid tegelikult pole midagi tõsist juhtunud. Programmeerijatele ei muutu midagi - nad jätkavad töötamist ainult Storage class'i nimega. Administratoritele on lisandunud helm chart'i installimine ja seadete struktuur on muutunud. Kui varem sisestati seaded otse Storage class'i, siis nüüd tuleb need esmalt määrata helm chart'is ja seejärel juba Storage class'is. Kui asja selgeks teha, siis pole midagi hullu juhtunud.

Vaatame näiteks, milliseid eeliseid on võimalik saavutada, minnes SСHD Ceph'i ühendamisele CSI draiveri abil.

Ceph'i kasutamisel annab CSI plugin rohkem võimalusi SСHD-ga töötamiseks kui sisseehitatud draiverid.

  1. Dünaamiline diskide loomine. Tavaliselt kasutatakse RBD-vankreid ainult RWO-režiimis, kuid CSI Cephi jaoks võimaldab neid kasutada RWX-režiimis. Mitmed pod'id erinevates sõlmedes saavad sama RDB-vankri oma sõlmedesse ühendada ja töötada nendega paralleelselt. Tõele au andes, pole kõik nii roosiline — see vanker saab ühenduda ainult bloos-seadmestikuna, mis tähendab, et tuleb rakendus kohandada, et see töötaks mitme juurdepääsuga.
  2. Snaipšoti loomine. Kubernetes klastris on võimalik luua manifest, mille nõudmiseks on snaipšoti loomine. CSI-plugin näeb selle ja teeb snaipšoti vankrilt. Selle alusel saab teha kas varukoopia või PersistentVolume'i koopia.
  3. Vankri suuruse suurendamine SÜD ja PersistentVolume Kubernetes klasstris.
  4. Kvoodid. Kubernetesis sisseehitatud CephFS draiverid ei toeta kvoote, kuid uued CSI-pluginad koos värske Ceph Nautilus'ega oskavad lubada kvoote CephFS-partitsioonides.
  5. Mõõdikud. CSI-plugin võib Prometheusesse edastada hulga mõõdikuid selle kohta, millised mahud on ühendatud, millised toimingud toimuvad jne.
  6. Topoloogia teadlik. Võimaldab määrata manfestides, kuidas klaster geograafiliselt jaotatud on, ja vältida ühendamist Londonis käitatavate andmesalvestussüsteemidega, mis asuvad Amsterdamis.

Kuidas ühendada Ceph Kubernetes'i klastriga läbi CSI, vaata õhtuse kooli Slörmi praktilises osas.Samuti on võimalik registreeruda Ceph videokursusele, mis algab 15. oktoobril.

Artikli autor: Sergei Bondarev, praktiseeriv arhitekt Southbridge, sertifitseeritud Kubernetes'i administraator, üks kubespray arendajatest.

Veidi post scriptum ei reklaamimiseks, vaid kasuks…

P.S. Sergei Bondarev juhendab kaht intensiivset kursust: uuendatud Kubernetes Baas 28-30 septembril ja edasijõudnud Kubernetes Mega 14–16. oktoobril.

Andmete salvestamine Kubernetes klastris

Allikas: habr.com

Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster