Datalagringsmønstre i Kubernetes

Hej Habr!

Vi minder dig om, at vi har udgivet en anden yderst interessant og nyttig bog om Kubernetes-mønstre. Det startede stadig medmønstre" Brendan Burns, og i øvrigt arbejde i dette segment med os koger. I dag inviterer vi dig til at læse en artikel fra MinIO-bloggen, som kort skitserer trends og specifikationer for datalagringsmønstre i Kubernetes.

Kubernetes har fundamentalt ændret de traditionelle mønstre for applikationsudvikling og implementering. Det kan nu tage et team-dage at udvikle, teste og implementere en applikation på tværs af flere miljøer, alt sammen inden for Kubernetes-klynger. Sådant arbejde med tidligere generationers teknologier tog normalt hele uger, hvis ikke måneder.

Denne fremskyndelse er muliggjort af abstraktionen leveret af Kubernetes - det vil sige ved det faktum, at Kubernetes selv interagerer med detaljerne på lavt niveau på fysiske eller virtuelle maskiner, hvilket giver brugerne mulighed for blandt andre parametre at angive den ønskede processor, den nødvendige mængde hukommelse, antallet af containerforekomster. Med et enormt fællesskab, der understøtter Kubernetes og den stadigt stigende brug af Kubernetes, er det langt lederen af ​​alle containerorkestreringsplatforme.

Efterhånden som brugen af ​​Kubernetes vokser, vokser også forvirringen om dets opbevaringsmønstre..

Med al konkurrencen om et stykke af Kubernetes-kagen (altså til datalagring), når det kommer til datalagring, druknes signalet her i en masse støj.
Kubernetes inkarnerer den moderne model til at udvikle, implementere og administrere applikationer. Denne moderne model afkobler datalagring fra computere. For fuldt ud at forstå denne løsrivelse i forbindelse med Kubernetes, skal du også forstå, hvad stateful og stateless applikationer er, og hvordan datalagring passer ind i det. Det er her, REST API-tilgangen, der bruges af S3, har klare fordele i forhold til POSIX/CSI-tilgangen, der findes i andre løsninger.

I denne artikel vil vi tale om opbevaringsmønstrene i Kubernetes og særskilt berøre debatten om vedholdenhed vs. statsløse applikationer for bedre at forstå, hvad forskellen er, og hvorfor den er vigtig. Længere i teksten vil applikationer og datalagringsmønstre, der anvendes i dem, blive overvejet i lyset af bedste praksis for at arbejde med containere og Kubernetes.

Statsløse containere

Beholdere er af natur lette og flygtige. De kan nemt stoppes, fjernes eller distribueres til en anden vært, alt på få sekunder. I et stort containerorkestreringssystem sker sådanne operationer hele tiden, og brugerne bemærker ikke engang sådanne ændringer. Flytninger er dog kun mulige, hvis containeren ikke har nogen afhængigheder af den vært, den er på. Sådanne beholdere siges at virke statsløs.

Stateful containere

Hvis en container gemmer data på lokalt tilsluttede enheder (eller på en blokenhed), så skal datalageret, den ligger på, flyttes til en ny vært sammen med selve containeren i tilfælde af fejl. Dette er vigtigt, fordi ellers vil en applikation, der kører i en container, ikke kunne fungere korrekt, da den skal have adgang til data, der er gemt på lokale medier. Sådanne beholdere siges at virke statelig.

Rent teknisk kan stateful containere også flyttes til andre noder. Dette opnås normalt gennem distribuerede filsystemer eller blokeret netværkslagring knyttet til alle noder, der kører containere. Containere får således adgang til volumener til vedvarende datalagring, og information lagres på diske, der er placeret på hele netværket. Jeg vil kalde denne metodestatelig containeriseret tilgang”, og i resten af ​​artiklen vil jeg henvise til det som sådan for ensartethedens skyld.

I en typisk stateful containeriseret tilgang er alle applikations-pods knyttet til et enkelt distribueret filsystem - en slags delt lagring, hvor alle applikationsdata findes. Selvom nogle variationer er mulige, er dette en tilgang på højt niveau.

Lad os nu se, hvorfor en containeriseret, statslig tilgang er et anti-mønster i en sky-centreret verden.

Cloud-baseret applikationsdesign

