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
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish