Hei Habr!
Vi minner deg om at vi har gitt ut en annen ekstremt interessant og nyttig om Kubernetes-mønstre. Det hele startet med ""Brendan Burns, og forresten, vi har arbeid i dette segmentet . I dag inviterer vi deg til å lese en artikkel fra MinIO-bloggen som kort skisserer trendene og spesifikasjonene til datalagringsmønstre i Kubernetes.
Kubernetes har fundamentalt endret tradisjonell applikasjonsutvikling og distribusjonsmønstre. Nå kan et team utvikle, teste og distribuere en applikasjon i løpet av få dager – på tvers av flere miljøer, alt innenfor Kubernetes-klynger. Slikt arbeid med tidligere generasjoner teknologi tok vanligvis uker, om ikke måneder.
Denne akselerasjonen er muliggjort av abstraksjonen gitt av Kubernetes - det vil si fordi Kubernetes selv samhandler med lavnivådetaljene til fysiske eller virtuelle maskiner, slik at brukere kan deklarere ønsket prosessor, ønsket mengde minne og antall containere forekomster, blant andre parametere. Med et enormt fellesskap som støtter Kubernetes og dets adopsjon stadig utvides, er Kubernetes lederen blant alle containerorkestreringsplattformer med stor margin.
Etter hvert som bruken av Kubernetes øker, øker også forvirringen rundt lagringsmønstrene..
Med alle som konkurrerer om en del av Kubernetes-kaken (dvs. datalagring), når det kommer til å snakke om datalagring, druknes signalet i mye støy.
Kubernetes legemliggjør en moderne modell for applikasjonsutvikling, distribusjon og administrasjon. Denne moderne modellen kobler fra datalagring fra beregning. For å forstå løsrivelse fullt ut i sammenheng med Kubernetes, må du også forstå hva tilstandsfulle og statsløse applikasjoner er, og hvordan datalagring passer inn i det. Det er her REST API-tilnærmingen som brukes av S3 har klare fordeler fremfor POSIX/CSI-tilnærmingen til andre løsninger.
I denne artikkelen skal vi snakke om datalagringsmønstre i Kubernetes og spesifikt berøre debatten mellom statistiske og statsløse applikasjoner for bedre å forstå hva forskjellen mellom dem er og hvorfor det er viktig. Resten av teksten vil se på applikasjoner og deres datalagringsmønstre i lys av beste praksis for arbeid med containere og Kubernetes.
Statsløse containere
Beholdere er av natur lette og flyktige. De kan enkelt stoppes, fjernes eller distribueres til en annen node - alt på sekunder. I et stort containerorkestreringssystem skjer slike operasjoner hele tiden, og brukere legger ikke engang merke til slike endringer. Flytt er imidlertid bare mulig hvis beholderen ikke har noen avhengigheter av noden den er plassert på. Slike beholdere sies å fungere statsløs.
Stateful containere
Hvis en container lagrer data på lokalt tilkoblede enheter (eller på en blokkenhet), må datalageret som den ligger på, flyttes til en ny node, sammen med selve containeren, i tilfelle feil. Dette er viktig fordi ellers vil applikasjonen som kjører i beholderen ikke kunne fungere ordentlig fordi den trenger tilgang til data som er lagret på lokale medier. Slike beholdere sies å fungere statelig.
Rent teknisk kan stateful containere også flyttes til andre noder. Dette oppnås vanligvis ved å bruke distribuerte filsystemer eller blokknettverkslagring knyttet til alle noder som kjører containere. På denne måten får containere tilgang til volumer for vedvarende datalagring, og informasjon lagres på disker plassert i hele nettverket. Jeg vil kalle denne metoden "stateful container-tilnærming", og i resten av artikkelen vil jeg kalle det det for enhetlighetens skyld.
I en typisk stateful container-tilnærming er alle applikasjonsputer koblet til et enkelt distribuert filsystem – en slags delt lagring der alle applikasjonsdata ligger. Selv om noen variasjoner er mulige, er dette en tilnærming på høyt nivå.
La oss nå se på hvorfor den stateful container-tilnærmingen er et anti-mønster i en skysentrisk verden.
Cloud-native applikasjonsdesign
Tradisjonelt brukte applikasjoner databaser for strukturert lagring av informasjon og lokale disker eller distribuerte filsystemer der alle ustrukturerte eller til og med semistrukturerte data ble dumpet. Etter hvert som volumene av ustrukturerte data vokste, innså utviklere at POSIX var for pratsomt, hadde betydelig overhead og til slutt hindret applikasjonsytelsen når de flyttet til virkelig store skalaer.
Dette bidro hovedsakelig til fremveksten av en ny standard for datalagring, det vil si skybasert lagring, som primært jobber basert på REST API og frigjør applikasjonen fra det tyngende vedlikeholdet av en lokal datalagring. I dette tilfellet går applikasjonen effektivt inn i tilstandsløs modus (siden tilstanden er i ekstern lagring). Moderne applikasjoner bygges fra bunnen av med denne faktoren i tankene. Som regel er enhver moderne applikasjon som behandler data av et eller annet slag (logger, metadata, blobs, etc.) bygget i henhold til et skyorientert paradigme, der staten overføres til et programvaresystem spesielt dedikert for lagringen.
Den statelige containertilnærmingen tvinger hele dette paradigmet tilbake akkurat der det startet!
Ved å bruke POSIX-grensesnitt for å lagre data, fungerer applikasjoner som om de var tilstandsfulle, og på grunn av dette avviker de fra de viktigste prinsippene for skysentrisk design, det vil si muligheten til å variere størrelsen på applikasjonsarbeidertråder avhengig av innkommende input.load, flytt til en ny node så snart den nåværende noden svikter, og så videre.
Når vi ser nærmere på denne situasjonen, finner vi at når vi velger et datalager, står vi igjen og igjen overfor POSIX vs. REST API-dilemmaet, MEN med den ytterligere forverringen av POSIX-problemer på grunn av den distribuerte naturen til Kubernetes-miljøer. Spesielt,
- POSIX er pratsom: POSIX-semantikk krever at hver operasjon er assosiert med metadata og filbeskrivelser som bidrar til å opprettholde tilstanden til operasjonen. Dette resulterer i betydelige kostnader som ikke har noen reell verdi. Objektlagrings-APIer, spesielt S3 API, kvitter seg med disse kravene, slik at applikasjonen kan utløses og deretter "glemme" samtalen. Lagringssystemets respons indikerer om handlingen var vellykket eller ikke. Hvis det mislykkes, kan programmet prøve på nytt.
- Nettverksbegrensninger: I et distribuert system antydes det at det kan være mange applikasjoner som prøver å skrive data til det samme vedlagte mediet. Derfor vil ikke bare applikasjoner konkurrere med hverandre om dataoverføringsbåndbredde (for å sende data til media), men lagringssystemet selv vil konkurrere om denne båndbredden ved å sende data over fysiske disker. På grunn av snakkesaligheten til POSIX, øker antallet nettverksanrop flere ganger. På den annen side gir S3 API et klart skille mellom nettverksanrop mellom de som stammer fra klienten til serveren og de som skjer innenfor serveren.
- Безопасность: POSIX-sikkerhetsmodellen er designet for aktiv menneskelig deltakelse: administratorer konfigurerer spesifikke tilgangsnivåer for hver bruker eller gruppe. Dette paradigmet er vanskelig å tilpasse til en skysentrisk verden. Moderne applikasjoner er avhengige av API-baserte sikkerhetsmodeller, der tilgangsrettigheter er definert som et sett med policyer, tjenestekontoer, midlertidig legitimasjon osv. blir tildelt.
- kontrollerbarhet: Stateful containere har noen administrasjonskostnader. Vi snakker om å synkronisere parallell tilgang til data, sikre datakonsistens, alt dette krever nøye vurdering av hvilke datatilgangsmønstre som skal brukes. Ytterligere programvare må installeres, overvåkes og konfigureres, for ikke å snakke om ytterligere utviklingsinnsats.
Beholderdatalagringsgrensesnitt
Selv om Container Storage Interface (CSI) har vært til stor hjelp med utbredelsen av Kubernetes volumlag, og delvis outsourcet det til tredjeparts lagringsleverandører, har det også utilsiktet bidratt til troen på at den stateful container-tilnærmingen er den anbefalte metoden for lagring av data i Kubernetes.
CSI ble utviklet som en standard for å tilby vilkårlige blokk- og fillagringssystemer til eldre applikasjoner når de kjøres på Kubernetes. Og, som denne artikkelen har vist, er den eneste situasjonen der en stateful container-tilnærming (og CSI i sin nåværende form) gir mening når selve applikasjonen er et eldre system der det ikke er mulig å legge til støtte for objektlagrings-APIet .
Det er viktig å forstå at ved å bruke CSI i sin nåværende form, det vil si å montere volumer når vi jobber med moderne applikasjoner, vil vi møte omtrent de samme problemene som oppsto i systemer der datalagring er organisert i POSIX-stilen.
En bedre tilnærming
I dette tilfellet er det viktig å forstå at de fleste applikasjoner iboende ikke er designet spesifikt for statlig eller statsløst arbeid. Denne oppførselen avhenger av den generelle systemarkitekturen og de spesifikke designvalgene som er gjort. La oss snakke litt om stateful applikasjoner.
I prinsippet kan alle applikasjonsdata deles inn i flere brede typer:
- Loggdata
- Tidsstempeldata
- Transaksjonsdata
- Metadata
- Containerbilder
- Blob-data (binært stort objekt).
Alle disse datatypene støttes veldig godt på moderne lagringsplattformer, og det finnes flere skybaserte plattformer som er skreddersydd for å levere data i hvert av disse spesifikke formatene. For eksempel kan transaksjonsdata og metadata ligge i en moderne skybasert database som CockroachDB, YugaByte, etc. Beholderbilder eller blobdata kan lagres i et docker-register basert på MinIO. Tidsstempeldata kan lagres i en tidsseriedatabase som InfluxDB, etc. Vi vil ikke gå i detalj om hver datatype og dens applikasjoner her, men den generelle ideen er å unngå vedvarende datalagring som er avhengig av lokal diskmontering.
I tillegg er det ofte effektivt å tilveiebringe et midlertidig hurtigbufferlag som fungerer som et midlertidig fillager for applikasjoner, men applikasjoner bør ikke avhenge av dette laget som kilde til sannhet.
Stateful applikasjonslagring
Mens det i de fleste tilfeller er nyttig å holde applikasjoner statsløse, må de applikasjonene som er utformet for å lagre data - som databaser, objektlagre, nøkkelverdilagre - være stateful. La oss se på hvorfor disse applikasjonene er distribuert på Kubernetes. La oss ta MinIO som et eksempel, men lignende prinsipper gjelder for alle andre store skybaserte lagringssystem.
Cloud-native applikasjoner er designet for å dra full nytte av fleksibiliteten som ligger i containere. Dette betyr at de ikke gjør noen antagelser om miljøet de vil bli utplassert i. For eksempel bruker MinIO en intern slettekodemekanisme for å gi systemet nok motstand til å forbli operativt selv om halvparten av diskene svikter. MinIO administrerer også dataintegritet og sikkerhet ved å bruke proprietær server-side hashing og kryptering.
For slike skysentriske applikasjoner er lokale vedvarende volumer (PV-er) mest praktiske som backuplagring. Lokal PV gir muligheten til å lagre rådata, mens applikasjoner som kjører på toppen av disse PV-ene samler uavhengig informasjon for å skalere data og håndtere økende databehov.
Denne tilnærmingen er mye enklere og betydelig mer skalerbar enn CSI-baserte PV-er, som introduserer sine egne lag med dataadministrasjon og redundans i systemet; poenget er at disse lagene vanligvis er i konflikt med applikasjoner designet for å være stateful.
En sterk bevegelse mot å frikoble data fra beregninger
I denne artikkelen snakket vi om hvordan applikasjoner reorienteres til å fungere uten å lagre tilstand, eller med andre ord, lagring av data er koblet fra databehandling på den. Avslutningsvis, la oss se på noen virkelige eksempler på denne trenden.
, en fremtredende dataanalyseplattform, har tradisjonelt vært statelig og distribuert på HDFS. Men etter hvert som Spark beveger seg inn i en skysentrisk verden, blir plattformen i økende grad brukt statsløs ved å bruke `s3a`. Spark bruker s3a for å overføre tilstand til andre systemer, mens Spark-containere selv opererer helt statsløse. Andre store bedriftsaktører innen big data-analyse, spesielt, , , De går også over til å jobbe med separering av datalagring og beregninger på dem.
Lignende mønstre kan også sees på andre store analytiske plattformer, inkludert Presto, Tensorflow til R, Jupyter. Ved å overføre tilstand til eksterne skylagringssystemer, blir det mye enklere å administrere og skalere applikasjonen din. I tillegg letter det portabiliteten av applikasjonen til en rekke miljøer.
Kilde: www.habr.com