Čau Habr!
Připomínáme, že jsme vydali další mimořádně zajímavou a užitečnou o vzorech Kubernetes. Stále to začalo s"Brendan Burns, a mimochodem, pracujte v tomto segmentu s námi . Dnes vás zveme k přečtení článku z blogu MinIO, který stručně nastiňuje trendy a specifika vzorů ukládání dat v Kubernetes.
Kubernetes zásadně změnil tradiční vzorce vývoje a nasazení aplikací. Vývoj, testování a nasazení aplikace v různých prostředích, to vše v clusterech Kubernetes, nyní může týmu trvat několik dní. Taková práce s technologiemi předchozí generace trvala obvykle celé týdny, ne-li měsíce.
Toto zrychlení je umožněno abstrakcí poskytovanou Kubernetes - to znamená skutečností, že Kubernetes sám interaguje s nízkoúrovňovými detaily fyzických nebo virtuálních strojů, což umožňuje uživatelům deklarovat kromě jiných parametrů požadovaný procesor, požadované množství paměti, počet instancí kontejneru. S obrovskou komunitou podporující Kubernetes a stále rostoucím používáním Kubernetes je zdaleka lídrem všech platforem pro orchestraci kontejnerů.
Jak roste používání Kubernetes, roste i zmatek ohledně vzorců úložiště..
Při vší konkurenci o kus koláče Kubernetes (tedy pro ukládání dat), když dojde na ukládání dat, je zde signál utopen ve velkém šumu.
Kubernetes ztělesňuje moderní model pro vývoj, nasazení a správu aplikací. Tento moderní model odděluje úložiště dat od výpočetní techniky. Chcete-li plně porozumět tomuto oddělení v kontextu Kubernetes, musíte také pochopit, co jsou stavové a bezstavové aplikace a jak do nich zapadá úložiště dat. Zde má přístup REST API používaný S3 jasné výhody oproti přístupu POSIX/CSI, který lze nalézt v jiných řešeních.
V tomto článku budeme hovořit o vzorcích úložiště v Kubernetes a samostatně se dotkneme debaty o perzistenci vs. bezstavové aplikace, abychom lépe pochopili, jaký je rozdíl a proč je důležitý. Dále v textu budou aplikace a vzory ukládání dat v nich používané ve světle osvědčených postupů pro práci s kontejnery a Kubernetes.
Bezstátní kontejnery
Kontejnery jsou od přírody lehké a pomíjivé. Lze je snadno zastavit, odstranit nebo nasadit na jiného hostitele, to vše během několika sekund. Ve velkém systému orchestrace kontejnerů se takové operace dějí neustále a uživatelé si takové změny ani nevšimnou. Přesuny jsou však možné pouze v případě, že kontejner nemá žádné závislosti na hostiteli, na kterém se nachází. Takové nádoby prý fungují bez státní příslušnosti.
Stavové kontejnery
Pokud kontejner ukládá data na místně připojených zařízeních (nebo na blokovém zařízení), pak se úložiště dat, na kterém se nachází, bude muset v případě selhání přesunout na nového hostitele spolu se samotným kontejnerem. To je důležité, protože jinak aplikace spuštěná v kontejneru nebude schopna správně fungovat, protože potřebuje přístup k datům uloženým na lokálních médiích. Takové nádoby prý fungují stavový.
Z čistě technického hlediska lze stavové kontejnery přesunout i do jiných uzlů. Toho je obvykle dosaženo prostřednictvím distribuovaných souborových systémů nebo blokového síťového úložiště připojeného ke všem uzlům, na kterých běží kontejnery. Kontejnery tak získají přístup ke svazkům pro trvalé ukládání dat a informace jsou uloženy na discích umístěných v celé síti. Tuto metodu budu nazývatstavový kontejnerový přístup“, a ve zbytku článku to tak budu pro jednotnost označovat.
V typickém stavovém kontejnerovém přístupu jsou všechny aplikační moduly připojeny k jedinému distribuovanému systému souborů – jakési sdílené úložiště, kde jsou uložena všechna aplikační data. I když jsou možné některé varianty, jedná se o přístup na vysoké úrovni.
Nyní se podívejme, proč je kontejnerizovaný, stavový přístup anti-vzorec ve světě zaměřeném na cloud.
Návrh aplikací založených na cloudu
Aplikace tradičně používaly databáze pro strukturované ukládání informací a místní disky nebo distribuované souborové systémy, kam byla ukládána všechna nestrukturovaná nebo dokonce polostrukturovaná data. Jak objem nestrukturovaných dat rostl, vývojáři si uvědomili, že POSIX je příliš „upovídaný“, s sebou nese značnou režii a nakonec brání aplikaci v přechodu do skutečně velkých měřítek.
To v podstatě přispělo ke vzniku nového standardu ukládání dat, tedy cloudových úložišť, která fungují převážně na bázi REST API a osvobozují aplikaci od zatěžující údržby lokálního datového úložiště. V tomto případě aplikace skutečně přejde do bezstavového režimu (protože stav je ve vzdáleném úložišti). Moderní aplikace jsou vytvářeny od nuly s ohledem na tento faktor. Každá moderní aplikace, která zpracovává data toho či onoho druhu (logy, metadata, blob atd.), je zpravidla postavena podle paradigmatu orientovaného na cloud, kde je stav přenesen do softwarového systému speciálně určeného pro jeho uložení.
Stavový kontejnerový přístup způsobuje, že se celé toto paradigma vrací přesně tam, kde začalo!
Při použití rozhraní POSIX k ukládání dat se aplikace chovají, jako by byly stavové, a proto se odchylují od nejdůležitějších zásad cloud-centrického designu, tedy schopnosti měnit velikost aplikačních pracovních vláken v závislosti na vstupní zatížení, přesun do nového uzlu, jakmile aktuální uzel selže atd.
Při bližším pohledu na tuto situaci zjistíme, že při výběru datového úložiště znovu a znovu čelíme dilematu „POSIX vs. REST API“, ALE s dalším vyostřením problémů POSIX kvůli distribuované povaze prostředí Kubernetes. Zejména,
- POSIX upovídaný: Sémantika POSIX vyžaduje, aby byla ke každé operaci přidružena metadata a deskriptory souborů, aby se pomohl udržovat stav operace. To vede ke značným nákladům, které nemají žádnou skutečnou hodnotu. API pro ukládání objektů, konkrétně S3 API, se těchto požadavků zbavilo a umožnilo aplikaci spustit a následně „zapomenout“ na volání. Odezva úložného systému ukazuje, zda byla akce úspěšná nebo ne. Pokud selže, aplikace to může zkusit znovu.
- Síťová omezení: V distribuovaném systému se rozumí, že může existovat několik aplikací, které se pokoušejí zapisovat data na stejné připojené médium. Aplikace tedy nebudou soutěžit pouze o šířku pásma přenosu dat (za účelem odeslání dat na médium), ale o tuto šířku bude soutěžit samotný úložný systém, který bude posílat data přes fyzické disky. Kvůli upovídanosti POSIXu počet síťových hovorů několikrát roste. Na druhou stranu, S3 API poskytuje jasný rozdíl mezi síťovými voláními, která přicházejí z klienta na server, a těmi, která se dějí na serveru.
- zabezpečení: Bezpečnostní model POSIX je navržen pro aktivní lidskou účast: správci konfigurují specifické úrovně přístupu pro každého uživatele nebo skupinu. Takové paradigma je obtížné přizpůsobit světu zaměřenému na cloud. Moderní aplikace závisí na modelech zabezpečení založených na rozhraní API, kde jsou přístupová práva definována jako sada zásad, přidělené účty služeb, dočasná pověření a tak dále.
- Spravovatelnost: Stavové kontejnery mají určitou režii na správu. Jde o synchronizaci paralelního přístupu k datům, o zajištění konzistence dat, to vše vyžaduje pečlivé zvážení, jaké vzory přístupu k datům použít. Musíte instalovat, spravovat a konfigurovat další software, nemluvě o dalším vývoji.
Rozhraní kontejneru úložiště dat
Rozhraní Containerized Data Storage Interface (CSI) sice odvedlo skvělou práci při propagaci objemové vrstvy Kubernetes, částečně ji přeneslo na dodavatele datových úložišť třetích stran, ale také neúmyslně přispělo k přesvědčení, že stavový kontejnerový přístup je doporučenou metodou úložiště dat v Kubernetes.
CSI byl vyvinut jako standard pro poskytování libovolných blokových a souborových úložných systémů pro starší aplikace při práci s Kubernetes. A jak ukázal tento článek, jedinou situací, kdy má stavový kontejnerový přístup (a CSI v současné podobě) smysl, je situace, kdy samotná aplikace je starší systém, kde není možné přidat podporu pro API pro ukládání objektů.
Je důležité pochopit, že při použití CSI v jeho současné podobě, tedy při připojování objemů v moderních aplikacích, narazíme na problémy podobné těm, které máme v systémech, kde jsou data organizována ve stylu POSIX.
Lepší přístup
V tomto případě je důležité pochopit, že většina aplikací není ze své podstaty navržena speciálně pro stavovou nebo bezstavovou práci. Toto chování závisí na celkové architektuře systému a na konkrétních možnostech zvolených během návrhu. Promluvme si trochu o stavových aplikacích.
V zásadě lze všechna aplikační data rozdělit do několika širokých typů:
- Log Data
- Údaje o časovém razítku
- Údaje o transakci
- Metadata
- Obrázky kontejnerů
- Data blob (binární velký objekt).
Všechny tyto datové typy jsou velmi dobře podporovány na dnešních úložných platformách a existuje několik nativních cloudových platforem, které poskytují data v každém z těchto specifických formátů. Transakční data a metadata mohou být například uloženy v moderní cloudové databázi, jako je CockroachDB, YugaByte atd. Obrazy kontejnerů nebo data objektů blob lze uložit do registru dockerů založeného na MinIO. Data časových razítek mohou být uložena v databázi časových řad, jako je InfluxDB atd. Nebudeme se zde zabývat podrobnostmi jednotlivých typů dat a jejich příslušných aplikací, ale obecnou myšlenkou je vyhnout se trvalému ukládání dat na lokálně připojených discích.
Kromě toho je často efektivní poskytnout dočasnou mezipaměťovou vrstvu, která slouží jako jakési úložiště pro aplikace pro dočasné soubory, ale aplikace by na této vrstvě jako na zdroji pravdy neměly záviset.
Úložiště pro stavové aplikace
Zatímco ve většině případů je užitečné udržovat aplikace bez stavu, ty aplikace, které jsou navrženy k ukládání dat – jako jsou databáze, úložiště objektů, úložiště klíčů a hodnot – by měly být stavové. Podívejme se, proč jsou tyto aplikace nasazeny na Kubernetes. Vezměme si jako příklad MinIO, ale podobné principy platí pro jakékoli jiné velké cloudové úložné systémy.
Cloudové nativní aplikace jsou navrženy tak, aby využívaly flexibility vlastní kontejnerům. To znamená, že nedělají žádné předpoklady o prostředí, ve kterém budou nasazeny. Například MinIO používá vnitřní mechanismus kódování výmazu, který poskytuje systému dostatečnou odolnost, aby jej udržel v chodu, i když selže polovina disků. MinIO také spravuje integritu a bezpečnost dat pomocí vlastního hashování a šifrování na straně serveru.
Pro tyto cloudové nativní aplikace jsou místní trvalé svazky (PV) nejužitečnějším úložištěm záloh. Místní PV poskytuje možnost ukládat nezpracovaná data, zatímco aplikace běžící na těchto PV samy shromažďují informace pro škálování dat a správu rostoucích požadavků na data.
Tento přístup je mnohem jednodušší a mnohem škálovatelnější než PV založené na CSI, které do systému zavádějí vlastní úrovně správy dat a redundance; jde o to, že tyto vrstvy mají tendenci být v konfliktu se stavovými aplikacemi.
Postupně se posouváme směrem k oddělení dat od výpočetní techniky
V tomto článku jsme hovořili o tom, jak jsou aplikace přeorientovány tak, aby fungovaly bez ukládání stavu, nebo, jinými slovy, ukládání dat je ohraničeno od výpočtů na nich. Na závěr se podívejme na pár reálných příkladů takového trendu.
, slavná platforma pro analýzu dat, byla tradičně stavová a nasazená na souborovém systému HDFS. Jak však Spark přechází do světa zaměřeného na cloud, tato platforma se stále více používá bezestavová pomocí `s3a`. Spark používá s3a k předání stavu jiným systémům, zatímco kontejnery Spark samotné běží zcela bez stavu. Jiní velcí podnikoví hráči v oblasti analýzy velkých dat, zejména , , také přejít k práci s oddělením úložiště dat a výpočty na nich.
Podobné vzory lze také vidět na dalších hlavních analytických platformách, včetně Presto, Tensorflow až R, Jupyter. Přesunutím stavu do vzdálených cloudových úložných systémů je mnohem jednodušší spravovat a škálovat vaši aplikaci. Navíc přispívá k přenositelnosti aplikace v různých prostředích.
Zdroj: www.habr.com