Hej Habr!
Vi påminner dig om att vi har släppt en annan extremt intressant och användbar om Kubernetes mönster. Allt började med "" Brendan Burns, och förresten, vi har arbete inom det här segmentet . Idag inbjuder vi dig att läsa en artikel från MinIO-bloggen som kort beskriver trenderna och specifikationerna för datalagringsmönster i Kubernetes.
Kubernetes har i grunden förändrat traditionell applikationsutveckling och distributionsmönster. Nu kan ett team utveckla, testa och distribuera en applikation på några dagar – i flera miljöer, allt inom Kubernetes-kluster. Sådant arbete med tidigare generationer av teknik tog vanligtvis veckor, om inte månader.
Denna acceleration möjliggörs av abstraktionen från Kubernetes - det vill säga eftersom Kubernetes själv interagerar med lågnivådetaljerna i fysiska eller virtuella maskiner, vilket gör det möjligt för användare att deklarera den önskade processorn, den önskade mängden minne och antalet behållare exempel, bland andra parametrar. Med en enorm gemenskap som stödjer Kubernetes och dess användning växer kontinuerligt, är Kubernetes ledande bland alla containerorkestreringsplattformar med stor marginal.
När användningen av Kubernetes ökar, ökar också förvirringen om dess lagringsmönster..
Med alla som tävlar om en bit av Kubernetes-kajen (dvs datalagring), när det kommer till att prata om datalagring, dränks signalen i mycket brus.
Kubernetes förkroppsligar en modern modell för applikationsutveckling, distribution och hantering. Denna moderna modell frikopplar datalagring från beräkning. För att till fullo förstå avskiljning i Kubernetes-sammanhang måste du också förstå vad tillståndssäkra och tillståndslösa applikationer är, och hur datalagring passar in i det. Det är här REST API-metoden som används av S3 har klara fördelar jämfört med POSIX/CSI-metoden för andra lösningar.
I den här artikeln kommer vi att prata om datalagringsmönster i Kubernetes och specifikt beröra debatten mellan statliga och tillståndslösa applikationer för att bättre förstå vad skillnaden mellan dem är och varför det är viktigt. Resten av texten kommer att titta på applikationer och deras datalagringsmönster i ljuset av bästa praxis för att arbeta med behållare och Kubernetes.
Statslösa behållare
Behållare är till sin natur lätta och tillfälliga. De kan enkelt stoppas, tas bort eller distribueras till en annan nod - allt på några sekunder. I ett stort containerorkestreringssystem sker sådana operationer hela tiden, och användare märker inte ens sådana förändringar. Flyttningar är dock endast möjliga om behållaren inte har några beroenden av noden på vilken den är placerad. Sådana behållare sägs fungera statslös.
Statliga behållare
Om en behållare lagrar data på lokalt anslutna enheter (eller på en blockenhet), måste datalagringen som den finns på flyttas till en ny nod, tillsammans med själva behållaren, i händelse av ett fel. Detta är viktigt eftersom annars applikationen som körs i behållaren inte kommer att kunna fungera korrekt eftersom den behöver komma åt data lagrad på lokala medier. Sådana behållare sägs fungera ståtlig.
Rent tekniskt kan stateful containrar även flyttas till andra noder. Detta uppnås vanligtvis med hjälp av distribuerade filsystem eller blocknätverkslagring kopplad till alla noder som kör behållare. På detta sätt får behållare åtkomst till volymer för beständig datalagring, och information lagras på diskar i hela nätverket. Jag kommer att kalla denna metod "stateful container approach", och i resten av artikeln kommer jag att kalla det det för enhetlighetens skull.
I ett typiskt tillståndsstyrt container-tillvägagångssätt är alla programpoddar kopplade till ett enda distribuerat filsystem – ett slags delad lagring där all programdata finns. Även om vissa variationer är möjliga, är detta ett tillvägagångssätt på hög nivå.
Låt oss nu titta på varför den statistiska containermetoden är ett antimönster i en molncentrerad värld.
Molnbaserad applikationsdesign
Traditionellt använde applikationer databaser för strukturerad lagring av information och lokala diskar eller distribuerade filsystem där all ostrukturerad eller till och med semistrukturerad data dumpades. När volymerna av ostrukturerad data växte insåg utvecklarna att POSIX var för pratsam, hade betydande omkostnader och i slutändan hindrade applikationsprestanda när de flyttade till verkligt stora skalor.
Detta bidrog främst till uppkomsten av en ny standard för datalagring, det vill säga molnbaserad lagring, som huvudsakligen arbetar baserat på REST API och frigör applikationen från det betungande underhållet av en lokal datalagring. I det här fallet går programmet i tillståndslöst läge (eftersom tillståndet är i fjärrlagring). Moderna applikationer byggs från grunden med denna faktor i åtanke. Som regel är alla moderna applikationer som behandlar data av ett eller annat slag (loggar, metadata, blobbar etc.) byggt enligt ett molnorienterat paradigm, där tillståndet överförs till ett mjukvarusystem speciellt dedikerat för dess lagring.
Den statistiska containermetoden tvingar tillbaka hela detta paradigm precis där det började!
Genom att använda POSIX-gränssnitt för att lagra data fungerar applikationer som om de vore tillståndsbestämda, och på grund av detta avviker de från de viktigaste principerna för molncentrerad design, det vill säga möjligheten att variera storleken på applikationsarbetartrådar beroende på inkommande input.load, flytta till en ny nod så snart den aktuella noden misslyckas, och så vidare.
Om vi tittar närmare på den här situationen finner vi att när vi väljer ett datalager ställs vi gång på gång inför POSIX vs. REST API-dilemmat, MEN med den ytterligare förvärringen av POSIX-problem på grund av den distribuerade naturen hos Kubernetes-miljöer. Särskilt,
- POSIX är pratsam: POSIX-semantik kräver att varje operation associeras med metadata och filbeskrivningar som hjälper till att upprätthålla operationens tillstånd. Detta resulterar i betydande kostnader som inte har något verkligt värde. Objektlagrings-API:er, särskilt S3 API:er, blir av med dessa krav, vilket gör att applikationen kan aktiveras och sedan "glömma" samtalet. Lagringssystemets svar indikerar om åtgärden lyckades eller inte. Om det misslyckas kan programmet försöka igen.
- Nätverksbegränsningar: I ett distribuerat system antyds det att det kan finnas många applikationer som försöker skriva data till samma anslutna media. Därför kommer inte bara applikationer att konkurrera med varandra om dataöverföringsbandbredd (för att skicka data till media), utan själva lagringssystemet kommer att konkurrera om denna bandbredd genom att skicka data över fysiska diskar. På grund av att POSIX är talande, ökar antalet nätverkssamtal flera gånger. Å andra sidan ger S3 API en tydlig skillnad mellan nätverksanrop mellan de som kommer från klienten till servern och de som sker inom servern.
- Безопасность: POSIX-säkerhetsmodellen är designad för aktivt mänskligt deltagande: administratörer konfigurerar specifika åtkomstnivåer för varje användare eller grupp. Detta paradigm är svårt att anpassa till en molncentrerad värld. Moderna applikationer är beroende av API-baserade säkerhetsmodeller, där åtkomsträttigheter definieras som en uppsättning policyer, tjänstekonton, tillfälliga referenser etc. tilldelas.
- styrbarhet: Stateful containrar har vissa förvaltningskostnader. Vi pratar om att synkronisera parallell åtkomst till data, säkerställa datakonsistens, allt detta kräver noggrant övervägande av vilka dataåtkomstmönster som ska användas. Ytterligare programvara måste installeras, övervakas och konfigureras, för att inte tala om ytterligare utvecklingsinsatser.
Gränssnitt för lagring av containerdata
Medan Container Storage Interface (CSI) har varit till stor hjälp med spridningen av Kubernetes volymlager, genom att delvis lägga ut det på tredjepartslagringsleverantörer, har det också oavsiktligt bidragit till tron att tillvägagångssättet för stateful container är den rekommenderade metoden för lagra data i Kubernetes.
CSI utvecklades som en standard för att tillhandahålla godtyckliga block- och fillagringssystem till äldre applikationer när de körs på Kubernetes. Och, som den här artikeln har visat, är den enda situationen där en stateful container-ansats (och CSI i sin nuvarande form) är meningsfull när själva applikationen är ett äldre system där det inte är möjligt att lägga till stöd för objektlagrings-API:et .
Det är viktigt att förstå att med CSI i sin nuvarande form, det vill säga att montera volymer när man arbetar med moderna applikationer, kommer vi att stöta på ungefär samma problem som uppstod i system där datalagring är organiserad i POSIX-stil.
Ett bättre tillvägagångssätt
I det här fallet är det viktigt att förstå att de flesta applikationer inte är utformade specifikt för tillståndslöst eller tillståndslöst arbete. Detta beteende beror på den övergripande systemarkitekturen och de specifika designval som gjorts. Låt oss prata lite om stateful applikationer.
I princip kan all applikationsdata delas in i flera breda typer:
- Logga data
- Tidsstämpeldata
- Transaktionsdata
- Metadata
- Containerbilder
- Blob-data (binärt stort objekt).
Alla dessa datatyper stöds mycket väl på moderna lagringsplattformar, och det finns flera molnbaserade plattformar som är skräddarsydda för att leverera data i vart och ett av dessa specifika format. Till exempel kan transaktionsdata och metadata finnas i en modern molnbaserad databas som CockroachDB, YugaByte, etc. Behållarbilder eller blobdata kan lagras i ett docker-register baserat på MinIO. Tidstämpeldata kan lagras i en tidsseriedatabas som InfluxDB, etc. Vi kommer inte att gå in i detalj om varje datatyp och dess tillämpningar här, men den allmänna idén är att undvika beständig datalagring som är beroende av lokal diskmontering.
Dessutom är det ofta effektivt att tillhandahålla ett temporärt cachelager som fungerar som ett temporärt fillager för applikationer, men applikationer bör inte vara beroende av detta skikt som källan till sanning.
Stateful applikationslagring
Även om det i de flesta fall är användbart att hålla applikationer tillståndslösa, måste de applikationer som är designade för att lagra data - såsom databaser, objektlagringar, nyckel-värdelagringar - vara tillståndsfulla. Låt oss titta på varför dessa applikationer distribueras på Kubernetes. Låt oss ta MinIO som ett exempel, men liknande principer gäller för alla andra stora molnbaserade lagringssystem.
Molnbaserade applikationer är designade för att dra full nytta av flexibiliteten som är inneboende i containrar. Det betyder att de inte gör några antaganden om miljön där de kommer att användas. Till exempel använder MinIO en intern raderingskodningsmekanism för att förse systemet med tillräckligt motståndskraft för att förbli funktionsdugligt även om hälften av diskarna misslyckas. MinIO hanterar även dataintegritet och säkerhet med hjälp av proprietär server-side hashing och kryptering.
För sådana molncentrerade applikationer är lokala persistenta volymer (PV) mest bekväma som backuplagring. Lokal PV ger möjlighet att lagra rådata, medan applikationer som körs ovanpå dessa PV:er samlar in information oberoende av varandra för att skala data och hantera växande datakrav.
Detta tillvägagångssätt är mycket enklare och betydligt mer skalbart än CSI-baserade PV:er, som introducerar sina egna lager av datahantering och redundans i systemet; poängen är att dessa lager vanligtvis är i konflikt med applikationer som är designade för att vara tillståndsfulla.
En stark rörelse mot att frikoppla data från beräkningar
I den här artikeln pratade vi om hur applikationer omorienteras för att fungera utan att spara tillstånd, eller med andra ord, lagring av data är frikopplad från datoranvändning på den. Avslutningsvis, låt oss titta på några verkliga exempel på denna trend.
, en framstående dataanalysplattform, har traditionellt sett varit tillståndsfull och distribuerad på HDFS. Men när Spark flyttar in i en molncentrerad värld, används plattformen i allt högre grad tillståndslös med "s3a". Spark använder s3a för att överföra tillstånd till andra system, medan Spark-containrar själva fungerar helt tillståndslösa. Andra stora företagsaktörer inom området big data analytics, i synnerhet, , , De går också över till att arbeta med separation av datalagring och beräkningar på dem.
Liknande mönster kan också ses på andra stora analytiska plattformar, inklusive Presto, Tensorflow till R, Jupyter. Genom att överföra tillstånd till fjärrbaserade molnlagringssystem blir det mycket lättare att hantera och skala din applikation. Dessutom underlättar det applikationens portabilitet till en mängd olika miljöer.
Källa: will.com