{"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\/sk\/blog\/administrirovanie\/patterny-hraneniya-dannyh-v-kubernetes","title":{"rendered":"Vzory ukladania d\u00e1t v Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Vzory<\/a><\/noindex>
\nAhoj, Habr!<\/p>\n

Pripom\u00edname, \u017ee sme vydali \u010fal\u0161iu mimoriadne zauj\u00edmav\u00fa a u\u017eito\u010dn\u00fa knihu<\/a><\/noindex> o vzoroch Kubernetes. V\u0161etko sa za\u010dalo s \"Vzorov<\/a><\/noindex>\" Brendanom Burnsom, a inak, pr\u00e1ca v tomto segmente u n\u00e1s vrie<\/a><\/noindex>. Dnes v\u00e1m pon\u00fakame pre\u010d\u00edta\u0165 si \u010dl\u00e1nok z blogu MinIO, ktor\u00fd stru\u010dne zobrazuje trendy a \u0161pecifik\u00e1 vzorov ukladania \u00fadajov v Kubernetes.
\n<\/a><\/noindex><\/p>\n

Kubernetes z\u00e1sadne zmenil tradi\u010dn\u00e9 vzory v\u00fdvoja a nasadzovania aplik\u00e1ci\u00ed. Teraz m\u00f4\u017ee t\u00edm str\u00e1vi\u0165 len nieko\u013eko dn\u00ed na v\u00fdvoji, testovan\u00ed a nasaden\u00ed aplik\u00e1cie \u2013 v r\u00f4znych prostrediach, a to v\u0161etko v r\u00e1mci klastrov Kubernetes. Tak\u00e1to pr\u00e1ca s technol\u00f3giami predch\u00e1dzaj\u00facich gener\u00e1ci\u00ed oby\u010dajne trvala cel\u00e9 t\u00fd\u017edne, ak nie mesiace.<\/p>\n

Toto zr\u00fdchlenie sa stalo mo\u017en\u00fdm v\u010faka abstrakcii, ktor\u00fa Kubernetes poskytuje \u2013 to znamen\u00e1, \u017ee Kubernetes s\u00e1m uskuto\u010d\u0148uje interakciu s n\u00edzkovrstvov\u00fdmi detailmi fyzick\u00fdch alebo virtu\u00e1lnych strojov, pri\u010dom u\u017e\u00edvate\u013eom umo\u017e\u0148uje vyhlasova\u0165 medzi in\u00fdmi parametrami potrebn\u00fd procesor, potrebn\u00fd objem pam\u00e4te a po\u010det in\u0161tanci\u00ed kontajnerov. Ke\u010f\u017ee podporou Kubernetes je zaanga\u017eovan\u00e9 obrovsk\u00e9 spolo\u010denstvo a rozsah nasadenia Kubernetes sa neust\u00e1le roz\u0161iruje, s ve\u013ek\u00fdm odstupom vedie medzi v\u0161etk\u00fdmi platformami orchestr\u00e1cie kontajnerov.<\/p>\n

S rast\u00facim vyu\u017eit\u00edm Kubernetes sa zvy\u0161uje aj zm\u00e4tok oh\u013eadom vzorov ukladania \u00fadajov, ktor\u00e9 v \u0148om pou\u017e\u00edvaj\u00fa.<\/b><\/i>.<\/p>\n

Pri v\u0161eobecnej konkurencii o k\u00fasok kol\u00e1\u010da Kubernetes (teda o \u00falo\u017eisko \u00fadajov), ke\u010f sa hovor\u00ed o ulo\u017een\u00ed \u00fadajov, jej sign\u00e1l sa str\u00e1ca v silnom \u0161ume.
\nKubernetes zosob\u0148uje modern\u00fd model v\u00fdvoja a nasadzovania aplik\u00e1ci\u00ed, ako aj ich spr\u00e1vy. Tento modern\u00fd model oddeluje ukladanie \u00fadajov od v\u00fdpo\u010dtov. Aby ste plne pochopili tak\u00e9to oddelenie v kontexte Kubernetes, mus\u00edte tie\u017e pochopi\u0165, \u010do s\u00fa aplik\u00e1cie s uchovan\u00edm stavu a bez uchovania stavu a ako to s\u00favis\u00ed s ukladan\u00edm \u00fadajov. Tu m\u00e1 pr\u00edstup REST API, ktor\u00fd sa pou\u017e\u00edva v S3, zjavn\u00e9 v\u00fdhody v porovnan\u00ed s pr\u00edstupom POSIX\/CSI, charakteristick\u00fdm pre in\u00e9 rie\u0161enia.<\/p>\n

V tomto \u010dl\u00e1nku sa budeme rozpr\u00e1va\u0165 o vzoroch ukladania \u00fadajov v Kubernetes a osobitne sa dotkneme debaty o aplik\u00e1ci\u00e1ch funguj\u00facich s ukladan\u00edm a bez ukladania stavu, aby sme porozumeli, ak\u00fd je medzi nimi rozdiel a pre\u010do je to d\u00f4le\u017eit\u00e9. \u010ealej v texte bud\u00fa presk\u00faman\u00e9 aplik\u00e1cie a pou\u017eit\u00e9 vzory ukladania \u00fadajov v svetle osved\u010den\u00fdch prakt\u00edk pr\u00e1ce s kontajnermi a Kubernetes.<\/p>\n

Kontajnery bez ukladania stavu<\/h4>\n

\nKontajnery s\u00fa zo svojej podstaty \u013eahk\u00e9 a efem\u00e9rne. Mo\u017eno ich bez probl\u00e9mov zastavova\u0165, maza\u0165 alebo nasadzova\u0165 na in\u00fd uzol \u2013 v\u0161etko to trv\u00e1 len nieko\u013eko sek\u00fand. V ve\u013ekom syst\u00e9me orchestr\u00e1cie kontajnerov sa tak\u00e9to oper\u00e1cie dej\u00fa neust\u00e1le a pou\u017e\u00edvatelia si ani nev\u0161imn\u00fa tak\u00e9to zmeny. Av\u0161ak presuny s\u00fa mo\u017en\u00e9 iba vtedy, ak kontajner nem\u00e1 \u017eiadne z\u00e1vislosti od uzla, na ktorom sa nach\u00e1dza. O tak\u00fdch kontajneroch hovor\u00edme, \u017ee funguj\u00fa bez ukladania stavu<\/i>.<\/p>\n

Kontajnery s ukladan\u00edm stavu<\/h4>\n

\nAk kontajner uchov\u00e1va \u00fadaje na lok\u00e1lne pripojen\u00fdch zariadeniach (alebo na blokovom zariaden\u00ed), potom sa \u00falo\u017eisko \u00fadajov, na ktorom sa nach\u00e1dza, mus\u00ed presun\u00fa\u0165 na nov\u00fd uzol spolu s kontajnerom \u2013 v pr\u00edpade zlyhania. Je to d\u00f4le\u017eit\u00e9, preto\u017ee inak aplik\u00e1cia be\u017eiaca v kontajneri nebude schopn\u00e1 spr\u00e1vne fungova\u0165, ke\u010f\u017ee potrebuje pristupova\u0165 k \u00fadajom ulo\u017een\u00fdm na miestnych m\u00e9di\u00e1ch. O tak\u00fdch kontajneroch hovor\u00edme, \u017ee funguj\u00fa s ukladan\u00edm stavu<\/i>.<\/p>\n

Z \u010disto technick\u00e9ho h\u013eadiska je mo\u017en\u00e9 kontajnery s ukladan\u00edm stavu tie\u017e pres\u00fava\u0165 na in\u00e9 uzly. Obvykle to zabezpe\u010duje pomocou distribuovan\u00fdch s\u00faborov\u00fdch syst\u00e9mov alebo blokov\u00fdch sie\u0165ov\u00fdch \u00falo\u017e\u00edsk pripojen\u00fdch ku v\u0161etk\u00fdm uzlom, na ktor\u00fdch pracuj\u00fa kontajnery. T\u00fdmto sp\u00f4sobom kontajnery z\u00edskavaj\u00fa pr\u00edstup k objemom pre trval\u00e9 ukladanie \u00fadajov a inform\u00e1cie s\u00fa ulo\u017een\u00e9 na diskoch nach\u00e1dzaj\u00facich sa po celej sieti. Tento pr\u00edstup nazvem \u201ekontajnerov\u00fdm pr\u00edstupom s ukladan\u00edm stavu<\/i>\u201c, a v zost\u00e1vaj\u00facej \u010dasti \u010dl\u00e1nku ho tak budem naz\u00fdva\u0165 pre zachovanie jednotnosti.<\/p>\n

\"Vzory
\n
\nPri typickom pr\u00edstupe k softv\u00e9rov\u00fdm kontajnerom s udr\u017eiavan\u00edm stavu s\u00fa v\u0161etky pod aplik\u00e1ci\u00ed pripojen\u00e9 k jednej distribuovanej s\u00faborovej s\u00fastave \u2013 ide v podstate o ak\u00fasi zdie\u013ean\u00fa pam\u00e4\u0165, kde sa nach\u00e1dzaj\u00fa v\u0161etky d\u00e1ta aplik\u00e1ci\u00ed. Hoci s\u00fa mo\u017en\u00e9 niektor\u00e9 vari\u00e1cie, toto je vysokon\u00e1vrhov\u00fd pr\u00edstup.<\/p>\n

Teraz sa pozrime, pre\u010do je pr\u00edstup k softv\u00e9rov\u00fdm kontajnerom s udr\u017eiavan\u00edm stavu v prostred\u00ed orientovanom na cloud antipatrom.<\/p>\n

Cloudovo orientovan\u00e9 navrhovanie aplik\u00e1ci\u00ed<\/h4>\n

\nTradi\u010dne aplik\u00e1cie pou\u017e\u00edvali datab\u00e1zy na \u0161trukt\u00farovan\u00e9 ukladanie inform\u00e1ci\u00ed a lok\u00e1lne disky alebo distribuovan\u00e9 s\u00faborov\u00e9 syst\u00e9my, kam sa ukladali v\u0161etky ne\u0161trukt\u00farovan\u00e9 alebo dokonca polo\u0161trukt\u00farovan\u00e9 d\u00e1ta. S narastaj\u00facim objemom ne\u0161trukt\u00farovan\u00fdch d\u00e1t si v\u00fdvoj\u00e1ri uvedomili, \u017ee POSIX je pr\u00edli\u0161 \"rozpr\u00e1van\u00fd\", spojen\u00fd so zna\u010dn\u00fdmi n\u00e1kladmi a nakoniec br\u00e1ni \u010dinnosti aplik\u00e1cie pri prechode na naozaj ve\u013ek\u00e9 objemy.<\/p>\n

To v podstate viedlo k vzniku nov\u00e9ho \u0161tandardu ukladania d\u00e1t, t. j. cloudovo orientovan\u00fdch \u00falo\u017e\u00edsk, ktor\u00e9 pracuj\u00fa preva\u017ene na z\u00e1klade REST API a oslobodzuj\u00fa aplik\u00e1ciu od za\u0165a\u017eovania \u00fadr\u017ebou lok\u00e1lneho ukladania d\u00e1t. V takom pr\u00edpade aplik\u00e1cia vlastne prech\u00e1dza do re\u017eimu bez udr\u017eiavania stavu (ke\u010f\u017ee stav sa nach\u00e1dza v vzdialenom \u00falo\u017eisku). Modern\u00e9 aplik\u00e1cie s\u00fa vybudovan\u00e9 od nuly u\u017e s oh\u013eadom na tento faktor. Zvy\u010dajne je ak\u00e1ko\u013evek modern\u00e1 aplik\u00e1cia, ktor\u00e1 sprac\u00fava d\u00e1ta r\u00f4zneho druhu (logy, metad\u00e1ta, blob-y a pod.) postaven\u00e1 na cloudovo orientovanej paradigme, kde sa stav pres\u00fava do \u0161peci\u00e1lne ur\u010denej softv\u00e9rovej syst\u00e9my na jeho ulo\u017eenie. <\/p>\n

Pr\u00edstup k softv\u00e9rov\u00fdm kontajnerom s udr\u017eiavan\u00edm stavu n\u00fati cel\u00fa t\u00fato paradigmu vr\u00e1ti\u0165 sa presne tam, odkia\u013e za\u010d\u00ednala! <\/b><\/i><\/p>\n

Pri pou\u017e\u00edvan\u00ed rozhran\u00ed POSIX na ukladanie \u00fadajov aplik\u00e1cie funguj\u00fa rovnako, ako keby uchov\u00e1vali stav, a z tohto d\u00f4vodu sa odchyluj\u00fa od najd\u00f4le\u017eitej\u0161\u00edch postul\u00e1tov cloudov\u00e9ho dizajnu, t.j. od mo\u017enosti variabilne upravova\u0165 ve\u013ekosti pracovn\u00fdch tokov aplik\u00e1cie v z\u00e1vislosti od prich\u00e1dzaj\u00facej z\u00e1\u0165a\u017ee, presun\u00fa\u0165 sa na nov\u00fd uzol, hne\u010f ako aktu\u00e1lny uzol zlyh\u00e1, a podobne.<\/p>\n

Ke\u010f sa na t\u00fato situ\u00e1ciu pozrieme bli\u017e\u0161ie, zis\u0165ujeme, \u017ee pri v\u00fdbere \u00falo\u017eiska \u00fadajov sa op\u00e4\u0165 a op\u00e4\u0165 stret\u00e1vame s dilemou \u201ePOSIX vs. REST API\u201c, ALE so sp\u00f4soben\u00fdm zhor\u0161en\u00edm probl\u00e9mov POSIX, ktor\u00e9 vypl\u00fdva zo distribuovanej povahy prostred\u00ed Kubernetes. Konkr\u00e9tne,<\/p>\n