I slutningen af det forgangne Är fandt endnu et direkte livestream af det russiske PostgreSQL-fÊllesskab sted , hvor dens medstifter Nikolaj Samokhvalov talte med den tekniske direktÞr for «Flant», Dmitrij Stolyarov, om denne database i konteksten af Kubernetes.
Vi offentliggÞr nu transkriptet af hoveddelen af denne diskussion, og pÄ er den fulde video optagelse offentliggjort:
Databaser og Kubernetes
NS: Vi skal ikke tale om VACUUM og CHECKPOINTS i dag. Vi vil tale om Kubernetes. Jeg ved, at du har mange Ärs erfaring. Jeg har set dine videoer og endda genset nogle sektioner⊠Lad os gÄ direkte til sagen: hvorfor overhovedet Postgres eller MySQL i K8s?
DS: Der er ikke et entydigt svar pÄ dette spÞrgsmÄl. Men generelt, det er enkelheden og bekvemmeligheden⊠potentielt. Alle Þnsker jo managed-tjenester.
NS: Ligesom , bare hos en selv?
DS: Ja: ligesom RDS, bare hvor som helst.
NS: «Hvor som helst» â det er et godt punkt. I store virksomheder er alt placeret forskellige steder. Hvorfor sĂ„ ikke tage en fĂŠrdig lĂžsning, hvis det er en stor virksomhed? For eksempel har Nutanix sine egne udviklinger, og andre virksomheder (VMwareâŠ) har den samme «RDS, bare hos sig selv».
DS: Men det taler vi om en specifik implementering, der kun vil fungere under bestemte forhold. Hvis det handler om Kubernetes, sĂ„ er der enorme variationer af infrastruktur (som kan vĂŠre i K8s). I bund og grund er det en standard for API til skyenâŠ
NS: Og sÄ er det endda gratis!
DS: Det er ikke sÄ vigtigt. Gratis er ikke sÄ vigtigt for et stort segment af markedet. Det vigtigste er noget andet⊠Du husker mÄske mit foredrag «»?
NS: Ja.
DS: Jeg forstod, at det blev modtaget meget blandet. Nogle mennesker troede, at jeg sagde: «Lad os alle sammen tage databasene til Kubernetes!», mens andre mente, at det hele var absurde cykler. Men jeg ville egentlig sige noget helt andet: «Se, hvad der sker, hvilke problemer der er, og hvordan de kan lÞses. Skal man kÞre databaser i Kubernetes? Produktion? Kun hvis du elsker⊠at beskÊftige dig med bestemte ting. Men til dev? Jeg kan sige, at jeg anbefaler det. Til dev er det meget vigtigt at kunne oprette/slette miljÞer dynamisk».
NS: Med dev mener du alle miljĂžer, der ikke er prod? Staging, QAâŠ
DS: Hvis vi taler om perf-stande, sÄ er det nok ikke muligt, fordi kravene her er specifikke. Hvis vi taler om sÊrlige tilfÊlde, hvor der er brug for en meget stor database pÄ staging, sÄ er det ogsÄ nok ikke muligt... Hvis det er et statisk miljÞ, der lever lÊnge, hvad er sÄ fordelen ved, at databasen er placeret i K8s?
NS: Ingen. Men hvor ser vi statiske miljĂžer? Det statiske miljĂž er allerede forĂŠldet i morgen.
DS: Staging kan vĂŠre statisk. Vi har klienter...
NS: Ja, jeg har ogsÄ nogle. Det er et stort problem, hvis du har en database pÄ 10 TB, og staging kun er 200 GB...
DS: Jeg har en rigtig fed case! PĂ„ staging ligger produktionsdatabasen, hvor der laves ĂŠndringer. Og der er en knap: "Udrul i produktion". Disse ĂŠndringer - delterne - overfĂžres (synkroniseres, ser det ud til, bare via API) til produktion. Det er en meget eksotisk variant.
NS: Jeg har set startups i Silicon Valley, der stadig sidder i RDS eller endda i Heroku â det er historier fra 2-3 Ă„r tilbage â og de downloader dumpen til deres laptop. Fordi databasen kun er 80 GB, og der er plads pĂ„ laptoppens harddisk. SĂ„ kĂžber de flere diske til alle, sĂ„ de kan have 3 databaser til forskellige udviklinger. Det sker ogsĂ„. Jeg har ogsĂ„ set, at de ikke er bange for at kopiere produktionen til staging â det afhĂŠnger meget af virksomheden. Men jeg har ogsĂ„ set, at de er meget bange, og at de ofte mangler tid og hĂŠnder. Men fĂžr vi gĂ„r videre til det emne, vil jeg gerne hĂžre om Kubernetes. ForstĂ„r jeg det korrekt, at ingen har det i produktionen endnu?
DS: Vi har nogle smĂ„ databaser i produktionen. Det drejer sig om mĂŠngder pĂ„ titusinder af gigabyte og ukritiske tjenester, for hvilke det var for besvĂŠrligt at lave replikaer (og der var ikke behov for det). Og forudsat at der er et ordentligt lager under Kubernetes. Denne database kĂžrte pĂ„ en virtuel maskine â betingelsesmĂŠssigt i VMware, oven pĂ„ SAN. Vi har placeret den i og nu kan vi flytte den fra maskine til maskine.
NS: Databaser af denne stÞrrelse, op til 100 GB, pÄ gode diske og med et godt netvÊrk kan udrulles pÄ fÄ minutter, er det ikke korrekt? En hastighed pÄ 1 GB i sekundet er ikke lÊngere eksotisk.
DS: Ja, for en lineĂŠr operation er det ikke et problem.
NS: Okay, vi skal kun tÊnke pÄ produktionen. Men hvis vi overvejer Kubernetes til ikke-produktionsmiljÞer - hvordan gÞr man sÄ? Jeg ser, at Zalando , i Crunchy , der er ogsÄ nogle andre muligheder. Og der er - det er vores gode ven Alvaro fra Spanien: de laver ikke bare , men en hel distribution (), som Postgres ikke alene, men ogsÄ backup og proxy Envoy...
DS: Hvad er Envoy til? Til belastningsfordeling af Postgres-trafik?
NS: Ja. AltsÄ, de ser det som: hvis vi tager en Linux-distribution og kernen, sÄ er den almindelige PostgreSQL kernen, og de Þnsker at lave en distribution, der er venlig mod cloud og kan kÞre i Kubernetes. De forbinder komponenter (backup osv.) og justerer dem, sÄ de fungerer godt.
DS: Meget godt! GrundlĂŠggende er det software til at lave sin egen managed Postgres.
NS: Linux-distributioner har evige problemer: hvordan man laver drivere, sĂ„ alt hardware understĂžttes. Og deres idĂ© er, at de vil fungere i Kubernetes. Jeg ved, at vi for nylig sĂ„ en binding til AWS i Zalando-operationssystemet, og det er ikke sĂ„ godt. Der burde ikke vĂŠre binding til en specifik infrastruktur â hvad er meningen sĂ„?
DS: Jeg ved ikke, under hvilke forhold Zalando er bundet, men i Kubernetes er storage nu lavet sĂ„dan, at man ikke kan tage en diskbackup pĂ„ en generisk mĂ„de. For nylig i standarden â i den seneste version â har de gjort det muligt at tage snapshots, men hvor er det implementeret? Ărligt talt, det er stadig sĂ„ ufuldstĂŠndigt... Vi prĂžver CSI ovenpĂ„ AWS, GCE, Azure, vSphere, men sĂ„ snart man begynder at bruge det, kan man se, at det ikke er klar endnu.
NS: Derfor mĂ„ man nogle gange binde sig til infrastrukturen. Jeg tror, det stadig er i en tidlig fase â vĂŠkstproblemer. SpĂžrgsmĂ„l: hvad ville du anbefale nybegyndere, der Ăžnsker at prĂžve PgSQL i K8s? Hvilken operator, mĂ„ske?
DS: Problemet er, at Postgres for os er 3%. Vi har ogsĂ„ en meget lang liste af forskellige software i Kubernetes, jeg gider ikke engang nĂŠvne dem alle. For eksempel Elasticsearch. Der er mange operatĂžrer: nogle udvikler sig aktivt, andre gĂžr det ikke. Vi har lavet krav til, hvad der skal vĂŠre i en operator, for at vi kan tage den alvorligt. I operatoren for Kubernetes â ikke i 'operatoren til at gĂžre noget under Amazon'... Faktisk bruger vi ret massiv (= nĂŠsten alle kunder) den samme operator â (snart udgiver vi en artikel om den).
NS: Men til MySQL er der heller ikke? Jeg ved, at Percona... da de nu beskÊftiger sig med bÄde MySQL, MongoDB og Postgres, mÄ de have en slags universel lÞsning: for alle databaser, for alle cloud-udbydere.
DS: Vi har ikke haft tid til at se pÄ operatÞrer for MySQL. For os er det ikke det primÊre fokus lige nu. MySQL fungerer fint i stand-alone. Hvorfor have en operatÞr, hvis man bare kan kÞre databasen⊠Man kan kÞre en Docker-container med Postgres, eller man kan gÞre det pÄ den enkel mÄde.
NS: Det spÞrgsmÄl kom ogsÄ op. Slet ingen operatÞr?
DS: Ja, vi kĂžrer 100% PostgreSQL uden operatĂžr. Lige nu er det sĂ„dan. Vi bruger aktivt operatĂžren til Prometheus og til Redis. Vi planlĂŠgger at finde en operatĂžr til Elasticsearch â det er det, der 'brĂŠnder' mest, fordi vi vil have det i 100% af tilfĂŠldene i Kubernetes. PĂ„ samme mĂ„de vil vi gerne have MongoDB til altid at blive installeret i Kubernetes. Her opstĂ„r der visse Ăžnsker â der er en fĂžlelse af, at der kan gĂžres noget i disse tilfĂŠlde. Og hvad angĂ„r Postgres, har vi ikke engang kigget pĂ„ det. SelvfĂžlgelig er vi klar over, at der findes forskellige muligheder, men faktum er, at vi har stand-alone.
Database til test i Kubernetes
NS: Lad os gĂ„ videre til emnet testning. Hvordan ruller man ĂŠndringer i databasen ud â fra et DevOps-perspektiv? Der er mikrotjenester, mange databaser, alt ĂŠndrer sig hele tiden. Hvordan sikrer man en ordentlig CI/CD, sĂ„ alt er i orden fra databaseperspektiv? Hvad er din tilgang?
DS: Der kan ikke vÊre ét svar. Der er flere parametre. Det fÞrste er stÞrrelsen pÄ databasen, som vi Þnsker at rulle ud. Du nÊvnte selv, at virksomheder forholder sig forskelligt til, at en kopi af prod-databasen er pÄ dev og stage.
NS: Og under GDPR, tror jeg, de er meget mere forsigtige... Jeg kan sige, at der allerede er begyndt at komme bĂžder i Europa.
DS: Men ofte kan man skrive software, der laver et dump fra produktionen og anonymiserer det. Det bliver produktionens data (snapshot, dump, binĂŠr kopiâŠ), men de er anonymiserede. I stedet kan der ogsĂ„ vĂŠre genereringsscripts: det kan vĂŠre fixtures eller blot et script, der genererer en stor database. Problemet er: hvor lang tid tager det at lave det grundlĂŠggende billede? Og hvor lang tid tager det at implementere det i det rigtige miljĂž?
Vi er kommet frem til en model: hvis kunden har et fixturesĂŠt (minimumsversion af databasen), bruger vi dem som standard. Hvis det handler om review-miljĂžer, nĂ„r vi har oprettet en branch, og vi har fĂ„et udrullet en instans af applikationen â sĂ„ udruller vi en lille database der. , nĂ„r vi dagligt (om natten) tager et dump fra produktionen og samler en Docker-container med PostgreSQL og MySQL med disse indlĂŠste data. Hvis vi skal deploye denne database 50 gange fra dette billede, er det ret enkelt og hurtigt at gĂžre.
NS: Er det bare ved simpel kopiering?
DS: Dataene opbevares direkte i Docker-billedet. Det vil sige, at vi har et fĂŠrdigt billede, lad os sige 100 GB. Takket vĂŠre lagene i Docker kan vi hurtigt deploye dette billede det nĂždvendige antal gange. Metoden er simpel, men fungerer ret godt.
NS: SĂ„ nĂ„r du tester, ĂŠndres det direkte inde i Docker, ikke? Copy-on-write indenfor Docker â vi smider det vĂŠk og starter forfra, alt fungerer godt. Fedt! Bruger I det allerede i stor stil?
DS: LĂŠnge.
NS: Vi arbejder med meget lignende ting. Bare vi bruger ikke Dockerâs copy-on-write, men et eller andet andet.
DS: Det er ikke generisk. Docker's fungerer overalt.
NS: I teorien, ja. Men vi har ogsĂ„ moduler, man kan lave forskellige moduler og arbejde med forskellige filsystemer. Her er det hele, at vi ser pĂ„ det pĂ„ en anden mĂ„de fra PostgreSQL's side. Nu har jeg set det fra Dockerâs side og set, at det fungerer for jer. Men hvis databasen er kĂŠmpestor, for eksempel 1 TB, sĂ„ tager det lĂŠngere tid: bĂ„de operationer om natten, og at putte alt i Docker⊠Eller gĂ„r det fint med at putte 5 TB i Docker?
DS: Hvad betyder det: det er jo blobs, bare bits og bytes.
NS: Forskellen er: gĂžr I det via dump og restore?
DS: Det er slet ikke nĂždvendigt. Metoderne til at generere dette billede kan vĂŠre forskellige.
NS: For nogle kunder har vi gjort det, sĂ„ i stedet for at generere et grundlĂŠggende billede regelmĂŠssigt, holder vi det konstant opdateret. Det er i bund og grund en replika, men dataene fĂ„r ikke direkte fra masteren, men gennem en arkiv. Et binĂŠrt arkiv, hvor WAL'erne opdateres dagligt, og hvor backup tages⊠Disse WAL'er ankommer senere â med en kort forsinkelse (kun 1-2 sekunder) â til det grundlĂŠggende billede. Fra det kloner vi pĂ„ enhver mĂ„de â nu som standard bruger vi ZFS.
DS: Men med ZFS er du begrĂŠnset til Ă©n node.
NS: Ja. Men ZFS har ogsĂ„ en magisk : med den kan du sende et snapshot, og endda (jeg har ikke rigtig testet det endnu, menâŠ) kan du sende forskellen mellem to PGDATA. Faktisk har vi ogsĂ„ et andet vĂŠrktĂžj, som vi ikke har overvejet meget til sĂ„danne opgaver. I PostgreSQL er der , der fungerer som «intelligent» rsync og springer meget over, eftersom der ikke er sket nogen ĂŠndringer. Vi kan lave en hurtig synkronisering mellem to servere og gĂ„ tilbage pĂ„ samme mĂ„de.
SĂ„ vi forsĂžger fra den mere DBA-agtige side at lave et vĂŠrktĂžj, der kan gĂžre det samme, som du talte om: vi har Ă©n database, men vi vil gerne teste noget 50 gange, nĂŠsten samtidigt.
DS: 50 gange betyder, at du skal bestille 50 Spot-instanser.
NS: Nej, vi gÞr alt pÄ én maskine.
DS: Men hvordan vil du deploye 50 gange, hvis denne ene database, lad os sige, er terabyte stor? Den har sandsynligvis brug for 256 Gb RAM?
NS: Ja, nogle gange har man brug for meget hukommelse â det er normalt. Men sĂ„dan et eksempel fra virkeligheden. PĂ„ produktionsmaskinen er der 96 kerner og 600 Gb. For databasen bruges 32 kerner (endda nogle gange 16 kerner nu) og 100-120 Gb hukommelse.
DS: Og kan der vĂŠre 50 kopier derinde?
NS: Men der er kun én kopi, og sÄ arbejder copy-on-write (ZFS'agtigt)⊠Jeg vil fortÊlle mere om det.
For eksempel har vi en database pĂ„ 10 Tb. Vi lavede en disk til den, ZFS komprimerede dens stĂžrrelse med 30-40%. Da vi ikke laver belastningstest, er den prĂŠcise svartid ikke vigtig: det kan vĂŠre op til 2 gange langsommere â det er okay.
Vi giver programmĂžrer, QA, DBA osv. mulighed for at teste i 1-2 trĂ„de. For eksempel kan de kĂžre en eller anden migration. Det krĂŠver ikke straks 10 kerner â det har brug for 1 backend Postgres, 1 kerne. Migrationen vil starte â mĂ„ske, vil starte op, sĂ„ den anden kerne aktiveres. Vi har 16-32 kerner tildelt, sĂ„ 10 personer kan arbejde samtidig, ingen problemer.
Da fysisk PGDATA er ens, ender det med, at vi i virkeligheden snyder Postgres. Pointen er denne: for eksempel kĂžrer 10 Postgres'er samtidig. Hvad er det typisk for et problem? De sĂŠtter , lad os sige, til 25%. Det vil sige, det er 200 Gb. Mere end tre af dem kan man ikke starte, fordi hukommelsen lĂžber tĂžr.
Men vi indsÄ pÄ et tidspunkt, at det ikke er nÞdvendigt: vi sÊtter shared_buffers til 2 Gb. PostgreSQL har , og i virkeligheden pÄvirker kun det . Det sÊtter vi til 0,5 Tb. Og det er ikke engang vigtigt, at de ikke reelt er der: den bygger planer, som om de er.
NÄr vi tester en migration, kan vi samle alle planer - vi vil se, hvordan det vil foregÄ i produktion. Sekunderne vil vÊre anderledes (slÞvere), men de data, vi reelt aflÊser, og selve planerne (hvilke JOINs osv.) forbliver nÞjagtig de samme som i produktion. Samtidig kan vi kÞre mange sÄdanne kontroller pÄ én maskine.
DS: TÊnker du ikke, at der er flere problemer her? Det fÞrste - det er en lÞsning, der kun virker pÄ PostgreSQL. Denne tilgang er meget specifik, den er ikke generisk. Det andet - Kubernetes (og alt, hvad cloud-teknologierne bevÊger sig imod) indebÊrer mange noder, og disse noder er efemÊre. I dit tilfÊlde er det en stateful, vedholdende node. Disse ting giver mig modstridende fÞlelser.
NS: For det fÞrste - jeg er enig, det er rent Postgres-historie. Jeg tÊnker, hvis vi har en eller anden direkte IO og en bufferpool nÊsten til hele hukommelsen, vil denne tilgang ikke fungere - planerne vil vÊre anderledes. Men indtil videre arbejder vi kun med Postgres og tÊnker ikke pÄ andre.
Om Kubernetes. Du fortÊller jo selv overalt, at vores database er vedholdende. Hvis en instans fejler, er det vigtigste at bevare disken. Vores platform er ogsÄ i Kubernetes, men komponenten med Postgres er separat (selvom den en dag vil vÊre der). Derfor er det sÄdan: instansen fejler, men vi har bevaret dens PV og tilsluttet det til en anden (ny) instans, som om intet var sket.
DS: Fra mit synspunkt skaber vi pods i Kubernetes. K8s er elastisk: noder bestilles selv efter behov. Opgaven er blot at oprette en pod og angive, at den har brug for X ressourcer, sÄ klarer K8s sig selv. Men understÞttelsen af lagring i Kubernetes er stadig ustabil: , i (denne version blev udgivet uger siden) disse funktioner er kun i beta.
Det vil tage et halvt Är til et Är - sÄ bliver det mere eller mindre stabilt, eller i det mindste vil det blive erklÊret som sÄdan. SÄ muligheden for snapshots og resize lÞser allerede dit problem fuldt ud. Fordi du har en database. Ja, den kan vÊre lidt langsom, men hastigheden afhÊnger af, hvad der ligger "under motorhjelmen", fordi nogle implementeringer kan klare kopiering og copy-on-write pÄ diskunderstÞttelsesniveau.
NS: Her skal alle engine (Amazon, GoogleâŠ) ogsĂ„ nĂ„ at begynde at understĂžtte denne version - det tager ogsĂ„ lidt tid.
DS: Indtil videre bruger vi dem ikke. Vi bruger vores eget.
Lokal udvikling under Kubernetes
NS: Har du nogensinde stÞdt pÄ et Þnske om at kÞre alle pod'er pÄ én maskine og lave en lille test? For hurtigt at fÄ et proof of concept og se, at applikationen fungerer i Kubernetes, uden at skulle dedikere en masse maskiner til det. Der findes Minikube, ikke?
DS: Jeg synes, denne sag â at deployere pĂ„ Ă©n node â handler udelukkende om lokal udvikling. Eller nogle manifestationer af sĂ„dan et mĂžnster. Der er , der er , . Vi er pĂ„ vej mod at bruge Kubernetes IN Docker. Vi er netop begyndt at arbejde med det til tests.
NS: Jeg troede tidligere, at det var et forsĂžg pĂ„ at pakke alle pod'er ind i et enkelt Docker-billede. Men det viste sig, at det handler om noget helt andet. Der er stadig separate containere, separate pod'er â bare i Docker.
DS: Ja. Der er lavet en ret sjov simulering, men meningen er sĂ„dan... Vi har et vĂŠrktĂžj til deployment â . Vi vil gerne lave en tilstand â sĂ„ at sige werf up: «Start mig en lokal Kubernetes». Og derefter kĂžre en hypotetisk werf follow. SĂ„ vil udvikleren kunne redigere i IDE'en, mens der kĂžrer en proces i systemet, der ser ĂŠndringerne og bygger billederne om og redeployerer dem til den lokale K8s. SĂ„dan vil vi forsĂžge at lĂžse problemet med lokal udvikling.
Snapshots og kloning af databaser i K8s-reality
NS: Hvis vi gĂ„r tilbage til copy-on-write. Jeg har bemĂŠrket, at cloud-lĂžsninger ogsĂ„ har snapshots. De fungerer forskelligt. For eksempel i GCP: du har en multiterabyte instans pĂ„ den Ăžstlige kyst af USA. Du tager periodisk snapshots. Du lĂžfter en kopi af disken fra snapshotet pĂ„ vestkysten â efter fĂ„ minutter er det klar, det fungerer meget hurtigt, kun cachen skal fyldes i hukommelsen. Men disse kloner (snapshots) â er til at 'provisionere' et nyt volumen. Det er fantastisk, nĂ„r du skal oprette mange instanser.
Men til tests, synes jeg, de snapshots, du taler om i Docker, eller jeg taler om i ZFS, btrfs og endda LVM... â de gĂžr netop, at du ikke skal lave nye data pĂ„ Ă©n maskine. I cloud'en skal du ogsĂ„ betale for dem hver gang og vente ikke sekunder, men minutter (og i tilfĂŠlde af , muligvis timer).
I stedet kan du pĂ„ fĂ„ sekunder fĂ„ disse data, kĂžre testen og smide dem vĂŠk. Disse snapshots lĂžser forskellige opgaver. I det fĂžrste tilfĂŠlde â til at skalere og fĂ„ nye replikaer, og i det andet â til tests.
DS: Jeg er uenig. At klone volumener korrekt er en opgave for skyen. Jeg har ikke set deres implementering, men jeg kender mÄden, vi gÞr det pÄ hardware. Vi har Ceph, der kan klone et hvilket som helst fysisk volumen () ved at sige clone og fÄ et andet volumen med de samme egenskaber pÄ fÊrre millisekunder, og sÄ videre. Man skal forstÄ, at der er en smart copy-on-write mekanisme indeni. Hvorfor skulle skyen ikke gÞre det samme? Jeg er sikker pÄ, at de pÄ den ene eller anden mÄde prÞver at gÞre det.
NS: Men de vil stadig bruge sekunder, titusinder af sekunder, pÄ at starte en instans, installere Docker osv.
DS: Hvorfor skal man nĂždvendigvis starte en hel instans? Vi har en instans med 32 kerner, 16⊠og der kan vĂŠre et vist antal inde â for eksempel fire. NĂ„r vi bestiller den femte, vil der allerede oprettes en instans, som derefter vil blive slettet.
NS: Ja, det er interessant, i Kubernetes er det en anden historie. Vi har ikke databaser i K8s og én instans. Men pÄ kloning af en multiterabyte database tager det ikke mere end to sekunder.
DS: Det er fantastisk. Men mit oprindelige budskab er, at dette ikke er en generisk lÞsning. Ja, det er fantastisk, men det passer kun til Postgres og kun pÄ én node.
NS: Det passer ikke kun til Postgres: de planer, jeg har beskrevet, vil kun fungere pÄ den. Men hvis man ikke bekymrer sig om planerne, og vi bare har brug for alle data til funktionel test, sÄ er det passende til enhver DBMS.
DS: For mange Ă„r siden lavede vi noget lignende med LVM-snapshots. Det er klassisk. Denne tilgang blev meget aktivt brugt. Stateful-noder er bare besvĂŠrligt. Fordi de ikke mĂ„ falde ned, man skal altid huske demâŠ
NS: Ser du ikke her en mulighed for en hybrid? Antag, at stateful er en pod, der fungerer for flere personer (mange testere). Vi har Ă©t volumen, men takket vĂŠre filsystemet er klonerne lokale. Hvis pod'en falder, forbliver disken â pod'en vil stige op, beregne informationen om alle kloner, starte det hele op igen og sige: 'Her er dine kloner pĂ„ disse porte, arbejd videre med dem'.
DS: Teknisk set betyder det, at indenfor Kubernetes er det Ă©n pod, inden i hvilken vi starter mange Postgres'er.
NS: Ja. Den har en grĂŠnse: lad os sige, at ikke mere end 10 personer arbejder med den samtidig. Hvis der er brug for 20 â sĂ„ starter vi en anden sĂ„dan pod. Det er helt muligt at klone den, sĂ„ vi fĂ„r et andet komplet volumen, som vil have de samme 10 'tynde' kloner. Ser du ikke sĂ„dan en mulighed?
DS: Der er behov for at tilfĂžje sikkerhedsspĂžrgsmĂ„l her. Denne organisationsform indebĂŠrer, at denne pod har hĂžje privilegier (capabilities), da den kan udfĂžre usĂŠdvanlige operationer pĂ„ filsystemet... Men jeg gentager: jeg tror, at Kubernetes vil lĂžse opbevaringsproblemerne pĂ„ mellemlang sigt, og i skyen vil de rette op pĂ„ hele historien med volumen â alt vil «bare fungere». Der vil vĂŠre resize, kloning... Der er et volumen â vi siger: «Opret et nyt baseret pĂ„ dette», â og pĂ„ halvandet sekund fĂ„r vi, hvad vi skal bruge.
NS: Jeg tror ikke pÄ halvandet sekund for mange terabyte. PÄ Ceph gÞr du det selv, men du taler om skyen. GÄ til skyen, lav en klon af EBS-volumen pÄ EC2, mange terabyte, og se hvilken ydeevne du fÄr. Det vil ikke tage et par sekunder. Jeg er meget interesseret i, hvornÄr de nÄr til sÄdan et niveau. Jeg forstÄr, hvad du taler om, men jeg tillader mig at vÊre uenig.
DS: Okay, men jeg sagde, at det var pÄ mellemlang sigt, ikke kortsigtet. I lÞbet af de nÊste par Är.
Om operatoren for PostgreSQL fra Zalando
I midten af dette mÞde tilsluttede Alexey Klyukin, tidligere udvikler fra Zalando, sig ogsÄ, og han fortalte om historien bag PostgreSQL-operatoren:
Det er fantastisk, at dette emne overhovedet er blevet berÞrt: bÄde Postgres og Kubernetes. Da vi begyndte at arbejde med dette i Zalando i 2017, var det et emne, som alle ville beskÊftige sig med, men ingen gjorde. Alle havde allerede begyndt at bruge Kubernetes, men nÄr man spurgte, hvordan man skulle forholde sig til databaser, sÄ sagde selv sÄdanne personer som , som prÊdikede K8s, omtrent fÞlgende:
«GÄ til managed-services og brug dem, ikke kÞr databaser i Kubernetes. Ellers vil din K8s beslutte sig for at opgradere, slukke for alle noder, og sÄ vil dine data forsvinde langt vÊk.»
Vi besluttede at lave en operator, der pĂ„ trods af dette rĂ„d ville kĂžre Postgres-databaser i Kubernetes. Og vi havde et godt grundlag â . Dette er automatisk failover for PostgreSQL, korrekt udfĂžrt, dvs. bruge etcd, consul eller ZooKeeper som lager for clusterinformationen. Et sĂ„dant lager, der vil give alle, der spĂžrger, den samme information â uanset at vi har alt distribueret â for at undgĂ„ split brain. Derudover havde vi et til det.
Overhovedet opstod behovet for auto failover i virksomheden efter migrationen fra et internt datacenter til skyen. Skyen var baseret pÄ en egenudviklet PaaS-lÞsning (Platform-as-a-Service). Den er Open Source, men for at fÄ den op at kÞre, skulle der ydes en betydelig indsats. Den blev kaldt .
Oprindeligt var der ikke noget Kubernetes. Mere prÊcist, da den egenudviklede lÞsning blev implementeret, var K8s allerede tilgÊngelig, men sÄ uferdig, at den ikke kunne bruges i produktion. Det var, hvis jeg husker korrekt, i 2015 eller 2016. I 2017 blev Kubernetes mere eller mindre modent, hvilket skabte behovet for migrering hertil.
Og vi havde allerede en Docker-container. Der var PaaS, der brugte Docker. Hvorfor ikke prĂžve K8s? Hvorfor ikke skrive vores egen operator? Murat Kabilov, som kom til os fra Avito, startede dette som et initiativ â 'for sjov' â og projektet fik succes.
Men jeg ville egentlig fortĂŠlle om AWS. Hvorfor der historisk set var kode relateret til AWS...
NĂ„r du lancerer noget i Kubernetes, er det vigtigt at forstĂ„, at K8s er et work in progress. Det udvikler sig konstant, forbedres og kan periodevis endda bryde sammen. Det er nĂždvendigt at holde nĂžje Ăžje med alle ĂŠndringer i Kubernetes, og man skal vĂŠre klar til i tilfĂŠlde af problemer at dykke ned i det og forstĂ„, hvordan det fungerer i detaljer â muligvis mere end man Ăžnsker. Det gĂŠlder generelt for enhver platform, hvor du kĂžrer dine databaser...
SÄ da vi lavede operatoren, havde vi Postgres, der arbejdede med en ekstern volume (i dette tilfÊlde EBS, da vi arbejdede pÄ AWS). Databasen voksede, og pÄ et tidspunkt blev det nÞdvendigt at lave en resize: for eksempel, den oprindelige stÞrrelse af EBS var 100 TB, databasen voksede til den stÞrrelse, nu ville vi lave EBS til 200 TB. Hvordan? Man kan lave dump/restore pÄ en ny instans, men det er langsomt og indebÊrer nedetid.
Derfor Þnskede vi en resize, der ville Þge EBS-partitionen og derefter fortÊlle filsystemet at bruge det nye rum. Og det gjorde vi, men pÄ det tidspunkt havde Kubernetes ingen API til resize-operationen. Da vi arbejdede pÄ AWS, skrev vi kode til dens API.
Ingen forhindrer dig i at gĂžre det samme for andre platforme. I operatoren er der ingen binding, som siger, at den kun kan kĂžre pĂ„ AWS, og at den ikke vil fungere andre steder. Det er i det hele taget et Open Source-projekt: hvis nogen Ăžnsker at fremskynde brugen af det nye API â er I alle sammen velkomne. , pull-forespĂžrgsler â Zalando-teamet forsĂžger at reagere pĂ„ dem ret hurtigt og fremme operatĂžren. Hvad jeg ved, involverede projektet i Google Summer of Code og nogle andre lignende initiativer. Zalando arbejder meget aktivt pĂ„ det.
P.S. Bonus!
Hvis du er interesseret i emnet PostgreSQL og Kubernetes, vil vi ogsÄ gerne pÄpege, at der i sidste uge fandt sted fÞlgende Postgres-tirsdag, hvor Nikolaj talte med Alexander Kukushkin fra Zalando. Videoen er tilgÊngelig .
P.P.S.
LÊs ogsÄ pÄ vores blog:
- «»;
- «»;
- «»;
- «».
Kilde: habr.com
