På slutten av fjoråret fant nok en direktesending av det russiske PostgreSQL-samfunnet sted , hvor dens medgründer Nikolai Samokhvalov snakket med Flant teknisk direktør Dmitry Stolyarov om dette DBMS i sammenheng med Kubernetes.
Vi publiserer en utskrift av hoveddelen av denne diskusjonen, og kl Full video lagt ut:
Databaser og Kubernetes
НС: Vi vil ikke snakke om VACUUM og CHECKPOINT i dag. Vi ønsker å snakke om Kubernetes. Jeg vet at du har mange års erfaring. Jeg så på videoene dine og så til og med på noen av dem på nytt... La oss gå rett til poenget: hvorfor Postgres eller MySQL i K8s i det hele tatt?
DS: Det er ikke og kan ikke være et sikkert svar på dette spørsmålet. Men generelt sett er dette enkelhet og bekvemmelighet ... potensial. Alle vil ha administrerte tjenester.
НС: Til hvordan , bare hjemme?
DS: Ja: som RDS, hvor som helst.
НС: "Hvor som helst" er et godt poeng. I store selskaper er alt plassert på forskjellige steder. Hvorfor da, hvis det er et stort selskap, ikke ta en ferdig løsning? For eksempel har Nutanix sin egen utvikling, andre selskaper (VMware...) har samme "RDS, bare hjemme."
DS: Men vi snakker om en egen implementering som kun vil fungere under visse forutsetninger. Og hvis vi snakker om Kubernetes, så er det et stort utvalg av infrastruktur (som kan være i K8s). I hovedsak er dette en standard for APIer til skyen...
НС: Det er også gratis!
DS: Det er ikke så viktig. Frihet er viktig for ikke et veldig stort segment av markedet. Noe annet er viktig... Du husker sikkert rapporten ""?
НС: Ja.
DS: Jeg skjønte at det ble mottatt veldig tvetydig. Noen trodde at jeg sa: "Gutter, la oss få alle databasene inn i Kubernetes!", mens andre bestemte at alt dette var forferdelige sykler. Men jeg ville si noe helt annet: «Se hva som skjer, hvilke problemer det er og hvordan de kan løses. Bør vi bruke Kubernetes-databaser nå? Produksjon? Vel, bare hvis du liker...å gjøre visse ting. Men for en utvikler kan jeg si at jeg anbefaler det. For en utvikler er dynamikken i å lage/slette miljøer veldig viktig.»
NS: Med dev, mener du alle miljøer som ikke er prod? Iscenesettelse, QA...
DS: Hvis vi snakker om perf stands, så sannsynligvis ikke, fordi kravene der er spesifikke. Hvis vi snakker om spesielle tilfeller hvor det trengs en veldig stor database for iscenesettelse, så sannsynligvis ikke... Hvis dette er et statisk miljø med lang levetid, hva er da fordelen med å ha databasen plassert i K8s?
НС: Ingen. Men hvor ser vi statiske miljøer? Et statisk miljø vil bli foreldet i morgen.
DS: Iscenesettelse kan være statisk. Vi har kunder...
НС: Ja, jeg har også en. Det er et stort problem hvis du har en 10 TB database og 200 GB staging...
DS: Jeg har en veldig kul sak! På iscenesettelse er det en produktdatabase som det gjøres endringer i. Og det er en knapp: "rull ut til produksjon". Disse endringene - deltaene - legges til (det ser ut til at de ganske enkelt er synkronisert via APIen) i produksjonen. Dette er et veldig eksotisk alternativ.
НС: Jeg har sett startups i Valley som sitter i RDS eller til og med i Heroku - dette er historier fra 2-3 år siden - og de laster ned dumpen til den bærbare datamaskinen. For databasen er fortsatt bare 80 GB, og det er plass på den bærbare datamaskinen. Deretter kjøper de ekstra disker til alle slik at de har 3 databaser til å utføre ulike utviklinger. Slik skjer det også. Jeg så også at de ikke er redde for å kopiere prod til iscenesettelse – det kommer veldig an på selskapet. Men jeg så også at de er veldig redde, og at de ofte ikke har nok tid og hender. Men før vi går videre til dette emnet, vil jeg høre om Kubernetes. Forstår jeg riktig at ingen er i prod ennå?
DS: Vi har små databaser i produksjon. Vi snakker om volumer på titalls gigabyte og ikke-kritiske tjenester som vi var for late til å lage kopier til (og det er ikke noe slikt behov). Og forutsatt at det er normal lagring under Kubernetes. Denne databasen fungerte i en virtuell maskin – betinget i VMware, på toppen av lagringssystemet. Vi plasserte den inn og nå kan vi overføre det fra maskin til maskin.
НС: Databaser av denne størrelsen, opptil 100 GB, kan rulles ut på noen få minutter på gode disker og et godt nettverk, ikke sant? En hastighet på 1 GB per sekund er ikke lenger eksotisk.
DS: Ja, for lineær drift er dette ikke et problem.
НС: Ok, vi må bare tenke på prod. Og hvis vi vurderer Kubernetes for ikke-prod-miljøer, hva bør vi gjøre? Jeg ser det på Zalando , i Crunchy , det er noen andre alternativer. Og det er det – dette er vår gode venn Alvaro fra Spania: det de gjør er i hovedsak ikke bare , og hele distribusjonen (), som de, i tillegg til Postgres selv, også bestemte seg for å sette en sikkerhetskopi, Envoy-proxyen...
DS: Utsending for hva? Balansere Postgres-trafikk spesifikt?
НС: Ja. Det vil si at de ser det slik: hvis du tar en Linux-distribusjon og kjerne, så er vanlig PostgreSQL kjernen, og de vil lage en distribusjon som skal være skyvennlig og kjøre på Kubernetes. De setter sammen komponenter (sikkerhetskopier osv.) og feilsøker dem slik at de fungerer bra.
DS: Veldig kult! I hovedsak er dette programvare for å lage din egen administrerte Postgres.
НС: Linux-distribusjoner har evige problemer: hvordan lage drivere slik at all maskinvare støttes. Og de har ideen om at de skal jobbe i Kubernetes. Jeg vet at i Zalando-operatøren så vi nylig en forbindelse til AWS, og dette er ikke lenger veldig bra. Det bør ikke være en binding til en spesifikk infrastruktur - hva er vitsen da?
DS: Jeg vet ikke nøyaktig hvilken situasjon Zalando havnet i, men i Kubernetes er lagring nå laget på en slik måte at det er umulig å ta en sikkerhetskopi av disk med en generisk metode. Nylig i standard - i siste versjon — vi gjorde øyeblikksbilder mulig, men hvor er det implementert? Ærlig talt, alt er fortsatt så rått... Vi prøver CSI på toppen av AWS, GCE, Azure, vSphere, men så snart du begynner å bruke det, kan du se at det ikke er klart ennå.
НС: Det er derfor vi noen ganger må stole på infrastruktur. Jeg tror dette fortsatt er et tidlig stadium - voksesmerter. Spørsmål: Hvilke råd vil du gi til nybegynnere som ønsker å prøve PgSQL i K8s? Hvilken operatør kanskje?
DS: Problemet er at Postgres er 3% for oss. Vi har også en veldig stor liste over forskjellig programvare i Kubernetes, jeg vil ikke engang liste opp alt. For eksempel Elasticsearch. Det er mange operatører: noen utvikler seg aktivt, andre er det ikke. Vi har laget krav til oss selv om hva en operatør skal ha for at vi skal ta det på alvor. I en operatør spesifikt for Kubernetes - ikke i en "operatør for å gjøre noe under Amazons forhold"... Faktisk bruker vi ganske mye (= nesten alle klienter) en enkelt operatør - (vi vil snart publisere en artikkel om ham).
НС: Og ikke for MySQL heller? Jeg vet at Percona... siden de nå jobber med MySQL, MongoDB og Postgres, må de lage en slags universell løsning: for alle databaser, for alle skyleverandører.
DS: Vi hadde ikke tid til å se på operatørene for MySQL. Dette er ikke vårt hovedfokus akkurat nå. MySQL fungerer fint i frittstående. Hvorfor bruke en operatør hvis du bare kan starte en database... Du kan starte en Docker-beholder med Postrges, eller du kan starte den på en enkel måte.
НС: Det var et spørsmål om dette også. Ingen operatør i det hele tatt?
DS: Ja, 100 % av oss kjører PostgreSQL uten en operatør. Så langt så. Vi bruker aktivt operatøren for Prometheus og Redis. Vi har planer om å finne en operatør for Elasticsearch - det er den som er mest "tenkt", fordi vi ønsker å installere den i Kubernetes i 100 % av tilfellene. Akkurat som vi ønsker å sikre at MongoDB også alltid er installert i Kubernetes. Her dukker det opp visse ønsker - det er en følelse av at i disse tilfellene kan noe gjøres. Og vi så ikke engang på Postgres. Selvfølgelig vet vi at det er forskjellige alternativer, men faktisk har vi en frittstående.
DB for testing i Kubernetes
НС: La oss gå videre til temaet testing. Slik ruller du ut endringer i databasen - fra et DevOps-perspektiv. Det er mikrotjenester, mange databaser, noe er i endring et sted hele tiden. Hvordan sikre normal CI/CD slik at alt er i orden fra DBMS-perspektivet. Hva er din tilnærming?
DS: Det kan ikke være ett svar. Det er flere alternativer. Den første er størrelsen på basen som vi ønsker å rulle ut. Du nevnte selv at bedrifter har ulike holdninger til å ha en kopi av prod-databasen på dev og scene.
НС: Og under betingelsene i GDPR tror jeg de er mer og mer forsiktige... Jeg kan si at i Europa har de allerede begynt å ilegge bøter.
DS: Men ofte kan du skrive programvare som tar en dump fra produksjonen og tilslører det. Prod-data innhentes (øyeblikksbilde, dump, binær kopi...), men det er anonymisert. I stedet kan det være generasjonsskript: disse kan være inventar eller bare et skript som genererer en stor database. Problemet er: hvor lang tid tar det å lage et basisbilde? Og hvor lang tid tar det å distribuere den i ønsket miljø?
Vi kom til en ordning: hvis klienten har et fast datasett (minimal versjon av databasen), bruker vi dem som standard. Hvis vi snakker om gjennomgangsmiljøer, da vi opprettet en filial, distribuerte vi en forekomst av applikasjonen - vi ruller ut en liten database der. Men det ble bra , når vi tar en dump fra produksjonen en gang om dagen (om natten) og bygger en Docker-container med PostgreSQL og MySQL med disse nedlastede dataene basert på den. Hvis du trenger å utvide databasen 50 ganger fra dette bildet, gjøres dette ganske enkelt og raskt.
НС: Ved enkel kopiering?
DS: Data lagres direkte i Docker-bildet. De. Vi har et ferdig bilde, om enn 100 GB. Takket være lag i Docker kan vi raskt distribuere dette bildet så mange ganger vi trenger. Metoden er dum, men den fungerer bra.
НС: Så, når du tester, endres det rett inne i Docker, ikke sant? Kopier-på-skriv inne i Docker - kast det og gå igjen, alt er i orden. Klasse! Og bruker du den til det fulle allerede?
DS: I lang tid.
НС: Vi gjør veldig like ting. Bare vi bruker ikke Dockers copy-on-write, men en annen.
DS: Det er ikke generisk. Og Docker fungerer overalt.
НС: I teorien, ja. Men vi har også moduler der, du kan lage forskjellige moduler og jobbe med forskjellige filsystemer. For et øyeblikk her. Fra Postgres-siden ser vi annerledes på alt dette. Nå så jeg fra Docker-siden og så at alt fungerer for deg. Men hvis databasen er enorm, for eksempel 1 TB, tar alt dette lang tid: operasjoner om natten, og å stappe alt inn i Docker... Og hvis 5 TB er stappet inn i Docker... Eller er alt i orden?
DS: Hva er forskjellen: dette er blobs, bare biter og bytes.
НС: Forskjellen er denne: gjør du det gjennom dump og gjenoppretting?
DS: Ikke nødvendig i det hele tatt. Metodene for å generere dette bildet kan være forskjellige.
НС: For noen klienter har vi gjort det slik at i stedet for regelmessig å generere et basisbilde, holder vi det hele tiden oppdatert. Det er i hovedsak en replika, men den mottar data ikke fra masteren direkte, men gjennom et arkiv. Et binært arkiv hvor WAL-er lastes ned hver dag, hvor sikkerhetskopier tas... Disse WAL-ene når deretter basisbildet med en liten forsinkelse (bokstavelig talt 1-2 sekunder). Vi kloner fra det på noen måte - nå har vi ZFS som standard.
DS: Men med ZFS er du begrenset til én node.
НС: Ja. Men ZFS har også en magisk : med den kan du sende et øyeblikksbilde og til og med (jeg har egentlig ikke testet dette ennå, men...) kan du sende et delta mellom to PGDATA. Faktisk har vi et annet verktøy som vi egentlig ikke har vurdert for slike oppgaver. PostgreSQL har , som fungerer som en "smart" rsync, og hopper over mye av det du ikke trenger å se, fordi ingenting har endret seg der. Vi kan gjøre en rask synkronisering mellom de to serverne og spole tilbake på samme måte.
Så fra denne, mer DBA-siden, prøver vi å lage et verktøy som lar oss gjøre det samme som du sa: vi har én database, men vi ønsker å teste noe 50 ganger, nesten samtidig.
DS: 50 ganger betyr at du må bestille 50 Spot-forekomster.
НС: Nei, vi gjør alt på én maskin.
DS: Men hvordan vil du utvide 50 ganger hvis denne databasen er for eksempel terabyte. Mest sannsynlig trenger hun en betinget 256 GB RAM?
НС: Ja, noen ganger trenger du mye hukommelse - det er normalt. Men dette er et eksempel fra livet. Produksjonsmaskinen har 96 kjerner og 600 GB. Samtidig brukes 32 kjerner (selv 16 kjerner nå noen ganger) og 100-120 GB minne til databasen.
DS: Og 50 eksemplarer passer inn der?
НС: Så det er bare ett eksemplar, så fungerer copy-on-write (ZFS)... Jeg skal fortelle deg mer detaljert.
For eksempel har vi en 10 TB database. De laget en disk for den, ZFS komprimerte også størrelsen med 30-40 prosent. Siden vi ikke utfører belastningstesting, er den nøyaktige responstiden ikke viktig for oss: la den være opptil 2 ganger langsommere - det er greit.
Vi gir muligheten til programmerere, QA, DBA, etc. utføre testing i 1-2 tråder. For eksempel kan de kjøre en form for migrering. Den krever ikke 10 kjerner samtidig - den trenger 1 Postgres backend, 1 kjerne. Migreringen starter – kanskje vil fortsatt starte, så vil den andre kjernen bli brukt. Vi har 16-32 kjerner tildelt, så 10 personer kan jobbe samtidig, ikke noe problem.
Fordi fysisk PGDATA det samme viser det seg at vi faktisk lurer Postgres. Trikset er dette: for eksempel lanseres 10 Postgres samtidig. Hva er problemet vanligvis? De putter , la oss si 25 %. Følgelig er dette 200 GB. Du vil ikke kunne starte mer enn tre av disse, fordi minnet vil gå tom.
Men på et tidspunkt innså vi at dette ikke var nødvendig: vi satte shared_buffers til 2 GB. PostgreSQL har , og i virkeligheten er det den eneste som påvirker . Vi satte den til 0,5 TB. Og det spiller ingen rolle at de faktisk ikke eksisterer: han legger planer som om de eksisterer.
Følgelig, når vi tester en form for migrering, kan vi samle alle planene - vi vil se hvordan det vil skje i produksjonen. Sekundene der vil være forskjellige (tregere), men dataene som vi faktisk leser, og selve planene (hvilke JOINs er der, osv.) blir nøyaktig det samme som i produksjonen. Og du kan kjøre mange slike kontroller parallelt på én maskin.
DS: Tror du ikke det er noen problemer her? Den første er en løsning som bare fungerer på PostgreSQL. Denne tilnærmingen er veldig privat, den er ikke generisk. Den andre er at Kubernetes (og alt som skyteknologier kommer til nå) involverer mange noder, og disse nodene er flyktige. Og i ditt tilfelle er det en statelig, vedvarende node. Disse tingene gjør meg i konflikt.
НС: For det første er jeg enig, dette er en ren Postgres-historie. Jeg tror at hvis vi har en slags direkte IO og en bufferpool for nesten hele minnet, vil ikke denne tilnærmingen fungere - planene vil være annerledes. Men foreløpig jobber vi bare med Postgres, vi tenker ikke på andre.
Om Kubernetes. Du selv forteller oss overalt at vi har en vedvarende database. Hvis forekomsten mislykkes, er det viktigste å lagre disken. Her har vi også hele plattformen i Kubernetes, og komponenten med Postgres er separat (selv om den vil være der en dag). Derfor er alt slik: forekomsten falt, men vi lagret PV-en og koblet den til en annen (ny) forekomst, som om ingenting hadde skjedd.
DS: Fra mitt ståsted lager vi pods i Kubernetes. K8s - strikk: knuter bestilles etter behov. Oppgaven er å lage en pod og si at den trenger X mengder ressurser, og så vil K8s finne ut av det på egen hånd. Men lagringsstøtte i Kubernetes er fortsatt ustabil: I (denne utgivelsen ble utgitt недели siden) blir disse funksjonene bare beta.
Seks måneder til et år vil gå - det vil bli mer eller mindre stabilt, eller i det minste vil det bli erklært som det. Da løser muligheten for øyeblikksbilder og endre størrelse problemet ditt fullstendig. Fordi du har en base. Ja, det er kanskje ikke veldig raskt, men hastigheten avhenger av hva som er "under panseret", fordi noen implementeringer kan kopiere og kopiere-på-skrive på diskundersystemnivå.
НС: Det er også nødvendig for alle motorer (Amazon, Google...) å begynne å støtte denne versjonen - dette tar også litt tid.
DS: Vi bruker dem ikke ennå. Vi bruker vår.
Lokal utvikling for Kubernetes
НС: Har du noen gang møtt et slikt ønske når du skal installere alle podene på én maskin og gjøre en så liten test. For raskt å få et proof of concept, se at applikasjonen kjører i Kubernetes, uten å dedikere en haug med maskiner til den. Det er Minikube, ikke sant?
DS: Det virker på meg som om denne saken – utplassert på én node – utelukkende handler om lokal utvikling. Eller noen manifestasjoner av et slikt mønster. Spise der , . Vi går mot å bruke Kubernetes IN Docker. Nå begynte vi å jobbe med det for tester.
НС: Jeg pleide å tro at dette var et forsøk på å pakke inn alle pods i ett Docker-bilde. Men det viste seg at dette handler om noe helt annet. Uansett, det er separate containere, separate pods - bare i Docker.
DS: Ja. Og det er laget en ganske morsom imitasjon, men meningen er dette... Vi har et verktøy for distribusjon - . Vi ønsker å gjøre det til en betinget modus werf up: "Få meg lokale Kubernetes." Og så kjøre den betingede der werf follow. Deretter vil utvikleren kunne redigere IDE, og en prosess vil bli lansert i systemet som ser endringene og gjenoppbygger bildene, og omdistribuerer dem til lokale K8-er. Slik ønsker vi å prøve å løse problemet med lokal utvikling.
Øyeblikksbilder og databasekloning i K8s virkelighet
НС: Hvis vi går tilbake til copy-on-write. Jeg la merke til at skyene også har øyeblikksbilder. De fungerer annerledes. For eksempel, i GCP: du har en multi-terabyte-forekomst på østkysten av USA. Du tar øyeblikksbilder med jevne mellomrom. Du henter en kopi av disken på vestkysten fra et øyeblikksbilde - om noen minutter er alt klart, det fungerer veldig raskt, bare cachen må fylles i minnet. Men disse klonene (øyeblikksbildene) er for å klargjøre et nytt volum. Dette er kult når du trenger å lage mange forekomster.
Men for tester ser det ut til at øyeblikksbilder, som du snakker om i Docker eller jeg snakker om i ZFS, btrfs og til og med LVM... - de lar deg ikke lage virkelig nye data på én maskin. I skyen vil du fortsatt betale for dem hver gang og vente ikke sekunder, men minutter (og i tilfelle , muligens en klokke).
I stedet kan du få disse dataene på et sekund eller to, kjøre testen og kaste dem. Disse øyeblikksbildene løser forskjellige problemer. I det første tilfellet - for å skalere opp og få nye kopier, og i det andre - for tester.
DS: Jeg er ikke enig. Å få volumkloning til å fungere skikkelig er skyens oppgave. Jeg har ikke sett på implementeringen deres, men jeg vet hvordan vi gjør det på maskinvare. Vi har Ceph, den tillater ethvert fysisk volum () si klone og få et andre volum med de samme egenskapene på titalls millisekunder, 'ami osv. Du må forstå at det er en vanskelig kopi-på-skriving inni. Hvorfor skulle ikke skyen gjøre det samme? Jeg er sikker på at de prøver å gjøre dette på en eller annen måte.
НС: Men det vil fortsatt ta dem sekunder, titalls sekunder å heve en instans, bringe Docker dit, osv.
DS: Hvorfor er det nødvendig å ta opp en hel instans? Vi har en instans med 32 kjerner, 16... og den kan passe inn i den - for eksempel fire. Når vi bestiller den femte, vil forekomsten allerede være hevet, og så blir den slettet.
НС: Ja, interessant, Kubernetes viser seg å være en annen historie. Databasen vår er ikke i K8s, og vi har én forekomst. Men å klone en multi-terabyte-database tar ikke mer enn to sekunder.
DS: Dette er flott. Men mitt første poeng er at dette ikke er en generisk løsning. Ja, det er kult, men det er bare egnet for Postgres og bare på én node.
НС: Den passer ikke bare for Postgres: disse planene, som jeg beskrev, vil bare fungere i den. Men hvis vi ikke bryr oss om planer, og vi bare trenger all data for funksjonell testing, så passer dette for alle DBMS.
DS: For mange år siden gjorde vi noe lignende på LVM-øyeblikksbilder. Dette er en klassiker. Denne tilnærmingen ble veldig aktivt brukt. Stateful noder er bare en smerte. For du bør ikke slippe dem, du bør alltid huske dem...
НС: Ser du noen mulighet for en hybrid her? La oss si stateful er en slags pod, den fungerer for flere personer (mange testere). Vi har ett volum, men takket være filsystemet er klonene lokale. Hvis poden faller, men disken forblir, vil poden reise seg, telle informasjon om alle klonene, plukke opp alt igjen og si: "Her kjører klonene dine på disse portene, fortsett å jobbe med dem."
DS: Teknisk betyr dette at innenfor Kubernetes er det én pod som vi kjører mange Postgres innenfor.
НС: Ja. Han har en grense: la oss si at ikke mer enn 10 personer jobber med ham samtidig. Hvis du trenger 20, lanserer vi en ny slik pod. Vi vil klone det fullstendig, etter å ha mottatt det andre hele volumet, vil det ha de samme 10 "tynne" klonene. Ser du ikke denne muligheten?
DS: Vi må legge til sikkerhetsproblemer her. Denne typen organisasjon innebærer at denne poden har høye privilegier (kapasiteter), fordi den kan utføre ikke-standard operasjoner på filsystemet... Men jeg gjentar: Jeg tror at de på mellomlang sikt vil fikse lagring i Kubernetes, og i skyene de vil fikse hele historien med volumer - alt vil "bare fungere". Det vil bli endre størrelse, kloning ... Det er et volum - vi sier: "Lag en ny basert på det," og etter halvannet sekund får vi det vi trenger.
НС: Jeg tror ikke på ett og et halvt sekund for mange terabyte. På Ceph gjør du det selv, men du snakker om skyene. Gå til skyen, lag en kloning av et multiterabyte EBS-volum på EC2 og se hva ytelsen blir. Det tar ikke noen sekunder. Jeg er veldig interessert i når de når dette nivået. Jeg forstår hva du mener, men jeg ber om å være annerledes.
DS: Ok, men jeg sa på mellomlang sikt, ikke kort sikt. I flere år.
Om operatøren for PostgreSQL fra Zalando
I midten av dette møtet ble også Alexey Klyukin, en tidligere utvikler fra Zalando, med og snakket om historien til PostgreSQL-operatøren:
Det er flott at dette emnet blir berørt generelt: både Postgres og Kubernetes. Da vi begynte å gjøre det på Zalando i 2017, var det et tema som alle ønsket å gjøre, men ingen gjorde det. Alle hadde allerede Kubernetes, men når de spurte hva de skulle gjøre med databaser, liker til og med folk , som forkynte K8s, sa noe sånt som dette:
"Gå til administrerte tjenester og bruk dem, ikke kjør databasen i Kubernetes. Ellers vil K8-ene dine bestemme seg for for eksempel å gjøre en oppgradering, slå av alle nodene, og dataene dine vil fly langt, langt unna.»
Vi bestemte oss for å lage en operatør som, i motsetning til dette rådet, vil lansere en Postgres-database i Kubernetes. Og vi hadde en god grunn - . Dette er en automatisk failover for PostgreSQL, utført på riktig måte, dvs. bruke etcd, consul eller ZooKeeper som lagring av informasjon om klyngen. Et slikt depot som skal gi alle som spør for eksempel hva dagens leder er, samme informasjon – til tross for at vi har alt fordelt – slik at det ikke blir splittet hjerne. Pluss at vi hadde for han.
Generelt dukket selskapets behov for automatisk failover opp etter migrering fra et internt maskinvaredatasenter til skyen. Skyen var basert på en proprietær PaaS-løsning (Platform-as-a-Service). Det er åpen kildekode, men det tok mye arbeid å få det opp å gå. Det het .
Opprinnelig var det ingen Kubernetes. Mer presist, da vår egen løsning ble distribuert, fantes allerede K8s, men den var så rå at den ikke var egnet for produksjon. Det var, etter min mening, 2015 eller 2016. I 2017 var Kubernetes blitt mer eller mindre modne – det var behov for å migrere dit.
Og vi hadde allerede en Docker-container. Det var en PaaS som brukte Docker. Hvorfor ikke prøve K8s? Hvorfor ikke skrive din egen operatør? Murat Kabilov, som kom til oss fra Avito, startet dette som et prosjekt på eget initiativ - "å spille" - og prosjektet "tok av."
Men generelt ønsket jeg å snakke om AWS. Hvorfor var det historisk AWS-relatert kode...
Når du kjører noe i Kubernetes, må du forstå at K8s er et slikt arbeid som pågår. Det utvikles, forbedres og brytes til og med ned fra tid til annen. Du må følge nøye med på alle endringene i Kubernetes, du må være klar til å dykke ned i det hvis noe skjer og lære hvordan det fungerer i detalj – kanskje mer enn du ønsker. Dette gjelder i prinsippet alle plattformer du kjører databasene dine på...
Så da vi gjorde uttalelsen, hadde vi Postgres kjørende på et eksternt volum (EBS i dette tilfellet, siden vi jobbet med AWS). Databasen vokste, på et tidspunkt var det nødvendig å endre størrelsen på den: for eksempel var den opprinnelige størrelsen på EBS 100 TB, databasen vokste til den, nå vil vi gjøre EBS 200 TB. Hvordan? La oss si at du kan gjøre en dump/gjenoppretting på en ny forekomst, men dette vil ta lang tid og innebære nedetid.
Derfor ønsket jeg en endringsstørrelse som ville øke EBS-partisjonen og deretter fortelle filsystemet å bruke den nye plassen. Og vi gjorde det, men på det tidspunktet hadde ikke Kubernetes noen API for å endre størrelse. Siden vi jobbet med AWS, skrev vi kode for API-en.
Ingen hindrer deg i å gjøre det samme for andre plattformer. Det er ingen antydning i uttalelsen om at den kun kan kjøres på AWS, og den vil ikke fungere på alt annet. Generelt er dette et åpen kildekode-prosjekt: hvis noen ønsker å fremskynde fremveksten av bruken av den nye APIen, er du velkommen. Spise , pull-forespørsler - Zalando-teamet prøver å svare på dem ganske raskt og promotere operatøren. Så vidt jeg vet, prosjektet på Google Summer of Code og noen andre lignende initiativer. Zalando jobber veldig aktivt med det.
P.S. Bonus!
Hvis du er interessert i emnet PostgreSQL og Kubernetes, så vær også oppmerksom på at neste Postgres tirsdag fant sted forrige uke, hvor jeg snakket med Nikolai Alexander Kukushkin fra Zalando. Video fra den er tilgjengelig .
PPS
Les også på bloggen vår:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com