Hoi Habr!
Wy herinnerje jo dat wy in oare ekstreem nijsgjirrige en nuttich hawwe frijlitten oer Kubernetes patroanen. It begon allegear mei "" Brendan Burns, en, trouwens, wy hawwe wurk yn dit segmint . Hjoed noegje wy jo út om in artikel te lêzen fan it MinIO-blog dat koart de trends en spesifikaasjes fan patroanen foar gegevensopslach yn Kubernetes beskriuwt.
Kubernetes hat tradisjonele applikaasjeûntwikkeling en ynsetpatroanen fûneminteel feroare. No kin in team in applikaasje ûntwikkelje, testen en ynsette yn in kwestje fan dagen - oer meardere omjouwings, allegear binnen Kubernetes-klusters. Sok wurk mei eardere generaasjes technology duorre meastentiids wiken, as net moannen.
Dizze fersnelling wurdt mooglik makke troch de abstraksje levere troch Kubernetes - dat is, om't Kubernetes sels ynteraksje mei de leech-nivo details fan fysike of firtuele masines, wêrtroch brûkers de winske prosessor, de winske hoemannichte ûnthâld en it oantal kontener kinne ferklearje. eksimplaren, ûnder oare parameters. Mei in enoarme mienskip dy't Kubernetes stipet en it oannimmen dêrfan kontinu útwreidet, is Kubernetes de lieder ûnder alle kontenerorkestraasjeplatfoarms mei in brede marzje.
As it gebrûk fan Kubernetes groeit, groeit ek betizing oer har opslachpatroanen..
Mei elkenien dy't konkurrearret foar in stik fan 'e Kubernetes-pie (dus gegevens opslach), as it giet om it praten oer gegevensopslach, wurdt it sinjaal ferdronken yn in protte lûd.
Kubernetes ferbyldet in modern model foar applikaasjeûntwikkeling, ynset en behear. Dit moderne model ûntkoppelt gegevensopslach fan berekkening. Om ûntbining folslein te begripen yn 'e kontekst fan Kubernetes, moatte jo ek begripe wat steatlike en steatleaze applikaasjes binne, en hoe't gegevensopslach dêr yn past. Dit is wêr't de REST API-oanpak brûkt troch S3 dúdlike foardielen hat boppe de POSIX / CSI-oanpak fan oare oplossingen.
Yn dit artikel sille wy prate oer patroanen foar gegevensopslach yn Kubernetes en spesifyk oanreitsje op it debat tusken steatlike en steatleaze applikaasjes om better te begripen wat it ferskil tusken har is en wêrom it wichtich is. De rest fan 'e tekst sil sjen nei applikaasjes en har patroanen foar gegevensopslach yn it ljocht fan bêste praktiken foar wurkjen mei konteners en Kubernetes.
Steateleaze konteners
Containers binne fan natuere lichtgewicht en ephemeral. Se kinne maklik wurde stoppe, fuortsmiten of ynset op in oare knooppunt - alles yn sekonden. Yn in grut kontener-orkestraasjesysteem komme sokke operaasjes de hiele tiid foar, en brûkers fernimme sokke feroaringen net iens. Bewegingen binne lykwols allinich mooglik as de kontener gjin ôfhinklikens hat fan it knooppunt wêrop it leit. Sokke konteners wurde sein te wurkjen steateleas.
Stateful Containers
As in kontener gegevens opslaat op lokaal taheakke apparaten (of op in blokapparaat), dan moat de gegevenswinkel dêr't it op sit, nei in nij knooppunt ferpleatst wurde, tegearre mei de kontener sels, yn gefal fan in mislearring. Dit is wichtich, om't oars de applikaasje dy't yn 'e kontener rint, net goed kin funksjonearje, om't it tagong hat ta gegevens opslein op lokale media. Sokke konteners wurde sein te wurkjen steatlike.
Ut in suver technysk eachpunt, steatlike konteners kinne ek ferpleatst wurde nei oare knopen. Dit wurdt typysk berikt mei ferdielde bestânsystemen of blokkearje netwurk opslach ferbûn oan alle knooppunten mei konteners. Op dizze manier krije konteners tagong ta folumes foar oanhâldende gegevens opslach, en ynformaasje wurdt opslein op skiven dy't yn it heule netwurk lizze. Ik sil dizze metoade neame "stateful container oanpak", en yn 'e rest fan it artikel sil ik it neame om' e unifoarmens.
Yn in typyske stateful container oanpak binne alle applikaasje pods hechte oan in inkele ferspraat triem systeem - in soarte fan dielde opslach dêr't alle applikaasje gegevens wenje. Wylst guon fariaasjes mooglik binne, is dit in oanpak op heech nivo.
Litte wy no sjen wêrom't de stateful container oanpak in anty-patroan is yn in wolk-sintraal wrâld.
Cloud-native applikaasje-ûntwerp
Tradysjoneel brûkten applikaasjes databases foar strukturearre opslach fan ynformaasje en lokale skiven as ferdielde triemsystemen wêr't alle net-strukturearre of sels semi-strukturearre gegevens waarden dumpt. Doe't de voluminten fan net-strukturearre gegevens groeiden, realisearre ûntwikkelders dat POSIX te praatsk wie, signifikante overhead hie, en úteinlik de prestaasjes fan 'e applikaasje hindere by it ferpleatsen nei echt grutte skalen.
Dit hat benammen bydroegen oan it ûntstean fan in nije standert foar gegevensopslach, dat is wolkbasearre opslach, dy't primêr wurket basearre op 'e REST API en befrijt de applikaasje fan it lestige ûnderhâld fan in lokale gegevensopslach. Yn dit gefal giet de applikaasje effektyf yn steatleaze modus (om't de steat yn opslach op ôfstân is). Moderne applikaasjes wurde fanôf it begjin boud mei dizze faktor yn gedachten. As regel is elke moderne applikaasje dy't gegevens fan ien of oare soart ferwurket (logs, metadata, blobs, ensfh.) is boud neffens in wolk-rjochte paradigma, wêrby't de steat wurdt oerbrocht nei in softwaresysteem dat spesjaal wijd is foar har opslach.
De stateful container oanpak twingt dit hiele paradigma werom krekt wêr't it begûn!
Troch POSIX-ynterfaces te brûken om gegevens op te slaan, wurkje applikaasjes as wiene se stateful, en dêrom geane se ôf fan 'e wichtichste útgongspunten fan wolk-sintraal ûntwerp, dat is de mooglikheid om de grutte fan' e applikaasje-wurker-threads te feroarjen ôfhinklik fan ynkommende input.load, ferpleatse nei in nij knooppunt sa gau as it hjoeddeiske knooppunt mislearret, ensfh.
Troch in tichterby te besjen op dizze situaasje, fine wy dat wy by it kiezen fan in gegevenswinkel wer en wer konfrontearre wurde mei it POSIX vs REST API-dilemma, MAAR mei de ekstra fergrieming fan POSIX-problemen troch de ferdielde aard fan Kubernetes-omjouwings. Yn't bysonder,
- POSIX is praatsk: POSIX semantyk fereasket dat elke operaasje wurdt assosjearre mei metadata en triem beskriuwers dy't helpe te behâlden de steat fan de operaasje. Dit resultearret yn signifikante kosten dy't gjin echte wearde hawwe. Objekt opslach API's, benammen de S3 API, kwyt dizze easken, wêrtroch't de applikaasje kin fjoer en dan "ferjitte" oer de oprop. It antwurd op it opslachsysteem jout oan oft de aksje suksesfol wie of net. As it mislearret, kin de applikaasje nochris besykje.
- Netwurk beheinings: Yn in ferspraat systeem wurdt ymplisearre dat der in protte applikaasjes wêze kinne dy't besykje gegevens te skriuwen nei deselde taheakke media. Dêrom sille applikaasjes net allinich mei elkoar konkurrearje foar bânbreedte foar gegevensferfier (om gegevens nei de media te stjoeren), mar it opslachsysteem sels sil konkurrearje foar dizze bânbreedte troch gegevens oer fysike skiven te ferstjoeren. Troch de loquaciousness fan POSIX nimt it oantal netwurkoproppen ferskate kearen ta. Oan 'e oare kant jout de S3 API in dúdlik ûnderskied tusken netwurkoproppen tusken dyjingen dy't fan 'e kliïnt nei de tsjinner komme en dyjingen dy't binnen de tsjinner foarkomme.
- Feiligens: It POSIX-befeiligingsmodel is ûntworpen foar aktive minsklike dielname: behearders konfigurearje spesifike tagongsnivo's foar elke brûker of groep. Dit paradigma is lestich oan te passen oan in wolk-sintraal wrâld. Moderne applikaasjes binne ôfhinklik fan API-basearre feiligens modellen, dêr't tagongsrjochten wurde definiearre as in set fan belied, tsjinst accounts, tydlike bewiisbrieven, ensfh wurde tawiisd.
- Behearberens: Stateful containers hawwe wat behear overhead. Wy prate oer it syngronisearjen fan parallelle tagong ta gegevens, it garandearjen fan konsistinsje fan gegevens, dit alles fereasket soarchfâldige ôfwaging fan hokker patroanen foar gegevenstagong te brûken. Oanfoljende software moat wurde ynstalleare, kontroleare en konfigureare, om net te sprekken fan ekstra ûntwikkelingspogingen.
Container Data Storage Interface
Wylst de Container Storage Interface (CSI) in grutte help west hat by de proliferaasje fan 'e Kubernetes folumelaach, it foar in part útbesteegje oan opslachferkeapers fan tredden, hat it ek per ongelok bydroegen oan it leauwe dat de stateful container oanpak de oanrikkemandearre metoade is foar gegevens opslaan yn Kubernetes.
CSI waard ûntwikkele as standert foar it leverjen fan willekeurige blok- en bestânopslachsystemen oan legacy-applikaasjes by it útfieren fan Kubernetes. En, lykas dit artikel hat oantoand, is de iennichste situaasje wêryn in stateful container oanpak (en CSI yn syn hjoeddeistige foarm) sin makket as de applikaasje sels in legacy systeem is wêryn it net mooglik is om stipe ta te foegjen foar de objekt opslach API .
It is wichtich om te begripen dat it brûken fan CSI yn syn hjoeddeistige foarm, dat is, mounting folumes by it wurkjen mei moderne applikaasjes, wy sille tsjinkomme likernôch deselde problemen dy't ûntstienen yn systemen dêr't gegevens opslach wurdt organisearre yn de POSIX styl.
In bettere oanpak
Yn dit gefal is it wichtich om te begripen dat de measte applikaasjes net ynherent spesifyk binne ûntworpen foar steatlike of steatleaze wurk. Dit gedrach hinget ôf fan 'e algemiene systeemarsjitektuer en de spesifike ûntwerpkeuzes makke. Litte wy in bytsje prate oer steatlike applikaasjes.
Yn prinsipe kinne alle applikaasjegegevens wurde ferdield yn ferskate brede soarten:
- Log gegevens
- Tiidstempel gegevens
- Transaksje gegevens
- Metadata
- Container ôfbyldings
- Blob (binêr grut objekt) gegevens
Al dizze gegevenstypen wurde heul goed stipe op moderne opslachplatfoarms, en d'r binne ferskate cloud-native platfoarms op maat om gegevens te leverjen yn elk fan dizze spesifike formaten. Transaksjegegevens en metadata kinne bygelyks wenje yn in moderne cloud-native database lykas CockroachDB, YugaByte, ensfh. Containerôfbyldings as blobgegevens kinne wurde opslein yn in docker-register basearre op MinIO. Tiidstempelgegevens kinne wurde opslein yn in tiidreeksdatabase lykas InfluxDB, ensfh. Wy sille hjir net yn detail gean oer elk gegevenstype en har tapassingen, mar it algemiene idee is om persistente gegevensopslach te foarkommen dy't fertrout op pleatslike skiifmontage.
Derneist is it faaks effektyf om in tydlike caching-laach te leverjen dy't tsjinnet as in tydlike triemwinkel foar applikaasjes, mar applikaasjes moatte net ôfhinklik wêze fan dizze laach as de boarne fan wierheid.
Stateful applikaasje opslach
Wylst it yn 'e measte gefallen nuttich is om applikaasjes steatleas te hâlden, moatte dy applikaasjes dy't ûntwurpen binne om gegevens op te slaan - lykas databases, objektwinkels, kaaiweardewinkels - stateful wêze. Litte wy sjen nei wêrom dizze applikaasjes wurde ynset op Kubernetes. Litte wy MinIO as foarbyld nimme, mar ferlykbere prinsipes jilde foar alle oare grutte wolk-native opslachsysteem.
Cloud-native applikaasjes binne ûntworpen om folslein te profitearjen fan de fleksibiliteit dy't yn konteners is. Dat betsjut dat se gjin oannames meitsje oer de omjouwing dêr't se yn ynset wurde. Bygelyks, MinIO brûkt in ynterne wiskjen kodearring meganisme te foarsjen it systeem mei genôch fearkrêft te bliuwen operasjoneel sels as de helte fan de skiven mislearje. MinIO beheart ek gegevensyntegriteit en feiligens mei help fan eigen server-side hashing en fersifering.
Foar sokke wolk-sintraal applikaasjes binne lokale persistente folumes (PV's) it handichste as backup opslach. Lokale PV biedt de mooglikheid om rauwe gegevens op te slaan, wylst applikaasjes dy't boppe op dizze PV's rinne, selsstannich ynformaasje sammelje om gegevens te skaaljen en groeiende gegevenseasken te behearjen.
Dizze oanpak is folle ienfâldiger en signifikant mear skalberber as CSI-basearre PV's, dy't har eigen lagen fan gegevensbehear en oerstalligens yn it systeem ynfiere; it punt is dat dizze lagen meastal yn striid binne mei applikaasjes ûntwurpen om steat te wêzen.
In sterke beweging nei it ûntkoppelen fan gegevens fan berekkeningen
Yn dit artikel hawwe wy praat oer hoe't applikaasjes wurde reoriïntearre om te wurkjen sûnder steat te bewarjen, of, mei oare wurden, it opslaan fan gegevens wurdt loskeppele fan it berekkenjen derop. As konklúzje, litte wy nei guon echte foarbylden fan dizze trend sjen.
, in prominint platfoarm foar gegevensanalyse, is tradisjoneel stateful en ynset op HDFS. As Spark lykwols ferhuzet yn in wolk-sintraal wrâld, wurdt it platfoarm hieltyd mear stateless brûkt mei `s3a`. Spark brûkt s3a om steat oer te dragen nei oare systemen, wylst Spark-konteners sels folslein steatleas operearje. Oare grutte ûndernimmingsspilers op it mêd fan big data analytics, benammen, , , Se geane ek oer om te wurkjen mei de skieding fan gegevensopslach en berekkeningen derop.
Fergelykbere patroanen kinne ek sjoen wurde op oare grutte analytyske platfoarms, ynklusyf Presto, Tensorflow nei R, Jupyter. Troch steat te lossen nei opslachsystemen op ôfstân fan wolken, wurdt it folle makliker om jo applikaasje te behearjen en te skaaljen. Derneist fasilitearret it de portabiliteit fan 'e applikaasje nei in ferskaat oan omjouwings.
Boarne: www.habr.com
