Haai Habr!
Ons herinner u daaraan dat ons nog 'n uiters interessante en nuttige vrygestel het oor Kubernetes-patrone. Dit het nog begin met"Brendan Burns, en, terloops, werk saam met ons in hierdie segment . Vandag nooi ons jou uit om 'n artikel van die MinIO-blog te lees, wat die neigings en besonderhede van databergingspatrone in Kubernetes kortliks uiteensit.
Kubernetes het die tradisionele patrone van toepassingsontwikkeling en -ontplooiing fundamenteel verander. Dit kan nou 'n span dae neem om 'n toepassing oor verskeie omgewings te ontwikkel, te toets en te ontplooi, alles binne Kubernetes-klusters. Sulke werk met vorige generasie tegnologieë het gewoonlik hele weke geduur, indien nie maande nie.
Hierdie versnelling word moontlik gemaak deur die abstraksie wat deur Kubernetes verskaf word - dit wil sê deur die feit dat Kubernetes self interaksie het met die lae-vlak besonderhede van fisiese of virtuele masjiene, wat gebruikers in staat stel om, onder andere parameters, die verlangde verwerker, die vereiste hoeveelheid te verklaar van geheue, die aantal houergevalle. Met 'n groot gemeenskap wat Kubernetes ondersteun en die steeds toenemende gebruik van Kubernetes, is dit verreweg die leier van alle houer-orkestrasieplatforms.
Namate die gebruik van Kubernetes toeneem, neem die verwarring oor die bergingspatrone daarvan ook toe..
Met al die kompetisie vir 'n stukkie van die Kubernetes-tert (dit wil sê vir databerging), wanneer dit by databerging kom, word die sein hier in baie geraas verdrink.
Kubernetes beliggaam die moderne model vir die ontwikkeling, ontplooiing en bestuur van toepassings. Hierdie moderne model ontkoppel databerging van rekenaars. Om hierdie losbandigheid ten volle te verstaan in die konteks van Kubernetes, moet jy ook verstaan wat statige en staatlose toepassings is en hoe databerging daarby inpas. Dit is hier waar die REST API-benadering wat deur S3 gebruik word, duidelike voordele het bo die POSIX/CSI-benadering wat in ander oplossings gevind word.
In hierdie artikel sal ons oor die bergingspatrone in Kubernetes praat en afsonderlik die debat oor volharding teenoor staatlose toepassings aanraak om beter te verstaan wat die verskil is en hoekom dit belangrik is. Verder in die teks sal toepassings en databergingspatrone wat daarin gebruik word, oorweeg word in die lig van die beste praktyke om met houers en Kubernetes te werk.
Staatlose Houers
Houers is van nature liggewig en kortstondig. Hulle kan maklik gestop, verwyder word of na 'n ander gasheer ontplooi word, alles in sekondes. In 'n groot houer-orkestrasiestelsel gebeur sulke bewerkings heeltyd, en gebruikers sien nie eens sulke veranderinge raak nie. Verskuiwings is egter slegs moontlik as die houer nie enige afhanklikhede het van die nodus waarop dit geleë is nie. Daar word gesê dat sulke houers werk staatloos.
Stateful Houers
As 'n houer data op plaaslik aangehegte toestelle (of op 'n bloktoestel) stoor, sal die datastoor waarop dit woon, na 'n nuwe gasheer saam met die houer self geskuif moet word in geval van mislukking. Dit is belangrik, want anders sal 'n toepassing wat in 'n houer loop nie behoorlik kan funksioneer nie, aangesien dit toegang tot data moet kry wat op plaaslike media gestoor is. Daar word gesê dat sulke houers werk statige.
Uit 'n suiwer tegniese oogpunt kan statige houers ook na ander nodusse verskuif word. Dit word gewoonlik bereik deur verspreide lêerstelsels of bloknetwerkberging gekoppel aan alle nodusse wat houers gebruik. Houers kry dus toegang tot volumes vir aanhoudende databerging, en inligting word gestoor op skywe wat regdeur die netwerk geleë is. Ek sal hierdie metode noemstatige houerbenadering”, en in die res van die artikel sal ek ter wille van eenvormigheid as sodanig daarna verwys.
In 'n tipiese stateful containerized-benadering word alle toepassings-peule aan 'n enkele verspreide lêerstelsel geheg - 'n soort gedeelde berging waar alle toepassingsdata geleë is. Alhoewel sommige variasies moontlik is, is dit 'n hoëvlakbenadering.
Kom ons kyk nou hoekom 'n houervormige, statige benadering 'n anti-patroon is in 'n wolkgesentreerde wêreld.
Wolk-gebaseerde toepassingsontwerp
Tradisioneel het toepassings databasisse gebruik vir gestruktureerde berging van inligting, en plaaslike skywe of verspreide lêerstelsels waar alle ongestruktureerde of selfs semi-gestruktureerde data gestort is. Namate die volume ongestruktureerde data toegeneem het, het ontwikkelaars besef dat POSIX te "praat" was, aansienlike bokoste aangaan, en uiteindelik die toepassing verhinder om na werklik groot skale te beweeg.
Dit het basies bygedra tot die ontstaan van 'n nuwe databergingstandaard, dit wil sê wolkgebaseerde bergings wat hoofsaaklik op die basis van die REST API werk en die toepassing bevry van die lastige instandhouding van die plaaslike databerging. In hierdie geval gaan die toepassing eintlik in staatlose modus (omdat die toestand in afgeleë berging is). Moderne toepassings word van nuuts af gebou met hierdie faktor in gedagte. As 'n reël word enige moderne toepassing wat data van een of ander aard (logs, metadata, blobs, ens.) verwerk volgens 'n wolk-georiënteerde paradigma gebou, waar die staat oorgedra word na 'n sagtewarestelsel wat spesiaal vir die berging daarvan toegewy is.
Die statige houerbenadering laat hierdie hele paradigma terugval presies waar dit begin het!
Wanneer die POSIX-koppelvlakke gebruik word om data te stoor, tree toepassings op asof dit statig is, en wyk as gevolg hiervan af van die belangrikste beginsels van wolkgesentreerde ontwerp, dit wil sê die vermoë om die grootte van toepassingswerkerdrade te verander na gelang van die invoerlading, skuif na 'n nuwe nodus sodra die huidige nodus misluk, ensovoorts.
As ons hierdie situasie van nader beskou, vind ons dat wanneer ons 'n datastoor kies, ons telkens die dilemma van "POSIX vs. REST API" in die gesig staar, MAAR met die bykomende verergering van POSIX-probleme as gevolg van die verspreide aard van Kubernetes-omgewings. In die besonder,
- POSIX gesels: POSIX semantiek vereis dat metadata en lêerbeskrywers met elke bewerking geassosieer word om te help om die toestand van die bewerking te handhaaf. Dit lei tot aansienlike koste wat geen werklike waarde het nie. API's vir die stoor van voorwerpe, spesifiek die S3 API, het van hierdie vereistes ontslae geraak, wat die toepassing toegelaat het om te vuur en dan van die oproep "vergeet". Die reaksie van die bergingstelsel dui aan of die aksie suksesvol was of nie. Indien onsuksesvol, kan die toepassing weer probeer.
- Netwerkbeperkings: In 'n verspreide stelsel word verstaan dat daar verskeie toepassings kan wees wat probeer om data na dieselfde aangehegte media te skryf. Daarom sal toepassings nie net met mekaar meeding vir data-oordragbandwydte nie (ten einde data na die media te stuur nie), die bergingstelsel self sal om hierdie bandwydte meeding, en data oor fisiese skywe stuur. As gevolg van die spraaksaamheid van POSIX, groei die aantal netwerkoproepe verskeie kere. Aan die ander kant bied die S3 API 'n duidelike onderskeid tussen netwerkoproepe wat van die kliënt na die bediener kom en dié wat binne die bediener plaasvind.
- sekuriteit: Die POSIX-sekuriteitsmodel is ontwerp vir aktiewe menslike deelname: administrateurs konfigureer spesifieke toegangsvlakke vir elke gebruiker of groep. So 'n paradigma is moeilik om aan te pas by 'n wolkgesentreerde wêreld. Moderne toepassings is afhanklik van API-gebaseerde sekuriteitsmodelle, waar toegangsregte gedefinieer word as 'n stel beleide, diensrekeninge toegewys word, tydelike geloofsbriewe, ensovoorts.
- beheerbaarheid: Statige houers het 'n mate van bestuursbokoste. Dit gaan oor die sinchronisering van parallelle datatoegang, om datakonsekwentheid te verseker, dit alles vereis noukeurige oorweging van watter datatoegangspatrone om te gebruik. Jy moet addisionele sagteware installeer, bestuur en konfigureer, om nie eens te praat van die ekstra ontwikkelingspoging nie.
Datastore Container Interface
Alhoewel die Containerized Data Storage Interface (CSI) 'n uitstekende werk gedoen het om die Kubernetes-volumelaag te help versprei, het dit gedeeltelik na derdeparty-databergingsverskaffers afgelaai, maar dit het ook per ongeluk bygedra tot die oortuiging dat die stateful-houerbenadering die aanbevole metode is om databerging in Kubernetes.
CSI is ontwikkel as 'n standaard vir die verskaffing van arbitrêre blok- en lêerbergingstelsels aan verouderde toepassings wanneer daar met Kubernetes gewerk word. En, soos hierdie artikel getoon het, is die enigste situasie waar 'n statige houerbenadering (en CSI in sy huidige vorm) sin maak wanneer die toepassing self 'n nalatenskapstelsel is waar dit nie moontlik is om ondersteuning vir die objekberging-API by te voeg nie.
Dit is belangrik om te verstaan dat die gebruik van CSI in sy huidige vorm, dit wil sê om volumes in moderne toepassings te monteer, ons probleme sal ondervind soortgelyk aan wat ons het in stelsels waar data in die POSIX-styl georganiseer word.
’n Beter benadering
In hierdie geval is dit belangrik om te verstaan dat die meeste toepassings inherent nie spesifiek vir staatkundige of staatlose werk ontwerp is nie. Hierdie gedrag hang af van die algehele argitektuur van die stelsel en van die spesifieke opsies wat tydens die ontwerp gekies is. Kom ons praat 'n bietjie oor statige toepassings.
In beginsel kan alle toepassingsdata in verskeie breë tipes verdeel word:
- Log data
- Tydstempel data
- Transaksie data
- Metadata
- Houer beelde
- Blob (binêre groot voorwerp) data
Al hierdie datatipes word baie goed ondersteun op vandag se bergingsplatforms, en daar is verskeie wolk-inheemse platforms beskikbaar om data in elk van hierdie spesifieke formate te lewer. Transaksiedata en metadata kan byvoorbeeld in 'n moderne wolkgebaseerde databasis soos CockroachDB, YugaByte, ens. Houerbeelde of blobdata kan in 'n MinIO-gebaseerde docker-register gestoor word. Tydstempeldata kan gestoor word in 'n tydreeksdatabasis soos InfluxDB ens. Ons gaan nie hier in op die besonderhede van elke tipe data en hul onderskeie toepassings nie, maar die algemene idee is om aanhoudende databerging gebaseer op plaaslik monterende skywe te vermy.
Daarbenewens is dit dikwels effektief om 'n tydelike kaslaag te verskaf wat dien as 'n soort bewaarplek vir toepassings vir tydelike lêers, maar toepassings behoort nie afhanklik te wees van hierdie laag as 'n bron van waarheid nie.
Berging vir statige toepassings
Alhoewel dit in die meeste gevalle nuttig is om toepassings staatloos te hou, moet daardie toepassings wat ontwerp is om data te stoor - soos databasisse, objekstore, sleutel- en waardestore - stateful wees. Kom ons kyk hoekom hierdie toepassings op Kubernetes ontplooi word. Kom ons neem MinIO as 'n voorbeeld, maar soortgelyke beginsels geld vir enige ander groot wolk-gebaseerde bergingstelsels.
Wolk-inheemse toepassings is ontwerp om voordeel te trek uit die buigsaamheid wat inherent is aan houers. Dit beteken dat hulle geen aannames maak oor die omgewing waarin hulle ontplooi gaan word nie. Byvoorbeeld, MinIO gebruik 'n interne uitvee-koderingsmeganisme wat die stelsel van genoeg veerkragtigheid voorsien om dit aan die gang te hou, selfs al misluk die helfte van die skywe. MinIO bestuur ook die integriteit en sekuriteit van data deur sy eie hashing en bedienerkant-enkripsie te gebruik.
Vir hierdie wolk-inheemse toepassings is Local Persistent Volumes (PV's) die nuttigste rugsteunberging. 'n Plaaslike PV bied die vermoë om rou data te stoor, terwyl toepassings wat bo-op hierdie PV's loop, inligting op hul eie insamel om data te skaal en groeiende data-eise te bestuur.
Hierdie benadering is baie eenvoudiger en baie meer skaalbaar as KSI-gebaseerde PV's, wat hul eie vlakke van databestuur en oortolligheid in die stelsel instel; die punt is dat hierdie lae geneig is om te bots met statige toepassings.
Beweeg voortdurend na die ontkoppeling van data van rekenaars
In hierdie artikel het ons gepraat oor hoe toepassings geheroriënteer word om te werk sonder om die toestand te stoor, of, met ander woorde, databerging word afgebaken van berekeninge daarop. Ten slotte, kom ons kyk na 'n paar werklike voorbeelde van so 'n neiging.
, die bekende data-ontledingsplatform, is tradisioneel statig en op die HDFS-lêerstelsel ontplooi. Soos Spark egter na 'n wolkgesentreerde wêreld oorgaan, word hierdie platform toenemend staatloos gebruik deur `s3a` te gebruik. Spark gebruik s3a om staat na ander stelsels oor te dra, terwyl Spark-houers self heeltemal staatloos loop. Ander groot ondernemingspelers op die gebied van grootdata-analise, veral, , , gaan ook voort om te werk met die skeiding van databerging en berekeninge daarop.
Soortgelyke patrone kan ook op ander groot analitiese platforms gesien word, insluitend Presto, Tensorflow to R, Jupyter. Deur toestand na afgeleë wolkbergingstelsels af te laai, word dit baie makliker om jou toepassing te bestuur en te skaal. Daarbenewens dra dit by tot die oordraagbaarheid van die toepassing in 'n verskeidenheid omgewings.
Bron: will.com