{"id":71858,"date":"2020-02-28T21:00:08","date_gmt":"2020-02-28T18:00:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/patterny-hraneniya-dannyh-v-kubernetes"},"modified":"2020-03-03T16:14:09","modified_gmt":"2020-03-03T13:14:09","slug":"patterny-hraneniya-dannyh-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/patterny-hraneniya-dannyh-v-kubernetes","title":{"rendered":"Andmete salvestamise mustrid Kuberneteses","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Andmete<\/a><\/noindex>
\nTere, Habr!<\/p>\n

Tuletame meelde, et oleme v\u00e4lja andnud uue, \u00e4\u00e4rmiselt huvitava ja kasuliku raamat<\/a><\/noindex> Kubernetesi mustritest. K\u00f5ik algas veel "Mustritest<\/a><\/noindex>" Brendani Burnsist, ja tegelikult on meil selles valdkonnas head saavutused keeb<\/a><\/noindex>. T\u00e4na pakume teile lugeda MinIO blogi artiklit, mis l\u00fchidalt k\u00e4sitleb andmemustrite hoidmise suundi ja spetsiifikat Kuberneteses.
\n<\/a><\/noindex><\/p>\n

Kubernetes on p\u00f5him\u00f5tteliselt muutnud traditsioonilisi rakenduste arendamise ja juurutamise mustreid. N\u00fc\u00fcd v\u00f5ivad meeskondadel minna p\u00e4evad rakenduse arendamiseks, testimiseks ja juurutamiseks \u2013 erinevates keskkondades, ja seda k\u00f5ike Kubernetes klastrite piirides. Selline t\u00f6\u00f6 eelneva p\u00f5lvkonna tehnoloogiatega v\u00f5ttis tavaliselt tervete n\u00e4dalate, kui mitte kuude, jagu aega.<\/p>\n

Selline kiirus on v\u00f5imalik t\u00e4nu Kubernetes'e pakkumisele, v\u00f5rreldes eelnevate p\u00f5lvkondade tehnoloogiatega \u2013 see t\u00e4hendab, et Kubernetes ise tegeleb f\u00fc\u00fcsiliste v\u00f5i virtuaalsete masinate madalama tasandi detailidega, v\u00f5imaldades kasutajatel m\u00e4rgata teiste parameetrite seas vajalikku protsessorit, vajaliku m\u00e4lumahtu ja konteinerite koopiate arvu. Kuna Kubernetes'e toetab tohutu kogukond ja selle rakendamine laieneb pidevalt, on see kaugel ees k\u00f5igist konteinerite orkestreerimise platvormidest.<\/p>\n

Kubernetes'e kasutamise kasvu korral suureneb ka segadus andmete hoidmise mustrite osas<\/b><\/i>.<\/p>\n

Kuna k\u00f5ik konkureerivad Kubernetes'e kukeldamise nimel (st andmete hoidmine), kadub andmete hoidmise arutelu siia segasesse m\u00fcrasse.
\nKubernetes kehastab kaasaegset rakenduste arendamise ja juurutamise mudelit, samuti nende haldamist. See kaasaegne mudel eraldab andmete hoidmise arvutustest. Et t\u00e4ielikult m\u00f5ista sellist eraldamist Kubernetes'e kontekstis, peab m\u00f5istma ka, mis on olekuga ja staatilise s\u00e4ilitamisega rakendused ning kuidas andmete hoidmine sellega seondub. Just siin on S3 kasutatav REST API l\u00e4henemisviisil selged eelised v\u00f5rreldes teiste lahenduste iseloomuliku POSIX\/CSI l\u00e4henemisega.<\/p>\n

Selles artiklis r\u00e4\u00e4gime andmete salvestamise mustritest Kuberneteses ning k\u00e4sitleme eraldi arutelu rakendustest, mis t\u00f6\u00f6tavad ilma ja koos oleku salvestamisega, et m\u00f5ista, mis nende vahel vahe on ja miks see on oluline. Edasi teksis vaatleme rakendusi ja kasutatavaid andmete salvestamise mustreid konteinerite ja Kubernetesega t\u00f6\u00f6tamise parimate praktikate valguses.<\/p>\n

Oleku salvestamata konteinerid<\/h4>\n

\nKonteinerid on oma olemuselt kerged ja ajutised. Neid saab kergesti peatada, kustutada v\u00f5i teisele s\u00f5lmele rakendada \u2013 sellele kulub vaid m\u00f5ned sekundid. Suures konteinerite orkestreerimise s\u00fcsteemis toimuvad sellised toimingud pidevalt ning kasutajad ei m\u00e4rkagi selliseid muutusi. Siiski on liikuvus v\u00f5imalik ainult juhul, kui konteineril ei ole mingeid s\u00f5ltuvusi s\u00f5lmest, kus see asub. Selliste konteinerite kohta \u00f6eldakse, et need t\u00f6\u00f6tavad ilma oleku salvestamiseta<\/i>.<\/p>\n

Oleku salvestavad konteinerid<\/h4>\n

\nKui konteiner salvestab andmeid kohalikult \u00fchendatud seadmetes (v\u00f5i plokkseadmestikes), peab andmete salvestus, kus ta asub, koos konteineriga uuele s\u00f5lmele liikuma \u2013 juhul kui tekib t\u00f5rge. See on oluline, kuna muidu ei saa konteineris k\u00e4ivituv rakendus korralikult toimida, sest tal on vaja juurdep\u00e4\u00e4su andmetele, mis on salvestatud kohalikesse m\u00e4luseadmetesse. Selliste konteinerite kohta \u00f6eldakse, et need t\u00f6\u00f6tavad oleku salvestamisega<\/i>.<\/p>\n

Puht tehnilisest vaatenurgast on oleku salvestavaid konteinerid v\u00f5imalik samuti teisele s\u00f5lmele liigutada. T\u00fc\u00fcpiliselt saavutatakse see kaudu jaotatud failis\u00fcsteemide v\u00f5i plokkide v\u00f5rgu andmesalvestuse kasutamisega, mis on seotud k\u00f5ikide s\u00f5lmedega, kus konteinerid t\u00f6\u00f6tavad. Sel moel saavad konteinerid juurdep\u00e4\u00e4su p\u00fcsivale andmesalvestusele ja teave salvestatakse kettale, mis asuvad kogu v\u00f5rgus. Seda meetodit nimetaksin ma \"oleku salvestava konteineri l\u00e4henemiseks<\/i>\", ja artikli \u00fclej\u00e4\u00e4nud osas nimetan seda niimoodi \u00fchtsuse nimel.<\/p>\n

\"Andmete
\n
\nT\u00fc\u00fcpilise konteinerip\u00f5hise l\u00e4henemise korral, kus s\u00e4ilitatakse riik, kinnitatakse k\u00f5ik rakenduste podid \u00fchte hajutatud failis\u00fcsteemi \u2013 saadakse omamoodi jagatud salvestus, kus on k\u00f5ik rakenduste andmed. Kuigi v\u00f5ivad esineda m\u00f5ned variatsioonid, on see k\u00f5rgetasemeline l\u00e4henemine.<\/p>\n

N\u00fc\u00fcd uurigem, miks konteinerip\u00f5hine l\u00e4henemine riigi s\u00e4ilitamisega pilvekeskses maailmas on antipattern.<\/p>\n

Pilvekesksed rakenduste projekteerimise p\u00f5him\u00f5tted<\/h4>\n

\nTraditsiooniliselt kasutasid rakendused andmebaase struktureeritud teabe salvestamiseks ja kohalikke kettaid v\u00f5i hajutatud failis\u00fcsteeme, kuhu salvestati k\u00f5ik struktureerimata v\u00f5i isegi osaliselt struktureeritud andmed. Aja jooksul, kui struktureerimata andmete maht kasvas, m\u00f5istsid arendajad, et POSIX on liiga \"r\u00e4\u00e4kiv\", seondub m\u00e4rkimisv\u00e4\u00e4rsete kuludega ja l\u00f5puks h\u00e4irib rakenduse t\u00f6\u00f6d, kui minnakse t\u00f5eliselt suurte mastaapide juurde.<\/p>\n

See aitas oluliselt kaasa uue andmete salvestamise standardi tekkimisele, st pilvekesksed salvestuss\u00fcsteemid, mis t\u00f6\u00f6tavad peamiselt REST API alusel ja vabastavad rakenduse koormavast kohaliku andmesalvestuse haldamisest. Sellisel juhul t\u00f6\u00f6tab rakendus sisuliselt seisundita re\u017eiimis (kuna olek asub kaugandmesalves). Kaasaegsed rakendused ehitatakse juba algusest peale arvesse v\u00f5ttes seda tegurit. \u00dcldiselt on iga kaasaegne rakendus, mis t\u00f6\u00f6tleb mingi teabe t\u00fc\u00fcpi (logid, metaandmed, blobid jne), \u00fcles ehitatud pilvekesksesse paradigmasse, kus olek viiakse spetsiaalselt selle jaoks n\u00e4htud tarkvaras\u00fcsteemi. <\/p>\n

Konteinerip\u00f5hine l\u00e4henemine riigi s\u00e4ilitamisega sunnib kogu selle paradigma tagasi minema aufs kanti, kust see alguse sai! <\/b><\/i><\/p>\n

Kasutades POSIX-liideseid rakenduste andmete salvestamiseks t\u00f6\u00f6tavad rakendused nagu nad salvestaksid olekut, mis toob kaasa k\u00f5rvalekaldeid k\u00f5ige olulisematest pilvep\u00f5hisest disaini postulaatidest, nagu v\u00f5imalus varieerida rakenduse t\u00f6\u00f6voogude suurusi vastavalt sisenevale koormusele, liikuda uuele s\u00f5lmele kohe, kui aktiivne s\u00f5lm eba\u00f5nnestub, jne.<\/p>\n

Sellele olukorrale l\u00e4hemalt vaatates leiame, et andmesalvestuse valimisel puutume taas kokku dilemma \u00abPOSIX vs REST API\u00bb, kuid lisaks POSIX-i probleemide s\u00fcvenemisele, mis on tingitud Kubernetes'e jaotatud keskkonnadest. Eesk\u00e4tt,<\/p>\n