I slutet av förra Äret hölls Ànnu ett direktsÀnt evenemang av det ryska PostgreSQL-samhÀllet , dÀr medgrundaren Nikolaj Samokhvalov pratade med teknikchefen för "Flanta", Dmitrij Stoljarev, om denna DBMS i kontexten av Kubernetes.
Vi publicerar en transkription av den huvudsakliga delen av denna diskussion, och pÄ har den fullstÀndiga videoinspelningen publicerats:
Databaser och Kubernetes
NS: Vi kommer inte att prata om VACUUM och CHECKPOINTs idag. Vi vill prata om Kubernetes. Jag vet att du har mÄnga Ärs erfarenhet. Jag har sett dina videor och till och med gÄtt tillbaka till vissa delar... LÄt oss gÄ rakt pÄ sak: varför ska man ens anvÀnda Postgres eller MySQL i K8s?
DS: Det finns inget entydigt svar pÄ den frÄgan. Men överlag handlar det om enkelhet och bekvÀmlighet... potentiellt. Alla vill ju ha managed-tjÀnster.
NS: SÄ att man kan , men bara för sig sjÀlv?
DS: Ja, sÄ som RDS, bara var som helst.
NS: "Var som helst" â det Ă€r en bra poĂ€ng. I stora företag finns allt spritt pĂ„ olika platser. Men varför skulle man, om det Ă€r ett stort företag, inte vĂ€lja en fĂ€rdig lösning? Till exempel har Nutanix sina egna utvecklingar, andra företag (VMware...) har likadana "RDS, bara för sig sjĂ€lv".
DS: Men det hÀr pratar vi om en specifik implementation som kommer att fungera endast under vissa förutsÀttningar. Om vi pratar om Kubernetes sÄ finns det en enorm variation i infrastrukturen (som kan finnas i K8s). I grund och botten Àr det en standard för API till molnet...
NS: Och dessutom gratis!
DS: Det Àr inte sÄ viktigt. Att det Àr gratis Àr inte sÄ viktigt för en stor del av marknaden. Det viktiga Àr nÄgot annat... Du kanske minns min presentation "»?
NS: Ja.
DS: Jag förstod att den uppfattades vĂ€ldigt blandat. Vissa mĂ€nniskor trodde att jag sa: "Hörni, lĂ„t oss köra alla databaser i Kubernetes!", medan andra tyckte att det var alla möjliga cyklar. Men jag ville egentligen sĂ€ga nĂ„got annat: "Se, vad som hĂ€nder, vilka problem som finns och hur man kan lösa dem. Ska man verkligen köra databaser i Kubernetes? I produktion? NĂ„vĂ€l, bara om man Ă€lskar... att syssla med vissa saker. Men för utveckling â kan jag sĂ€ga att jag rekommenderar det. För utveckling Ă€r det vĂ€ldigt viktigt med dynamik i skapandet/ raderingen av miljöer."
NS: Med utveckling menar du alla miljöer som inte Àr produktion? Staging, QA...
DS: NÀr det gÀller perf-stÀnder, sÄ tror jag att det nog inte finns lÀngre, eftersom kraven dÀr Àr specifika. Om vi pratar om sÀrskilda fall dÀr en mycket stor databas behövs pÄ staging, sÄ Àr svaret nog ocksÄ nej... Om det Àr en statisk miljö, som Àr lÄnglivad, vad Àr dÄ vinsten med att databasen ligger i K8s?
NS: Ingen. Men var ser vi statiska miljöer? En statisk miljö Àr redan gammal imorgon.
DS: Staging kan vara statisk. Vi har kunder...
NS: Ja, jag har ocksÄ nÄgra. Det Àr ett stort problem om du har en databas pÄ 10 TB, men staging Àr 200 GB...
DS: Jag har en riktigt cool casus! PĂ„ staging finns produktionsdatabasen, dĂ€r Ă€ndringar görs. Och det finns en knapp: "rulla ut till produktion". Dessa Ă€ndringar â delta â lĂ€ggs till (det verkar som om de helt enkelt synkroniseras via API) i produktionen. Det Ă€r en mycket exotisk variant.
NS: Jag har sett startups i dalen som fortfarande sitter i RDS eller till och med i Heroku â det Ă€r historier frĂ„n 2-3 Ă„r sedan â och de laddar ner dumpen till sin laptop. Eftersom databasen bara Ă€r 80 GB just nu och det finns utrymme pĂ„ laptopen. Sedan köper de till diskar till var och en sĂ„ att de kan ha 3 databaser för att arbeta med olika utvecklingar. SĂ„nt förekommer ocksĂ„. Jag har ocksĂ„ sett att de inte Ă€r rĂ€dda för att kopiera prod till staging â det beror vĂ€ldigt mycket pĂ„ företaget. Men jag har ocksĂ„ sett att mĂ„nga Ă€r vĂ€ldigt rĂ€dda, och att det ofta saknas tid och resurser. Men innan vi gĂ„r in pĂ„ det Ă€mnet, vill jag gĂ€rna höra om Kubernetes. FörstĂ„r jag rĂ€tt att ingen har det i produktion Ă€n?
DS: Vi har smĂ„ databaser i produktion. Det handlar om volymer pĂ„ tiotals gigabyte och icke-kritiska tjĂ€nster, för vilka det kĂ€ndes för jobbigt att göra repliker (och det finns ingen sĂ„dan efterfrĂ„gan). Och under förutsĂ€ttning att det finns en bra lagring under Kubernetes. Den hĂ€r databasen fungerade i en virtuell maskin â villket i VMware, ovanpĂ„ lagringsenheten. Vi lade den i och nu kan vi flytta den mellan maskiner.
NS: Databaser av denna storlek, upp till 100 GB, pÄ bra diskar och med bra nÀtverk kan distribueras pÄ nÄgra minuter, eller hur? En hastighet pÄ 1 GB i sekunden Àr redan ingen exotik.
DS: Ja, för linjÀra operationer Àr det inget problem.
NS: Okej, vi mĂ„ste bara tĂ€nka pĂ„ prod. Men om vi övervĂ€ger Kubernetes för icke-prod-miljöer â hur gör vi dĂ„? Jag ser att Zalando , i Crunchy , finns det nĂ„gra andra alternativ. Och det finns â vĂ„r goda vĂ€n Alvaro frĂ„n Spanien: de gör i princip inte bara , utan en hel distribution (), i vilket de förutom sjĂ€lva Postgres ocksĂ„ beslutat att inkludera backup, proxy EnvoyâŠ
DS: Varför Envoy? För att balansera just Postgres-trafik?
NS: Ja. SÄ de ser detta som: om vi tar en Linux-distribution och kÀrnan, sÄ Àr vanlig PostgreSQL kÀrnan, och de vill skapa en distribution som Àr vÀnlig mot molnet och kan köras i Kubernetes. De kopplar ihop komponenter (backuper osv.) och justerar dem sÄ att de fungerar bra.
DS: VÀldigt coolt! Det Àr i grunden mjukvara för att skapa sin egen hanterade Postgres.
NS: Linux-distributioner har stĂ€ndiga problem: hur man gör drivrutiner sĂ„ att all hĂ„rdvara stöds. Deras idĂ© Ă€r att de ska fungera i Kubernetes. Jag vet att vi nyligen sĂ„g en koppling till AWS i Zalando-operatören och det Ă€r inte sĂ„dĂ€r jĂ€ttebra. Det borde ju inte vara en koppling till en specifik infrastruktur â vad skulle dĂ„ syftet vara?
DS: Jag vet inte i vilken situation Zalando kopplade, men i Kubernetes Ă€r lagringssystemet just nu gjort sĂ„ att man inte kan ta en diskbackup pĂ„ ett generiskt sĂ€tt. Nyligen i standarden â i den senaste versionen â sĂ„ âgjordeâ de möjligheten till snapshots, men var har den implementerats? Ărligt talat, det Ă€r fortfarande sĂ„ rĂ„tt⊠Vi försöker CSI ovanpĂ„ AWS, GCE, Azure, vSphere, men sĂ„ fort man börjar anvĂ€nda det ser man att det Ă€nnu inte Ă€r klart.
NS: DĂ€rför tvingas man ibland koppla pĂ„ infrastruktur. Jag tror det fortfarande Ă€r i ett tidigt stadium â tillvĂ€xtproblem. FrĂ„gan Ă€r: vad skulle du rekommendera nybörjare som vill prova PgSQL i K8s? Vilken operatör, kanske?
DS: Problemet Ă€r att Postgres för oss Ă€r 3%. Vi har ocksĂ„ en mycket stor lista med olika mjukvaror i Kubernetes, jag kommer inte ens att rĂ€kna upp dem alla. Till exempel Elasticsearch. Det finns massor av operatörer: vissa utvecklas aktivt, andra gör det inte. Vi har satt upp krav pĂ„ vad som mĂ„ste finnas i en operatör för att vi ska ta den pĂ„ allvar. I operatören specifikt för Kubernetes â inte i âoperatören för att göra nĂ„got i Amazons miljöâ⊠Faktiskt anvĂ€nder vi ganska massivt (= nĂ€stan alla kunder) den enda operatören â (snart publicerar vi en artikel om den ocksĂ„).
NS: Men för MySQL finns det ingen heller? Jag vet att Percona⊠eftersom de nu sysslar med bÄde MySQL, MongoDB och Postgres, de borde skapa nÄgon form av universell lösning: för alla databaser, för alla molnleverantörer.
DS: Vi har inte haft tid att titta pÄ operatörer för MySQL. För oss Àr det inte det viktigaste just nu. MySQL fungerar bra som fristÄende. Varför en operatör, nÀr du bara kan köra databasen... Du kan köra en Docker-container med PostgreSQL, eller sÄ kan du bara köra den enkelt.
NS: Det var ocksÄ en frÄga. Helt utan operatör?
DS: Ja, vi har 100% PostgreSQL som körs utan operatör. SĂ„ Ă€r det Ă€n sĂ„ lĂ€nge. Vi anvĂ€nder aktivt operatören för Prometheus och Redis. Vi planerar att hitta en operatör för Elasticsearch â det Ă€r det som âbrinner mestâ, eftersom vi vill kunna installera det i Kubernetes i 100% av fallen. Liksom vi vill att MongoDB alltid ska installeras i Kubernetes. Det finns vissa önskemĂ„l â det kĂ€nns som om man kan göra nĂ„got i dessa fall. Men vi har inte ens tittat pĂ„ Postgres. SjĂ€lvklart vet vi om olika alternativ, men i praktiken har vi fristĂ„ende.
Databas för testning i Kubernetes
NS: LĂ„t oss gĂ„ vidare till testning. Hur rullar man ut förĂ€ndringar i databasen â sett frĂ„n en DevOps-perspektiv. Det finns mikrotjĂ€nster, mĂ„nga databaser, hela tiden förĂ€ndras nĂ„got nĂ„gonstans. Hur sĂ€kerstĂ€ller man en bra CI/CD sĂ„ att allt Ă€r i ordning ur databassynpunkt? Vad Ă€r din metod?
DS: Det kan inte finnas ett enda svar. Det finns flera faktorer. Den första Àr storleken pÄ databasen som vi vill rulla ut. Du nÀmnde att företag har olika instÀllningar till att kopian av produktionsdatabasen ska finnas pÄ dev och staging.
NS: Och under GDPR, tror jag att de hanterar det mer och mer varsamt... Jag kan sÀga att i Europa har man redan börjat bötfÀlla.
DS: Men ofta kan man skriva mjukvara som gör en dump frÄn produktionen och obfuskerar den. DÄ fÄr man produktionsdata (snapshot, dump, binÀr kopia...), men de Àr anonymiserade. IstÀllet kan det finnas skript för att generera data: det kan vara fixtures eller helt enkelt ett skript som genererar en stor databas. Problemet Àr: hur lÄng tid tar det att skapa den grundlÀggande bilden? Och hur lÄng tid tar det att deploya den i rÀtt miljö?
Vi har kommit fram till en modell: om kunden har ett fixtures dataset (minimal version av databasen), sĂ„ anvĂ€nder vi dem som standard. För review-miljöer, nĂ€r vi har skapat en branch, sĂ„ har vi en instans av applikationen som rullas ut â vi lĂ€gger in en liten databas dĂ€r. Men det blev bra och , nĂ€r vi varje natt tar en dump frĂ„n produktion och bygger en Docker-container med PostgreSQL och MySQL baserat pĂ„ dessa inladdade data. Om vi behöver Ă„terstĂ€lla databasen 50 gĂ„nger frĂ„n denna bild, görs det ganska enkelt och snabbt.
NS: Enkelt genom att kopiera?
DS: Data lagras direkt i Docker-bilden. Det vill sÀga, vi har en fÀrdig bild, lÄt oss sÀga pÄ 100 GB. Tack vare lagren i Docker kan vi snabbt bygga upp denna bild det antal gÄnger vi behöver. Metoden Àr enkel, men fungerar ganska bra.
NS: SĂ„ nĂ€r du testar, Ă€ndras det direkt i Docker, eller hur? Copy-on-write inom Docker â vi kastar bort och börjar om, allt fungerar bra. Coolt! AnvĂ€nder ni det redan?
DS: LĂ€ngesedan.
NS: Vi arbetar ocksÄ med ganska liknande saker. Men vi anvÀnder inte Dockers copy-on-write, utan nÄgot annat.
DS: Den Àr inte generell. Men Docker-versionen fungerar överallt.
NS: IdĂ©en Ă€r ja. Men vi har ocksĂ„ moduler, kan skapa olika moduler och arbeta med olika filsystem. HĂ€r Ă€r en punkt att beakta. Vi ser allt detta pĂ„ ett annat sĂ€tt ur Postgres-perspektivet. Nu har jag tittat ur Dockers perspektiv och sett att allt fungerar. Men om databasen Ă€r enorm, till exempel 1 TB, blir det lĂ„ngsamt: bĂ„de operationerna pĂ„ natten och att fĂ„ in allt i Docker... Och om man ska fĂ„ in 5 TB i Docker... Ăr det okej?
DS: Vad spelar det för roll: det Àr ju blobbar, bara bitar och byte.
NS: Skillnaden Àr: gör ni det genom dump och ÄterstÀllning?
DS: Inte nödvÀndigtvis. Metoderna för att generera denna bild kan variera.
NS: För vissa kunder har vi gjort sĂ„ att istĂ€llet för att regelbundet generera grundbilden, sĂ„ hĂ„ller vi den stĂ€ndigt uppdaterad. Den Ă€r i praktiken en replik, men datan fĂ„r vi inte direkt frĂ„n master utan via arkivet. En binĂ€r arkiv, dĂ€r WAL:s lĂ€ggs pĂ„ varje dag, och dĂ€r backuper tas⊠Dessa WAL:s nĂ„r sedan grundbilden â med en liten fördröjning (bokstavligen 1-2 sekunder) â och frĂ„n den klonar vi pĂ„ vilket sĂ€tt vi vill â för nĂ€rvarande anvĂ€nder vi ZFS som standard.
DS: Men med ZFS Àr ni begrÀnsade till en nod.
NS: Ja. Men med ZFS finns det ocksÄ en magisk : med den kan man skicka en snapshot och till och med (jag har inte testat detta sÄ mycket Àn, men...) kan man skicka en delta mellan tvÄ PGDATA. Faktum Àr att vi har ett annat verktyg som vi inte har övervÀgt sÄ mycket för sÄdana uppgifter. I PostgreSQL finns det , som fungerar som en "smart" rsync och hoppar över mycket som man kan skippa, eftersom det inte har Àndrats överhuvudtaget. Vi kan snabbt synkronisera mellan tvÄ servrar och backa tillbaka pÄ exakt samma sÀtt.
SÄ vi försöker frÄn den mer DBA-aktiga sidan att skapa ett verktyg som möjliggör samma sak som du nÀmnde: vi har en databas, men vi vill testa nÄgot 50 gÄnger, nÀstan samtidigt.
DS: 50 gÄnger betyder att ni behöver bestÀlla 50 Spot-instanser.
NS: Nej, allt görs pÄ en maskin.
DS: Men hur ska ni rulla ut 50 gÄnger om just den databasen, sÀg, Àr terabyte-stor? Den behöver nog typ 256 GB RAM?
NS: Ja, ibland behövs mycket minne â det Ă€r normalt. Men hĂ€r Ă€r ett exempel frĂ„n verkligheten. PĂ„ produktionsmaskinen har vi 96 kĂ€rnor och 600 GB. För databasen anvĂ€nds 32 kĂ€rnor (Ă€ven 16 kĂ€rnor ibland nu) och 100-120 GB minne.
DS: Och ryms 50 kopior dÀr?
NS: Men kopian Àr faktiskt en, vidare fungerar copy-on-write (ZFS-aktigt)⊠Jag berÀttar mer om det.
Vi har till exempel en databas pĂ„ 10 TB. Vi gjorde disken för den, och ZFS komprimerade storleken med cirka 30-40%. Eftersom vi inte gör belastningstest Ă€r vi inte intresserade av exakt svarstid: det kan vara upp till 2 gĂ„nger lĂ„ngsammare â det Ă€r okej.
Vi ger programmerare, QA, DBA, etc. möjlighet att testa i 1-2 trĂ„dar. Till exempel kan de starta nĂ„gon migration. Den krĂ€ver inte direkt 10 kĂ€rnor â den behöver 1 backend Postgres, 1 kĂ€rna. Migrationen startar â kanske en annan startar, dĂ„ anvĂ€nds den andra kĂ€rnan. Vi har tilldelat 16-32 kĂ€rnor, sĂ„ 10 personer kan arbeta samtidigt, inga problem.
Eftersom fysiskt PGDATA likadant, sÄ lurar vi egentligen Postgres. Grejen Àr: vi kör till exempel 10 Postgres-instansar samtidigt. Vad brukar vara problemet? Man sÀtter , lÄt oss sÀga, vid 25%. SÄ det blir 200 GB. Mer Àn tre sÄdana kan man inte starta, för dÄ tar minnet slut.
Men vi insÄg pÄ nÄgot sÀtt att det inte behövdes: vi sÀtter shared_buffers till 2 GB. PostgreSQL har , och egentligen pÄverkar bara det . Vi sÀtter det till 0,5 TB. Och det spelar ingen roll att de faktiskt inte finns: den bygger planer som om de fanns.
NĂ€r vi testar en migration kan vi samla alla planer â vi kommer att se hur det kommer att ske i produktion. DĂ€r kommer sekunderna att vara annorlunda (lĂ„ngsammare), men de data vi faktiskt lĂ€ser och sjĂ€lva planerna (till exempel vilken JOIN som anvĂ€nds, etc.) Ă€r exakt samma som i produktion. Dessutom kan vi parallellt köra mĂ„nga sĂ„dana kontroller pĂ„ en och samma maskin.
DS: Tycker du inte att det hĂ€r finns nĂ„gra problem? Det första â det hĂ€r Ă€r en lösning som bara fungerar pĂ„ PostgreSQL. Denna metod Ă€r mycket specifik, den Ă€r inte generell. Den andra â Kubernetes (och allt som gĂ„r mot molnteknologier nu) förutsĂ€tter mĂ„nga noder, och dessa noder Ă€r flyktiga. I ditt fall Ă€r det en stateful, persistent nod. Dessa saker vĂ€cker motsĂ€gelser för mig.
NS: För det första â jag hĂ„ller med, detta Ă€r en ren Postgres-historia. Jag tror att om vi har nĂ„gon form av direkt IO och en buffertpool som nĂ€stan tar upp hela minnet, sĂ„ kommer denna metod inte att passa â planerna kommer att se annorlunda ut. Men vi arbetar just nu bara med Postgres och tĂ€nker inte pĂ„ andra.
Om Kubernetes. Du sÀger ju sjÀlv överallt att vÄr databas Àr persistent. Om instansen kraschar, Àr det viktigaste att spara disken. VÄr plattform Àr ocksÄ helt i Kubernetes, och komponenten med Postgres Àr separat (Àven om den en dag kommer att vara dÀr). SÄ hÀr Àr det: instansen kraschar, men vi har sparat dess PV och helt enkelt kopplat den till en annan (ny) instans, som om ingenting har hÀnt.
DS: Ur min synvinkel skapar vi pods i Kubernetes. K8s Àr elastisk: noder bestÀlls sjÀlva vid behov. Uppgiften Àr bara att skapa en pod och ange hur mÄnga resurser den behöver, och sedan kommer K8s att hantera resten. Men stödet för lagring i Kubernetes Àr fortfarande instabilt: i , i (den hÀr versionen slÀpptes veckor sedan) blir dessa funktioner bara en beta.
Om ett halvÄr till ett Är kommer det att bli mer eller mindre stabilt, eller i alla fall sÄ kommer det att deklareras som sÄdant. DÄ löser möjligheten till snapshots och resize ditt problem helt. För ni har en databas. Ja, den kanske inte Àr super snabb, men hastigheten beror pÄ vad som Àr "under huven", eftersom vissa implementeringar kan hantera kopiering och copy-on-write pÄ disknivÄ.
NS: HĂ€r mĂ„ste vi ocksĂ„ se till att alla motorer (Amazon, GoogleâŠ) har börjat stödja denna version â det tar ju ocksĂ„ tid.
DS: För tillfÀllet anvÀnder vi dem inte. Vi anvÀnder vÄr egen.
Lokal utveckling för Kubernetes
NS: Har du nÄgonsin stött pÄ en sÄdan önskan, att behöva köra alla poddar pÄ en maskin och göra en liten testning. För att snabbt fÄ ett proof of concept och se att applikationen fungerar i Kubernetes, utan att behöva reservera en massa maskiner för det. Finns Minikube, eller hur?
DS: Jag tycker att det hĂ€r fallet â att rulla ut pĂ„ en nod â handlar uteslutande om lokal utveckling. Eller kanske nĂ„gra manifestationer av det mönstret. Det finns , det finns , . Vi gĂ„r mot att anvĂ€nda Kubernetes IN Docker. Vi har just börjat arbeta med det för tester.
NS: Jag trodde tidigare att detta var ett försök att packa alla poddar i en Docker-bild. Men det visade sig handla om nĂ„got helt annat. Det finns fortfarande separata containrar, separata poddar â bara i Docker.
DS: Ja. Det finns en ganska rolig imitation dĂ€r, men poĂ€ngen Ă€r att⊠Vi har ett verktyg för distribution â . Vi vill göra ett lĂ€ge i det â hypotetiskt werf up: «Starta min lokala Kubernetes». Och sen starta en hypotetisk werf follow. DĂ„ kan utvecklaren redigera i IDE, medan det i systemet körs en process som ser Ă€ndringar och bygger om bilder, distribuerar dem till lokal K8s. SĂ„ vill vi försöka lösa problemet med lokal utveckling.
Snapshots och kloning av databaser i K8s-realiteten
NS: Om vi Ă„tergĂ„r till copy-on-write. Jag har noterat att molnen ocksĂ„ har snapshots. De fungerar pĂ„ olika sĂ€tt. Till exempel, i GCP: om du har en multiterabyte-instans pĂ„ östkusten i USA. Du tar periodiskt snapshots. Du startar en kopia av disken frĂ„n snapshotet pĂ„ vĂ€stkusten â efter nĂ„gra minuter Ă€r allt klart, det gĂ„r mycket snabbt, du mĂ„ste bara fylla cachen i minnet. Men dessa kloner (snapshots) â Ă€r för att 'provision' en ny volym. Det Ă€r fantastiskt nĂ€r man behöver skapa mĂ„nga instanser.
Men för tester, tycker jag att snapshots, som du pratar om i Docker eller jag pratar om i ZFS, btrfs och till och med LVM⊠â de gör det möjligt att inte faktiskt skapa nya data pĂ„ en och samma maskin. I molnet kommer du ocksĂ„ att betala för dem varje gĂ„ng och vĂ€nta inte sekunder utan minuter (och i fallet med , möjligtvis i timmar).
IstĂ€llet kan du fĂ„ dessa data pĂ„ en eller tvĂ„ sekunder, köra ditt test och kasta bort det. Dessa snapshots löser olika uppgifter. I det första fallet â för att kunna skala upp och fĂ„ nya repliker, och i det andra â för tester.
DS: Jag hÄller inte med. Att göra en korrekt kloning av volymer Àr en uppgift för molnet. Jag har inte sett deras implementation, men jag vet hur vi gör det pÄ hÄrdvara. Vi har Ceph, och i det kan man sÀga till vilken fysisk volym som helst () och fÄ en andra volym med samma egenskaper pÄ bara nÄgra tiotals millisekunder, clone IOPS : Men de kommer ÀndÄ att ta sekunder, tiotals sekunder, för att starta en instans, installera Docker, osv.
NS: Varför mĂ„ste man nödvĂ€ndigtvis starta en hel instans? Vi har en instans med 32 kĂ€rnor, med 16... och den rymmer ett visst antal â till exempel fyra. NĂ€r vi bestĂ€ller den femte kommer en instans att starta, och sen kommer den att tas bort.
DS: Ja, intressant, i Kubernetes Àr det en annan historia. Vi har inte databasen i K8s, utan en enda instans. Men att klona en flerterrabytes databas tar inte mer Àn tvÄ sekunder.
NS: Det Àr fantastiskt. Men min ursprungliga poÀng Àr att detta inte Àr en generisk lösning. Ja, det Àr bra, men det passar bara Postgres och bara pÄ en nod.
DS: Det passar inte bara för Postgres: det hÀr Àr planer, som jag beskrev, kommer bara att fungera sÄ i den. Men om man inte bryr sig om planerna, utan bara behöver all data för funktionell testning, dÄ fungerar det med vilken databas som helst.
NS: För mÄnga Är sedan gjorde vi nÄgot liknande med LVM-snapshots. Det Àr klassiskt. Denna metod anvÀndes mycket aktivt. Men stateful-noder Àr en utmaning. För de mÄste man alltid ha koll pÄ och inte lÄta dem falla.
DS: Ser du inte hĂ€r nĂ„gon möjlighet för ett hybrid? LĂ„t oss sĂ€ga, stateful â det Ă€r en pod av nĂ„got slag, den arbetar med flera personer (mĂ„nga testare). Vi har en volym, men tack vare filsystemet Ă€r klonerna lokala. Om podden kraschar, sĂ„ finns disken kvar â podden kommer att starta igen, lĂ€sa informationen om alla kloner, Ă„terstĂ€lla allt och sĂ€ga: 'HĂ€r Ă€r era kloner startade pĂ„ dessa portar, jobba vidare med dem.'
NS: Teknisk sett innebÀr det att det inom Kubernetes Àr en pod dÀr vi kör flera Postgres.
DS: Ja. Den har en grĂ€ns: lĂ„t oss sĂ€ga att samtidigt arbetar högst 10 personer med den. Om 20 behövs â vi startar en andra sĂ„dan pod. Det Ă€r helt möjligt att klona den, fĂ„ en andra full volym, dĂ€r det kommer att finnas 10 'tunna' kloner. Ser du inte det som en möjlighet?
NS: Ja.
DS: Vi behöver lĂ€gga till sĂ€kerhetsfrĂ„gor hĂ€r. Denna typ av organisation innebĂ€r att denna pod har hög privilegier (capabilities), eftersom den kan utföra icke-standard Ă„tgĂ€rder pĂ„ filsystemet⊠Men jag upprepar: jag anser att lagring kommer att fixas i Kubernetes pĂ„ medellĂ„ng sikt, i molnen kommer hela historien med volymer att fixas â allt kommer att "bara fungera". Det kommer att finnas resize, kloning⊠Det finns en volym â vi sĂ€ger: "Skapa en ny baserad pĂ„ den", och inom en och en halv sekund fĂ„r vi det vi behöver.
NS: Jag tror inte pÄ en och en halv sekund för mÄnga terabyte. I Ceph gör du det sjÀlv, men du pratar om moln. GÄ till molnet, gör en kloning av en EBS-volym pÄ mÄnga terabyte pÄ EC2 och se vilken prestanda du fÄr. Det kommer inte att ta nÄgra sekunder. Jag Àr mycket intresserad av nÀr de nÄr den nivÄn. Jag förstÄr vad du pratar om, men jag tillÄter mig att inte hÄlla med.
DS: Okej, men jag sa att det handlar om medellÄng sikt, inte kortsiktig. Inom nÄgra Är.
Om PostgreSQL-operatören frÄn Zalando
Vid mitten av detta möte anslöt sig ocksÄ Alexey Klyukin, en tidigare utvecklare frÄn Zalando, som berÀttade om historien om PostgreSQL-operatören:
Det Àr bra att detta Àmne överhuvudtaget togs upp: bÄde Postgres och Kubernetes. NÀr vi började arbeta med det i Zalando 2017 var det ett Àmne som alla ville syssla med, men ingen gjorde det. Alla hade redan börjat anvÀnda Kubernetes, men nÀr man frÄgade hur man skulle hantera databaser, sÄ sa till och med sÄdana personer som , som predikade K8s, ungefÀr följande:
"GÄ till managed-tjÀnster och anvÀnd dem, kör inte databaser i Kubernetes. Annars kommer din K8s att till exempel besluta att göra en uppgradering, stÀnga av alla noder, och dina data kommer att Äka lÄngt bort."
Vi beslutade oss för att göra en operatör som, trots detta rĂ„d, skulle köra Postgres-databaser i Kubernetes. Och vi hade en god grund â . Det Ă€r en automatisk failover för PostgreSQL, korrekt utförd, det vill sĂ€ga den anvĂ€nder etcd, consul eller ZooKeeper som informationslagring om klustret. En sĂ„dan lagring som kommer att ge alla som frĂ„gar samma information, till exempel vem som Ă€r ledare just nu â trots att allt Ă€r distribuerat â sĂ„ att det inte uppstĂ„r ett split brain. Dessutom hade vi för den.
Generellt sett uppstod behovet av auto failover hos företaget efter migreringen frÄn en intern datacenterlösning till molnet. Molnet byggdes pÄ en egen PaaS-lösning (Platform-as-a-Service). Den Àr Open Source, men för att fÄ igÄng den krÀvdes det mycket arbete. Den kallades .
I början fanns det ingen Kubernetes. Egentligen, nĂ€r den egna lösningen rullades ut, fanns K8s redan, men den var sĂ„ pass rudimentĂ€r att den inte var produktionsduglig. Det var, om jag minns rĂ€tt, 2015 eller 2016. Till 2017 hade Kubernetes blivit mer eller mindre moget â det blev nödvĂ€ndigt 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 vĂ„r egen operator? Murat Kabilov, som kom till oss frĂ„n Avito, startade detta som ett initiativ â för att "leka", â och projektet "flög".
Men jag ville egentligen berÀtta om AWS. Varför det historiskt sett fanns kod kopplad till AWS...
NÀr du startar nÄgot i Kubernetes mÄste du förstÄ att K8s Àr ett sÄdant work in progress. Det utvecklas stÀndigt, förbÀttras och ibland gÄr det till och med sönder. Du mÄste noggrant följa alla Àndringar i Kubernetes, vara beredd pÄ att dyka ner i det och förstÄ hur det fungerar i detalj - kanske mer Àn du skulle vilja. Detta gÀller i princip för vilken plattform som helst dÀr du kör dina databaser...
SÄ nÀr vi skapade operatorn hade vi en Postgres som arbetade med ett externt volume (i det hÀr fallet - EBS, eftersom vi arbetade i AWS). Databasen vÀxte, och vid nÄgot tillfÀlle behövde vi göra en resize: exempelvis, den ursprungliga storleken pÄ EBS var 100 TB, databasen hade vÀxt till den storleken, nu ville vi göra EBS till 200 TB. Hur? Naturligtvis kan man göra dump/restore till en ny instans, men det Àr tidskrÀvande och innebÀr driftstopp.
DÀrför ville vi ha en resize som skulle öka partitionen pÄ EBS och sedan sÀga till filsystemet att börja anvÀnda det nya utrymmet. Och vi gjorde det, men vid den tiden fanns det inget API för resizet i Kubernetes. Eftersom vi arbetade pÄ AWS skrev vi kod för dess API.
Ingen hindrar en frĂ„n att göra samma sak för andra plattformar. I operatorn finns det ingen koppling som sĂ€ger att den bara kan köras pĂ„ AWS, och att den inte kommer att fungera pĂ„ nĂ„got annat. SĂ„, det Ă€r ett Open Source-projekt: om nĂ„gon vill pĂ„skynda anvĂ€ndningen av det nya API:et â varsĂ„god. Det finns , pull-förfrĂ„gningar â Zalando-teamet försöker reagera ganska snabbt pĂ„ dem och frĂ€mja operatören. SĂ„vitt jag vet, projektet i Google Summer of Code och nĂ„gra andra liknande initiativ. Zalando arbetar mycket aktivt med det.
P.S. Bonus!
Om du Àr intresserad av Àmnet PostgreSQL och Kubernetes, sÄ vill vi ocksÄ uppmÀrksamma att förra veckan hölls nÀsta Postgres-tisdag, dÀr Nikolaj hade ett samtal med Alexander Kukushkin frÄn Zalando. Inspelningen finns tillgÀnglig .
P.P.S.
LÀs Àven i vÄr blogg:
- «»;
- «»;
- «»;
- «».
KĂ€lla: habr.com
