Datu glabāšana Kubernetes klasterī

Kubernetes klasterī darbojošos lietojumprogrammu datu glabāšanu var konfigurēt vairākos veidos. Daži no tiem ir novecojuši, citi ir parādījušies pavisam nesen. Šajā rakstā tiks apskatīta trīs piekļuves variantu koncepcija, tostarp jaunākais — piekļuve Caurskatāmo krātuves interfeisa (Container Storage Interface) izmantošana.

1. metode. PV norādīšana poda manisfestā

Tipisks manifests, kas apraksta podu Kubernetes klasterī:

Manifestā izkrāsotās daļas parāda, kurš apjoms tiek pievienots un kur.

Sadaļā volumeMounts norāda montēšanas punktus (mountPath) — kurā katalogā konteinerā tiks montēts pastāvīgais apjoms, kā arī apjoma nosaukumu.

Sadaļā x uzskaita visus apjomus, kas tiek izmantoti podā. Norāda katra apjoma nosaukumu, kā arī tipu (mūsu gadījumā: awsElasticBlockStore) un pieslēgšanas parametrus. Kas tieši tiek norādīts manifestā, ir atkarīgs no apjoma veida.

Viens un tas pats apjoms var tikt montēts vienlaikus vairākos podu konteineros. Tādējādi dažādi lietojumprogrammu procesi var piekļūt vieniem un tiem pašiem datiem.

Šī piekļuves metode tika izstrādāta pašā sākumā, kad Kubernetes tikai parādījās, un tagad tā ir novecojusi.

To izmantojot, rodas vairākas problēmas:

1. visus apjomus ir jārada manuāli, Kubernetes neko mūsu vietā izveidot nevar;
2. katram apjomam piekļuves parametri ir unikāli, un tos jānorāda visos podu manifestos, kas izmanto apjomu;
3. lai mainītu glabāšanas sistēmu (piemēram, pārvietotos no AWS uz Google Cloud), ir jāmaina iestatījumi un pievienoto apjomu veidi visos manifestos.

Viss šis process ir ļoti neērtas, tāpēc praksē šī metode tiek izmantota tikai dažiem īpaša veida apjomiem: configMap, secret, emptyDir, hostPath:

• configMap un secret — pakalpojumu apjomi, ļauj izveidot konteinerā apjomu ar failiem no Kubernetes manifestiem.

• emptyDir — pagaidu apjoms, tiek izveidots tikai podu dzīves laikā. Ērti izmantot testēšanai vai pagaidu datu glabāšanai. Kad pods tiek dzēsts, emptyDir tips apjoms arī tiek dzēsts un visi dati pazūd.

• hostPath — ļauj pieslēgt jebkuru lokālā servera diska katalogu, kurā darbojas lietojumprogramma, tieši konteineram ar lietojumprogrammu, tostarp /etc/kubernetes. Šī nav droša iespēja, tādēļ parasti drošības politika aizliedz šāda veida apjomu izmantošanu. Pretējā gadījumā uzbrucēja lietojumprogramma varēs pieslēgt savu konteineram HTC Kubernetes katalogu un izsist visus klastera sertifikātus. Parasti hostPath apjomu izmantošanu atļauj tikai sistēmas lietojumprogrammām, kas darbojas kube-system namespace.

Uzglabāšanas sistēmas, ar kurām Kubernetes strādā noklusēti ir uzskaitītas dokumentācijā.

Veids 2. Pieslēgšanās pie SC/PVC/PV

Alternatīvs savienojuma veids ir Storage class, PersistentVolumeClaim, PersistentVolume koncepcija.

Storage class satur savienojuma parametrus ar uzglabāšanas sistēmu.

PersistentVolumeClaim apraksta prasības apjomam, kas nepieciešams lietojumprogrammām.
PersistentVolume satur piekļuves parametrus un apjoma statusu.

Idejas būtība: podu manisfestā norāda volume tipa PersistentVolumeClaim un šīs vienības nosaukumu claimedName parametrajā.

PersistentVolumeClaim manisfestā tiek aprakstītas prasības apjomam, kas nepieciešams lietojumprogrammām. Tajā skaitā:

• disku izmērs;
• piekļuves veids: ReadWriteOnce vai ReadWriteMany;
• atsauce uz Storage class — kurā uzglabāšanas sistēmā vēlamies veidot apjomu.

Storage class manisfestā tiek saglabāti tips un savienojuma parametri ar uzglabāšanas sistēmu. Tie ir nepieciešami kubelet, lai pieslēgtu apjomu savam mezglam.

PersistentVolume manisfestos norādītas Storage class un piekļuves parametri konkrētajam apjomam (apjoma ID, ceļš utt.).

Izveidojot PVC, Kubernetes pārbauda, kāda izmēra apjoms un no kādas Storage class nepieciešams, un izvēlas brīvo PersistentVolume.

Ja tādu PV nav pieejami, Kubernetes var palaist speciālu programmu — Provisioner (tās nosaukumu norāda Storage class). Šī programma pieslēdzas uzglabāšanas sistēmai, izveido nepieciešamā izmēra apjomu, iegūst identifikatoru un izveido Kubernetes klasterī PersistentVolume manisfestu, kas saistās ar PersistentVolumeClaim.

