{"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\/ro\/blog\/administrirovanie\/patterny-hraneniya-dannyh-v-kubernetes","title":{"rendered":"Modele de stocare a datelor \u00een Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Modele<\/a><\/noindex>
\nSalut, Habr!<\/p>\n

\u00ce\u021bi reamintim c\u0103 a ap\u0103rut un nou articol extrem de interesant \u0219i util carte<\/a><\/noindex> despre tiparele Kubernetes. Totul a \u00eenceput cuModelele<\/a><\/noindex>Brendan Burns, iar, de altfel, activitatea noastr\u0103 \u00een acest domeniu este intens\u0103<\/a><\/noindex>. Ast\u0103zi, \u00ee\u021bi propunem s\u0103 cite\u0219ti un articol din blogul MinIO, care rezum\u0103 tendin\u021bele \u0219i specificul modelelor de stocare a datelor \u00een Kubernetes.
\n<\/a><\/noindex><\/p>\n

Kubernetes a schimbat fundamental modelele tradi\u021bionale de dezvoltare \u0219i implementare a aplica\u021biilor. Acum, echipele pot dezvolta, testa \u0219i implementa o aplica\u021bie \u00een c\u00e2teva zile \u2014 \u00een medii diferite, toate acestea \u00een cadrul clusterelor Kubernetes. O astfel de munc\u0103 cu tehnologiile din genera\u021biile anterioare ocupa de obicei s\u0103pt\u0103m\u00e2ni \u00eentregi, dac\u0103 nu luni.<\/p>\n

Aceast\u0103 accelerare a devenit posibil\u0103 datorit\u0103 abstrac\u021biei oferite de Kubernetes \u2014 adic\u0103, datorit\u0103 faptului c\u0103 Kubernetes se ocup\u0103 de interac\u021biunile cu detaliile de nivel inferior ale ma\u0219inilor fizice sau virtuale, permi\u021b\u00e2nd utilizatorilor s\u0103 declare, printre altele, procesorul necesar, volumul de memorie dorit \u0219i num\u0103rul de instan\u021be ale containerelor. Av\u00e2nd \u00een vedere c\u0103 un imens comunitate se ocup\u0103 de suportul Kubernetes, iar domeniul de aplicare al Kubernetes continu\u0103 s\u0103 se extind\u0103, acesta conduce cu un avans considerabil \u00eentre toate platformele de orchestrare a containerelor.<\/p>\n

Pe m\u0103sur\u0103 ce utilizarea Kubernetes se extinde, confuzia cu privire la modelele de stocare a datelor utilizate \u00een acesta cre\u0219te<\/b><\/i>.<\/p>\n

\u00centr-o competi\u021bie general\u0103 pentru o parte din acest \"tort\" Kubernetes (adic\u0103, pentru stocarea datelor), atunci c\u00e2nd vine vorba de stocarea datelor, mesajul devine cufundat \u00eentr-un zgomot puternic.
\nKubernetes \u00eentruchipeaz\u0103 modelul modern de dezvoltare \u0219i implementare a aplica\u021biilor, precum \u0219i gestionarea acestora. Acest model modern separ\u0103 stocarea datelor de procesare. Pentru a \u00een\u021belege pe deplin aceast\u0103 separare \u00een contextul Kubernetes, este necesar s\u0103 \u00een\u021belegem ce sunt aplica\u021biile cu salvare a st\u0103rii \u0219i cele f\u0103r\u0103 salvare a st\u0103rii, precum \u0219i cum se \u00eembin\u0103 aceste concepte cu stocarea datelor. Aici, abordarea REST API utilizat\u0103 de S3 are avantaje evidente \u00een compara\u021bie cu abordarea POSIX\/CSI caracteristic\u0103 altor solu\u021bii.<\/p>\n

\u00cen acest articol vom discuta despre modele de stocare a datelor \u00een Kubernetes \u0219i vom aborda \u00een mod special dezbaterea despre aplica\u021biile care func\u021bioneaz\u0103 cu \u0219i f\u0103r\u0103 stocare persistent\u0103, pentru a \u00een\u021belege \u00een profunzime care este diferen\u021ba dintre ele \u0219i de ce este important\u0103. \u00cen textul de mai jos, vor fi exploreaz\u0103 aplica\u021biile \u0219i modelele de stocare a datelor utilizate \u00een lumina celor mai bune practici pentru lucrul cu containere \u0219i Kubernetes.<\/p>\n

Containere f\u0103r\u0103 stocare persistent\u0103<\/h4>\n

\nContainerele sunt, prin natura lor, u\u0219oare \u0219i efemere. Acestea pot fi oprite, \u0219terse sau desf\u0103\u0219urate pe un alt nod \u00een c\u00e2teva secunde. \u00centr-un sistem mare de orchestrare a containerelor, astfel de opera\u021biuni se desf\u0103\u0219oar\u0103 constant, iar utilizatorii aproape c\u0103 nu observ\u0103 aceste schimb\u0103ri. Totu\u0219i, mut\u0103rile sunt posibile doar dac\u0103 containerul nu are nicio dependen\u021b\u0103 de nodul pe care se afl\u0103. Despre aceste containere se spune c\u0103 func\u021bioneaz\u0103 f\u0103r\u0103 stocare persistent\u0103<\/i>.<\/p>\n

Containere cu stocare persistent\u0103<\/h4>\n

\nDac\u0103 un container stocheaz\u0103 date pe dispozitive local conectate (sau pe un dispozitiv bloc), atunci stocarea datelor pe care se afl\u0103 va trebui mutat\u0103 pe un nou nod \u00eempreun\u0103 cu containerul \u2013 \u00een caz de e\u0219ec. Acest lucru este important, deoarece, \u00een caz contrar, aplica\u021bia rulat\u0103 \u00een container nu va putea func\u021biona corect, deoarece trebuie s\u0103 acceseze datele stocate pe suporturi locale. Despre aceste containere se spune c\u0103 func\u021bioneaz\u0103 cu stocare persistent\u0103<\/i>.<\/p>\n

Dintr-o perspectiv\u0103 pur tehnic\u0103, containerele cu stocare persistent\u0103 pot fi, de asemenea, mutate pe alte noduri. Acest lucru este de obicei realizat prin intermediul sistemelor de fi\u0219iere distribuite sau a stoc\u0103rilor de date de re\u021bea ata\u0219ate la toate nodurile pe care func\u021bioneaz\u0103 containerele. Astfel, containerele au acces la volume pentru stocarea persistent\u0103 a datelor, iar informa\u021biile sunt stocate pe discuri dispersate \u00een re\u021bea. Aceast\u0103 metod\u0103 o voi numi \u201eabordarea containerelor cu stocare persistent\u0103<\/i>\u201d, iar \u00een restul articolului voi continua s\u0103 \u00eei spun a\u0219a pentru a men\u021bine uniformitatea.<\/p>\n

\"Modele
\n
\n\u00cen abordarea tipic\u0103 a containerelor cu p\u0103strarea st\u0103rii, toate modulele aplica\u021biilor se ata\u0219eaz\u0103 la un sistem de fi\u0219iere distribuit - astfel se ob\u021bine un fel de stocare comun\u0103, \u00een care se afl\u0103 toate datele aplica\u021biilor. Chiar dac\u0103 pot exista unele varia\u021bii, aceasta este o abordare la nivel \u00eenalt.<\/p>\n

Acum s\u0103 analiz\u0103m de ce abordarea containerelor cu p\u0103strarea st\u0103rii \u00een lumea orientat\u0103 spre cloud este un antipattern.<\/p>\n

Proiectarea aplica\u021biilor orientate spre cloud<\/h4>\n

\n\u00cen mod tradi\u021bional, aplica\u021biile foloseau baze de date pentru stocarea structurat\u0103 a informa\u021biilor \u0219i discuri locale sau sisteme de fi\u0219iere distribuite, unde erau stocate toate datele nestructurate sau chiar semi-structurate. Pe m\u0103sur\u0103 ce volumul datelor nestructurate cre\u0219tea, dezvoltatorii \u0219i-au dat seama c\u0103 POSIX este prea \"vorb\u0103re\u021b\", asociat cu costuri semnificative \u0219i, \u00een cele din urm\u0103, \u00eempiedic\u0103 func\u021bionarea aplica\u021biei atunci c\u00e2nd se trece la scale cu adev\u0103rat mari.<\/p>\n

Acest lucru a contribuit semnificativ la apari\u021bia unui nou standard de stocare a datelor, adic\u0103 stoc\u0103rile orientate spre cloud, care func\u021bioneaz\u0103 predominant pe baza REST API \u0219i \u00eenl\u0103tur\u0103 aplica\u021bia de greutatea \u00eentre\u021binerii stoc\u0103rii locale de date. \u00cen acest caz, aplica\u021bia intr\u0103, de fapt, \u00een modul f\u0103r\u0103 p\u0103strarea st\u0103rii (deoarece starea se afl\u0103 \u00een stocarea distant\u0103). Aplica\u021biile moderne sunt construite de la zero av\u00e2nd \u00een vedere acest factor. De obicei, orice aplica\u021bie modern\u0103 care proceseaz\u0103 date de orice fel (jurnale, metadate, BLOB-uri etc.) este construit\u0103 pe o paradigm\u0103 orientat\u0103 spre cloud, \u00een care starea este mutat\u0103 \u00eentr-un sistem software dedicat pentru stocarea acesteia. <\/p>\n

Abordarea containerelor cu p\u0103strarea st\u0103rii for\u021beaz\u0103 \u00eentreaga aceast\u0103 paradigm\u0103 s\u0103 revin\u0103 exact la \u00eenceput! <\/b><\/i><\/p>\n

C\u00e2nd folose\u0219ti interfe\u021bele POSIX pentru stocarea datelor, aplica\u021biile func\u021bioneaz\u0103 similar cu modul \u00een care ar salva starea, ceea ce le face s\u0103 se \u00eendep\u0103rteze de cele mai importante principii ale designului bazat pe cloud, adic\u0103 de capacitatea de a varia dimensiunile fluxurilor de lucru ale aplica\u021biei \u00een func\u021bie de \u00eenc\u0103rc\u0103tura de intrare, de a se muta pe un nou nod imediat ce nodul actual e\u0219ueaz\u0103 etc.<\/p>\n

Dac\u0103 ne uit\u0103m mai atent la aceast\u0103 situa\u021bie, observ\u0103m c\u0103 atunci c\u00e2nd alegem un stocare a datelor ne confrunt\u0103m din nou \u0219i din nou cu dilema \u201ePOSIX versus REST API\u201d, DAR cu o agravare suplimentar\u0103 a problemelor POSIX, cauzat\u0103 de natura distribuit\u0103 a mediilor Kubernetes. \u00cen special,<\/p>\n