I slutningen af sidste år fandt endnu en live-udsendelse af det russiske PostgreSQL-fællesskab sted , hvor dets medstifter Nikolai Samokhvalov talte med Flants tekniske direktør Dmitry Stolyarov om dette DBMS i forbindelse med Kubernetes.
Vi udgiver et udskrift af hoveddelen af denne diskussion, og kl Fuld video lagt ud:
Databaser og Kubernetes
NS: Vi vil ikke tale om VACUUM og CHECKPOINT i dag. Vi vil gerne tale om Kubernetes. Jeg ved, du har mange års erfaring. Jeg så dine videoer og så endda nogle af dem igen... Lad os komme direkte til sagen: hvorfor Postgres eller MySQL i K8s overhovedet?
DS: Der er ikke og kan ikke være et entydigt svar på dette spørgsmål. Men generelt er dette enkelhed og bekvemmelighed... potentiale. Alle vil have administrerede tjenester.
NS: Til hvordan , kun derhjemme?
DS: Ja: ligesom RDS, hvor som helst.
NS: "Anywhere" er en god pointe. I store virksomheder er alt placeret forskellige steder. Hvorfor så, hvis det er en stor virksomhed, ikke tage en færdig løsning? For eksempel har Nutanix sin egen udvikling, andre virksomheder (VMware...) har den samme "RDS, kun derhjemme."
DS: Men vi taler om en separat implementering, der kun vil fungere under visse betingelser. Og hvis vi taler om Kubernetes, så er der en enorm variation af infrastruktur (som kan være i K8s). Dette er i bund og grund en standard for API'er til skyen...
NS: Det er også gratis!
DS: Det er ikke så vigtigt. Frihed er vigtig for ikke et meget stort segment af markedet. Noget andet er vigtigt... Du husker sikkert rapporten “"?
NS: Ja.
DS: Jeg indså, at det blev modtaget meget tvetydigt. Nogle mennesker troede, at jeg sagde: "Gunner, lad os få alle databaserne ind i Kubernetes!", mens andre besluttede, at det alle var forfærdelige cykler. Men jeg ville sige noget helt andet: ”Se, hvad der sker, hvilke problemer der er, og hvordan de kan løses. Skal vi bruge Kubernetes-databaser nu? Produktion? Nå, kun hvis du kan lide...at gøre visse ting. Men for en udvikler kan jeg sige, at jeg anbefaler det. For en udvikler er dynamikken i at skabe/slette miljøer meget vigtig."
NS: Med dev, mener du alle miljøer, der ikke er prod? Iscenesættelse, QA...
DS: Hvis vi taler om perf stande, så nok ikke, fordi kravene der er specifikke. Hvis vi taler om særlige tilfælde, hvor der er behov for en meget stor database til iscenesættelse, så nok ikke... Hvis dette er et statisk, langlivet miljø, hvad er så fordelen ved at have databasen placeret i K8s?
NS: Ingen. Men hvor ser vi statiske miljøer? Et statisk miljø vil blive forældet i morgen.
DS: Iscenesættelse kan være statisk. Vi har kunder...
NS: 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 meget cool sag! På iscenesættelse er der en produktdatabase, hvor der foretages ændringer. Og der er en knap: "rul ud til produktion". Disse ændringer - deltaer - tilføjes (det ser ud til, at de simpelthen er synkroniseret via API'en) i produktionen. Dette er en meget eksotisk mulighed.
NS: Jeg har set startups i dalen, der sidder i RDS eller endda i Heroku - det er historier fra 2-3 år siden - og de downloader dumpen til deres bærbare computer. For databasen er stadig kun på 80 GB, og der er plads på den bærbare. Så køber de ekstra diske til alle, så de har 3 databaser til at udføre forskellige udviklinger. Sådan foregår det også. Jeg så også, at de ikke er bange for at kopiere prod til iscenesættelse – det afhænger meget af virksomheden. Men jeg så også, at de er meget bange, og at de ofte ikke har tid og hænder nok. Men før vi går videre til dette emne, vil jeg gerne høre om Kubernetes. Forstår jeg rigtigt, at ingen er i prod endnu?
DS: Vi har små databaser i prod. Vi taler om mængder på snesevis af gigabyte og ikke-kritiske tjenester, som vi var for dovne til at lave replikaer til (og der er ikke et sådant behov). Og forudsat at der er normal opbevaring under Kubernetes. Denne database fungerede i en virtuel maskine - betinget i VMware oven på lagersystemet. Vi lagde den ind og nu kan vi overføre det fra maskine til maskine.
NS: Databaser af denne størrelse, op til 100 GB, kan rulles ud på få minutter på gode diske og et godt netværk, ikke? En hastighed på 1 GB i sekundet er ikke længere eksotisk.
DS: Ja, for lineær drift er dette ikke et problem.
NS: Okay, vi skal lige tænke på prod. Og hvis vi overvejer Kubernetes til ikke-prod-miljøer, hvad skal vi så gøre? Det ser jeg i Zalando , i Crunchy , der er nogle andre muligheder. Og der er - dette er vores gode ven Alvaro fra Spanien: Det, de gør, er i bund og grund ikke bare , og hele distributionen (), hvori de, udover Postgres selv, også besluttede at fylde en backup, Envoy proxy...
DS: Udsending for hvad? Balancerer Postgres trafik specifikt?
NS: Ja. Det vil sige, de ser det som: hvis du tager en Linux-distribution og -kerne, så er almindelig PostgreSQL kernen, og de vil lave en distribution, der vil være sky-venlig og køre på Kubernetes. De sammensætter komponenter (backups osv.) og fejlretter dem, så de fungerer godt.
DS: Meget sejt! I bund og grund er dette software til at skabe din egen administrerede Postgres.
NS: Linux-distributioner har evige problemer: hvordan laver man drivere, så al hardware er understøttet. Og de har den idé, at de skal arbejde i Kubernetes. Jeg ved, at i Zalando-operatøren så vi for nylig en forbindelse til AWS, og det er ikke længere særlig godt. Der burde ikke være en binding til en specifik infrastruktur - hvad er meningen så?
DS: Jeg ved ikke præcis, hvilken situation Zalando kom i, men i Kubernetes er lager nu lavet på en sådan måde, at det er umuligt at tage en diskbackup ved hjælp af en generisk metode. Senest i standard - i seneste version — vi gjorde snapshots muligt, men hvor er det implementeret? Helt ærligt, alt er stadig så råt... Vi prøver CSI oven på AWS, GCE, Azure, vSphere, men så snart du begynder at bruge det, kan du se, at det ikke er klar endnu.
NS: Derfor er vi nogle gange nødt til at stole på infrastruktur. Jeg tror, at dette stadig er et tidligt stadium - vokseværk. Spørgsmål: Hvilket råd vil du give til nybegyndere, der ønsker at prøve PgSQL i K8s? Hvilken operatør måske?
DS: Problemet er, at Postgres er 3% for os. Vi har også en meget stor liste over forskellige software i Kubernetes, jeg vil ikke engang liste alt. For eksempel Elasticsearch. Der er mange operatører: nogle udvikler sig aktivt, andre er ikke. Vi har udarbejdet krav til os selv, hvad der skal være i operatøren, så vi tager det seriøst. I en operatør specifikt til Kubernetes - ikke i en "operatør til at gøre noget under Amazons forhold"... Faktisk bruger vi ret bredt (= næsten alle klienter) en enkelt operatør - (vi vil snart offentliggøre en artikel om ham).
NS: Og heller ikke til MySQL? Jeg ved, at Percona... da de nu arbejder på MySQL, MongoDB og Postgres, bliver de nødt til at skabe en form for universel løsning: for alle databaser, for alle cloud-udbydere.
DS: Vi havde ikke tid til at se på operatørerne for MySQL. Det er ikke vores hovedfokus lige nu. MySQL fungerer fint i standalone. Hvorfor bruge en operatør, hvis du bare kan starte en database... Du kan starte en Docker-container med Postrges, eller du kan starte den på en enkel måde.
NS: Der var også et spørgsmål om dette. Ingen operatør overhovedet?
DS: Ja, 100 % af os har PostgreSQL kørende uden en operatør. Så langt så. Vi bruger aktivt operatøren til Prometheus og Redis. Vi har planer om at finde en operatør til Elasticsearch - det er den, der er mest "i brand", fordi vi vil installere den i Kubernetes i 100 % af tilfældene. Ligesom vi vil sikre, at MongoDB også altid er installeret i Kubernetes. Her dukker visse ønsker op - der er en følelse af, at der i disse tilfælde kan lade sig gøre noget. Og vi så ikke engang på Postgres. Selvfølgelig ved vi, at der er forskellige muligheder, men faktisk har vi en selvstændig.
DB til test i Kubernetes
NS: Lad os gå videre til emnet test. Sådan udrulles ændringer til databasen - fra et DevOps-perspektiv. Der er mikrotjenester, mange databaser, noget ændrer sig et eller andet sted hele tiden. Hvordan man sikrer normal CI/CD, så alt er i orden set fra DBMS perspektivet. Hvad er din tilgang?
DS: Der kan ikke være ét svar. Der er flere muligheder. Den første er størrelsen på den base, som vi vil rulle ud. Du nævnte selv, at virksomheder har forskellige holdninger til at have en kopi af prod-databasen på dev og scene.
NS: Og under betingelserne i GDPR tror jeg, at de er mere og mere forsigtige... Jeg kan sige, at i Europa er de allerede begyndt at pålægge bøder.
DS: Men ofte kan du skrive software, der tager et dump fra produktionen og slører det. Prod-data indhentes (snapshot, dump, binær kopi...), men det er anonymiseret. I stedet kan der være generationsscripts: disse kan være fixtures eller bare et script, der genererer en stor database. Problemet er: hvor lang tid tager det at skabe et basisbillede? Og hvor lang tid tager det at implementere det i det ønskede miljø?
Vi kom til en ordning: Hvis klienten har et fast datasæt (minimal version af databasen), så bruger vi dem som standard. Hvis vi taler om anmeldelsesmiljøer, da vi oprettede en filial, implementerede vi en instans af applikationen - vi ruller en lille database ud der. Men det blev godt , når vi tager et dump fra produktionen en gang om dagen (om natten) og bygger en Docker-container med PostgreSQL og MySQL med disse indlæste data baseret på det. Skal du udvide databasen 50 gange fra dette billede, gøres dette ganske enkelt og hurtigt.
NS: Ved simpel kopiering?
DS: Data gemmes direkte i Docker-billedet. De der. Vi har et færdigt billede, dog 100 GB. Takket være lag i Docker kan vi hurtigt implementere dette billede så mange gange, som vi har brug for. Metoden er dum, men den fungerer godt.
NS: Så, når du tester, ændres det lige inde i Docker, ikke? Kopier-på-skriv inde i Docker - smid det væk og gå igen, alt er i orden. Klasse! Og bruger du det allerede fuldt ud?
DS: I lang tid.
NS: Vi laver meget lignende ting. Kun vi bruger ikke Dockers copy-on-write, men en anden.
DS: Det er ikke generisk. Og Docker arbejder overalt.
NS: I teorien, ja. Men vi har også moduler der, du kan lave forskellige moduler og arbejde med forskellige filsystemer. Sikke et øjeblik her. Fra Postgres side ser vi anderledes på alt dette. Nu kiggede jeg fra Docker-siden og så, at alt fungerer for dig. Men hvis databasen er enorm, f.eks. 1 TB, så tager alt dette lang tid: operationer om natten, og at fylde alt i Docker... Og hvis 5 TB er fyldt i Docker... Eller er alt i orden?
DS: Hvad er forskellen: disse er blobs, bare bits og bytes.
NS: Forskellen er denne: gør du det gennem dump og gendannelse?
DS: Slet ikke nødvendigt. Metoderne til at generere dette billede kan være forskellige.
NS: For nogle kunder har vi gjort det sådan, at vi i stedet for regelmæssigt at generere et basisbillede konstant holder det opdateret. Det er i det væsentlige en replika, men det modtager data ikke direkte fra masteren, men gennem et arkiv. Et binært arkiv, hvor WAL'er downloades hver dag, hvor der tages backups... Disse WAL'er når derefter basisbilledet med en lille forsinkelse (bogstaveligt talt 1-2 sekunder). Vi kloner fra det på nogen måde - nu har vi ZFS som standard.
DS: Men med ZFS er du begrænset til én node.
NS: Ja. Men ZFS har også en magisk : med det kan du sende et snapshot og endda (jeg har ikke rigtig testet dette endnu, men...) du kan sende et delta mellem to PGDATA. Faktisk har vi et andet værktøj, som vi ikke rigtig har overvejet til sådanne opgaver. PostgreSQL har , som fungerer som en "smart" rsync, der springer meget af det, du ikke behøver at se, for intet har ændret sig der. Vi kan lave en hurtig synkronisering mellem de to servere og spole tilbage på samme måde.
Så fra denne, mere DBA-side, forsøger vi at skabe et værktøj, der giver os mulighed for at gøre det samme, som du sagde: vi har én database, men vi vil teste noget 50 gange, næsten samtidigt.
DS: 50 gange betyder, at du skal bestille 50 Spot-forekomster.
NS: Nej, vi laver alt på én maskine.
DS: Men hvordan vil du udvide 50 gange, hvis denne ene database er f.eks. terabyte. Mest sandsynligt har hun brug for en betinget 256 GB RAM?
NS: Ja, nogle gange har man brug for meget hukommelse – det er normalt. Men dette er et eksempel fra livet. Produktionsmaskinen har 96 kerner og 600 GB. Samtidig bruges 32 kerner (selv 16 kerner nu nogle gange) og 100-120 GB hukommelse til databasen.
DS: Og der passer 50 eksemplarer derinde?
NS: Så der er kun én kopi, så virker copy-on-write (ZFS)... Jeg fortæller dig mere detaljeret.
For eksempel har vi en 10 TB database. De lavede en disk til det, ZFS komprimerede også dens størrelse med 30-40 procent. Da vi ikke laver belastningstest, er den nøjagtige responstid ikke vigtig for os: lad den være op til 2 gange langsommere - det er okay.
Vi giver mulighed for programmører, QA, DBA mv. udføre test i 1-2 tråde. For eksempel kan de køre en form for migration. Det kræver ikke 10 kerner på én gang - det har brug for 1 Postgres backend, 1 kerne. Migrationen starter - måske vil stadig starte, så vil den anden kerne blive brugt. Vi har 16-32 kerner tildelt, så 10 personer kan arbejde på samme tid, ikke noget problem.
Fordi fysisk PGDATA det samme viser det sig, at vi faktisk snyder Postgres. Tricket er dette: for eksempel lanceres 10 Postgres samtidigt. Hvad er problemet normalt? De sætter , lad os sige 25 %. Derfor er dette 200 GB. Du vil ikke være i stand til at starte mere end tre af disse, fordi hukommelsen løber tør.
Men på et tidspunkt indså vi, at dette ikke var nødvendigt: vi satte shared_buffers til 2 GB. PostgreSQL har , og i virkeligheden er det den eneste, der påvirker . Vi satte den til 0,5 TB. Og det gør ikke engang noget, at de faktisk ikke eksisterer: han laver planer, som om de eksisterer.
Derfor, når vi tester en form for migration, kan vi samle alle planerne - vi vil se, hvordan det vil ske i produktionen. Sekunderne der vil være anderledes (langsommere), men de data, som vi rent faktisk læser, og selve planerne (hvilke JOINs er der osv.) bliver nøjagtig det samme som i produktionen. Og du kan køre mange sådanne kontroller parallelt på én maskine.
DS: Tror du ikke, der er et par problemer her? Den første er en løsning, der kun virker på PostgreSQL. Denne tilgang er meget privat, den er ikke generisk. Den anden er, at Kubernetes (og alt, hvad cloud-teknologier går til nu) involverer mange noder, og disse noder er flygtige. Og i dit tilfælde er det en tilstandsfuld, vedvarende node. Disse ting gør mig i konflikt.
NS: For det første er jeg enig, dette er en ren Postgres-historie. Jeg tror, at hvis vi har en form for direkte IO og en bufferpulje til næsten al hukommelsen, vil denne tilgang ikke fungere - planerne vil være anderledes. Men indtil videre arbejder vi kun med Postgres, vi tænker ikke på andre.
Om Kubernetes. Du fortæller selv overalt, at vi har en vedvarende database. Hvis instansen mislykkes, er det vigtigste at gemme disken. Her har vi også hele platformen i Kubernetes, og komponenten med Postgres er separat (selvom den vil være der en dag). Derfor er alt sådan her: instansen faldt, men vi gemte dens PV og tilsluttede den simpelthen til en anden (ny) instans, som om intet var hændt.
DS: Fra mit synspunkt opretter vi pods i Kubernetes. K8s - elastisk: knuder bestilles efter behov. Opgaven er simpelthen at oprette en pod og sige, at den har brug for X mængder af ressourcer, og så finder K8'ere ud af det på egen hånd. Men lagerunderstøttelse i Kubernetes er stadig ustabil: I (denne udgivelse blev udgivet af ugen siden) bliver disse funktioner kun beta.
Der går seks måneder til et år - det bliver mere eller mindre stabilt, eller det vil i det mindste blive erklæret som sådan. Så løser muligheden for snapshots og størrelsesændring dit problem fuldstændigt. Fordi du har en base. Ja, det er måske ikke særlig hurtigt, men hastigheden afhænger af, hvad der er "under motorhjelmen", fordi nogle implementeringer kan kopiere og kopiere-på-skrive på diskundersystemniveau.
NS: Det er også nødvendigt for alle motorer (Amazon, Google...) at begynde at understøtte denne version - det tager også noget tid.
DS: Vi bruger dem ikke endnu. Vi bruger vores.
Lokal udvikling for Kubernetes
NS: Er du stødt på sådan et ønske, når du skal installere alle pods på én maskine og lave sådan en lille test. For hurtigt at få et proof of concept, se, at applikationen kører i Kubernetes uden at dedikere en masse maskiner til det. Der er Minikube, ikke?
DS: Det forekommer mig, at denne case - indsat på én knude - udelukkende handler om lokal udvikling. Eller nogle manifestationer af et sådant mønster. Spise , Der er , . Vi bevæger os i retning af at bruge Kubernetes IN Docker. Nu begyndte vi at arbejde med det til test.
NS: Jeg plejede at tro, at dette var et forsøg på at pakke alle pods ind i et Docker-billede. Men det viste sig, at det her handler om noget helt andet. I hvert fald er der separate beholdere, separate pods - bare i Docker.
DS: Ja. Og der er lavet en ret sjov efterligning, men meningen er denne... Vi har et værktøj til implementering - . Vi ønsker at gøre det til en betinget tilstand werf up: "Få mig lokale Kubernetes." Og kør så den betingede der werf follow. Derefter vil udvikleren være i stand til at redigere IDE'en, og en proces vil blive lanceret i systemet, som ser ændringerne og genopbygger billederne og omdistribuerer dem til lokale K8'er. Sådan vil vi forsøge at løse problemet med lokal udvikling.
Snapshots og databasekloning i K8s virkelighed
NS: Hvis vi vender tilbage til copy-on-write. Jeg lagde mærke til, at skyerne også har snapshots. De arbejder forskelligt. For eksempel i GCP: du har en multi-terabyte-instans på østkysten af USA. Du tager snapshots med jævne mellemrum. Du henter en kopi af disken på vestkysten fra et øjebliksbillede - om få minutter er alt klar, det virker meget hurtigt, kun cachen skal udfyldes i hukommelsen. Men disse kloner (snapshots) er for at 'provisionere' et nyt bind. Det er fedt, når du skal oprette mange forekomster.
Men for test, forekommer det mig, at snapshots, som du taler om i Docker eller jeg taler om i ZFS, btrfs og endda LVM... - de tillader dig ikke at skabe rigtig nye data på én maskine. I skyen vil du stadig betale for dem hver gang og vente ikke sekunder, men minutter (og i tilfældet , muligvis et ur).
I stedet kan du få disse data på et sekund eller to, køre testen og smide dem væk. Disse snapshots løser forskellige problemer. I det første tilfælde - at skalere op og få nye replikaer, og i det andet - til test.
DS: Jeg er ikke enig. At få volumenkloning til at fungere korrekt er skyens opgave. Jeg har ikke set på deres implementering, men jeg ved, hvordan vi gør det på hardware. Vi har Ceph, det tillader enhver fysisk volumen () sige klone og få et andet bind med de samme karakteristika i titusvis af millisekunder, 'ami osv. Du skal forstå, at der er en vanskelig copy-on-write indeni. Hvorfor skulle skyen ikke gøre det samme? Jeg er sikker på, at de prøver at gøre det på den ene eller anden måde.
NS: Men det vil stadig tage dem sekunder, titusinder af sekunder at rejse en instans, bringe Docker dertil osv.
DS: Hvorfor er det nødvendigt at rejse en hel instans? Vi har en instans med 32 kerner, 16... og den kan passe ind i den - for eksempel fire. Når vi bestiller den femte, vil instansen allerede være rejst, og så slettes den.
NS: Ja, interessant, Kubernetes viser sig at være en anden historie. Vores database er ikke i K8s, og vi har én instans. Men at klone en multi-terabyte-database tager ikke mere end to sekunder.
DS: Dette er godt. Men min indledende pointe er, at dette ikke er en generisk løsning. Ja, det er fedt, men det er kun egnet til Postgres og kun på én node.
NS: Det er ikke kun egnet til Postgres: disse planer, som jeg beskrev, vil kun fungere i det. Men hvis vi ikke bekymrer os om planer, og vi bare skal bruge alle data til funktionel test, så er dette velegnet til enhver DBMS.
DS: For mange år siden lavede vi noget lignende på LVM-snapshots. Dette er en klassiker. Denne tilgang blev brugt meget aktivt. Stateful noder er bare en smerte. For du skal ikke tabe dem, du skal altid huske dem...
NS: Ser du nogen mulighed for en hybrid her? Lad os sige, at stateful er en slags pod, den virker for flere personer (mange testere). Vi har én bind, men takket være filsystemet er klonerne lokale. Hvis poden falder, men disken forbliver, vil poden rejse sig, tælle information om alle klonerne, samle alt op igen og sige: "Her kører dine kloner på disse porte, fortsæt med at arbejde med dem."
DS: Teknisk betyder det, at inden for Kubernetes er det én pod, inden for hvilken vi kører mange Postgres.
NS: Ja. Han har en grænse: Lad os sige, at der ikke er mere end 10 personer, der arbejder med ham på samme tid. Hvis du har brug for 20, lancerer vi en anden sådan pod. Vi vil klone det fuldt ud, efter at have modtaget det andet fulde volumen, vil det have de samme 10 "tynde" kloner. Ser du ikke denne mulighed?
DS: Vi skal tilføje sikkerhedsproblemer her. Denne type organisation indebærer, at denne pod har høje privilegier (kapaciteter), fordi den kan udføre ikke-standard operationer på filsystemet... Men jeg gentager: Jeg tror, at de på mellemlang sigt vil rette oplagring i Kubernetes, og i skyerne vil de ordne hele historien med bind - alt vil "bare fungere". Der vil være ændring af størrelse, kloning... Der er et volumen - vi siger: "Opret en ny baseret på det," og efter halvandet sekund får vi, hvad vi har brug for.
NS: Jeg tror ikke på halvandet sekund i mange terabyte. På Ceph gør du det selv, men du taler om skyerne. Gå til skyen, lav en klon af en multi-terabyte EBS-volumen på EC2 og se, hvad ydeevnen vil være. Det tager ikke et par sekunder. Jeg er meget interesseret i, hvornår de når dette niveau. Jeg forstår, hvad du siger, men jeg beder om at være anderledes.
DS: Ok, men jeg sagde på mellemlang sigt, ikke på kort sigt. For flere år.
Om operatøren for PostgreSQL fra Zalando
Midt under dette møde deltog Alexey Klyukin, en tidligere udvikler fra Zalando, også og talte om PostgreSQL-operatørens historie:
Det er dejligt, at dette emne bliver berørt generelt: både Postgres og Kubernetes. Da vi begyndte at lave det på Zalando i 2017, var det et emne, som alle gerne ville, men ingen gjorde. Alle havde allerede Kubernetes, men når de spurgte, hvad de skulle gøre med databaser, kunne selv folk godt lide , der prædikede K8s, sagde noget som dette:
"Gå til administrerede tjenester og brug dem, lad være med at køre databasen i Kubernetes. Ellers vil dine K8'ere beslutte sig for for eksempel at lave en opgradering, slukke for alle noder, og dine data vil flyve langt, langt væk."
Vi besluttede at lave en operatør, der i modsætning til dette råd vil lancere en Postgres-database i Kubernetes. Og vi havde en god grund - . Dette er en automatisk failover for PostgreSQL, udført korrekt, dvs. ved at bruge etcd, consul eller ZooKeeper som opbevaring af information om klyngen. Sådan et depot, der vil give alle, der for eksempel spørger, hvad den nuværende leder er, samme information - på trods af at vi har alt fordelt - så der ikke er en splittet hjerne. Plus vi havde For ham.
Generelt dukkede virksomhedens behov for automatisk failover op efter migrering fra et internt hardwaredatacenter til skyen. Skyen var baseret på en proprietær PaaS-løsning (Platform-as-a-Service). Det er Open Source, men det krævede meget arbejde at få det op at køre. Den blev kaldt .
I starten var der ingen Kubernetes. Mere præcist, da vores egen løsning blev implementeret, eksisterede K8s allerede, men den var så rå, at den ikke var egnet til produktion. Det var efter min mening 2015 eller 2016. I 2017 var Kubernetes blevet mere eller mindre modne - der var behov for at migrere dertil.
Og vi havde allerede en Docker-container. Der var en PaaS, der brugte Docker. Hvorfor ikke prøve K8s? Hvorfor ikke skrive din egen operatør? Murat Kabilov, som kom til os fra Avito, startede dette som et projekt på eget initiativ - "at spille" - og projektet "tog fart."
Men generelt ville jeg tale om AWS. Hvorfor var der historisk AWS-relateret kode...
Når du kører noget i Kubernetes, skal du forstå, at K8s er sådan et work in progress. Det udvikler sig konstant, forbedrer og går endda i stykker fra tid til anden. Du skal holde godt øje med alle ændringerne i Kubernetes, du skal være klar til at dykke ned i det, hvis der sker noget og lære, hvordan det fungerer i detaljer – måske mere end du kunne tænke dig. Dette gælder i princippet enhver platform, hvor du kører dine databaser...
Så da vi lavede erklæringen, havde vi Postgres kørende på en ekstern volumen (EBS i dette tilfælde, da vi arbejdede på AWS). Databasen voksede, på et tidspunkt var det nødvendigt at ændre størrelsen på den: for eksempel var den oprindelige størrelse af EBS 100 TB, databasen voksede til den, nu vil vi lave EBS 200 TB. Hvordan? Lad os sige, at du kan lave en dump/gendannelse på en ny instans, men dette vil tage lang tid og involvere nedetid.
Derfor ønskede jeg en ændring af størrelsen, der ville forstørre EBS-partitionen og derefter fortælle filsystemet at bruge den nye plads. Og vi gjorde det, men på det tidspunkt havde Kubernetes ikke nogen API til at ændre størrelsen. Siden vi arbejdede på AWS, skrev vi kode til dets API.
Ingen forhindrer dig i at gøre det samme for andre platforme. Der er ingen antydning i erklæringen om, at det kun kan køres på AWS, og det vil ikke fungere på alt andet. Generelt er dette et Open Source-projekt: hvis nogen ønsker at fremskynde fremkomsten af brugen af den nye API, er du velkommen. Spise , pull-anmodninger - Zalando-teamet forsøger at reagere på dem ret hurtigt og fremme operatøren. Så vidt jeg ved, projektet på Google Summer of Code og nogle andre lignende tiltag. Zalando arbejder meget aktivt på det.
PS bonus!
Hvis du er interesseret i emnet PostgreSQL og Kubernetes, så bemærk også, at den næste Postgres tirsdag fandt sted i sidste uge, hvor jeg talte med Nikolai Alexander Kukushkin fra Zalando. Video fra den er tilgængelig .
PPS
Læs også på vores blog:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com