Traditionelt brugte applikationer databaser til struktureret lagring af information og lokale diske eller distribuerede filsystemer, hvor alle ustrukturerede eller endda semistrukturerede data blev dumpet. Efterhånden som mængden af ​​ustrukturerede data voksede, indså udviklerne, at POSIX var for "snasket", medførte betydelige omkostninger og i sidste ende forhindrede applikationen i at flytte til virkelig store skalaer.

Dette bidrog dybest set til fremkomsten af ​​en ny datalagringsstandard, det vil sige cloud-baserede storages, der hovedsageligt arbejder på basis af REST API og frigør applikationen fra den byrdefulde vedligeholdelse af den lokale datalagring. I dette tilfælde går applikationen faktisk i tilstandsløs tilstand (fordi tilstanden er i fjernlager). Moderne applikationer bygges fra bunden med denne faktor i tankerne. Som regel er enhver moderne applikation, der behandler data af den ene eller anden art (logfiler, metadata, blobs osv.) bygget efter et sky-orienteret paradigme, hvor staten overføres til et softwaresystem, der er specielt dedikeret til dets lagring.

Den statelige containertilgang får hele dette paradigme til at falde tilbage, præcis hvor det startede!

Når POSIX-grænseflader bruges til at gemme data, opfører applikationer sig, som om de var stateful, og afviger derfor fra de vigtigste principper i sky-centreret design, dvs. evnen til at variere størrelsen af ​​applikationsarbejdertråde afhængigt af inputbelastning, flyt til en ny node, så snart den aktuelle node fejler, og så videre.

Ser vi nærmere på denne situation, finder vi, at når vi vælger et datalager, står vi igen og igen over for dilemmaet "POSIX vs. REST API", MEN med den yderligere forværring af POSIX-problemer på grund af Kubernetes-miljøernes distribuerede natur. I særdeleshed,

• POSIX snakkesalig: POSIX-semantik kræver, at metadata og filbeskrivelser tilknyttes hver handling for at hjælpe med at vedligeholde operationens tilstand. Dette fører til betydelige omkostninger, som ikke har nogen reel værdi. API'er til lagring af objekter, specifikt S3 API'en, slap af med disse krav, hvilket tillod applikationen at udløse og derefter "glemme" opkaldet. Lagersystemets svar angiver, om handlingen var vellykket eller ej. Hvis det ikke lykkes, kan applikationen prøve igen.
• Netværksbegrænsninger: I et distribueret system er det underforstået, at der kan være flere applikationer, der forsøger at skrive data til det samme vedhæftede medie. Derfor vil applikationer ikke kun konkurrere med hinanden om dataoverførselsbåndbredde (for at sende data til mediet), selve lagersystemet vil konkurrere om denne båndbredde og sende data på tværs af fysiske diske. På grund af POSIX's snakkesalighed vokser antallet af netværksopkald flere gange. På den anden side giver S3 API en klar skelnen mellem netværksopkald, der kommer fra klienten til serveren, og dem, der sker inden for serveren.
• Безопасность: POSIX-sikkerhedsmodellen er designet til aktiv menneskelig deltagelse: administratorer konfigurerer specifikke adgangsniveauer for hver bruger eller gruppe. Et sådant paradigme er svært at tilpasse til en sky-centreret verden. Moderne applikationer afhænger af API-baserede sikkerhedsmodeller, hvor adgangsrettigheder er defineret som et sæt politikker, servicekonti tildeles, midlertidige legitimationsoplysninger og så videre.
• styrbarhed: Stateful containere har nogle administrationsomkostninger. Det handler om at synkronisere parallel dataadgang, om at sikre datakonsistens, alt dette kræver nøje overvejelse af, hvilke dataadgangsmønstre der skal bruges. Du skal installere, administrere og konfigurere yderligere software, for ikke at nævne den ekstra udviklingsindsats.

Datastore Container Interface

Mens Containerized Data Storage Interface (CSI) gjorde et godt stykke arbejde med at hjælpe med at udbrede Kubernetes-volumenlaget, dels aflastede det til tredjeparts datalagringsleverandører, men det bidrog også utilsigtet til troen på, at den stateful container-tilgang er den anbefalede metode til datalagring i Kubernetes.

CSI blev udviklet som en standard til at levere vilkårlige blok- og fillagringssystemer til ældre applikationer, når du arbejder med Kubernetes. Og, som denne artikel har vist, er den eneste situation, hvor en stateful containertilgang (og CSI i sin nuværende form) giver mening, når selve applikationen er et ældre system, hvor det ikke er muligt at tilføje understøttelse af objektlagrings-API'en.

