{"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\/sl\/blog\/administrirovanie\/patterny-hraneniya-dannyh-v-kubernetes","title":{"rendered":"Vzorci shranjevanja podatkov v Kubernetesu","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Vzorci<\/a><\/noindex>
\nHello, Habr!<\/p>\n

Pripominjamo, da smo izdali novo izredno zanimivo in uporabno knjiga<\/a><\/noindex> o vzorih Kubernetes. Za\u010delo se je \u0161e sVzorci<\/a><\/noindex>Brendana Bernsa, in vendar pa je na\u0161e delo na tem segmentu brzostrelno poteka<\/a><\/noindex>. Danes vam ponujamo, da preberete \u010dlanek iz bloga MinIO, ki na kratko povzema trende in posebnosti vzorcev shranjevanja podatkov v Kubernetes.
\n<\/a><\/noindex><\/p>\n

Kubernetes je temeljito spremenil tradicionalne vzorce razvoja in uvajanja aplikacij. Zdaj lahko ekipa v le nekaj dneh razvije, testira in uvaja aplikacijo \u2013 v razli\u010dnih okoljih, vse to znotraj Kubernetes grozdov. Tak\u0161na delo s tehnologijami prej\u0161njih generacij obi\u010dajno je zahtevalo tedne, \u010de ne mesece.<\/p>\n

Tak\u0161no pospe\u0161evanje je postalo mogo\u010de zaradi abstrakcije, ki jo zagotavlja Kubernetes \u2014 to je, zahvaljujo\u010d temu, da Kubernetes sam obravnava interakcije z nizkotnim tehni\u010dnim specifikacijam fizi\u010dnih ali virtualnih strojev, kar uporabnikom omogo\u010da, da na primer dolo\u010dijo potreben procesor, potrebne koli\u010dine pomnilnika in \u0161tevilo primerkov kontejnerjev. Ker je za podporo Kubernetes anga\u017eirana ogromna skupnost, ter ker se obseg uporabe Kubernetes nenehno \u0161iri, vodi dale\u010d pred vsemi platformami za orkestracijo kontejnerjev.<\/p>\n

S \u0161irjenjem uporabe Kubernetes se pove\u010duje tudi zmeda glede vzorcev shranjevanja podatkov, ki se uporabljajo.<\/b><\/i>.<\/p>\n

Pri vsej konkurenci za kos pite Kubernetes (tj. za shranjevanje podatkov), ko gre za shranjevanje podatkov, se signal tukaj potopi v mo\u010dan \u0161um.
\nKubernetes predstavlja sodobni model razvoja, uvajanja in upravljanja aplikacij. Ta sodoben model lo\u010duje shranjevanje podatkov od obdelave. Da bi popolnoma razumeli to lo\u010ditev v kontekstu Kubernetes, je treba prav tako razumeti, kaj so aplikacije, ki delujejo s trajnimi in netrajnimi shranjevanjem, ter kako se to usklajuje s shranjevanjem podatkov. Tu ima pristop REST API, ki se uporablja v S3, jasne prednosti v primerjavi s pristopom POSIX\/CSI, ki je zna\u010dilen za druge re\u0161itve.<\/p>\n

V tem \u010dlanku se bomo pogovorili o vzorcih shranjevanja podatkov v Kubernetesu in posebej obravnavali razpravo o aplikacijah, ki delujejo z shranjevanjem in brez shranjevanja stanja, da bomo temeljito razumeli, v \u010dem je razlika med njimi in zakaj je ta razlika pomembna. V nadaljevanju besedila bodo obravnavane aplikacije in vzorci shranjevanja podatkov, ki se uporabljajo v skladu z najbolj\u0161imi praksami dela s posodami in Kubernetesom.<\/p>\n

Posode brez shranjevanja stanja<\/h4>\n

\nPosode so po naravi lahke in efemerne. Lahko jih enostavno ustavimo, izbri\u0161emo ali prenesemo na drugo vozli\u0161\u010de \u2013 to traja le sekunde. V velikem sistemu orkestracije posod se tak\u0161ne operacije nenehno dogajajo, uporabniki pa teh sprememb pogosto ne opazijo. Vendar pa so premiki mo\u017eni le, \u010de posoda nima nobenih odvisnosti od vozli\u0161\u010da, na katerem se nahaja. O tak\u0161nih posodah pravimo, da delujejo brez shranjevanja stanja<\/i>.<\/p>\n

Posode s shranjevanjem stanja<\/h4>\n

\n\u010ce posoda shranjuje podatke na lokalno priklju\u010denih napravah (ali na blokovni napravi), bo treba shranjevanje podatkov, na katerem se nahaja, prenesti na novo vozli\u0161\u010de skupaj s samo posodo \u2013 v primeru okvare. To je pomembno, saj v nasprotnem primeru aplikacija, ki te\u010de v posodi, ne bo mogla pravilno delovati, saj mora dostopati do podatkov, shranjenih na lokalnih medijih. O tak\u0161nih posodah pravimo, da delujejo s shranjevanjem stanja<\/i>.<\/p>\n

Z \u010dist tehni\u010dnega vidika je mogo\u010de tudi posode s shranjevanjem stanja premikati na druga vozli\u0161\u010da. To se obi\u010dajno zagotavlja s pomo\u010djo porazdeljenih datote\u010dnih sistemov ali blokovnih omre\u017enih shranjevanj podatkov, pritrjenih na vsa vozli\u0161\u010da, na katerih delujejo posode. Tako posode dobijo dostop do volumov za trajno shranjevanje podatkov, informacije pa se shranjujejo na diskih, razporejenimi po celotnem omre\u017eju. Ta na\u010din bom poimenoval \u2018pristop posod s shranjevanjem stanja<\/i>\u2019, in v preostanku \u010dlanka ga bom tako imenoval za enotnost.<\/p>\n

\"Vzorci
\n
\nV tipi\u010dnem pristopu kontejnerne tehnologije s shranjevanjem stanja so vse aplikacijske posode pripete na en razdeljen datote\u010dni sistem \u2013 ustvarja se nekak\u0161en skupni prostor za shranjevanje, kjer se zbirajo vse podatke aplikacij. \u010ceprav so mo\u017ene dolo\u010dene variacije, gre za visok nivo pristopa.<\/p>\n

Zdaj pa se podu\u010dimo, zakaj je pristop kontejnerne tehnologije s shranjevanjem stanja v svetu, usmerjenem v oblak, antipateren.<\/p>\n

Obla\u010dno usmerjeno na\u010drtovanje aplikacij<\/h4>\n

\nTradicionalno so aplikacije uporabljale baze podatkov za strukturirano shranjevanje informacij ter lokalne diske ali razdeljene datote\u010dne sisteme, kamor so shranjevali vse nestrukturirane ali celo polstrukturirane podatke. Ko so se koli\u010dine nestrukturiranih podatkov pove\u010dale, so razvijalci spoznali, da je POSIX prenagljen, povezan z znatnimi stro\u0161ki in na koncu ovira delovanje aplikacije pri prehodu na resni\u010dno velike razse\u017enosti.<\/p>\n

To je v veliki meri prispevalo k nastanku novega standarda shranjevanja podatkov, torej obla\u010dno usmerjenih shranjevanj, ki delujejo predvsem na osnovi REST API in razbremenjujejo aplikacijo napornih nalog lokalnega shranjevanja podatkov. V takem primeru aplikacija pravzaprav prehaja v na\u010din delovanja brez shranjevanja stanja (ker je stanje v oddaljenem shranjevanju). Sodobne aplikacije so zasnovane od samega za\u010detka upo\u0161tevajo\u010d ta dejavnik. Na splo\u0161no je vsaka sodobna aplikacija, ki obdeluje podatke razli\u010dnih vrst (dnevniki, metapodatki, blobi itd.), zgrajena po obla\u010dno usmerjeni paradigmi, kjer se stanje prenese v posebno programsko opremo, namenjeno shranjevanju. <\/p>\n

Kontejnerski pristop s shranjevanjem stanja prisili celotno to paradigmo, da se vrne nazaj to\u010dno tja, kjer se je za\u010dela! <\/b><\/i><\/p>\n

Pri uporabi POSIX vmesnikov za shranjevanje podatkov aplikacije delujejo tako, kot da bi ohranjale stanje, kar jih oddaljuje od najpomembnej\u0161ih na\u010del oblikovanja v oblaku, tj. mo\u017enosti prilagajanja velikosti delovnih tokov aplikacije glede na prihajajo\u010do obremenitev, premikanja na nov vozli\u0161\u010de takoj, ko trenutno vozli\u0161\u010de odpove, in tako naprej.<\/p>\n

Ko se natan\u010dneje osredoto\u010dimo na to situacijo, ugotovimo, da se pri izbiri shranjevanja podatkov znova in znova soo\u010damo z dilemo \"POSIX proti REST API\", VENDAR s dodatnim ote\u017enjem te\u017eav POSIX, ki izhajajo iz porazdeljene narave okolij Kubernetes. Zlasti,<\/p>\n