Хей Хабр!
Напомняме, че пуснахме още един изключително интересен и полезен относно моделите на Kubernetes. Все пак започна с" Брендън Бърнс и, между другото, работи в този сегмент с нас . Днес ви каним да прочетете статия от блога MinIO, която накратко очертава тенденциите и спецификата на моделите за съхранение на данни в Kubernetes.
Kubernetes фундаментално промени традиционните модели на разработка и внедряване на приложения. Вече може да отнеме дни на екип, за да разработи, тества и внедри приложение в множество среди, всички в рамките на Kubernetes клъстери. Подобна работа с технологии от предишно поколение обикновено отнема цели седмици, ако не и месеци.
Това ускоряване става възможно благодарение на абстракцията, предоставена от Kubernetes - тоест от факта, че самият Kubernetes взаимодейства с детайлите на ниско ниво на физически или виртуални машини, позволявайки на потребителите да декларират, наред с други параметри, желания процесор, необходимото количество памет, броят екземпляри на контейнера. С огромна общност, подкрепяща Kubernetes и непрекъснато нарастващото използване на Kubernetes, той е далеч лидер сред всички платформи за оркестриране на контейнери.
С нарастването на използването на Kubernetes нараства и объркването относно моделите му за съхранение..
При цялата конкуренция за парче от пая Kubernetes (т.е. за съхранение на данни), когато става въпрос за съхранение на данни, сигналът тук е удавен в много шум.
Kubernetes въплъщава модерния модел за разработване, внедряване и управление на приложения. Този модерен модел отделя съхранението на данни от компютъра. За да разберете напълно това отделяне в контекста на Kubernetes, вие също трябва да разберете какво представляват приложенията със състояние и без състояние и как съхранението на данни се вписва в него. Това е мястото, където подходът REST API, използван от S3, има ясни предимства пред подхода POSIX/CSI, открит в други решения.
В тази статия ще говорим за моделите за съхранение в Kubernetes и отделно ще се докоснем до дебата за постоянство срещу приложение без състояние, за да разберем по-добре каква е разликата и защо е важна. По-нататък в текста приложенията и моделите за съхранение на данни, използвани в тях, ще бъдат разгледани в светлината на най-добрите практики за работа с контейнери и Kubernetes.
Контейнери без състояние
Контейнерите по природа са леки и ефимерни. Те могат лесно да бъдат спрени, премахнати или разположени на друг хост, всичко това за секунди. В система за оркестриране на големи контейнери такива операции се случват през цялото време и потребителите дори не забелязват подобни промени. Преместванията обаче са възможни само ако контейнерът няма никакви зависимости от хоста, на който се намира. Твърди се, че такива контейнери работят без гражданство.
Контейнери със състояние
Ако даден контейнер съхранява данни на локално свързани устройства (или на блоково устройство), тогава хранилището на данни, на което се намира, ще трябва да бъде преместено на нов хост заедно със самия контейнер в случай на повреда. Това е важно, защото в противен случай приложение, работещо в контейнер, няма да може да функционира правилно, тъй като трябва да има достъп до данни, съхранявани на локален носител. Твърди се, че такива контейнери работят състояние.
От чисто техническа гледна точка, контейнерите със състояние също могат да бъдат преместени в други възли. Това обикновено се постига чрез разпределени файлови системи или блоково мрежово съхранение, прикрепено към всички възли, работещи с контейнери. Така контейнерите получават достъп до обеми за постоянно съхранение на данни, а информацията се съхранява на дискове, разположени в цялата мрежа. Ще нарека този методконтейнеризиран подход със състояние”, и в останалата част от статията ще го наричам такъв с цел еднообразие.
При типичния контейнеризиран подход с поддържане на състоянието, всички пакети на приложения са прикрепени към една разпределена файлова система – вид споделено хранилище, където се намират всички данни на приложението. Въпреки че са възможни някои варианти, това е подход на високо ниво.
Сега нека да видим защо един контейнеризиран, поддържащ състоянието подход е анти-модел в свят, ориентиран към облак.
Дизайн на облачно базирано приложение
Традиционно приложенията използват бази данни за структурирано съхранение на информация и локални дискове или разпределени файлови системи, където всички неструктурирани или дори полуструктурирани данни се изхвърлят. Тъй като обемът на неструктурираните данни нарастваше, разработчиците осъзнаха, че POSIX е твърде „говорлив“, причинявайки значителни разходи и в крайна сметка възпрепятства преминаването на приложението към наистина големи мащаби.
Това основно допринесе за появата на нов стандарт за съхранение на данни, тоест облачно базирани хранилища, които работят главно на базата на REST API и освобождават приложението от натоварващата поддръжка на локалното съхранение на данни. В този случай приложението всъщност преминава в режим без състояние (защото състоянието е в отдалечено хранилище). Съвременните приложения се създават от нулата, като се има предвид този фактор. По правило всяко съвременно приложение, което обработва данни от един или друг вид (логове, метаданни, blobs и т.н.), е изградено според облачно-ориентирана парадигма, където състоянието се прехвърля към софтуерна система, специално предназначена за неговото съхранение.
Контейнерният подход с поддържане на състоянието кара цялата тази парадигма да се върне точно там, където е започнала!
Когато използват POSIX интерфейсите за съхраняване на данни, приложенията се държат така, сякаш са със състояние и поради това се отклоняват от най-важните принципи на дизайна, ориентиран към облака, т.е. способността да се променя размера на работните нишки на приложението в зависимост от входно натоварване, преместване на нов възел веднага щом текущият възел се повреди и т.н.
Разглеждайки по-отблизо тази ситуация, откриваме, че когато избираме хранилище за данни, ние отново и отново се изправяме пред дилемата „POSIX срещу REST API“, НО с допълнителното изостряне на проблемите с POSIX поради разпределения характер на Kubernetes средите. В частност,
- POSIX разговорлив: POSIX семантиката изисква метаданни и файлови дескриптори да бъдат свързани с всяка операция, за да се поддържа състоянието на операцията. Това води до значителни разходи, които нямат реална стойност. API за съхраняване на обекти, по-специално S3 API, се отърваха от тези изисквания, позволявайки на приложението да се задейства и след това да „забрави“ за повикването. Отговорът на системата за съхранение показва дали действието е било успешно или не. Ако не успее, приложението може да опита отново.
- Мрежови ограничения: В една разпределена система се разбира, че може да има множество приложения, които се опитват да записват данни на един и същ прикачен носител. Следователно не само приложенията ще се конкурират помежду си за честотна лента за пренос на данни (за да изпращат данни към носителя), самата система за съхранение ще се конкурира за тази честотна лента, изпращайки данни през физически дискове. Поради приказливостта на POSIX, броят на мрежовите разговори нараства няколко пъти. От друга страна, S3 API предоставя ясно разграничение между мрежовите повиквания, които идват от клиента към сървъра, и тези, които се случват в сървъра.
- сигурност: POSIX моделът за сигурност е проектиран за активно човешко участие: администраторите конфигурират специфични нива на достъп за всеки потребител или група. Такава парадигма е трудна за адаптиране към свят, ориентиран към облака. Съвременните приложения зависят от базирани на API модели за сигурност, където правата за достъп се дефинират като набор от политики, разпределят се акаунти за услуги, временни идентификационни данни и т.н.
- управляемост: Контейнерите със състояние имат някои допълнителни разходи за управление. Става дума за синхронизиране на паралелен достъп до данни, за осигуряване на съгласуваност на данните, всичко това изисква внимателно обмисляне на това кои модели за достъп до данни да се използват. Трябва да инсталирате, управлявате и конфигурирате допълнителен софтуер, да не говорим за допълнителните усилия за разработка.
Интерфейс на контейнер на хранилище за данни
Въпреки че Containerized Data Storage Interface (CSI) свърши страхотна работа за подпомагане на разпространението на обемния слой на Kubernetes, частично го разтовари на доставчици за съхранение на данни на трети страни, но също така по невнимание допринесе за убеждението, че подходът на контейнера със състояние е препоръчителният метод за съхранение на данни в Kubernetes.
CSI е разработен като стандарт за предоставяне на произволни блокови и файлови системи за съхранение на наследени приложения при работа с Kubernetes. И, както тази статия показа, единствената ситуация, в която подходът на контейнер със състояние (и CSI в сегашната му форма) има смисъл, е когато самото приложение е наследена система, където не е възможно да се добави поддръжка за API за съхранение на обекти.
Важно е да разберем, че използвайки CSI в сегашната му форма, тоест монтиране на томове в модерни приложения, ще се сблъскаме с проблеми, подобни на тези, които имаме в системи, където данните са организирани в стил POSIX.
По-добър подход
В този случай е важно да се разбере, че повечето приложения по своята същност не са проектирани специално за работа със състояние или без състояние. Това поведение зависи от цялостната архитектура на системата и от специфичните опции, избрани по време на проектирането. Нека поговорим малко за приложенията със състояние.
По принцип всички данни за приложения могат да бъдат разделени на няколко общи типа:
- Регистрационни данни
- Данни за времево клеймо
- Данни за транзакцията
- Метаданни
- Изображения на контейнери
- Blob (двоичен голям обект) данни
Всички тези типове данни се поддържат много добре в днешните платформи за съхранение и има няколко налични облачни платформи за доставяне на данни във всеки от тези специфични формати. Например данните за транзакциите и метаданните могат да се намират в модерна база данни, базирана на облак, като CockroachDB, YugaByte и др. Контейнерни изображения или blob данни могат да се съхраняват в докер регистър, базиран на MinIO. Данните за времеви клейма могат да се съхраняват в база данни с времеви серии като InfluxDB и др. Тук няма да навлизаме в подробности за всеки тип данни и съответните им приложения, но общата идея е да се избегне постоянното съхранение на данни на базата на локално монтирани дискове.
В допълнение, често е ефективно да се осигури временен кеш слой, който служи като вид хранилище за приложения за временни файлове, но приложенията не трябва да зависят от този слой като източник на истина.
Съхранение за приложения със състояние
Въпреки че в повечето случаи е полезно приложенията да се поддържат без състояние, онези приложения, които са проектирани да съхраняват данни - като бази данни, хранилища на обекти, хранилища на ключове и стойности - трябва да имат състояние. Нека да видим защо тези приложения се внедряват в Kubernetes. Да вземем MinIO като пример, но подобни принципи важат за всички други големи системи за съхранение, базирани на облак.
Облачните приложения са проектирани да се възползват от гъвкавостта, присъща на контейнерите. Това означава, че те не правят предположения за средата, в която ще бъдат разположени. Например, MinIO използва вътрешен механизъм за кодиране на изтриване, който осигурява на системата достатъчно устойчивост, за да продължи да работи дори ако половината дискове се повредят. MinIO също управлява целостта и сигурността на данните, използвайки собствено хеширане и криптиране от страна на сървъра.
За тези собствени в облака приложения локалните постоянни томове (PV) са най-полезното хранилище за архивиране. Локалният PV предоставя възможност за съхраняване на необработени данни, докато приложенията, работещи върху тези PV, събират информация самостоятелно, за да мащабират данните и да управляват нарастващите изисквания за данни.
Този подход е много по-опростен и много по-мащабируем от CSI-базирани PV, които въвеждат свои собствени нива на управление на данни и излишък в системата; въпросът е, че тези слоеве са склонни да влизат в конфликт с приложенията със състояние.
Стабилно се движи към отделяне на данните от изчисленията
В тази статия говорихме за това как приложенията се преориентират да работят без запазване на състоянието или, с други думи, съхранението на данни се разграничава от изчисленията върху тях. В заключение, нека да разгледаме няколко реални примера за такава тенденция.
, известната платформа за анализ на данни, традиционно е със състояние и е внедрена на файловата система HDFS. Въпреки това, тъй като Spark преминава към свят, ориентиран към облака, тази платформа все повече се използва без състояние, използвайки `s3a`. Spark използва s3a, за да предава състояние на други системи, докато самите контейнери на Spark работят изцяло без състояние. Други големи корпоративни играчи в областта на анализа на големи данни, по-специално, , , също така преминете към работа с разделянето на съхранението на данни и изчисленията върху тях.
Подобни модели могат да се видят и на други големи аналитични платформи, включително Presto, Tensorflow to R, Jupyter. Чрез разтоварване на състоянието към отдалечени облачни системи за съхранение става много по-лесно да управлявате и мащабирате вашето приложение. В допълнение, той допринася за преносимостта на приложението в различни среди.
Източник: www.habr.com