{"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\/cs\/blog\/administrirovanie\/patterny-hraneniya-dannyh-v-kubernetes","title":{"rendered":"Vzorov\u00e9 ukl\u00e1d\u00e1n\u00ed dat v Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

P\u0159ipom\u00edn\u00e1me, \u017ee jsme vydali dal\u0161\u00ed velmi zaj\u00edmav\u00fd a u\u017eite\u010dn\u00fd kniha<\/a><\/noindex> o vzorech Kubernetes. V\u0161echno to za\u010dalo s \"Vzory<\/a><\/noindex>\" Brendanem Burnsem, a mimochodem, pr\u00e1ce v tomto segmentu m\u00e1me vzkv\u00e9t\u00e1<\/a><\/noindex>. Dnes v\u00e1m nab\u00edz\u00edme p\u0159e\u010d\u00edst si \u010dl\u00e1nek z blogu MinIO, kter\u00fd stru\u010dn\u011b shrnuje tendence a specifika vzor\u016f ukl\u00e1d\u00e1n\u00ed dat v Kubernetes.
\n<\/a><\/noindex><\/p>\n

Kubernetes z\u00e1sadn\u011b zm\u011bnil tradi\u010dn\u00ed vzory v\u00fdvoje a nasazen\u00ed aplikac\u00ed. Nyn\u00ed m\u016f\u017ee t\u00fdmu trvat jen n\u011bkolik dn\u00ed na v\u00fdvoj, testov\u00e1n\u00ed a nasazen\u00ed aplikace \u2013 v r\u016fzn\u00fdch prost\u0159ed\u00edch, a to v\u0161e v r\u00e1mci cluster\u016f Kubernetes. Takov\u00e1 pr\u00e1ce s technologiemi minul\u00fdch generac\u00ed obvykle trvala cel\u00e9 t\u00fddny, ne-li m\u011bs\u00edce.<\/p>\n

Toto zrychlen\u00ed bylo mo\u017en\u00e9 d\u00edky abstrakci, kterou Kubernetes poskytuje \u2013 tedy proto, \u017ee Kubernetes samo realizuje interakci s n\u00edzko\u00farov\u0148ov\u00fdmi detaily fyzick\u00fdch nebo virtu\u00e1ln\u00edch stroj\u016f, umo\u017e\u0148uj\u00edc\u00ed u\u017eivatel\u016fm deklarovat mimo jin\u00e9 pot\u0159ebn\u00fd procesor, pot\u0159ebn\u00e9 mno\u017estv\u00ed pam\u011bti, po\u010det instanc\u00ed kontejner\u016f. Vzhledem k tomu, \u017ee o podporu Kubernetes se star\u00e1 obrovsk\u00e9 spole\u010denstv\u00ed a rozsah pou\u017e\u00edv\u00e1n\u00ed Kubernetes se neust\u00e1le roz\u0161i\u0159uje, jednozna\u010dn\u011b vede p\u0159ed ostatn\u00edmi platformami pro orchestraci kontejner\u016f.<\/p>\n

Jak se pou\u017e\u00edv\u00e1n\u00ed Kubernetes roz\u0161i\u0159uje, roste i zmatek ohledn\u011b vzor\u016f ukl\u00e1d\u00e1n\u00ed dat, kter\u00e9 se v n\u011bm pou\u017e\u00edvaj\u00ed.<\/b><\/i>.<\/p>\n

P\u0159i v\u0161eobecn\u00e9 konkurenci o kousek kol\u00e1\u010de Kubernetes (tedy o ukl\u00e1d\u00e1n\u00ed dat), kdy\u017e dojde na \u0159e\u010d o ukl\u00e1d\u00e1n\u00ed dat, sign\u00e1l zde tonie ve siln\u00e9m \u0161umu.
\nKubernetes p\u0159edstavuje sou\u010dasn\u00fd model v\u00fdvoje a nasazen\u00ed aplikac\u00ed, stejn\u011b jako jejich spr\u00e1vu. Tento modern\u00ed model odd\u011bluje ukl\u00e1d\u00e1n\u00ed dat od v\u00fdpo\u010dt\u016f. Abychom pln\u011b pochopili toto odd\u011blen\u00ed v kontextu Kubernetes, mus\u00edme tak\u00e9 porozum\u011bt tomu, co jsou aplikace pracuj\u00edc\u00ed se zachov\u00e1n\u00edm stavu a bez zachov\u00e1n\u00ed stavu, a jak se k tomu vztahuje ukl\u00e1d\u00e1n\u00ed dat. Pr\u00e1v\u011b zde p\u0159\u00edstup REST API, kter\u00fd pou\u017e\u00edv\u00e1 S3, m\u00e1 z\u0159eteln\u00e9 v\u00fdhody oproti p\u0159\u00edstupu POSIX\/CSI, kter\u00fd je charakteristick\u00fd pro jin\u00e1 \u0159e\u0161en\u00ed.<\/p>\n

V tomto \u010dl\u00e1nku se budeme zab\u00fdvat vzory ukl\u00e1d\u00e1n\u00ed dat v Kubernetes a podrobn\u011b se dotkneme debaty o aplikac\u00edch provozovan\u00fdch bez stavu a s ulo\u017een\u00edm stavu, abychom dob\u0159e pochopili, v \u010dem spo\u010d\u00edv\u00e1 rozd\u00edl mezi nimi a pro\u010d je d\u016fle\u017eit\u00fd. V textu budou tak\u00e9 zva\u017eov\u00e1ny aplikace a vzory ukl\u00e1d\u00e1n\u00ed dat pou\u017e\u00edvan\u00e9 v souladu s nejlep\u0161\u00edmi praktikami pr\u00e1ce s kontejnery a Kubernetes.<\/p>\n

Kontejnery bez ukl\u00e1d\u00e1n\u00ed stavu<\/h4>\n

\nKontejnery jsou ze sv\u00e9 podstaty lehk\u00e9 a efem\u00e9rn\u00ed. Lze je snadno zastavit, odstranit nebo nasadit na jin\u00e9m uzlu \u2013 na to v\u0161e sta\u010d\u00ed jen n\u011bkolik sekund. V rozs\u00e1hl\u00e9m syst\u00e9mu orchestrace kontejner\u016f se tyto operace odehr\u00e1vaj\u00ed neust\u00e1le a u\u017eivatel\u00e9 si ani nev\u0161imnou t\u011bchto zm\u011bn. Av\u0161ak, p\u0159esuny jsou mo\u017en\u00e9 pouze tehdy, pokud kontejner nem\u00e1 \u017e\u00e1dn\u00e9 z\u00e1vislosti na uzlu, na kter\u00e9m je um\u00edst\u011bn. O takov\u00fdch kontejnerech se \u0159\u00edk\u00e1, \u017ee funguj\u00ed bez ukl\u00e1d\u00e1n\u00ed stavu<\/i>.<\/p>\n

Kontejnery s ukl\u00e1d\u00e1n\u00edm stavu<\/h4>\n

\nPokud kontejner ukl\u00e1d\u00e1 data na lok\u00e1ln\u011b p\u0159ipojen\u00e1 za\u0159\u00edzen\u00ed (nebo na blokov\u00e9 za\u0159\u00edzen\u00ed), pak bude t\u0159eba p\u0159esunout datov\u00e9 \u00falo\u017ei\u0161t\u011b, na kter\u00e9m se nach\u00e1z\u00ed, na nov\u00fd uzel spole\u010dn\u011b s kontejnerem \u2013 v p\u0159\u00edpad\u011b selh\u00e1n\u00ed. To je d\u016fle\u017eit\u00e9, proto\u017ee jinak aplikace spu\u0161t\u011bn\u00e1 v kontejneru nebude spr\u00e1vn\u011b fungovat, proto\u017ee mus\u00ed m\u00edt p\u0159\u00edstup k dat\u016fm ulo\u017een\u00fdm na lok\u00e1ln\u00edch m\u00e9di\u00edch. O takov\u00fdch kontejnerech se \u0159\u00edk\u00e1, \u017ee funguj\u00ed s ukl\u00e1d\u00e1n\u00edm stavu<\/i>.<\/p>\n

Z \u010dist\u011b technick\u00e9ho hlediska je mo\u017en\u00e9 tak\u00e9 p\u0159esouvat kontejnery s ukl\u00e1d\u00e1n\u00edm stavu na jin\u00e9 uzly. Obvykle je to zaji\u0161t\u011bno pomoc\u00ed distribuovan\u00fdch souborov\u00fdch syst\u00e9m\u016f nebo blokov\u00fdch s\u00ed\u0165ov\u00fdch \u00falo\u017ei\u0161\u0165 dat p\u0159ipojen\u00fdch ke v\u0161em uzl\u016fm, na kter\u00fdch kontejnery b\u011b\u017e\u00ed. T\u00edmto zp\u016fsobem kontejnery z\u00edsk\u00e1vaj\u00ed p\u0159\u00edstup k objem\u016fm pro trval\u00e9 ukl\u00e1d\u00e1n\u00ed dat a informace se ukl\u00e1daj\u00ed na disc\u00edch rozm\u00edst\u011bn\u00fdch po cel\u00e9 s\u00edti. Tuto metodu naz\u00fdv\u00e1mkontejnerov\u00fdm p\u0159\u00edstupem s ukl\u00e1d\u00e1n\u00edm stavu<\/i>a v zbytek \u010dl\u00e1nku ji tak budu naz\u00fdvat pro jednotnost.<\/p>\n

\"Vzorov\u00e9
\n
\nP\u0159i typick\u00e9m kontejnerov\u00e9m p\u0159\u00edstupu se zachov\u00e1n\u00edm stavu jsou v\u0161echny pod\u0159\u00edzen\u00e9 aplikac\u00ed p\u0159ipojeny k jedn\u00e9 distribuovan\u00e9 souborov\u00e9 soustav\u011b \u2013 co\u017e vytvo\u0159\u00ed jakousi sd\u00edlenou pam\u011b\u0165, kde se nach\u00e1zej\u00ed v\u0161echna data aplikac\u00ed. I kdy\u017e jsou mo\u017en\u00e9 ur\u010dit\u00e9 variace, je to p\u0159\u00edstup na vysok\u00e9 \u00farovni.<\/p>\n

Nyn\u00ed si poj\u010fme vysv\u011btlit, pro\u010d je kontejnerov\u00fd p\u0159\u00edstup se zachov\u00e1n\u00edm stavu v oble\u010dn\u00e9m sv\u011bt\u011b anti-vzorem.<\/p>\n

N\u00e1vrh aplikac\u00ed zam\u011b\u0159en\u00fd na cloud<\/h4>\n

\nTradi\u010dn\u011b aplikace pou\u017e\u00edvaly datab\u00e1ze pro strukturovan\u00e9 uchov\u00e1v\u00e1n\u00ed informac\u00ed a m\u00edstn\u00ed disky \u010di distribuovan\u00e9 souborov\u00e9 syst\u00e9my, kam se ukl\u00e1dala v\u0161echna nestrukturovan\u00e1 nebo dokonce polo-strukturovan\u00e1 data. Jak objem nestrukturovan\u00fdch dat rostl, v\u00fdvoj\u00e1\u0159i si uv\u011bdomili, \u017ee POSIX je p\u0159\u00edli\u0161 \"mluvn\u00fd\", spojen\u00fd s v\u00fdznamn\u00fdmi n\u00e1klady a nakonec br\u00e1n\u00ed fungov\u00e1n\u00ed aplikace p\u0159i p\u0159echodu na skute\u010dn\u011b velk\u00e9 m\u011b\u0159\u00edtka.<\/p>\n

To v\u0161e p\u0159isp\u011blo k vzniku nov\u00e9ho standardu uchov\u00e1v\u00e1n\u00ed dat, tedy cloudov\u011b orientovan\u00fdch \u00falo\u017ei\u0161\u0165, kter\u00e1 funguj\u00ed p\u0159ev\u00e1\u017en\u011b na z\u00e1klad\u011b REST API a osvobozuj\u00ed aplikaci od n\u00e1ro\u010dn\u00e9ho spravov\u00e1n\u00ed m\u00edstn\u00edho \u00falo\u017ei\u0161t\u011b dat. V takov\u00e9m p\u0159\u00edpad\u011b aplikace fakticky p\u0159ech\u00e1z\u00ed do re\u017eimu bez uchov\u00e1v\u00e1n\u00ed stavu (proto\u017ee stav se nach\u00e1z\u00ed v d\u00e1lkov\u00e9m \u00falo\u017ei\u0161ti). Modern\u00ed aplikace jsou budov\u00e1ny od z\u00e1klad\u016f s p\u0159ihl\u00e9dnut\u00edm k tomuto faktoru. Obvykle je ka\u017ed\u00e1 modern\u00ed aplikace, kter\u00e1 zpracov\u00e1v\u00e1 data jak\u00e9hokoli druhu (logy, metadata, blob atd.) postavena podle cloudov\u011b orientovan\u00e9 paradigmatiky, kde je stav p\u0159esunut do speci\u00e1ln\u011b vyhrazen\u00e9ho softwarov\u00e9ho syst\u00e9mu pro jeho uchov\u00e1v\u00e1n\u00ed. <\/p>\n

Kontejnerov\u00fd p\u0159\u00edstup se zachov\u00e1n\u00edm stavu nut\u00ed celou tuto paradigmu vr\u00e1tit se zp\u011bt k tomu, odkud za\u010dala! <\/b><\/i><\/p>\n

P\u0159i pou\u017eit\u00ed rozhran\u00ed POSIX pro ukl\u00e1d\u00e1n\u00ed dat aplikace funguj\u00ed stejn\u011b, jako by ukl\u00e1daly sv\u016fj stav, a t\u00edm se odkl\u00e1n\u011bj\u00ed od nejd\u016fle\u017eit\u011bj\u0161\u00edch postul\u00e1t\u016f cloudov\u011b orientovan\u00e9ho designu, tedy od mo\u017enosti m\u011bnit velikosti pracovn\u00edch tok\u016f aplikace podle p\u0159\u00edchoz\u00ed z\u00e1t\u011b\u017ee, p\u0159esouvat se na nov\u00fd uzel, jakmile aktu\u00e1ln\u00ed uzel sel\u017ee, a tak d\u00e1le.<\/p>\n

Pokud se pod\u00edv\u00e1me na tuto situaci bl\u00ed\u017ee, zjist\u00edme, \u017ee p\u0159i v\u00fdb\u011bru \u00falo\u017ei\u0161t\u011b dat se op\u011bt a op\u011bt setk\u00e1v\u00e1me s dilematem \"POSIX kontra REST API\", A TO S DAL\u0160\u00cdM ZES\u00cdLEN\u00cdM PROBL\u00c9M\u016e POSIX zp\u016fsoben\u00fdm distribuovanou povahou prost\u0159ed\u00ed Kubernetes. Zejm\u00e9na,<\/p>\n