I slutet av förra Äret Àgde Ànnu en livesÀndning av den ryska PostgreSQL-gemenskapen rum , under vilken dess medgrundare Nikolai Samokhvalov talade med Flant tekniska direktör Dmitry Stolyarov om detta DBMS i samband med Kubernetes.
Vi publicerar en utskrift av huvuddelen av denna diskussion, och kl Hela videon publicerad:
Databaser och Kubernetes
NA: Vi kommer inte att prata om VAKUUM och KONTROLLPOINT idag. Vi vill prata om Kubernetes. Jag vet att du har mÄnga Ärs erfarenhet. Jag tittade pÄ dina videor och sÄg till och med pÄ nÄgra av dem igen... LÄt oss gÄ direkt till saken: varför Postgres eller MySQL i K8s överhuvudtaget?
DS: Det finns inte och kan inte finnas ett definitivt svar pÄ denna frÄga. Men i allmÀnhet Àr detta enkelhet och bekvÀmlighet... potential. Alla vill ha hanterade tjÀnster.
NA: Till hur , bara hemma?
DS: Ja: som RDS, precis var som helst.
NA: "Var som helst" Àr en bra poÀng. I stora företag finns allt pÄ olika platser. Varför dÄ, om det Àr ett stort företag, inte ta en fÀrdig lösning? Till exempel har Nutanix sin egen utveckling, andra företag (VMware...) har samma "RDS, bara hemma."
DS: Men vi pratar om en separat implementering som bara kommer att fungera under vissa förutsÀttningar. Och om vi pratar om Kubernetes, sÄ finns det en enorm variation av infrastruktur (som kan vara i K8s). Detta Àr i huvudsak en standard för API:er till molnet...
NA: Det Àr ocksÄ gratis!
DS: Det Àr inte sÄ viktigt. Frihet Àr viktigt för ett inte sÀrskilt stort segment av marknaden. NÄgot annat Àr viktigt... Du kommer sÀkert ihÄg rapporten ""?
NA: Ja.
DS: Jag insĂ„g att det togs emot vĂ€ldigt tvetydigt. Vissa mĂ€nniskor trodde att jag sa: "Gubbar, lĂ„t oss lĂ€gga in alla databaser i Kubernetes!", medan andra bestĂ€mde sig för att alla dessa var hemska cyklar. Men jag ville sĂ€ga nĂ„got helt annat: âTitta vad som hĂ€nder, vilka problem som finns och hur de kan lösas. Ska vi anvĂ€nda Kubernetes-databaser nu? Produktion? Tja, bara om du gillar...att göra vissa saker. Men för en utvecklare kan jag sĂ€ga att jag rekommenderar det. För en utvecklare Ă€r dynamiken i att skapa/ta bort miljöer mycket viktig.â
NS: Med dev, menar du alla miljöer som inte Àr prod? Staging, QA...
DS: Om vi ââpratar om perf-stativ, sĂ„ förmodligen inte, eftersom kraven dĂ€r Ă€r specifika. Om vi ââpratar om speciella fall dĂ€r det behövs en mycket stor databas för iscensĂ€ttning, sĂ„ förmodligen inte... Om detta Ă€r en statisk, lĂ„nglivad miljö, vad Ă€r dĂ„ fördelen med att ha databasen placerad i K8s?
NA: Ingen. Men var ser vi statiska miljöer? En statisk miljö kommer att bli förÄldrad imorgon.
DS: Staging kan vara statisk. Vi har kunder...
NA: Ja, jag har en ocksÄ. Det Àr ett stort problem om du har en 10 TB databas och 200 GB mellanlagring...
DS: Jag har ett vÀldigt coolt fodral! PÄ iscensÀttning finns en produktdatabas som Àndringar görs i. Och det finns en knapp: "rulla ut till produktion". Dessa förÀndringar - deltas - lÀggs till (det verkar som om de helt enkelt synkroniseras via API) i produktionen. Detta Àr ett mycket exotiskt alternativ.
NA: Jag har sett startups i Valley som sitter i RDS eller till och med i Heroku - det hĂ€r Ă€r historier frĂ„n 2-3 Ă„r sedan - och de laddar ner dumpen till sin bĂ€rbara dator. Eftersom databasen fortfarande bara Ă€r 80 GB, och det finns utrymme pĂ„ den bĂ€rbara datorn. Sedan köper de ytterligare diskar till alla sĂ„ att de har 3 databaser för att utföra olika utvecklingar. SĂ„ hĂ€r gĂ„r det ocksĂ„ till. Jag sĂ„g ocksĂ„ att de inte Ă€r rĂ€dda för att kopiera prod till iscensĂ€ttning â det beror vĂ€ldigt mycket pĂ„ företaget. Men jag sĂ„g ocksĂ„ att de Ă€r vĂ€ldigt rĂ€dda, och att de ofta inte har tillrĂ€ckligt med tid och hĂ€nder. Men innan vi gĂ„r vidare till det hĂ€r Ă€mnet vill jag höra om Kubernetes. FörstĂ„r jag rĂ€tt att ingen Ă€r i prod Ă€n?
DS: Vi har smÄ databaser i prod. Vi pratar om volymer pÄ tiotals gigabyte och icke-kritiska tjÀnster för vilka vi var för lata för att göra repliker (och det finns inget sÄdant behov). Och förutsatt att det finns normal lagring under Kubernetes. Denna databas fungerade i en virtuell maskin - villkorligt i VMware, ovanpÄ lagringssystemet. Vi placerade in den och nu kan vi överföra det frÄn maskin till maskin.
NA: Databaser av den hÀr storleken, upp till 100 GB, kan vÀl rullas ut pÄ nÄgra minuter pÄ bra diskar och ett bra nÀtverk? En hastighet pÄ 1 GB per sekund Àr inte lÀngre exotiskt.
DS: Ja, för linjÀr drift Àr detta inget problem.
NA: Okej, vi mÄste bara tÀnka pÄ prod. Och om vi övervÀger Kubernetes för icke-prod miljöer, vad ska vi göra? Jag ser det pÄ Zalando , i Crunchy , det finns nÄgra andra alternativ. Och dÀr Àr - det hÀr Àr vÄr gode vÀn Alvaro frÄn Spanien: vad de gör Àr i princip inte bara , och hela distributionen (), dÀr de, förutom Postgres sjÀlv, ocksÄ bestÀmde sig för att stoppa in en sÀkerhetskopia, Envoy proxy...
DS: SÀndebud för vad? Balansera Postgres-trafik specifikt?
NA: Ja. Det vill sÀga, de ser det som: om du tar en Linux-distribution och kÀrna, sÄ Àr vanlig PostgreSQL kÀrnan, och de vill göra en distribution som ska vara molnvÀnlig och köras pÄ Kubernetes. De sÀtter ihop komponenter (sÀkerhetskopior etc.) och felsöker dem sÄ att de fungerar bra.
DS: VÀldigt coolt! I huvudsak Àr detta programvara för att skapa din egen hanterade Postgres.
NA: Linux-distributioner har eviga problem: hur man gör drivrutiner sÄ att all hÄrdvara stöds. Och de har tanken att de ska jobba i Kubernetes. Jag vet att i Zalando-operatören sÄg vi nyligen en koppling till AWS och detta Àr inte lÀngre sÀrskilt bra. Det borde inte finnas nÄgon koppling till en specifik infrastruktur - vad Àr poÀngen dÄ?
DS: Jag vet inte exakt vilken situation Zalando hamnade i, men i Kubernetes Ă€r lagring nu gjord pĂ„ ett sĂ„dant sĂ€tt att det Ă€r omöjligt att ta en disksĂ€kerhetskopiering med en generisk metod. Nyligen i standard - i senaste version â vi gjorde ögonblicksbilder möjliga, men var implementeras det? Ărligt talat, allt Ă€r fortfarande sĂ„ rĂ„tt... Vi provar CSI ovanpĂ„ AWS, GCE, Azure, vSphere, men sĂ„ fort du börjar anvĂ€nda det kan du se att det inte Ă€r klart Ă€n.
NA: Det Àr dÀrför vi ibland mÄste förlita oss pÄ infrastruktur. Jag tror att detta fortfarande Àr ett tidigt stadium - vÀxtvÀrk. FrÄga: Vilka rÄd skulle du ge till nybörjare som vill prova PgSQL i K8s? Vilken operatör kanske?
DS: Problemet Àr att Postgres Àr 3% för oss. Vi har ocksÄ en mycket stor lista med olika programvaror i Kubernetes, jag kommer inte ens att lista allt. Till exempel Elasticsearch. Det finns mÄnga operatörer: vissa utvecklas aktivt, andra inte. Vi har stÀllt upp krav pÄ oss sjÀlva, vad som ska finnas i operatören sÄ att vi tar det pÄ allvar. I en operatör specifikt för Kubernetes - inte i en "operatör att göra nÄgot under Amazons förhÄllanden"... Faktum Àr att vi ganska brett (= nÀstan alla kunder) anvÀnder en enda operatör - (vi kommer snart att publicera en artikel om honom).
NA: Och inte för MySQL heller? Jag vet att Percona... eftersom de nu arbetar med MySQL, MongoDB och Postgres kommer de att behöva skapa nÄgon form av universell lösning: för alla databaser, för alla molnleverantörer.
DS: Vi hade inte tid att titta pÄ operatörerna för MySQL. Detta Àr inte vÄrt huvudfokus just nu. MySQL fungerar bra i fristÄende. Varför anvÀnda en operatör om du bara kan starta en databas... Du kan starta en Docker-behÄllare med Postrges, eller sÄ kan du starta den pÄ ett enkelt sÀtt.
NA: Det var en frÄga om detta ocksÄ. Ingen operatör alls?
DS: Ja, 100 % av oss har PostgreSQL igĂ„ng utan en operatör. SĂ„ lĂ„ngt sĂ„. Vi anvĂ€nder aktivt operatören för Prometheus och Redis. Vi har planer pĂ„ att hitta en operatör för Elasticsearch - det Ă€r den som brinner mest, eftersom vi vill installera den i Kubernetes i 100 % av fallen. Precis som vi vill sĂ€kerstĂ€lla att MongoDB ocksĂ„ alltid Ă€r installerat i Kubernetes. HĂ€r dyker det upp vissa önskemĂ„l â det finns en kĂ€nsla av att i dessa fall kan nĂ„got göras. Och vi tittade inte ens pĂ„ Postgres. Naturligtvis vet vi att det finns olika alternativ, men i sjĂ€lva verket har vi en fristĂ„ende.
DB för testning i Kubernetes
NA: LĂ„t oss gĂ„ vidare till Ă€mnet testning. Hur man rullar ut Ă€ndringar i databasen â ur ett DevOps-perspektiv. Det finns mikrotjĂ€nster, mĂ„nga databaser, nĂ„got förĂ€ndras nĂ„gonstans hela tiden. Hur man sĂ€kerstĂ€ller normal CI/CD sĂ„ att allt Ă€r i sin ordning ur DBMS perspektiv. Vad Ă€r ditt förhĂ„llningssĂ€tt?
DS: Det kan inte finnas ett svar. Det finns flera alternativ. Den första Àr storleken pÄ basen som vi vill rulla ut. Du nÀmnde sjÀlv att företag har olika attityder till att ha en kopia av prod-databasen pÄ dev och scen.
NA: Och under villkoren i GDPR tror jag att de Àr mer och mer försiktiga... Jag kan sÀga att i Europa har de redan börjat utdöma böter.
DS: Men ofta kan du skriva programvara som tar en dumpning frÄn produktionen och fördunklar den. Prod-data erhÄlls (snapshot, dump, binÀr kopia...), men den Àr anonymiserad. IstÀllet kan det finnas generationsskript: dessa kan vara fixturer eller bara ett skript som genererar en stor databas. Problemet Àr: hur lÄng tid tar det att skapa en basbild? Och hur lÄng tid tar det att distribuera den i önskad miljö?
Vi kom till ett schema: om klienten har en fast datamĂ€ngd (minimal version av databasen), anvĂ€nder vi dem som standard. Om vi ââpratar om granskningsmiljöer, nĂ€r vi skapade en filial, distribuerade vi en instans av applikationen - vi rullar ut en liten databas dĂ€r. Men det blev bra , nĂ€r vi tar en dump frĂ„n produktionen en gĂ„ng om dagen (pĂ„ natten) och bygger en Docker-container med PostgreSQL och MySQL med denna laddade data baserad pĂ„ den. Om du behöver utöka databasen 50 gĂ„nger frĂ„n den hĂ€r bilden görs detta ganska enkelt och snabbt.
NA: Genom enkel kopiering?
DS: Data lagras direkt i Docker-bilden. De dÀr. Vi har en fÀrdig bild, om Àn 100 GB. Tack vare lager i Docker kan vi snabbt distribuera den hÀr bilden sÄ mÄnga gÄnger vi behöver. Metoden Àr dum, men den fungerar bra.
NA: Sedan, nÀr du testar, Àndras det precis inuti Docker, eller hur? Kopiera-pÄ-skriv i Docker - slÀng det och gÄ igen, allt Àr bra. Klass! Och anvÀnder du det redan till fullo?
DS: Under en lÄng tid.
NA: Vi gör vÀldigt liknande saker. Bara vi anvÀnder inte Dockers copy-on-write, utan nÄgon annan.
DS: Det Àr inte generiskt. Och Docker fungerar överallt.
NA: I teorin, ja. Men vi har ocksÄ moduler dÀr, du kan göra olika moduler och arbeta med olika filsystem. Vilken stund hÀr. FrÄn Postgres sida ser vi pÄ allt detta annorlunda. Nu tittade jag frÄn Docker-sidan och sÄg att allt fungerar för dig. Men om databasen Àr enorm, till exempel 1 TB, tar allt detta lÄng tid: operationer pÄ natten och att stoppa in allt i Docker... Och om 5 TB stoppas i Docker... Eller Àr allt bra?
DS: Vad Àr skillnaden: det hÀr Àr blobbar, bara bitar och bytes.
NA: Skillnaden Àr denna: gör du det genom dumpning och ÄterstÀllning?
DS: Inte alls nödvÀndigt. Metoderna för att skapa denna bild kan vara olika.
NA: För vissa kunder har vi gjort det sÄ att vi i stÀllet för att regelbundet generera en basbild stÀndigt hÄller den uppdaterad. Det Àr i huvudsak en replik, men den tar inte emot data frÄn mastern direkt, utan genom ett arkiv. Ett binÀrt arkiv dÀr WALs laddas ner varje dag, dÀr sÀkerhetskopior tas... Dessa WALs nÄr sedan basbilden med en liten fördröjning (bokstavligen 1-2 sekunder). Vi klonar frÄn det pÄ vilket sÀtt som helst - nu har vi ZFS som standard.
DS: Men med ZFS Àr du begrÀnsad till en nod.
NA: Ja. Men ZFS har ocksÄ en magisk : med den kan du skicka en ögonblicksbild och till och med (jag har inte riktigt testat det hÀr Àn, men...) kan du skicka ett delta mellan tvÄ PGDATA. Faktum Àr att vi har ett annat verktyg som vi inte riktigt har övervÀgt för sÄdana uppgifter. PostgreSQL har , som fungerar som en "smart" rsync, och hoppar över mycket av det du inte behöver titta pÄ, eftersom ingenting har förÀndrats dÀr. Vi kan göra en snabb synkronisering mellan de tvÄ servrarna och spola tillbaka pÄ samma sÀtt.
SÄ frÄn denna, mer DBA-sida, försöker vi skapa ett verktyg som lÄter oss göra samma sak som du sa: vi har en databas, men vi vill testa nÄgot 50 gÄnger, nÀstan samtidigt.
DS: 50 gÄnger betyder att du behöver bestÀlla 50 Spot-instanser.
NA: Nej, vi gör allt pÄ en maskin.
DS: Men hur kommer du att expandera 50 gÄnger om den hÀr databasen Àr, sÀg, terabyte. Troligtvis behöver hon villkorade 256 GB RAM?
NA: Ja, ibland behöver man mycket minne - det Àr normalt. Men det hÀr Àr ett exempel frÄn livet. Produktionsmaskinen har 96 kÀrnor och 600 GB. Samtidigt anvÀnds 32 kÀrnor (Àven 16 kÀrnor nu ibland) och 100-120 GB minne för databasen.
DS: Och 50 exemplar fÄr plats dÀr?
NA: SÄ det finns bara en kopia, sedan fungerar kopiera-pÄ-skriv (ZFS)... Jag ska berÀtta mer detaljerat.
Vi har till exempel en databas pÄ 10 TB. De gjorde en disk för den, ZFS komprimerade ocksÄ dess storlek med 30-40 procent. Eftersom vi inte gör belastningstestning Àr den exakta svarstiden inte viktig för oss: lÄt den vara upp till 2 gÄnger lÄngsammare - det Àr okej.
Vi ger möjlighet till programmerare, QA, DBA m.m. utför testning i 1-2 trĂ„dar. Till exempel kan de köra nĂ„gon form av migrering. Den krĂ€ver inte 10 kĂ€rnor samtidigt - den behöver 1 Postgres backend, 1 kĂ€rna. Migrationen kommer att börja â kanske kommer fortfarande att starta, dĂ„ kommer den andra kĂ€rnan att anvĂ€ndas. Vi har 16-32 kĂ€rnor tilldelade, sĂ„ 10 personer kan arbeta samtidigt, inga problem.
För fysiskt PGDATA samma sak visar det sig att vi faktiskt lurar Postgres. Tricket Àr detta: till exempel lanseras 10 Postgres samtidigt. Vad Àr problemet vanligtvis? De sÀtter , lÄt oss sÀga 25 %. Följaktligen Àr detta 200 GB. Du kommer inte att kunna starta mer Àn tre av dessa, eftersom minnet kommer att ta slut.
Men vid nÄgot tillfÀlle insÄg vi att detta inte var nödvÀndigt: vi satte shared_buffers till 2 GB. PostgreSQL har , och i verkligheten Àr det den enda som pÄverkar . Vi stÀller in den pÄ 0,5 TB. Och det spelar ingen roll att de faktiskt inte existerar: han planerar som om de existerar.
Följaktligen, nÀr vi testar nÄgon form av migrering, kan vi samla alla planer - vi fÄr se hur det kommer att hÀnda i produktionen. Sekunderna dÀr kommer att vara annorlunda (lÄngsammare), men den data som vi faktiskt lÀser, och sjÀlva planerna (vilka JOINs finns dÀr, etc.) blir exakt samma som i produktionen. Och du kan köra mÄnga sÄdana kontroller parallellt pÄ en maskin.
DS: Tror du inte att det finns nÄgra problem hÀr? Den första Àr en lösning som bara fungerar pÄ PostgreSQL. Detta tillvÀgagÄngssÀtt Àr mycket privat, det Àr inte generiskt. Den andra Àr att Kubernetes (och allt som molnteknologier kommer till nu) involverar mÄnga noder, och dessa noder Àr tillfÀlliga. Och i ditt fall Àr det en tillstÄndsgivande, ihÄllande nod. Dessa saker gör mig i konflikt.
NA: För det första hÄller jag med, det hÀr Àr en ren Postgres-berÀttelse. Jag tror att om vi har nÄgon form av direkt IO och en buffertpool för nÀstan allt minne, kommer detta tillvÀgagÄngssÀtt inte att fungera - planerna kommer att vara annorlunda. Men för nÀrvarande arbetar vi bara med Postgres, vi tÀnker inte pÄ andra.
Om Kubernetes. Du berÀttar sjÀlv överallt att vi har en bestÀndig databas. Om instansen misslyckas Àr det viktigaste att spara disken. HÀr har vi ocksÄ hela plattformen i Kubernetes, och komponenten med Postgres Àr separat (Àven om den kommer att finnas dÀr en dag). DÀrför Àr allt sÄ hÀr: instansen föll, men vi sparade dess PV och kopplade den helt enkelt till en annan (ny) instans, som om ingenting hade hÀnt.
DS: Ur min synvinkel skapar vi poddar i Kubernetes. K8s - resÄr: knutar bestÀlls efter behov. Uppgiften Àr att helt enkelt skapa en pod och sÀga att den behöver X mÀngd resurser, och sedan kommer K8s att rÀkna ut det pÄ egen hand. Men lagringsstödet i Kubernetes Àr fortfarande instabilt: I (denna version slÀpptes av veckan sedan) blir dessa funktioner bara beta.
Sex mÄnader till ett Är kommer att gÄ - det kommer att bli mer eller mindre stabilt, eller Ätminstone kommer det att deklareras som sÄdant. DÄ löser möjligheten till ögonblicksbilder och storleksÀndring ditt problem helt. För du har en bas. Ja, det kanske inte Àr sÀrskilt snabbt, men hastigheten beror pÄ vad som Àr "under huven", eftersom vissa implementeringar kan kopiera och kopiera-pÄ-skriva pÄ disksubsystemnivÄ.
NA: Det Àr ocksÄ nödvÀndigt för alla motorer (Amazon, Google...) att börja stödja denna version - detta tar ocksÄ lite tid.
DS: Vi anvÀnder dem inte Àn. Vi anvÀnder vÄr.
Lokal utveckling för Kubernetes
NA: Har du stött pÄ en sÄdan önskan nÀr du behöver installera alla poddar pÄ en maskin och göra ett sÄ litet test. För att snabbt fÄ ett proof of concept, se att applikationen körs i Kubernetes, utan att dedikera ett gÀng maskiner för det. Det finns Minikube, eller hur?
DS: Det verkar för mig att det hĂ€r fallet - utplacerat pĂ„ en nod - uteslutande handlar om lokal utveckling. Eller nĂ„gra manifestationer av ett sĂ„dant mönster. Ăta , Det finns , . Vi gĂ„r mot att anvĂ€nda Kubernetes IN Docker. Nu började vi jobba med det för tester.
NA: Jag trodde att det hÀr var ett försök att slÄ in alla poddar i en Docker-bild. Men det visade sig att det hÀr handlar om nÄgot helt annat. Hur som helst, det finns separata behÄllare, separata baljor - bara i Docker.
DS: Ja. Och det finns en ganska rolig imitation, men meningen Àr den hÀr... Vi har ett verktyg för utplacering - . Vi vill göra det till ett villkorat lÀge werf up: "FÄ mig lokala Kubernetes." Och kör sedan villkoret dÀr werf follow. Sedan kommer utvecklaren att kunna redigera IDE, och en process kommer att lanseras i systemet som ser Àndringarna och bygger om bilderna och distribuerar dem till lokala K8:er. Det Àr sÄ vi vill försöka lösa problemet med lokal utveckling.
Ăgonblicksbilder och databaskloning i K8s verklighet
NA: Om vi ââĂ„tergĂ„r till copy-on-write. Jag mĂ€rkte att molnen ocksĂ„ har ögonblicksbilder. De fungerar annorlunda. Till exempel i GCP: du har en multi-terabyte-instans pĂ„ USA:s östkust. Du tar ögonblicksbilder med jĂ€mna mellanrum. Du plockar upp en kopia av skivan pĂ„ vĂ€stkusten frĂ„n en ögonblicksbild - om nĂ„gra minuter Ă€r allt klart, det fungerar vĂ€ldigt snabbt, bara cachen behöver fyllas i minnet. Men dessa kloner (ögonblicksbilder) Ă€r för att "tillhandahĂ„lla" en ny volym. Det hĂ€r Ă€r coolt nĂ€r du behöver skapa mĂ„nga instanser.
Men för tester verkar det som om ögonblicksbilder, som du pratar om i Docker eller jag pratar om i ZFS, btrfs och till och med LVM... - de tillÄter dig att inte skapa riktigt ny data pÄ en maskin. I molnet kommer du fortfarande att betala för dem varje gÄng och vÀnta inte sekunder, utan minuter (och i fallet , möjligen en klocka).
IstÀllet kan du fÄ dessa data pÄ en eller tvÄ sekunder, köra testet och slÀnga dem. Dessa ögonblicksbilder löser olika problem. I det första fallet - att skala upp och fÄ nya kopior, och i det andra - för tester.
DS: Jag hÄller inte med. Att fÄ volymkloning att fungera korrekt Àr molnets uppgift. Jag har inte tittat pÄ deras implementering, men jag vet hur vi gör det pÄ hÄrdvara. Vi har Ceph, den tillÄter vilken fysisk volym som helst () sÀger klona och fÄ en andra volym med samma egenskaper pÄ tiotals millisekunder, 'ami, etc. Du mÄste förstÄ att det finns en knepig copy-on-write inuti. Varför skulle inte molnet göra detsamma? Jag Àr sÀker pÄ att de försöker göra det hÀr pÄ ett eller annat sÀtt.
NA: Men det kommer fortfarande att ta dem sekunder, tiotals sekunder att höja en instans, ta dit Docker, etc.
DS: Varför Àr det nödvÀndigt att ta upp en hel instans? Vi har en instans med 32 kÀrnor, 16... och den kan passa in i den - till exempel fyra. NÀr vi bestÀller den femte kommer instansen redan att höjas och sedan tas den bort.
NA: Ja, intressant, Kubernetes visar sig vara en annan historia. VÄr databas Àr inte i K8s, och vi har en instans. Men att klona en databas med flera terabyte tar inte mer Àn tvÄ sekunder.
DS: Det hÀr Àr bra. Men min första poÀng Àr att detta inte Àr en generisk lösning. Ja, det Àr coolt, men det Àr bara lÀmpligt för Postgres och bara pÄ en nod.
NA: Den passar inte bara för Postgres: dessa planer, som jag beskrev, fungerar bara i den. Men om vi inte bryr oss om planer och vi bara behöver all data för funktionstestning, sÄ Àr detta lÀmpligt för alla DBMS.
DS: För mÄnga Är sedan gjorde vi nÄgot liknande pÄ LVM ögonblicksbilder. Det hÀr Àr en klassiker. Detta tillvÀgagÄngssÀtt anvÀndes mycket aktivt. Statliga noder Àr bara en smÀrta. För du ska inte tappa dem, du ska alltid komma ihÄg dem...
NA: Ser du nÄgon möjlighet till en hybrid hÀr? LÄt oss sÀga att stateful Àr nÄgon form av pod, den fungerar för flera personer (mÄnga testare). Vi har en volym, men tack vare filsystemet Àr klonerna lokala. Om podden faller, men disken finns kvar, kommer podden att stiga, rÀkna information om alla kloner, plocka upp allt igen och sÀga: "HÀr körs dina kloner pÄ dessa portar, fortsÀtt att arbeta med dem."
DS: Tekniskt sett betyder detta att inom Kubernetes Àr det en pod inom vilken vi kör mÄnga Postgres.
NA: Ja. Han har en grÀns: lÄt oss sÀga att inte mer Àn 10 personer arbetar med honom samtidigt. Om du behöver 20, lanserar vi en andra sÄdan pod. Vi kommer att helt klona den, efter att ha fÄtt den andra fulla volymen, kommer den att ha samma 10 "tunna" kloner. Ser du inte denna möjlighet?
DS: Vi mÄste lÀgga till sÀkerhetsproblem hÀr. Denna typ av organisation innebÀr att den hÀr podden har höga privilegier (kapacitet), eftersom den kan utföra icke-standardiserade operationer pÄ filsystemet... Men jag upprepar: jag tror att de pÄ medellÄng sikt kommer att fixa lagring i Kubernetes, och i molnen de kommer att fixa hela historien med volymer - allt kommer "bara att fungera". Det kommer att Àndras storlek, klonas ... Det finns en volym - vi sÀger: "Skapa en ny baserat pÄ det," och efter en och en halv sekund fÄr vi vad vi behöver.
NA: Jag tror inte pÄ en och en halv sekund för mÄnga terabyte. PÄ Ceph gör du det sjÀlv, men du pratar om molnen. GÄ till molnet, gör en klon av en multiterabyte EBS-volym pÄ EC2 och se hur prestandan kommer att bli. Det tar inte nÄgra sekunder. Jag Àr vÀldigt intresserad av nÀr de nÄr den hÀr nivÄn. Jag förstÄr vad du sÀger, men jag ber att skilja mig Ät.
DS: Ok, men jag sa pÄ medellÄng sikt, inte pÄ kort sikt. För nÄgra Är.
Om operatören för PostgreSQL frÄn Zalando
Mitt under det hÀr mötet gick Àven Alexey Klyukin, en före detta utvecklare frÄn Zalando, med och berÀttade om PostgreSQL-operatörens historia:
Det Àr bra att det hÀr Àmnet berörs i allmÀnhet: bÄde Postgres och Kubernetes. NÀr vi började göra det pÄ Zalando 2017 var det ett Àmne som alla ville göra, men ingen gjorde det. Alla hade redan Kubernetes, men nÀr de frÄgade vad de skulle göra med databaser gillar till och med folk , som predikade K8s, sa ungefÀr sÄ hÀr:
"GĂ„ till hanterade tjĂ€nster och anvĂ€nd dem, kör inte databasen i Kubernetes. Annars kommer dina K8:or att bestĂ€mma sig för att till exempel göra en uppgradering, stĂ€nga av alla noder och din data kommer att flyga lĂ„ngt, lĂ„ngt bort.â
Vi bestĂ€mde oss för att skapa en operatör som, i motsats till detta rĂ„d, kommer att lansera en Postgres-databas i Kubernetes. Och vi hade en bra anledning - . Detta Ă€r en automatisk failover för PostgreSQL, gjord pĂ„ rĂ€tt sĂ€tt, d.v.s. anvĂ€nder etcd, consul eller ZooKeeper som lagring av information om klustret. Ett sĂ„dant förrĂ„d som ska ge alla som frĂ„gar till exempel vad den nuvarande ledaren Ă€r, samma information â trots att vi har allt utdelat â sĂ„ att det inte blir en splittrad hjĂ€rna. Plus att vi hade för honom.
I allmÀnhet uppstod företagets behov av automatisk failover efter migrering frÄn ett internt hÄrdvarudatacenter till molnet. Molnet var baserat pÄ en egenutvecklad PaaS-lösning (Platform-as-a-Service). Det Àr öppen kÀllkod, men det krÀvdes mycket arbete för att fÄ det igÄng. Det kallades .
FrĂ„n början fanns det ingen Kubernetes. NĂ€rmare bestĂ€mt, nĂ€r vĂ„r egen lösning implementerades fanns redan K8s, men den var sĂ„ rĂ„ att den inte lĂ€mpade sig för produktion. Det var enligt mig 2015 eller 2016. 2017 hade Kubernetes blivit mer eller mindre mogna â det fanns ett behov av att migrera dit.
Och vi hade redan en Docker-container. Det fanns en PaaS som anvÀnde Docker. Varför inte prova K8s? Varför inte skriva din egen operatör? Murat Kabilov, som kom till oss frÄn Avito, startade detta som ett projekt pÄ eget initiativ - "att spela" - och projektet "tog fart."
Men generellt sett ville jag prata om AWS. Varför fanns det historisk AWS-relaterad kod...
NĂ€r du kör nĂ„got i Kubernetes mĂ„ste du förstĂ„ att K8s Ă€r ett sĂ„dant pĂ„gĂ„ende arbete. Det utvecklas, förbĂ€ttras och till och med gĂ„r sönder dĂ„ och dĂ„. Du mĂ„ste hĂ„lla ett öga pĂ„ alla förĂ€ndringar i Kubernetes, du mĂ„ste vara redo att dyka ner i det om nĂ„got hĂ€nder och lĂ€ra dig hur det fungerar i detalj â kanske mer Ă€n du skulle vilja. Detta gĂ€ller i princip alla plattformar dĂ€r du kör dina databaser...
SÄ nÀr vi gjorde uttalandet körde vi Postgres pÄ en extern volym (EBS i det hÀr fallet eftersom vi arbetade med AWS). Databasen vÀxte, nÄgon gÄng var det nödvÀndigt att Àndra storlek pÄ den: till exempel var den ursprungliga storleken pÄ EBS 100 TB, databasen vÀxte till den, nu vill vi göra EBS 200 TB. Hur? LÄt oss sÀga att du kan göra en dumpning/ÄterstÀllning pÄ en ny instans, men det kommer att ta lÄng tid och innebÀra driftstopp.
DÀrför ville jag ha en storleksÀndring som skulle förstora EBS-partitionen och sedan berÀtta för filsystemet att anvÀnda det nya utrymmet. Och vi gjorde det, men vid den tiden hade Kubernetes inget API för storleksÀndringsoperationen. Eftersom vi arbetade med AWS skrev vi kod för dess API.
Ingen hindrar dig frĂ„n att göra samma sak för andra plattformar. Det finns ingen antydan i uttalandet att det bara kan köras pĂ„ AWS, och det kommer inte att fungera pĂ„ allt annat. I allmĂ€nhet Ă€r detta ett Open Source-projekt: om nĂ„gon vill pĂ„skynda uppkomsten av anvĂ€ndningen av det nya API:et Ă€r du vĂ€lkommen. Ăta , pull-förfrĂ„gningar - Zalando-teamet försöker svara pĂ„ dem ganska snabbt och marknadsföra operatören. SĂ„ vitt jag vet, projektet pĂ„ Google Summer of Code och nĂ„gra andra liknande initiativ. Zalando arbetar mycket aktivt med det.
PS bonus!
Om du Àr intresserad av Àmnet PostgreSQL och Kubernetes, observera ocksÄ att nÀsta Postgres tisdag Àgde rum förra veckan, dÀr jag pratade med Nikolai Alexander Kukushkin frÄn Zalando. Video frÄn den finns tillgÀnglig .
PPS
LÀs Àven pÄ vÄr blogg:
- «";
- «";
- «";
- «".
KĂ€lla: will.com