{"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\/da\/blog\/administrirovanie\/patterny-hraneniya-dannyh-v-kubernetes","title":{"rendered":"Dataopbevaringsm\u00f8nstre i Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Dataopbevaringsm\u00f8nstre<\/a><\/noindex>
\nHello, Habr!<\/p>\n

Vi minder om, at vi har offentliggjort endnu en ekstremt interessant og nyttig bog<\/a><\/noindex> om Kubernetes-m\u00f8nstre. Det hele startede med \"M\u00f8nstre<\/a><\/noindex>\" Brendan Burns, og desuden er arbejdet inden for dette segment hos os i fuld gang<\/a><\/noindex>. I dag tilbyder vi dig at l\u00e6se et blogindl\u00e6g fra MinIO, der kortl\u00e6gger tendenserne og specifikationerne for datalagringsm\u00f8nstre i Kubernetes.
\n<\/a><\/noindex><\/p>\n

Kubernetes har fundamentalt \u00e6ndret de traditionelle m\u00f8nstre for udvikling og implementering af applikationer. Nu kan teamet bruge kun f\u00e5 dage p\u00e5 at udvikle, teste og implementere en applikation \u2013 i forskellige milj\u00f8er, alt sammen inden for Kubernetes-klynger. Arbejde med teknologi fra tidligere generationer tog normalt hele uger, hvis ikke flere m\u00e5neder.<\/p>\n

Denne acceleration er blevet muliggjort takket v\u00e6re den abstraktion, som Kubernetes tilbyder \u2013 det vil sige, at Kubernetes selv h\u00e5ndterer interaktionen med de lavere niveauer af fysiske eller virtuelle maskiner, hvilket g\u00f8r det muligt for brugerne at angive blandt andre parametre den n\u00f8dvendige processor, den n\u00f8dvendige m\u00e6ngde hukommelse, og antallet af containerinstanser. Da et enormt f\u00e6llesskab er involveret i vedligeholdelsen af Kubernetes, og anvendelsen af Kubernetes konstant udvides, f\u00f8rer det klart blandt alle containerorkestreringsplatforme.<\/p>\n

I takt med at brugen af Kubernetes vokser, stiger forvirringen omkring de anvendte datalagringsm\u00f8nstre<\/b><\/i>.<\/p>\n

I den udbredte konkurrence om en del af kagen Kubernetes (det vil sige, om datalagring), n\u00e5r det kommer til datalagring, drukner signalet i det st\u00e6rke st\u00f8j.
\nKubernetes repr\u00e6senterer den moderne model for udvikling og implementering af applikationer samt for deres administration. Denne moderne model adskiller datalagring fra beregning. For fuldt ud at forst\u00e5 denne adskillelse i konteksten af Kubernetes, skal man ogs\u00e5 forst\u00e5, hvad applikationer, der arbejder med tilstand og uden tilstand, er, samt hvordan datalagring passer ind i dette. Her har REST API-tilgangen, der anvendes af S3, klare fordele i forhold til POSIX\/CSI-tilgangen, som er karakteristisk for andre l\u00f8sninger.<\/p>\n

I denne artikel vil vi tale om datalagringsm\u00f8nstre i Kubernetes og s\u00e6rligt ber\u00f8re debatten om applikationer, der k\u00f8rer med og uden vedvarende tilstand, for bedre at forst\u00e5 forskellen mellem dem, og hvorfor den er vigtig. Artiklen vil se p\u00e5 applikationer og de anvendte datalagringsm\u00f8nstre i lyset af bedste praksis for arbejde med containere og Kubernetes.<\/p>\n

Containere uden vedvarende tilstand<\/h4>\n

\nContainere er iboende letv\u00e6gts og efemeriske. De kan nemt stoppes, slettes eller implementeres p\u00e5 en anden node - alt dette tager kun f\u00e5 sekunder. I et stort containers orchestrationssystem sker s\u00e5danne operationer konstant, og brugerne bem\u00e6rker ikke engang disse \u00e6ndringer. Dog er flytninger kun mulige, hvis containeren ikke har nogen afh\u00e6ngigheder fra den node, den befinder sig p\u00e5. Disse containere siges at fungere uden vedvarende tilstand<\/i>.<\/p>\n

Containere med vedvarende tilstand<\/h4>\n

\nHvis en container gemmer data p\u00e5 lokalt tilsluttede enheder (eller p\u00e5 et bloklager), skal datalagringsmediet, som den befinder sig p\u00e5, flyttes til den nye node sammen med selve containeren i tilf\u00e6lde af fejl. Dette er vigtigt, da applikationen, der k\u00f8rer i containeren, ellers ikke kan fungere korrekt, fordi den skal tilg\u00e5 de data, der er gemt p\u00e5 de lokale medier. Disse containere siges at fungere med vedvarende tilstand<\/i>.<\/p>\n

Rent teknisk kan containere med vedvarende tilstand ogs\u00e5 flyttes til andre noder. Dette sikres typisk ved hj\u00e6lp af distribuerede filsystemer eller block storage-netv\u00e6rk tilsluttet alle noder, hvor containere k\u00f8rer. P\u00e5 denne m\u00e5de f\u00e5r containere adgang til volumener til vedvarende datalagring, og informationen gemmes p\u00e5 diske, der er spredt over hele netv\u00e6rket. Jeg vil kalde denne metode \"container-tilgangen med vedvarende tilstand<\/i>\", og i resten af artiklen vil jeg referere til den p\u00e5 denne m\u00e5de for ensartethed.<\/p>\n

\"Dataopbevaringsm\u00f8nstre
\n
\nI et typisk container-baseret tilgang med vedholdenhed knyttes alle applikations-pods til et f\u00e6lles distribueret filsystem - hvilket skaber en slags delt lager, hvor alle applikationsdata findes. Selvom der kan v\u00e6re visse variationer, er dette en overordnet tilgang.<\/p>\n

Lad os nu se p\u00e5, hvorfor den container-baserede tilgang med vedholdenhed i en cloud-venlig verden er et antipattern.<\/p>\n

Cloud-orienteret applikationsdesign<\/h4>\n

\nTraditionelt brugte applikationer databaser til struktureret opbevaring af information og lokale diske eller distribuerede filsystemer, hvor alle ustrukturerede eller endda semi-strukturerede data blev gemt. Efterh\u00e5nden som volumenerne af ustrukturerede data voksede, inds\u00e5 udviklerne, at POSIX var for \"snakkesalig\", forbundet med betydelige omkostninger og til sidst h\u00e6mmede applikationens funktion, n\u00e5r den skulle skalere til reelle store st\u00f8rrelser.<\/p>\n

Dette bidrog hovedsageligt til fremkomsten af en ny datalagringsstandard, nemlig cloud-orienterede lagre, der prim\u00e6rt opererer baseret p\u00e5 REST API'er og frig\u00f8r applikationen fra den byrdefulde vedligeholdelse af lokalt datalager. I s\u00e5 fald arbejder applikationen reelt uden vedholdenhed (da tilstanden er i det fjerntliggende lager). Moderne applikationer bygges fra bunden med dette aspekt i tankerne. Generelt er enhver moderne applikation, der h\u00e5ndterer data af forskellige slags (logs, metadata, blobs osv.), bygget efter et cloud-orienteret paradigme, hvor tilstanden overf\u00f8res til et dedikeret software-system til opbevaring af dette. <\/p>\n

Den container-baserede tilgang med vedholdenhed tvinger hele denne paradigm til at tilbageg\u00e5 til det, hvor det startede! <\/b><\/i><\/p>\n

N\u00e5r der anvendes POSIX-gr\u00e6nseflader til datalagring, fungerer applikationerne p\u00e5 samme m\u00e5de, som hvis de gemte tilstand, og derfor fraviger de de mest centrale postulater i skydesign, nemlig muligheden for at variere st\u00f8rrelserne af applikationernes arbejdstr\u00e5de afh\u00e6ngigt af den indkommende belastning, at bev\u00e6ge sig til en ny node, s\u00e5 snart den aktuelle node fejler, og s\u00e5 videre.<\/p>\n

Ved at se n\u00e6rmere p\u00e5 denne situation opdager vi, at n\u00e5r vi v\u00e6lger datalagring, st\u00e5r vi igen og igen over for dilemmaet \"POSIX versus REST API\", MEN med en yderligere forv\u00e6rring af problemsituationer med POSIX, der skyldes den distribuerede natur af Kubernetes-milj\u00f8er. Is\u00e6r,<\/p>\n