{"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\/sv\/blog\/administrirovanie\/patterny-hraneniya-dannyh-v-kubernetes","title":{"rendered":"M\u00f6nster f\u00f6r datalagring i Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"M\u00f6nster<\/a><\/noindex>
\nHej, Habr!<\/p>\n

Vi p\u00e5minner om att vi har sl\u00e4ppt en ny, extremt intressant och anv\u00e4ndbar en bok<\/a><\/noindex> \u043e \u043f\u0430\u0442\u0442\u0435\u0440\u043d\u0430\u0445 Kubernetes. \u041d\u0430\u0447\u0438\u043d\u0430\u043b\u043e\u0441\u044c \u0432\u0441\u0435 \u0435\u0449\u0435 \u0441 "M\u00f6nster<\/a><\/noindex>" \u0411\u0440\u0435\u043d\u0434\u0430\u043d\u0430 \u0411\u0435\u0440\u043d\u0441\u0430, \u0438, \u0432\u043f\u0440\u043e\u0447\u0435\u043c, \u0440\u0430\u0431\u043e\u0442\u0430 \u0432 \u044d\u0442\u043e\u043c \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u0435 \u0443 \u043d\u0430\u0441 intensivt<\/a><\/noindex>. Idag erbjuder vi dig att l\u00e4sa ett inl\u00e4gg fr\u00e5n MinIO:s blogg som kortfattat redog\u00f6r f\u00f6r trenderna och specifikationen av datalagringsm\u00f6nster i Kubernetes.
\n<\/a><\/noindex><\/p>\n

Kubernetes har fundamentalt f\u00f6r\u00e4ndrat de traditionella m\u00f6nstren f\u00f6r utveckling och distribution av applikationer. Teamet kan nu ta bara n\u00e5gra dagar f\u00f6r att utveckla, testa och distribuera en applikation \u2013 i olika milj\u00f6er, allt inom Kubernetes-kluster. Ett s\u00e5dant arbete med tidigare generationers teknik tog vanligtvis flera veckor, om inte m\u00e5nader.<\/p>\n

Denna acceleration blev m\u00f6jlig tack vare den abstraktion som Kubernetes erbjuder \u2014 det vill s\u00e4ga, tack vare att Kubernetes sj\u00e4lv hanterar interaktionen med de l\u00e5gniv\u00e5detaljer av fysiska eller virtuella maskiner, vilket g\u00f6r att anv\u00e4ndarna kan specificera bland annat den \u00f6nskade processorn, den \u00f6nskade m\u00e4ngden minne och antalet instanser av containrar. Eftersom en enorm gemenskap \u00e4r engagerad i att st\u00f6dja Kubernetes och anv\u00e4ndningen av Kubernetes st\u00e4ndigt v\u00e4xer, leder den med stor marginal bland alla plattformar f\u00f6r orkestrering av containrar.<\/p>\n

I takt med att anv\u00e4ndningen av Kubernetes \u00f6kar, v\u00e4xer ocks\u00e5 f\u00f6rvirringen kring de datalagringsm\u00f6nster som anv\u00e4nds i den.<\/b><\/i>.<\/p>\n

Vid den allm\u00e4nna konkurrensen om en bit av kakan (dvs. datalagring), n\u00e4r det kommer till datalagring, drunknar signalen i ett starkt brus.
\nKubernetes representerar den moderna modellen f\u00f6r utveckling och distribution av applikationer samt hanteringen av dem. Denna moderna modell frikopplar datalagring fr\u00e5n ber\u00e4kningar. F\u00f6r att helt f\u00f6rst\u00e5 denna frikoppling i samband med Kubernetes \u00e4r det ocks\u00e5 n\u00f6dv\u00e4ndigt att f\u00f6rst\u00e5 vad som menas med applikationer som arbetar med och utan tillst\u00e5nd, samt hur datalagring passar in i detta. H\u00e4r har REST API-ansatsen, som anv\u00e4nds av S3, tydliga f\u00f6rdelar j\u00e4mf\u00f6rt med den POSIX\/CSI-ansats som \u00e4r typisk f\u00f6r andra l\u00f6sningar.<\/p>\n

I den h\u00e4r artikeln kommer vi att prata om m\u00f6nster f\u00f6r datalagring i Kubernetes och vi kommer s\u00e4rskilt att ber\u00f6ra diskussionen om applikationer som arbetar med och utan best\u00e5ende tillst\u00e5nd, f\u00f6r att verkligen f\u00f6rst\u00e5 vad som skiljer dem \u00e5t och varf\u00f6r det \u00e4r viktigt. H\u00e4refter kommer applikationer och de m\u00f6nster f\u00f6r datalagring som anv\u00e4nds i dem att diskuteras utifr\u00e5n b\u00e4sta praxis f\u00f6r arbete med containrar och Kubernetes.<\/p>\n

Containrar utan best\u00e5ende tillst\u00e5nd<\/h4>\n

\nContainrar \u00e4r per definition l\u00e4tta och efem\u00e4ra. De kan l\u00e4tt stoppas, tas bort eller distribueras p\u00e5 en annan nod \u2013 allt detta tar bara n\u00e5gra sekunder. I stora system f\u00f6r orkestrering av containrar sker s\u00e5dana operationer hela tiden, och anv\u00e4ndarna l\u00e4gger knappt m\u00e4rke till dessa f\u00f6r\u00e4ndringar. Emellertid \u00e4r flyttningar m\u00f6jliga endast om containern inte har n\u00e5gra beroenden fr\u00e5n den nod d\u00e4r den \u00e4r placerad. S\u00e5dana containrar s\u00e4gs arbeta utan best\u00e5ende tillst\u00e5nd<\/i>.<\/p>\n

Containrar med best\u00e5ende tillst\u00e5nd<\/h4>\n

\nOm en container lagrar data p\u00e5 lokalt anslutna enheter (eller p\u00e5 blockenheter), m\u00e5ste datalagret som det ligger p\u00e5 flyttas till en ny nod tillsammans med sj\u00e4lva containern \u2013 vid ett fel. Detta \u00e4r viktigt, eftersom annars kan inte applikationen som k\u00f6rs i containern fungera korrekt, eftersom den m\u00e5ste komma \u00e5t data som lagras p\u00e5 lokala medium. S\u00e5dana containrar s\u00e4gs arbeta med best\u00e5ende tillst\u00e5nd<\/i>.<\/p>\n

Ur en rent teknisk synvinkel kan containrar med best\u00e5ende tillst\u00e5nd ocks\u00e5 flyttas till andra noder. Detta uppn\u00e5s vanligtvis genom distribuerade filsystem eller blocklagringssystem knutna till alla noder d\u00e4r containrarna k\u00f6rs. P\u00e5 s\u00e5 s\u00e4tt f\u00e5r containrarna \u00e5tkomst till volymer f\u00f6r best\u00e5ende datalagring, och informationen lagras p\u00e5 diskar som finns spridda \u00f6ver hela n\u00e4tverket. Denna metod kommer jag att kalla \"containeranslaget med best\u00e5ende tillst\u00e5nd<\/i>\", och i resten av artikeln kommer jag att referera till det p\u00e5 detta s\u00e4tt f\u00f6r enhetlighet.<\/p>\n

\"M\u00f6nster
\n
\nVid en typisk containeransats med beh\u00e5llning av tillst\u00e5nd binds alla applikationens pods till ett distribuerat filsystem \u2013 det blir en slags delad lagring d\u00e4r all applikationsdata finns. \u00c4ven om det kan finnas vissa variationer, \u00e4r detta en h\u00f6g niv\u00e5 av tillv\u00e4gag\u00e5ngss\u00e4tt.<\/p>\n

L\u00e5t oss nu utforska varf\u00f6r beh\u00e5llande av tillst\u00e5nd i en containeransats i en molncentrerad v\u00e4rld \u00e4r ett antipattern.<\/p>\n

Molncentrerad applikationsdesign<\/h4>\n

\nTraditionellt anv\u00e4nde applikationer databaser f\u00f6r strukturerad informationslagring och lokala enheter eller distribuerade filsystem d\u00e4r all icke-strukturerad eller halvstrukturerad data sparades. I takt med att volymen av icke-strukturerad data \u00f6kade, ins\u00e5g utvecklarna att POSIX var alltf\u00f6r \"pratsam\", med betydande kostnader och, i slut\u00e4ndan, hindrade applikationens funktionalitet n\u00e4r det kom till verkligt stora skalor.<\/p>\n

Detta bidrog huvudsakligen till framv\u00e4xten av en ny datalagringsstandard, det vill s\u00e4ga molncentrerade lagringssystem som fr\u00e4mst fungerar via REST API och avlastar applikationen fr\u00e5n b\u00f6rdan av att underh\u00e5lla lokal datalagring. I det h\u00e4r fallet arbetar applikationen faktiskt i ett tillst\u00e5ndsl\u00f6st l\u00e4ge (eftersom tillst\u00e5ndet finns i det fj\u00e4rrlagrade systemet). Moderna applikationer byggs fr\u00e5n grunden med h\u00e4nsyn till denna faktor. Generellt sett \u00e4r varje modern applikation som hanterar data av olika slag (loggar, metadata, blobs etc.) konstruerad utifr\u00e5n en molncentrerad paradigm d\u00e4r tillst\u00e5ndet flyttas till ett specifikt programvarusystem avsett f\u00f6r dess lagring. <\/p>\n

Den containerbaserade ansatsen med beh\u00e5llning av tillst\u00e5nd tvingar hela denna paradigm att \u00e5terv\u00e4nda till exakt det d\u00e4r det b\u00f6rjade! <\/b><\/i><\/p>\n

N\u00e4r man anv\u00e4nder POSIX-gr\u00e4nssnitt f\u00f6r lagring av data fungerar applikationerna p\u00e5 samma s\u00e4tt som om de sparade tillst\u00e5nd, och p\u00e5 grund av detta avviker de fr\u00e5n de mest grundl\u00e4ggande postulaten f\u00f6r molnorienterad design, det vill s\u00e4ga m\u00f6jligheten att variera storlekarna p\u00e5 applikationens arbetsfl\u00f6den beroende p\u00e5 den inkommande belastningen, flytta till en ny nod s\u00e5 snart den aktuella noden misslyckas, och s\u00e5 vidare.<\/p>\n

N\u00e4r vi granskar denna situation mer noggrant uppt\u00e4cker vi att vi vid valet av datalagring g\u00e5ng p\u00e5 g\u00e5ng st\u00e4lls inf\u00f6r dilemmat \"POSIX kontra REST API\", MEN med en ytterligare f\u00f6rv\u00e4rring av POSIX-problemen, vilket beror p\u00e5 den distribuerade naturen hos Kubernetes-milj\u00f6er. Specifikt,<\/p>\n