Det er vigtigt at forstå, at ved at bruge CSI i sin nuværende form, det vil sige montering af volumener i moderne applikationer, vil vi løbe ind i problemer, der ligner det, vi har i systemer, hvor data er organiseret i POSIX-stilen.

En bedre tilgang

I dette tilfælde er det vigtigt at forstå, at de fleste applikationer i sagens natur ikke er designet specifikt til statsligt eller statsløst arbejde. Denne adfærd afhænger af systemets overordnede arkitektur og af de specifikke muligheder, der er valgt under designet. Lad os tale lidt om stateful applikationer.

I princippet kan alle applikationsdata opdeles i flere brede typer:

• Log data
• Tidsstempeldata
• Transaktionsdata
• Metadata
• Container billeder
• Blob-data (binært stort objekt).

Alle disse datatyper er meget godt understøttet på nutidens lagringsplatforme, og der er flere cloud-native platforme tilgængelige til at levere data i hvert af disse specifikke formater. For eksempel kan transaktionsdata og metadata ligge i en moderne cloud-baseret database som CockroachDB, YugaByte osv. Containerbilleder eller blob-data kan gemmes i et MinIO-baseret docker-register. Tidsstempeldata kan gemmes i en tidsseriedatabase som InfluxDB osv. Vi vil ikke gå ind i detaljerne for hver type data og deres respektive applikationer her, men den generelle idé er at undgå vedvarende datalagring baseret på lokalt monterede diske.

Derudover er det ofte effektivt at tilvejebringe et midlertidigt cachelag, der fungerer som en slags repository for applikationer til midlertidige filer, men applikationer bør ikke afhænge af dette lag som en kilde til sandhed.

Opbevaring til statelige applikationer

Selvom det i de fleste tilfælde er nyttigt at holde applikationer statsløse, bør de applikationer, der er designet til at gemme data - såsom databaser, objektlagre, nøgle- og værdilagre - være stateful. Lad os se, hvorfor disse applikationer bliver implementeret på Kubernetes. Lad os tage MinIO som et eksempel, men lignende principper gælder for alle andre store cloud-baserede lagersystemer.

Cloud-native applikationer er designet til at drage fordel af den iboende fleksibilitet i containere. Det betyder, at de ikke gør nogen antagelser om det miljø, de vil blive indsat i. For eksempel bruger MinIO en intern slettekodningsmekanisme, der giver systemet tilstrækkelig modstandskraft til at holde det kørende, selvom halvdelen af ​​diskene fejler. MinIO administrerer også integriteten og sikkerheden af ​​data ved hjælp af sin egen hashing og server-side kryptering.

For disse cloud-native applikationer er Local Persistent Volumes (PV'er) det mest nyttige backuplager. En lokal PV giver mulighed for at gemme rå data, mens applikationer, der kører oven på disse PV'er, indsamler information på egen hånd for at skalere data og administrere voksende databehov.

Denne tilgang er meget enklere og meget mere skalerbar end CSI-baserede PV'er, som introducerer deres egne niveauer af datastyring og redundans i systemet; pointen er, at disse lag har en tendens til at komme i konflikt med stateful applikationer.

Bevæger sig støt mod at afkoble data fra computere

I denne artikel talte vi om, hvordan applikationer omorienteres til at fungere uden at gemme tilstand, eller med andre ord, datalagring er afgrænset fra beregninger på dem. Afslutningsvis, lad os se på et par rigtige eksempler på en sådan tendens.

Spark, den berømte dataanalyseplatform, har traditionelt været stateful og implementeret på HDFS-filsystemet. Men efterhånden som Spark overgår til en sky-centreret verden, bliver denne platform i stigende grad brugt statsløs ved hjælp af `s3a`. Spark bruger s3a til at overføre tilstand til andre systemer, mens Spark-containere selv kører helt statsløse. Andre store virksomhedsaktører inden for big data-analyse, især, Vertica, Teradata, Greenplum også gå videre til arbejdet med adskillelse af datalagring og beregninger på dem.

Lignende mønstre kan også ses på andre større analytiske platforme, herunder Presto, Tensorflow til R, Jupyter. Ved at aflaste tilstand til eksterne cloud-lagersystemer bliver det meget nemmere at administrere og skalere din applikation. Derudover bidrager det til applikationens portabilitet i en række forskellige miljøer.

Kilde: www.habr.com