{"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 avaldanud veel \u00fche \u00e4\u00e4rmiselt huvitava ja kasuliku raamat<\/a><\/noindex> \u043e \u043f\u0430\u0442\u0442\u0435\u0440\u043d\u0430\u0445 Kubernetes. \u041d\u0430\u0447\u0438\u043d\u0430\u043b\u043e\u0441\u044c \u0432\u0441\u0435 \u0435\u0449\u0435 \u0441 "Mustritest<\/a><\/noindex>" \u0411\u0440\u0435\u043d\u0434\u0430\u043d\u0430 \u0411\u0435\u0440\u043d\u0441\u0430, \u0438, \u0432\u043f\u0440\u043e\u0447\u0435\u043c, \u0440\u0430\u0431\u043e\u0442\u0430 \u0432 \u044d\u0442\u043e\u043c \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u0435 \u0443 \u043d\u0430\u0441 aktiivne<\/a><\/noindex>. T\u00e4na pakume teile lugeda MinIO blogi artiklit, kus l\u00fchi\u00fclevaates kajastatakse andmete hoidmise mustrite trende ja spetsiifikat Kubernetes'es.
\n<\/a><\/noindex><\/p>\n

Kubernetes on fundamentaalselt muutnud traditsioonilisi rakenduste arendamise ja juurutamise mustreid. N\u00fc\u00fcd v\u00f5ib meeskonnal kuluda vaid paar p\u00e4eva rakenduse arendamiseks, testimiseks ja juurutamiseks - erinevates keskkondades, ja k\u00f5ik see Kubernetes'e klastrites. Selline t\u00f6\u00f6 varasemate p\u00f5lvkondade tehnoloogiatega v\u00f5ttis tavaliselt terveid n\u00e4dalad, kui mitte kuid.<\/p>\n

See kiirus on v\u00f5imalik t\u00e4nu Kubernetes'i poolt pakutud abstraktsioonile \u2014 see t\u00e4hendab, et Kubernetes ise tegeleb f\u00fc\u00fcsiliste v\u00f5i virtuaalmasinate madalama taseme detailidega, v\u00f5imaldades kasutajatel kuulutada teiste parameetrite seas vajaliku protsessori, vajaliku m\u00e4lu hulga ja konteinerite eksemplaride arvu. Kuna Kubernetes'e toetamine on suurte kogukondade tegevuse alla kuuluv ning selle rakendamise ulatus pidevalt laieneb, on ta kaugel k\u00f5igist konteinerite orkestreerimise platvormidest.<\/p>\n

Kuna Kubernetes'e kasutamine laieneb, suureneb ka segadus andmete salvestamise mustrite osas, mida selle s\u00f5numis kasutatakse.<\/b><\/i>.<\/p>\n

Kuna Kubernetes'e (st andmesalvestuse) jaoks k\u00e4ib \u00fcldine konkurents, siis kui jutt k\u00e4ib andmete salvestamisest, kaob signaal tugevas k\u00f5rvalhelis.
\nKubernetes esindab kaasaegset rakenduste arendamise ja juurutamise ning haldamise mudelit. See kaasaegne mudel eraldab andmete salvestamise arvutustest. Selle eraldamise t\u00e4ielikuks m\u00f5istmiseks kontekstis Kubernetes on samuti oluline m\u00f5ista, mis on olekuga ja olekuta rakendused, ning kuidas need sobituvad andmete salvestamisega. Just siin omab REST API l\u00e4henemine, mida rakendab S3, selgemaid eeliseid v\u00f5rreldes POSIX\/CSI l\u00e4henemisega, mis on iseloomulik teistele lahendustele.<\/p>\n

Selles artiklis arutame Kuberneteses andmete salvestamise mustreid ja k\u00e4sitleme eraldi vaidlust olekuga ja olekuta rakenduste vahel, et paremini m\u00f5ista nende vahe ja miks see on oluline. Artikli edaspidises osas vaadatakse rakendusi ning nende juures kasutatavaid andmete salvestamise mustreid konteinerite ja Kubernetesega parimate praktikate valguses.<\/p>\n

Olekuta konteinerid<\/h4>\n

\nKonteinerid on oma olemuselt kerged ja efemeersed. Neid saab h\u00f5lpsasti peatada, kustutada v\u00f5i m\u00f5nel teisel s\u00f5lmel k\u00e4ivitada \u2013 k\u00f5ik need toimingud v\u00f5tavad aega vaid sekundeid. Suures konteinerite orchestration s\u00fcsteemis toimuvad sellised operatsioonid pidevalt ning kasutajad ei pruugi neid muutusi isegi m\u00e4rkama. Kuid liikumised on v\u00f5imalikud ainult siis, kui konteineril ei ole mingeid s\u00f5ltuvusi s\u00f5lme, millel ta asub. Selliseid konteinereid kirjeldavad nad kui t\u00f6\u00f6tavaid ilma olekuta<\/i>.<\/p>\n

Olekuhoidvad konteinerid<\/h4>\n

\nKui konteiner salvestab andmeid kohalikult \u00fchendatud seadmetesse (v\u00f5i plokkseadmestikusse), tuleb andmesalv, millel ta asub, liigutada uuele s\u00f5lmele koos konteineriga \u2013 t\u00f5rke korral. See on oluline, kuna vastasel juhul ei suuda konteineris t\u00f6\u00f6tav rakendus korralikult funktsioneerida, kuna tal on vajalik juurdep\u00e4\u00e4s kohalikele salvestusseadmetele salvestatud andmetele. Selliseid konteinereid kirjeldavad nad kui t\u00f6\u00f6tavaid olekuhoidvatena<\/i>.<\/p>\n

Puhtalt tehnilisest vaatepunktist vaadatuna on olekuga konteinerid samuti v\u00f5imalik teisele s\u00f5lmele liikuda. Seda tavaliselt toetavad jaotatud failis\u00fcsteemid v\u00f5i plokip\u00f5hised v\u00f5rgukettavarud, mis on \u00fchendatud k\u00f5ikide s\u00f5lmedega, kus konteinerid t\u00f6\u00f6tavad. Nii saavad konteinerid juurde p\u00e4\u00e4seda mahutitele p\u00fcsiva andmete salvestamise jaoks ning teave salvestatakse kettale, mis asub kogu v\u00f5rgus. Seda meetodit nimetaksin \"olekuga konteinerite l\u00e4henemiseks<\/i>\" ja nimetaksin seda ka edaspidi sama v\u00e4ljendi t\u00f5ttu.<\/p>\n

\"Andmete
\n
\nT\u00fc\u00fcpilise olekuga konteinerite l\u00e4henemise puhul on k\u00f5ik rakenduste podid kinnitatud \u00fchele jaotatud failis\u00fcsteemile \u2013 see loob mingisuguse jagatud salvestuslahenduse, kus k\u00f5ik rakenduste andmed paiknevad. Kuigi on v\u00f5imalikud m\u00f5ned variatsioonid, on see k\u00f5rgetasemeline l\u00e4henemine.<\/p>\n

N\u00fc\u00fcd vaatame aga, miks olekuga konteinerite l\u00e4henemine pilvep\u00f5hisest maailmas on antimuster.<\/p>\n

Pilvep\u00f5hine rakenduste projekteerimine<\/h4>\n

\nTraditsiooniliselt kasutasid rakendused andmete struktureeritud salvestamiseks andmebaase ja kohalikke kettaid v\u00f5i jagatud failis\u00fcsteeme, kuhu suunati k\u00f5ik mittestruktureeritud v\u00f5i isegi osaliselt struktureeritud andmed. Kuid kui mittestruktureeritud andmete mahud kasvasid, tunnustasid arendajad, et POSIX on liiga \"lobus\" ning kaasneb m\u00e4rkimisv\u00e4\u00e4rsete kuludega, takistades l\u00f5puks rakenduse t\u00f6\u00f6 efektiivselt t\u00f5eliselt suurtes mahtudes.<\/p>\n

See peamiselt aitas kaasa uue andmesalvestuse standardsuse loomisele, nimelt pilvep\u00f5histe salvestuste s\u00fcsteemide ilmumisele, mis t\u00f6\u00f6tavad peamiselt REST API p\u00f5hjal ning vabastavad rakendused kohalikest andmesalvestuss\u00fcsteemidest. Sellisel juhul t\u00f6\u00f6tab rakendus t\u00f5eliselt olekuta, kuna olek asub eemal olevas salvestusruumis. T\u00e4nap\u00e4eva rakendused ehitatakse juba nullist arvesse v\u00f5ttes seda tegurit. \u00dcldiselt on iga kaasaegne rakendus, mis t\u00f6\u00f6tleb erinevat t\u00fc\u00fcpi andmeid (logid, metainfo, blobid jne), \u00fcles ehitatud pilvep\u00f5hise paradigma kohaselt, kus olek kolitakse spetsiaalselt tema hoidmiseks m\u00f5eldud tarkvaras\u00fcsteemi. <\/p>\n

Konteinerip\u00f5hine oleku s\u00e4ilitamine toob k\u00f5ik need paradigmad tagasi t\u00e4pselt sinna, kus nad algasid! <\/b><\/i><\/p>\n

Kui POSIX-liideseid andmete s\u00e4ilitamiseks kasutatakse, k\u00e4ituvad rakendused samamoodi kui siis, kui nad salvestavad olekud. Selle t\u00f5ttu k\u00f5rvaldatakse k\u00f5ige olulisemad pilvep\u00f5hise kujundamise postulaadid, nagu rakenduse t\u00f6\u00f6protsesside suuruse muutmine vastavalt sisendikoormusele, \u00fcleminek uuele s\u00f5lmele, kui praegune s\u00f5lm eba\u00f5nnestub, jne.<\/p>\n

Sellele olukorrale l\u00e4hemalt vaatates leiame, et andmehoidla valimisel puutume ikka ja j\u00e4lle kokku dilemmaga \"POSIX vs REST API\", kuid lisaks on POSIX-i probleemid s\u00fcvenenud Kubernetes'i jaotatud keskkondade t\u00f5ttu. Eriti,<\/p>\n