Visas šīs abstrakcijas ļauj pārvērst informāciju par to, ar kādu uzglabāšanas sistēmu lietojumprogramma strādā, no lietojumprogrammu manisfesta līmeņa uz administrēšanas līmeni.

Visi savienojuma parametri uz datu glabāšanas sistēmu atrodas Storage class, par kuru atbild klastera administratori. Viss, kas jāizdara, pārejot no AWS uz Google Cloud, — tas ir jāmaina Storage class nosaukums PVC manisfestos. Persistance Volume datu glabāšanai tiks automātiski izveidoti klasterī, izmantojot Provisioner programmu.

3. metode. Container Storage Interface

Visi kods, kas mijiedarbojas ar dažādām datu glabāšanas sistēmām, ir daļa no Kubernetes kodola. Kļūdu labojumu vai jauna funkcionāla izlaišana ir saistīta ar jauniem izlaidumiem, kods ir jāmaina visām atbalstītajām Kubernetes versijām. Viss šis ir grūti uzturēt un pievienot jaunu funkcionalitāti.

Lai atrisinātu problēmu, izstrādātāji no Cloud Foundry, Kubernetes, Mesos un Docker izveidoja Container Storage Interface (CSI) — vienkāršu standartizētu interfeisu, kas apraksta mijiedarbību starp konteineru pārvaldības sistēmu un speciālo draiveri (CSI Driver), kas strādā ar konkrēto SĶD. Visi kods, kas mijiedarbojas ar SĶD, tika izņemts no Kubernetes kodola un novietots atsevišķā sistēmā.

Dokumentācija par Container Storage Interface.

Parasti CSI draiveris sastāv no diviem komponentiem: Node Plugin un Controller plugin.

Node Plugin tiek palaista katrā mezglā un atbild par apjoma montāžu un operācijām ar tiem. Controller plugin mijiedarbojas ar SĶD: izveido vai dzēš apjomus, piešķir piekļuves tiesības utt.

Kamēr Kubernetes kodolā paliek vecie draiveri, tomēr to lietošana vairs nav ieteicama, un visiem ieteicams instalēt CSI draiveri tieši attiecīgajai sistēmai, ar kuru būs jāstrādā.

Jaunums var satraukt tos, kuri jau pieraduši konfigurēt datu glabāšanu caur Storage class, taču patiesībā nekas briesmīgs nenotika. Programmētājiem nekas nemainās — viņi kā strādāja tikai ar Storage class nosaukumu, tā arī turpina. Administrātoriem pievienojās helm chart uzstādīšana un mainījās iestatījumu struktūra. Ja iepriekš iestatījumi tika ievadīti tieši Storage class, tad tagad vispirms tos jāpievieno helm chart, un tikai tad jau Storage class. Ja saprot, nekas briesmīgs nenotika.

Apskatīsim piemēru, kādas priekšrocības var iegūt, pārejot uz Ceph SĶD savienojumu, izmantojot CSI draiveri.

Strādājot ar Ceph, CSI draiveris nodrošina vairāk iespēju darbam ar SĶD nekā iebūvētie draiveri.

1. Dinamisks disku izveidojums. Parasti RBD diski tiek izmantoti tikai RWO režīmā, bet CSI Ceph atļauj tos izmantot RWX režīmā. Vairāki podi dažādās mezglu var piekļūt vienam un tam pašam RBD diskam un strādāt ar to paralēli. Jāatzīmē, ka šis disks var tikt pieslēgts tikai kā blokierīce, tas ir, būs jāpielāgo lietojumprogramma, lai tā varētu darboties ar to vairāku piekļuves režīmā.
2. Snapshotu izveide. Kubernetes klasterī var izveidot manifestu, kas pieprasa izveidot snapshot. CSI spraudnis to redzēs un veiks snapshot no diska. Pamatojoties uz to, varēs veikt vai nu dublējumu, vai kopiju PersistentVolume.
3. Diska izmēra palielināšana uz SAN un PersistentVolume Kubernetes klasterī.
4. Kvotas. Iebūvētie Kubernetes CephFS draiveri neatbalsta kvotas, bet jaunākie CSI spraudņi ar jaunāko Ceph Nautilus spēj aktivizēt kvotas CephFS nodalījumos.
5. Metrikas. CSI spraudnis var nodot Prometheus vairākas metrikas par to, kādi apjomi ir pieslēgti, kādi noris mijiedarbības u.tml.
6. Topoloģiskā apziņa. Atļauj norādīt manifeste, kā ģeogrāfiski ir izkliedēts klasteris, un izvairīties no pieslēgšanās podiem, kas tiek palaisti Londonā, datu uzglabāšanai, kas atrodas Amsterdamā.

Kā pieslēgt Ceph Kubernetes klasterim caur CSI, skatieties praktiskajā lekcijas daļā vakara skolas Sļērma. Tāpat var pierakstīties uz Ceph video kursu, kas sāksies 15. oktobrī.

Raksta autors: Sergejs Bondarevs, praktizējošs arhitekts Southbridge, Certified Kubernetes Administrator, viens no kubespray izstrādātājiem.

Mazliet Post Scriptum nav reklāmas, bet lai būtu noderīgi…

P.S. Sergejs Bondarevs vada divus intensīvos kursus: atjaunoto Kubernetes Bāze 28.-30. septembrī un padziļināto Kubernetes Mega no 14. līdz 16. oktobrim.

Avots: habr.com