I slutten av fjorÄret ble det avholdt et nytt direktesendt program for det russiske PostgreSQL-samfunnet , der medgrunnlegger Nikolai Samokhvalov snakket med teknisk direktÞr for «Flant» Dmitry Stolyarov om denne DBMS i konteksten av Kubernetes.
Vi publiserer transkriptet av hoveddelen av denne diskusjonen, og pÄ er den fullstendige videoopptaket publisert:
Databaser og Kubernetes
NS: Vi skal ikke snakke om VACUUM og CHECKPOINT i dag. Vi vil snakke om Kubernetes. Jeg vet at du har mange Ärs erfaring. Jeg har sett videoene dine og noen har jeg til og med sett pÄ nytt... La oss gÄ rett pÄ sak: hvorfor bruke Postgres eller MySQL i K8s?
DS: Det er ikke noe entydig svar pÄ dette spÞrsmÄlet, og det kan ikke finnes. Men generelt handler det om enkelhet og bekvemmelighet... potensielt. Alle vil jo ha managed tjenester.
NS: Som , bare hos seg selv?
DS: Ja: som RDS, bare hvor som helst.
NS: «Hvor som helst» â det er et godt poeng. I store selskaper er alt fordelt over flere steder. Men hvorfor velge et ferdig lĂžsning hvis det er et stort selskap? For eksempel har Nutanix sine egne utviklinger, og andre selskaper (VMware...) â den samme «RDS, bare hos seg selv».
DS: Men dette snakker vi om en spesifikk implementering som bare vil fungere under bestemte forhold. NĂ„r vi snakker om Kubernetes, er det et enormt mangfold av infrastruktur (som kan vĂŠre i K8s). Dette er i essens en standard for API til skyen...
NS: Og det er gratis!
DS: Det er ikke sÄ viktig. Gratishet er ikke sÄ viktig for et lite segment av markedet. Det andre er viktigere... Du husker sikkert foredraget «»?
NS: Ja.
DS: Jeg forstod at det ble mottatt svÊrt ulikt. Noen tenkte at jeg sa: «Folkens, la oss bruke alle databaser i Kubernetes!», mens andre mente at dette var helt latterlige ideer. Men jeg Þnsket egentlig Ä si noe annet: «Se hva som skjer, hvilke problemer som finnes og hvordan de kan lÞses. Er det aktuelt Ä bruke databaser i Kubernetes nÄ? Produksjon? Vel, bare hvis du liker... Ä drive med spesifikke ting. Men for utvikling... jeg kan si at jeg anbefaler det. For utvikling er dynamikken i Ä opprette/slette miljÞer veldig viktig.»
NS: Med utvikling mener du alle miljĂžer som ikke er produksjon? Staging, QA...
DS: Hvis vi snakker om perf-stativer, sÄ er det vel neppe det, fordi kravene der er spesifikke. Hvis vi snakker om spesielle tilfeller hvor det pÄ staging er behov for en veldig stor DB, sÄ er svaret ogsÄ neppe⊠Hvis det er et statisk miljÞ som lever lenge, hvilken fordel er det at databasen ligger i K8s?
NS: Ingen. Men hvor ser vi statiske miljĂžer? Et statisk miljĂž er allerede utdatert i morgen.
DS: Staging kan vĂŠre statisk. Vi har kunderâŠ
NS: Ja, jeg har ogsĂ„ noen. Det er et stort problem hvis du har en database pĂ„ 10 TB, men staging er 200 GBâŠ
DS: Jeg har en veldig kul case! PĂ„ staging ligger prod-databasen, som fĂ„r endringer. Og det er en knapp: «deploy til produksjon». Disse endringene â deltabaser â fylles opp (ser ut som de synkroniseres via API) i produksjon. Dette er en veldig eksotisk variant.
NS: Jeg har sett startups i dalen som sitter i RDS eller til og med Heroku fortsatt â dette er historier fra 2-3 Ă„r tilbake â og de laster ned dumps til laptopen sin. Fordi databasen bare er 80 GB, og det er plass pĂ„ laptopen. SĂ„ kjĂžper de ekstra disker til hver person for Ă„ ha 3 databaser for Ă„ drive med forskjellige prosjekter. Slik skjer det ogsĂ„. Jeg har ogsĂ„ sett at de ikke er redde for Ă„ kopiere prod til staging â det avhenger sterkt av selskapet. Men jeg har ogsĂ„ sett at de er veldig redde, og ofte mangler tid og ressurser. Men fĂžr vi gĂ„r videre til dette emnet, vil jeg gjerne hĂžre om Kubernetes. Jeg har rett i at ingen bruker det i prod ennĂ„?
DS: Vi har smĂ„ databaser i prod. Det gjelder volum i titalls gigabyte og ikke-kritiske tjenester, der det var for mye arbeid Ă„ lage replikater (og det er ikke noe behov). Og med forutsetningen av at det under Kubernetes er et tilfredsstillende lagringssystem. Denne databasen jobbet pĂ„ en virtuell maskin â betinget i VMware, over lagringsnettverk. Vi plasserte den i og nĂ„ kan vi flytte den fra maskin til maskin.
NS: Databaser av den stÞrrelsen, opp til 100 GB, pÄ gode disker og med godt nettverk kan rulles ut pÄ noen fÄ minutter, ikke sant? En hastighet pÄ 1 GB per sekund er ikke lenger eksotisk.
DS: Ja, for en lineĂŠr operasjon er det ikke et problem.
NS: Ok, vi mĂ„ bare tenke pĂ„ prod. Men hvis vi vurderer Kubernetes for ikke-prod-miljĂžer â hvordan gĂ„r vi frem? Jeg ser at Zalando , i Crunchy , det finnes ogsĂ„ andre alternativer. Og det er â det er vĂ„r gode bekjent Alvaro fra Spania: de lager ikke bare , men en hel distribusjon (), der i tillegg til selve Postgres ogsĂ„ vil inkludere backup og proxy EnvoyâŠ
DS: Envoy til hva? Lastbalansering av Postgres-trafikk?
NS: Ja. De ser pÄ det som: hvis man tar en Linux-distribusjon og kjernen, sÄ er vanlig PostgreSQL kjernen, og de vil lage en distribusjon som er vennlig mot skyer og kan kjÞre i Kubernetes. De kobler sammen komponenter (backups osv.) og finjusterer for at de skal fungere godt.
DS: Veldig kult! I bunn og grunn er dette programvare for Ă„ lage sin egen managed Postgres.
NS: Linux-distribusjoner har evige problemer: hvordan lage drivere slik at alt maskinvare stĂžttes. Og deres idĂ© er at de skal fungere i Kubernetes. Jeg vet at vi i Zalando-opponenten nylig sĂ„ en tilknytning til AWS, og det er ikke spesielt bra. Det burde ikke vĂŠre knyttet til en spesifikk infrastruktur â hva er da meningen?
DS: Jeg vet ikke i hvilken situasjon Zalando konkret ble knyttet, men i Kubernetes er lagring nĂ„ laget slik at man ikke kan ta diskbackup pĂ„ en generell mĂ„te. Nylig i standarden â i siste versjon â laget muligheten for snapshots, men hvor er det implementert? Ărlig talt, det er fortsatt sĂ„ rĂ„tt⊠Vi prĂžver CSI over AWS, GCE, Azure, vSphere, men sĂ„ snart man begynner Ă„ bruke det, ser man at det fortsatt ikke er klart.
NS: Derfor mĂ„ man noen ganger knytte seg til infrastrukturen. Jeg tror dette fortsatt er en tidlig fase â vekstproblemer. SpĂžrsmĂ„let er: hva ville du anbefale nybegynnere som Ăžnsker Ă„ prĂžve PgSQL i K8s? Hvilken operator, kanskje?
DS: Problemet er at Postgres for oss er 3%. Vi har ogsĂ„ en veldig lang liste med forskjellig programvare i Kubernetes, jeg gidder ikke engang Ă„ liste alt. For eksempel Elasticsearch. Det finnes mange operatĂžrer: noen utvikler seg aktivt, andre ikke. Vi har laget vĂ„re egne krav til hva som bĂžr vĂŠre i operatĂžren for at vi skal ta den seriĂžst. Det er en operatĂžr egentlig for Kubernetes â ikke i «operatĂžr for Ă„ gjĂžre noe i Amazon»⊠Faktisk bruker vi ganske massivt (= nesten alle kunder) en eneste operatĂžr â (vi vil snart publisere en artikkel om den ogsĂ„).
NS: Men for MySQL finnes det ikke? Jeg vet at Percona⊠siden de nÄ jobber med bÄde MySQL, MongoDB og Postgres, bÞr de lage en slags universell lÞsning: for alle databaser, for alle skytjenesteleverandÞrer.
DS: Vi rakk ikke Ä se pÄ operatÞrene for MySQL. For oss er det ikke hovedfokuset nÄ. MySQL fungerer fint pÄ egen hÄnd. Hva trenger vi en operatÞr for, nÄr vi kan bare starte databasen⊠Vi kan starte en Docker-container med Postrges, eller vi kan gjÞre det pÄ en enkel mÄte.
NS: Det var ogsÄ et spÞrsmÄl om dette. Kanskje helt uten operatÞr?
DS: Ja, vi har PostgreSQL kjĂžrende uten operatĂžr 100%. SĂ„nn er det forelĂžpig. Vi bruker aktivt operatĂžr for Prometheus, for Redis. Vi har planer om Ă„ finne en operatĂžr for Elasticsearch â det er mest presserende, siden vi Ăžnsker Ă„ ha det installert i Kubernetes i 100% av tilfellene. PĂ„ samme mĂ„te Ăžnsker vi Ă„ sĂžrge for at MongoDB alltid installeres i Kubernetes. Det dukker opp visse Ăžnsker â det fĂžles som man kan gjĂžre noe her. Men vi har ikke engang sett pĂ„ Postgres. Vi vet selvsagt om de ulike alternativene, men i praksis er vi pĂ„ standalone.
Database for testing i Kubernetes
NS: La oss gĂ„ videre til temaet testing. Hvordan rulle ut endringer i databasen â fra et DevOps-perspektiv. Det finnes mikrotjenester, mange databaser, og det endres hele tiden noe. Hvordan kan vi sĂžrge for en skikkelig CI/CD slik at alt fungerer som det skal fra databasen sin side. Hva er din tilnĂŠrming?
DS: Det er ingen enkelt svar. Det finnes flere parametere. Den fÞrste er stÞrrelsen pÄ databasen vi Þnsker Ä rulle ut. Du nevnte selv at selskaper har ulike holdninger til om en kopi av produksjonsdatabasen skal vÊre i utvikling og staging.
NS: Og under GDPR tror jeg de blir mer og mer forsiktige⊠Jeg kan si at i Europa har de allerede begynt Ä ilegge bÞter.
DS: Men ofte kan man skrive programvare som lager et dump fra produksjon og obfuskerer det. Resultatet blir produksjonsdata (snapshot, dump, binĂŠr kopiâŠ), men de er anonymisert. I stedet kan det vĂŠre genereringsskripter: det kan vĂŠre fixtures eller bare et skript som genererer en stor database. Problemet er: hvor mye tid tar det Ă„ lage det grunnleggende bildet? Og hvor lang tid tar det Ă„ rulle det ut i den nĂždvendige omgivelsen?
Vi har kommet frem til en plan: hvis kunden har et sett med fixturedata (minimumsversjon av databasen), bruker vi dem som standard. Hvis det gjelder review-miljĂžer, nĂ„r vi har opprettet en gren og deployet en instans av applikasjonen â da ruller vi ut en liten database der. , nĂ„r vi fra produksjon tar en dump en gang om dagen (om natten) og bygger en Docker-container med PostgreSQL og MySQL basert pĂ„ disse innlastede dataene. Hvis vi mĂ„ sette opp databasen 50 ganger fra dette bildet, gjĂžres det ganske enkelt og raskt.
NS: Bare ved Ă„ kopiere?
DS: Dataene lagres rett i Docker-bildet. Det vil si at vi har et klart bilde, la oss si pÄ 100 Gb. Takket vÊre lagene i Docker kan vi raskt implementere dette bildet sÄ mange ganger vi trenger. Metoden er enkel, men fungerer ganske bra.
NS: SĂ„ nĂ„r du tester, endres det direkte inne i Docker, ikke sant? Copy-on-write inne i Docker â vi kaster det og starter pĂ„ nytt, alt er bra. Kult! Bruker du dette allerede?
DS: Ja, lenge.
NS: Vi driver med lignende ting. Men vi bruker ikke Docker sin copy-on-write, men et annet alternativ.
DS: Det er ikke generisk. Men Docker sin fungerer overalt.
NS: I teorien, ja. Men vi har ogsÄ moduler der, sÄ vi kan lage forskjellige moduler og jobbe med forskjellige filsystemer. Her er greia. Vi ser pÄ alt dette fra PostgreSQL-siden pÄ en annen mÄte. NÄ har jeg sett fra Docker-siden og sett at det fungerer for dere. Men hvis databasen er enorm, for eksempel 1 Tb, blir det langvarig: bÄde operasjoner om natten og Ä fÄ alt inn i Docker... Og hvis man skal putte 5 Tb i Docker... Eller er det greit?
DS: Hva gjĂžr det? Det er bare blobs, bare biter og bytes.
NS: Forskjellen er: gjĂžr dere det via dump og restore?
DS: Det er overhodet ikke nĂždvendig. Metoder for Ă„ generere dette bildet kan vĂŠre forskjellige.
NS: For noen kunder har vi gjort det slik at vi i stedet for Ă„ generere det grunnleggende bildet regelmessig, holder det stadig oppdatert. Det er i hovedsak en replika, men dataene hentes ikke direkte fra mesteren, men gjennom et arkiv. Et binĂŠrt arkiv, hvor WAL'ene lastes opp hver dag, der tas ogsĂ„ sikkerhetskopier⊠Disse WAL'ene sender deretter, med en liten forsinkelse (mest 1-2 sekunder) â til det grunnleggende bildet. Fra det kloner vi med hvilken som helst metode â nĂ„ bruker vi som standard ZFS.
DS: Men med ZFS er du begrenset til Ă©n node.
NS: Ja. Men ZFS har en magisk : med det kan du sende et snapshot og til og med (jeg har ikke testet dette sĂ„ mye, menâŠ) kan du sende endringene mellom to PGDATA. Faktisk har vi et annet verktĂžy som vi ikke har vurdert sĂ„ mye for slike oppgaver. I PostgreSQL finnes det , som fungerer som en «smart» rsync, og hopper over mye av det som ikke trenger Ă„ bli sett pĂ„, fordi det ikke har endret seg i det hele tatt. Vi kan gjĂžre en rask synkronisering mellom to servere og rulle tilbake pĂ„ samme mĂ„te.
SĂ„ vi prĂžver Ă„ lage et verktĂžy fra denne mer DBA-aktige siden som lar oss gjĂžre det samme som du snakket om: vi har Ă©n database, men vi vil teste noe 50 ganger, nesten samtidig.
DS: 50 ganger betyr at du trenger Ă„ bestille 50 Spot-instanser.
NS: Nei, vi gjÞr alt pÄ én maskin.
DS: Men hvordan skal du distribuere det 50 ganger, hvis denne ene databasen er for eksempel terabyte stor? Den trenger sannsynligvis omtrent 256 GB RAM?
NS: Ja, noen ganger trenger du mye minne â det er normalt. Men her er et eksempel fra virkeligheten. PĂ„ produksjonsmaskinen er det 96 kjerner og 600 GB. For databasen brukes 32 kjerner (noen ganger til og med 16 kjerner nĂ„) og 100-120 GB minne.
DS: FĂ„r du plass til 50 kopier der?
NS: Men kopien er én, sÄ kjÞringen skjer ved hjelp av copy-on-write (ZFS)... Jeg skal fortelle mer.
For eksempel, vi har en database pĂ„ 10 TB. Disken for den er laget, ZFS komprimerte stĂžrrelsen med 30-40 prosent. Siden vi ikke gjĂžr belastningstesting, er faktisk responstid ikke viktig for oss: hvis det er opptil 2 ganger tregere â det er greit.
Vi gir mulighet for programmerere, QA, DBA osv. Ă„ kjĂžre tester med 1-2 trĂ„der. For eksempel kan de kjĂžre en migrasjon. Den krever ikke umiddelbart 10 kjerner â den trenger 1 backend av Postgres, 1 kjerne. Migrasjonen vil starte â kanskje, den vil starte igjen, da blir den andre kjernen aktivert. Vi har avsatt 16-32 kjerner, sĂ„ 10 personer kan arbeide samtidig, det er ingen problemer.
Siden fysisk PGDATA er den samme, viser det seg at vi faktisk lurer Postgres. Poenget er: for eksempel starter vi 10 Postgres-er samtidig. Hva er vanligvis problemet? De setter , la oss si, til 25%. Dermed er det 200 GB. Mer enn tre slike kan du ikke starte fordi minnet vil ta slutt.
Men vi innsÄ pÄ et tidspunkt at det ikke var nÞdvendig: vi setter shared_buffers til 2 GB. PostgreSQL har en , og i virkeligheten pÄvirker bare den . Den setter vi til 0,5 TB. Og det er ikke engang viktig at de faktisk ikke er der: den bygger planer som om de er der.
NĂ„r vi tester en migrasjon, kan vi samle alle planene â vi vil se hvordan det vil skje i produksjon. Det vil ta litt lengre tid, men dataene vi faktisk leser og selve planene (som hvilke JOIN-er som brukes osv.) vil vĂŠre akkurat de samme som i produksjon. Samtidig kan vi kjĂžre mange slike sjekker pĂ„ Ă©n maskin.
DS: Mener du ikke at det her er flere problemer? Det fĂžrste â dette er en lĂžsning som kun fungerer pĂ„ PostgreSQL. En sĂ„nn tilnĂŠrming er veldig spesifikk, den er ikke generisk. Det andre â Kubernetes (og alt som nĂ„ skjer med skyteknologi) forutsetter mange noder, og disse nodene er flyktige. I ditt tilfelle er det en stateful, vedvarende node. Disse tingene gir meg motstridende fĂžlelser.
NS: Det fĂžrste â jeg er enig, dette er utelukkende en Postgres-historie. Jeg tror at hvis vi har noe direkte IO og et bufferpool som nesten tar all minne, vil ikke denne tilnĂŠrmingen fungere â planene vil vĂŠre annerledes. Men vi jobber kun med Postgres nĂ„, vi tenker ikke pĂ„ andre.
NÄr det gjelder Kubernetes. Du forteller jo selv overalt at vi har en vedvarende database. Hvis instansen faller, er det viktigste Ä bevare disken. VÄr plattform er ogsÄ i Kubernetes, og komponenten med Postgres er separat (selv om den en dag ogsÄ vil vÊre der). SÄnn er det: instansen har falt, men vi har bevart dens PV og bare koblet den til en annen (ny) instans, som om ingenting har skjedd.
DS: Etter min mening, oppretter vi pod-er i Kubernetes. K8s er fleksibel: nodene bestilles selv etter behov. Oppgaven er bare Ä opprette en pod og si hva den trenger av ressurser, sÄ ordner K8s resten selv. Men stÞtten for lagring i Kubernetes er fortsatt ustabil: i , i (denne utgaven kom ut uker siden) disse funksjonene blir bare beta.
Om seks mĂ„neder til et Ă„r â det vil bli mer eller mindre stabilt, eller i det minste erklĂŠrt som det. Da vil muligheten for snapshots og resizing allerede lĂžse oppgaven din helt. Fordi du har en database. Ja, den kan vĂŠre litt treg, men hastigheten avhenger av hva som er «under panseret», fordi noen implementeringer kan hĂ„ndtere kopiering og copy-on-write pĂ„ disknivĂ„.
NS: Her mĂ„ vi ogsĂ„ sĂžrge for at alle motorer (Amazon, GoogleâŠ) har begynt Ă„ stĂžtte denne versjonen â det tar jo ogsĂ„ litt tid.
DS: Vi bruker dem ikke ennÄ. Vi bruker vÄrt eget.
Lokal utvikling pÄ Kubernetes
NS: Har du noen gang stÞtt pÄ et scenario hvor du mÄ kjÞre alle pod'ene pÄ én maskin for Ä gjÞre en liten testing? For Ä raskt fÄ bevis pÄ konseptet og se at applikasjonen fungerer i Kubernetes, uten Ä bruke mange maskiner. Det finnes Minikube, ikke sant?
DS: Jeg mener, denne saken â Ă„ deploye pĂ„ Ă©n node â handler utelukkende om lokal utvikling. Eller noen manifestasjoner av dette mĂžnsteret. Det finnes , det finnes , . Vi gĂ„r mot Ă„ bruke Kubernetes IN Docker. Vi har akkurat begynt Ă„ jobbe med det for tester.
NS: Jeg trodde tidligere at det var et forsĂžk pĂ„ Ă„ pakke alle pod'ene inn i ett Docker-bilde. Men det viste seg Ă„ handle om noe helt annet. Der er det fortsatt separate containere, separate pod'er â bare innvendig i Docker.
DS: Ja. Og der er det laget en ganske morsom simulering, men poenget er slik ⊠Vi har et verktĂžy for deploy â . Vi Ăžnsker Ă„ lage en modus i den â la oss si werf up: «Sette opp en lokal Kubernetes for meg». Og deretter kjĂžre en bestemt werf follow. Da kan utvikleren gjĂžre endringer i IDE, mens det gĂ„r en prosess i systemet som ser endringene og bygger bildene pĂ„ nytt, deployer dem i lokal K8s. Det er slik vi Ăžnsker Ă„ forsĂžke Ă„ lĂžse problemet med lokal utvikling.
Snapshots og kloning av databaser i K8s
NS: Hvis vi vender tilbake til copy-on-write. Jeg har lagt merke til at skyene ogsĂ„ har snapshots. De fungerer forskjellig. For eksempel, i GCP: du har en multiterabyte-instans pĂ„ Ăžstkysten av USA. Du tar snapshots med jevne mellomrom. Du lĂžfter en kopi av disken fra snapshotet pĂ„ vestkysten â etter noen minutter er alt klart, det gĂ„r veldig raskt, bare cache mĂ„ fylles i minnet. Men disse klonene (snapshots) â de er for Ă„ 'provision' et nytt volum. Det er fantastisk nĂ„r du mĂ„ lage mange instanser.
For tester, synes jeg snapshots, som du snakker om i Docker eller som jeg nevner i ZFS, btrfs og til og med LVM ... â de lar deg nettopp unngĂ„ Ă„ lage reelle nye data pĂ„ Ă©n maskin. I skyen mĂ„ du ogsĂ„ betale for dem hver gang og vente ikke sekunder, men minutter (muligens timer i tilfelle ).
I stedet kan man fĂ„ disse dataene pĂ„ ett til to sekunder, kjĂžre testen og sĂ„ kaste dem. Disse snapshotene lĂžser forskjellige oppgaver. I det fĂžrste tilfellet â for Ă„ skalere opp og fĂ„ nye kopier, i det andre â for tester.
DS: Jeg er ikke enig. à gjÞre volumkloning skikkelig er en oppgave for skyen. Jeg har ikke sett implementeringen deres, men jeg vet hvordan vi gjÞr det pÄ maskinvaren vÄr. Vi har Ceph, hvor man kan si til ethvert fysisk volum () klon og fÄ et nytt volum med de samme egenskapene pÄ bare noen titalls millisekunder, og sÄ videre. Man mÄ forstÄ at det inni der er en smart copy-on-write. Hvorfor kan ikke skyen gjÞre det pÄ samme mÄte? Jeg er sikker pÄ at de pÄ en eller annen mÄte prÞver Ä fÄ det til.
NS: Men de vil fortsatt bruke sekunder, titalls sekunder, pÄ Ä starte opp en instans, sette opp Docker, osv.
DS: Hvorfor mĂ„ man nĂždvendigvis starte en hel instans? Vi har jo en instans med 32 kjerner, 16 kjerner⊠og den kan hĂ„ndtere en viss mengde â for eksempel fire. NĂ„r vi bestiller den femte, vil det allerede bli startet en instans, og sĂ„ vil den bli slettet.
NS: Ja, interessant, i Kubernetes er det en annen historie. Vi har ikke databasen i K8s, og bruker bare Ă©n instans. Men Ă„ klone en multi-terabyte database tar ikke mer enn to sekunder.
DS: Det er kult. Men mitt opprinnelige poeng er at dette ikke er et generisk lÞsningen. Ja, det er bra, men passer kun for Postgres og bare pÄ én node.
NS: Det er ikke bare for Postgres: disse planene, som jeg beskrev, vil fungere slik kun i det. Men hvis man ikke bryr seg om planer, og vi bare trenger alle dataene til funksjonell testing, da er det passende for enhver DBMS.
DS: For mange Ă„r siden gjorde vi noe lignende med LVM-snapshots. Det er klassisk. Denne tilnĂŠrmingen ble brukt veldig aktivt. Bare stateful-noder er et problem. Fordi de mĂ„ ikke krasje, man mĂ„ alltid huske pĂ„ demâŠ
NS: Ser du ikke her en mulighet for et hybridopplegg? La oss si, stateful er en pod, den fungerer for flere mennesker (mange testere). Vi har Ă©n volum, men takket vĂŠre filsystemet er klonene lokale. Hvis podden krasjer, blir disken vĂŠrende â podden blir gjenopprettet, tar informasjon om alle klonene, gjenoppretter alt og sier: «Her er klonene deres pĂ„ disse portene, fortsett Ă„ jobbe med dem».
DS: Teknisk sett betyr dette at innenfor Kubernetes er det Ă©n pod, der vi kjĂžrer mange Postgres-instanser.
NS: Ja. Den har en grense: la oss si, samtidig jobber ikke mer enn 10 personer med den. Hvis man trenger 20 â starter vi en ny slik pod. Det er helt mulig Ă„ klone den, og fĂ„ et fullt volum, hvor det vil vĂŠre ti «tynne» kloner av den. Ser du ikke muligheten her?
DS: Vi mÄ legge til sikkerhetsspÞrsmÄl her. Denne typen organisering innebÊrer at denne pod'en har hÞye privilegier (capabilities), ettersom den kan utfÞre ikke-standardoperasjoner pÄ filsystemet... Men jeg vil gjenta: jeg mener at Kubernetes vil fikse lagringsproblematikken pÄ mellomlang sikt, og skyene vil fikse hele historien med volumene - alt vil «bare fungere». Det vil vÊre resizing, kloning... Det er et volum - vi sier: «Lag en ny basert pÄ det», og etter ett og et halvt sekund fÄr vi det vi trenger.
NS: 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, pÄ EC2 gjÞr et klon av EBS-volumet pÄ mange terabyte og se hvilken ytelse det fÄr. Det vil ikke ta flere sekunder. Jeg er veldig interessert i nÄr de vil nÄ et slikt mÄl. Jeg forstÄr hva du snakker om, men jeg lar meg selv vÊre uenig.
DS: Ok, men jeg sa at pÄ mellomlang sikt, ikke kortsiktig. I lÞpet av noen Är.
Om operatoren for PostgreSQL fra Zalando
Midt i dette mÞtet koblet ogsÄ Alexey Klyukin seg til, en tidligere utvikler fra Zalando, som fortalte om historien til PostgreSQL-operatoren:
Det er flott at dette emnet i det hele tatt ble tatt opp: bÄde Postgres og Kubernetes. Da vi begynte Ä jobbe med det i Zalando i 2017, var dette et emne som alle ville jobbe med, men ingen gjorde det. Alle hadde allerede fÄtt Kubernetes, men nÄr de spurte hvordan de skulle hÄndtere databasene, var til og med folk som , som forkynte K8s, omtrent sa fÞlgende:
«GÄ til managed-tjenester og bruk dem, ikke kjÞr databaser i Kubernetes. Ellers vil K8s ditt for eksempel bestemme seg for Ä oppgradere, slukke alle noder, og dataene dine vil fly langt, langt bort».
Vi bestemte oss for Ä lage en operator som, til tross for dette rÄdet, ville kjÞre Postgres-databaser i Kubernetes. Og vi hadde et godt grunnlag - . Dette er automatisk failover for PostgreSQL, gjort riktig, dvs. ved hjelp av etcd, consul eller ZooKeeper som lagringsplass for informasjon om klyngen. Et slikt lager som vil gi alle som spÞr, for eksempel hvilken leder som nÄ er, den samme informasjonen - til tross for at alt er distribuert - for ikke Ä fÄ split brain. I tillegg hadde vi et for det.
Generelt kom behovet for auto failover i selskapet etter migreringen fra intern serverdatacenter til skyen. Skyen var basert pÄ en egenutviklet PaaS-lÞsning (Platform-as-a-Service). Den er Open Source, men for Ä sette den opp, mÄtte man jobbe hardt. Den ble kalt .
Opprinnelig fantes det ingen Kubernetes. Mer presist, da den egenutviklede lĂžsningen ble satt opp, var K8s allerede til stede, men sĂ„ uferdig at den ikke var egnet for produksjon. Det var, om jeg ikke tar feil, 2015 eller 2016. Innen 2017 hadde Kubernetes blitt relativt modent â det oppsto et 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 en egen operator? Murat Kabilov, som kom til oss fra Avito, startet dette som et prosjekt pĂ„ egenhĂ„nd â for Ă„ 'lekke', â og prosjektet 'flĂžy'.
Men jeg Ăžnsket egentlig Ă„ fortelle om AWS. Hvorfor det historisk var kode knyttet til AWS...
NĂ„r du kjĂžrer noe i Kubernetes, mĂ„ du forstĂ„ at K8s er et work in progress. Det utvikles stadig, forbedres og noen ganger til og med bryter ned. Man mĂ„ fĂžlge med pĂ„ alle endringer i Kubernetes, vĂŠre klar til Ă„ dykke ned i det om nĂždvendig og finne ut hvordan det fungerer i detalj â kanskje mer enn du Ăžnsket. Dette gjelder generelt for enhver plattform der du kjĂžrer databasene dine...
SĂ„, da vi laget operatoren, hadde vi Postgres som jobbet med en ekstern volum (i dette tilfellet â EBS, siden vi jobbet i AWS). Databasen vokste, og pĂ„ et tidspunkt ble det nĂždvendig Ă„ gjĂžre en resize: for eksempel, den opprinnelige stĂžrrelsen pĂ„ EBS var 100 TB, databasen vokste til denne stĂžrrelsen, nĂ„ vil vi gjĂžre EBS til 200 TB. Hvordan? La oss si at man kan lage dump/restore til en ny instans, men det er tidkrevende og med nedetid.
Derfor Þnsket vi en resize som ville Þke EBS-partisjonen og deretter si til filsystemet Ä bruke det nye rommet. Og vi fikk det til, men pÄ den tiden hadde ikke Kubernetes noen API for resize-operasjonen. Siden vi jobbet pÄ AWS, skrev vi kode for dets API.
Ingen hindrer Ă„ gjĂžre det samme for andre plattformer. I operatoren er det ingen binding som sier at den kun kan kjĂžres pĂ„ AWS, og at den ikke vil fungere pĂ„ alt annet. Generelt er dette et Open Source-prosjekt: hvis noen Ăžnsker Ă„ forkorte introduksjonen av den nye API-en â vĂŠr sĂ„ god. , pull-forespĂžrslene â Zalando-teamet forsĂžker ganske raskt Ă„ reagere pĂ„ dem og fremme operatĂžren. SĂ„ vidt jeg vet, deltok prosjektet Google Summer of Code og andre lignende initiativer. Zalando jobber veldig aktivt med det.
P.S. Bonus!
Hvis du er interessert i temaet PostgreSQL og Kubernetes, vil vi ogsÄ henlede oppmerksomheten pÄ at forrige uke ble den neste Postgres-tirsdagen holdt, hvor Nikolai snakket med Alexander Kukushkin fra Zalando. Videoen er tilgjengelig .
P.P.S.
Also read in our blog:
- «»;
- «»;
- «»;
- «».
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish