Aan die einde van verlede jaar het nog 'n regstreekse uitsending van die Russiese PostgreSQL-gemeenskap plaasgevind , waarin sy mede-stigter Nikolai Samokhvalov met die tegniese direkteur van Flant Dmitry Stolyarov gepraat het oor hierdie DBMS in die konteks van Kubernetes.
Ons publiseer die transkripsie van die hoofgedeelte van hierdie bespreking, en aan Volledige video geplaas:
Databasisse en Kubernetes
NS: Ons praat nie vandag oor VAKUUM en KONTROLEPUNTE nie. Ons wil oor Kubernetes praat. Ek weet jy het baie jare se ondervinding. Ek het na jou video's gekyk en selfs 'n paar daarvan weer gekyk ... Kom ons kom reguit na die punt: hoekom het jy Postgres of MySQL in K8s nodig?
DS: Daar is geen ondubbelsinnige antwoord op hierdie vraag nie en kan nie wees nie. Maar in die algemeen is dit eenvoud en gerief ... potensiaal. Almal wil immers bestuurde dienste hê.
NS: Om van te hou , net by die huis?
DS: Ja: soos RDS, maar enige plek.
NS: "Enige plek" is 'n goeie punt. In groot maatskappye is alles op verskillende plekke geleë. En hoekom dan, as dit 'n groot maatskappy is, nie 'n klaargemaakte oplossing te neem nie? Byvoorbeeld, Nutanix het sy eie ontwikkelings, ander maatskappye (VMware ...) het dieselfde "RDS, net by die huis".
DS: Maar ons praat van 'n enkele implementering wat slegs onder sekere voorwaardes sal werk. En as ons van Kubernetes praat, dan is daar 'n groot verskeidenheid infrastruktuur (wat in K8's kan wees). Trouens, dit is die standaard vir API na die wolk ...
NS: Ook gratis!
DS: Dit is nie so belangrik nie. Gratis is nie belangrik vir 'n baie groot segment van die mark nie. Iets anders is belangrik ... Jy onthou seker die berig ""?
NS: Ja.
DS: Ek het besef dat dit baie dubbelsinnig waargeneem is. Sommige mense het gedink dat ek sê: "Ouens, kom ons gaan al die databasisse na Kubernetes!", terwyl ander besluit het dat dit almal verskriklike fietse is. Maar ek wou heeltemal iets anders sê: “Kyk wat gebeur, watter probleme bestaan en hoe dit opgelos kan word. Gaan nou basisse in Kubernetes? Produksie? Wel, net as jy daarvan hou om ... sekere dinge te doen. Maar vir dev kan ek sê dat ek dit aanbeveel. Vir ontwikkelaars is dinamiese omgewingskepping/-uitwissing baie belangrik.”
NS: Met dev bedoel jy alle omgewings wat nie prod is nie? Opvoering, QA...
DS: As ons van perf-stande praat, dan waarskynlik nie, want die vereistes daar is spesifiek. As ons praat van spesiale gevalle waar 'n baie groot databasis nodig is vir die opstel, dan waarskynlik ook nie ... As dit 'n statiese omgewing is, langlewende, wat is die voordeel daarvan om die databasis in K8s te hê?
NS: Geen. Maar waar sien ons statiese omgewings? ’n Statiese omgewing is môre reeds uitgedien.
DSA: Opstelling kan staties wees. Ons het kliënte...
NSA: Ja, ek het ook. Dit is 'n groot probleem as jy 'n 10 TB-basis en 200 GB-opstelling het ...
DS: Ek het 'n baie cool saak! Op die verhoog is daar 'n produksiebasis wat aangepas word. En 'n knoppie word verskaf: "rol uit na produksie". Hierdie veranderinge - deltas - word bygevoeg (dit blyk dat hulle eenvoudig via die API gesinchroniseer word) in produksie. Dit is 'n baie eksotiese opsie.
NS: Ek het beginondernemings in die Vallei gesien wat in RDS of selfs in Heroku sit - dit is stories van 2-3 jaar gelede - en hulle laai die storting af na hul skootrekenaar. Want die databasis is nog net 80 GB, en daar is spasie op die skootrekenaar. Dan koop hulle bykomende skywe vir almal, sodat hulle 3 basisse het om verskillende ontwikkelings uit te voer. Dit is hoe dit ook gebeur. Ek het ook gesien dat hulle nie bang is om prod na verhoog te kopieer nie – dit hang baie van die maatskappy af. Maar ek het ook gesien dat hulle baie bang was, en dat daar dikwels nie genoeg tyd en hande was nie. Maar voordat ons na hierdie onderwerp oorgaan, wil ek van Kubernetes hoor. Ek verstaan reg dat niemand dit nog in prod het nie?
DS: Ons het klein basisse in produksie. Ons praat van volumes van tientalle gigagrepe en nie-kritiese dienste waarvoor dit te lui was om replikas te maak (en daar is nie so 'n behoefte nie). En mits daar 'n normale berging onder Kubernetes is. Hierdie databasis het in 'n virtuele masjien gewerk - voorwaardelik in VMware, bo-op die bergingstelsel. Ons het dit ingesit en nou kan ons dit van kar na kar oorplaas.
NS: Databasisse van hierdie grootte, tot 100 GB, op goeie skywe en met 'n goeie netwerk kan binne 'n paar minute uitgerol word, reg? ’n Spoed van 1 GB per sekonde is nie meer eksoties nie.
DSA: Ja, vir lineêre werking is dit nie 'n probleem nie.
NS: Goed, ons moet net aan prod dink. En as ons Kubernetes vir nie-prod-omgewings oorweeg - hoe om dit te doen? Ek sien dit in Zalando , in Crunchy , daar is ander opsies. En daar is - dit is ons goeie vriend Alvaro van Spanje: hulle doen, in werklikheid, nie net nie , en die hele verspreidingskit (), waarin hulle, benewens Postgres self, ook besluit het om die rugsteun, die Envoy-instaanbediener ...
DS: Gesant waarvoor? Balanseer presies Postgres-verkeer?
NS: Ja. Dit wil sê, hulle sien dit as: as jy 'n Linux-verspreiding en 'n kern neem, dan is die gewone PostgreSQL die kern, en hulle wil 'n verspreiding maak wat wolkvriendelik sal wees en in Kubernetes draai. Hulle verbind komponente (rugsteun, ens.) en ontfout dit sodat dit goed werk.
DS: Baie koel! Trouens, dit is sagteware om jou eie bestuurde Postgres te maak.
NS: Linux-verspreidings het ewige probleme: hoe om drywers te maak sodat alle hardeware ondersteun word. En hulle het die idee dat hulle in Kubernetes sal werk. Ek weet dat ons onlangs in die Zalando-operateur 'n koppeling op AWS gesien het, en dit is nie meer baie goed nie. Daar moet nie 'n skakel na 'n spesifieke infrastruktuur wees nie - wat is die punt dan?
DS: Ek weet nie in watter situasie presies Zalando begin het nie, maar in Kubernetes word stoor nou op so 'n manier gemaak dat dit onmoontlik is om 'n skyfrugsteun op 'n generiese manier te verwyder. Onlangs in die standaard - in die nuutste weergawe - het die moontlikheid van foto's gemaak, maar waar word dit geïmplementeer? Eerlik, dit is nog steeds so rou... Ons probeer CSI bo-op AWS, GCE, Azure, vSphere, maar sodra jy dit begin gebruik, is dit duidelik dat dit nog nie gereed is nie.
NS: Daarom moet jy soms by die infrastruktuur betrokke raak. Ek dink dit is nog in die vroeë stadiums, groeiprobleme. V: Watter raad sal jy gee aan beginners wat PgSQL in K8's wil probeer? Watter operateur, miskien?
DS: Die probleem is dat Postgres vir ons 3% is. Ons het ook 'n baie groot lys van verskillende sagteware in Kubernetes, ek sal nie eers alles lys nie. Byvoorbeeld, elastiese soek. Daar is baie operateurs: sommige ontwikkel aktief, ander nie. Ons het vereistes vir onsself opgestel, wat in die operateur moet wees sodat ons hom ernstig opneem. In die operateur spesifiek vir Kubernetes - nie in die "operateur om iets te doen in Amazon se omstandighede" ... Trouens, ons gebruik nogal massief (= amper alle kliënte) 'n enkele operateur - (ons sal binnekort 'n artikel oor hom publiseer).
NS: Is dit nie ook vir MySQL nie? Ek weet dat Percona ... aangesien hulle nou besig is met MySQL, en MongoDB, en Postgres, sal hulle 'n soort universele lêer moet indien: vir alle databasisse, vir alle wolkverskaffers.
DS: Ons het nie tyd gehad om na die operateurs vir MySQL te kyk nie. Vir ons is dit nie nou die hooffokus nie. MySQL werk goed in selfstandige. Hoekom die operateur, as jy net die databasis kan begin ... Jy kan 'n Docker-houer met Postrges laat loop, of jy kan dit op 'n eenvoudige manier laat loop.
NS: Dit was ook 'n vraag. Sonder 'n operateur enigsins?
DS: Ja, in 100% het ons PostgreSQL wat sonder 'n operateur loop. So ver so. Ons gebruik aktief die operateur vir Prometheus, vir Redis. Ons het planne om 'n operateur vir Elasticsearch te vind - dit "brand" die meeste, want ons wil dit in 100% van die gevalle in Kubernetes installeer. Op dieselfde manier as wat ons by die punt wil kom waar MongoDB ook altyd in Kubernetes geïnstalleer is. Hier verskyn sekere wense - daar is 'n gevoel dat in hierdie gevalle iets gedoen kan word. Ons het nie eers na Postgres gekyk nie. Natuurlik weet ons van die bestaan van verskillende opsies, maar in werklikheid het ons selfstandige.
DB vir toetsing in Kubernetes
NS: Kom ons gaan oor na die onderwerp van toetsing. Hoe om veranderinge in die databasis uit te voer - vanuit die oogpunt van DevOps-perspektief. Daar is mikrodienste, baie databasisse, iets verander heeltyd iewers. Hoe om normale CI / CD te verseker, sodat alles in orde is vanaf die posisie van die DBMS. Wat is jou benadering?
DSA: Daar kan nie een antwoord wees nie. Daar is verskeie opsies. Die eerste is die grootte van die basis wat ons wil uitrol. U het self genoem dat maatskappye verskillende houdings het teenoor 'n kopie van die prod-basis op ontwikkelaar en verhoog.
NS: En onder die GDPR, ek dink hulle is meer en meer versigtig ... Ek kan sê dat hulle in Europa reeds begin boet.
DS: Maar jy kan dikwels sagteware skryf wat produksie stort en dit verduister. Jy kry prod se data (snapshot, dump, binêre kopie...), maar hulle is anoniem. In plaas daarvan kan daar generasie-skrifte wees: dit kan toebehore wees of net 'n skrif wat 'n groot basis genereer. Wat is die probleem: hoe lank neem dit om 'n basisbeeld te skep? En hoeveel tyd om dit op die regte omgewing te ontplooi?
Ons het tot 'n skema gekom: as die kliënt 'n wedstryddatastel het (die minimum weergawe van die databasis), gebruik ons dit by verstek. As ons praat oor hersieningsomgewings, toe ons 'n tak geskep het, het ons 'n geval van die toepassing ontplooi - ons is besig om 'n klein basis daar uit te rol. Maar goed gedoen en , wanneer ons een keer per dag (snags) 'n stortplek van produksie afhaal en 'n Docker-houer met PostgreSQL en MySQL saamstel wat daarop gebaseer is met hierdie gelaaide data. As jy die basis vanaf hierdie prent 50 keer moet uitbrei, word dit baie eenvoudig en vinnig gedoen.
NS: Eenvoudige kopie?
DS: Data word direk in die Docker-beeld gestoor. Dié. ons het 'n gereed beeld, laat dit 100 GB wees. Danksy lae in Docker kan ons hierdie prent vinnig ontplooi soveel keer as wat ons nodig het. Die metode is dom, maar dit werk goed.
NS: Verder, wanneer jy toets, verander dit reg binne Docker, reg? Kopieer-op-skryf binne Docker - gooi dit weg en gaan weer, alles is reg. Klas! En jy gebruik dit reeds met mag en hoof?
DS: Vir 'n lang tyd.
NS: Ons doen baie soortgelyke dinge. Net ons gebruik nie Docker se copy-on-write nie, maar 'n ander een.
DSA: Dit is nie generies nie. En Docker werk oral.
NS: In teorie, ja. Maar ons het ook modules daar, jy kan verskillende modules maak en met verskillende lêerstelsels werk. Hier is 'n oomblik. Van die Postgres-kant af kyk ons anders na dit alles. Nou het ek van die kant van Docker gekyk en gesien dat alles vir jou werk. Maar as die databasis groot is, byvoorbeeld 1 TB, dan is dit reeds 'n lang tyd: beide bedrywighede in die nag, en alles in Docker stoot ... En as 5 TB in Docker gedruk word ... Of is alles reg?
DS: Wat is die verskil: dit is blobs, net stukkies en grepe.
NS: Die verskil is dit: doen jy dit deur storting en herstel?
DS: Glad nie nodig nie. Daar is verskillende maniere om hierdie beeld te genereer.
NS: Vir sommige kliënte het ons dit so gemaak dat in plaas daarvan om gereeld 'n basisbeeld te genereer, ons dit voortdurend op datum hou. Dit is in wese 'n replika, maar dit ontvang data nie direk vanaf die meester nie, maar deur die argief. 'n Binêre argief waar WAL's elke dag gerol word, rugsteun daarheen geneem ... Hierdie WAL's bereik dan - met 'n effense vertraging (letterlik 1-2 sekondes) - tot by die basisbeeld. Ons kloon op enige manier daarvan - nou het ons ZFS by verstek.
DSA: Maar met ZFS is jy beperk tot een nodus.
NS: Ja. Maar ZFS het nog 'n magiese : jy kan 'n momentopname daarmee stuur, en selfs (ek het dit nog nie regtig getoets nie, maar ...) kan jy 'n delta tussen twee stuur PGDATA. Trouens, ons het nog 'n instrument wat ons nie regtig oorweeg het vir sulke take nie. PostgreSQL het , wat werk soos 'n "slim" rsync, slaan baie oor wat jy nie kan kyk nie, want niks het daar verander nie. Ons kan 'n vinnige sinchronisasie tussen twee bedieners maak en op dieselfde manier terugspoel.
So, van hierdie, meer DBA-kant, probeer ons om 'n instrument te maak wat jou toelaat om dieselfde ding te doen as waarvan jy gepraat het: ons het een databasis, maar ons wil iets 50 keer toets, amper gelyktydig.
DS: 50 keer beteken dat jy 50 Spot Instances moet bestel.
NS: Nee, ons doen alles op een masjien.
DS: Maar hoe ontplooi jy 50 keer as hierdie een basis byvoorbeeld 'n teragreep is. Heel waarskynlik het sy voorwaardelik 256 GB RAM nodig?
NS: Ja, soms het jy baie geheue nodig - dit is normaal. Maar so 'n voorbeeld uit die lewe. Die produksiemasjien het 96 kerne en 600 GB. Terselfdertyd word 32 kerne vir die databasis gebruik (selfs soms 16 kerne) en 100-120 GB geheue.
DS: En 50 kopieë pas daar in?
NS: Daar is dus net een kopie, dan werk copy-on-write (ZFS'ny) ... ek vertel jou meer.
Ons het byvoorbeeld 'n basis van 10 TB. Hulle het 'n skyf daarvoor gemaak, ZFS het ook die grootte daarvan met 30-40 persent saamgepers. Aangesien ons nie vragtoetse doen nie, is die presiese reaksietyd nie vir ons belangrik nie: laat dit tot 2 keer stadiger wees - dit is goed.
Ons stel programmeerders, QA, DBA, ens. voer toetsing in 1-2 drade uit. Hulle kan byvoorbeeld 'n soort migrasie uitvoer. Dit benodig nie 10 kerns gelyktydig nie - dit benodig 1 Postgres-agterkant, 1 kern. Migrasie sal begin - miskien begin steeds, dan word die tweede kern geaktiveer. Ons het 16-32 kerns toegewys, so 10 mense kan op dieselfde tyd werk, geen probleem nie.
Want fisies PGDATA dieselfde, dit blyk dat ons eintlik Postgres bedrieg. Die truuk is: dit begin byvoorbeeld 10 Postgres op dieselfde tyd. Wat is die probleem gewoonlik? Hulle sit Kom ons sê 25%. Gevolglik is dit 200 GB. Jy kan nie meer as drie hiervan laat loop nie, want die geheue sal opraak.
Maar op 'n stadium het ons besef dat dit nie nodig is nie: ons het shared_buffers op 2 GB gestel. PostgreSQL het , en in werklikheid raak dit net . Ons sit dit in 0,5 TB. En dit maak nie eers saak dat hulle nie regtig bestaan nie: hy maak planne asof dit is.
Gevolglik, wanneer ons 'n soort migrasie toets, kan ons al die planne versamel - ons sal sien hoe dit in produksie sal gebeur. Die sekondes daar sal anders wees (stadiger), maar die data wat ons werklik lees, en die planne self (watter soort JOINs, ens.) word presies dieselfde verkry as in produksie. En in parallel kan jy baie sulke kontroles op een masjien uitvoer.
DS: Dink jy nie hier is 'n paar probleme nie? Die eerste is 'n oplossing wat net op PostgreSQL werk. Hierdie benadering is baie privaat, dit is nie generies nie. Die tweede is Kubernetes (en alles wat wolktegnologieë nou gaan) behels baie nodusse, en hierdie nodusse is kortstondig. En in jou geval is dit 'n statige, aanhoudende nodus. Hierdie dinge weerspreek my.
NS: Eerstens - ek stem saam, hierdie is 'n suiwer Postgres-storie. Ek dink as ons 'n soort direkte IO en 'n bufferpoel vir byna al die geheue het, sal hierdie benadering nie werk nie - die planne sal anders wees. Maar vir nou werk ons net met Postgres, ons dink nie aan ander nie.
Oor Kubernetes. Jy vertel self oral dat ons 'n aanhoudende basis het. As die instansie neergestort het, is die belangrikste ding om die skyf te stoor. Hier het ons ook die hele platform in Kubernetes, en die komponent met Postgres is apart (hoewel dit eendag daar sal wees). Daarom is alles so: die instansie het geval, maar ons het sy PV gestoor en dit eenvoudig aan 'n ander (nuwe) instansie gekoppel, asof niks gebeur het nie.
DS: Uit my oogpunt skep ons peule in Kubernetes. K8s - rek: knope word bestel soos nodig. Die taak is om eenvoudig 'n peul te skep en te sê dat dit X hulpbronne benodig, en dan sal K8's dit uitvind. Maar bergingondersteuning in Kubernetes is steeds onstabiel: in In (hierdie vrystelling is uit van die week gelede) word hierdie kenmerke slegs beta.
Ses maande of 'n jaar sal verbygaan - dit sal min of meer stabiel word, of ten minste sal dit as sodanig verklaar word. Dan los die moontlikheid van foto's en grootteverandering reeds jou probleem heeltemal op. Want jy het 'n basis. Ja, dit is dalk nie baie vinnig nie, maar die spoed hang af van wat "onder die enjinkap" is, want sommige implementerings kan kopieer en kopieer-op-skryf op die skyfsubstelselvlak.
NS: Dit is ook onmiddellik nodig dat alle enjins (Amazon, Google ...) tyd het om hierdie weergawe te begin ondersteun - dit neem ook 'n geruime tyd.
DS: Terwyl ons dit nie gebruik nie. Ons gebruik ons s'n.
Plaaslike ontwikkeling vir Kubernetes
NS: Het jy al so 'n wenslys teëgekom wanneer jy al die peule op een masjien moet grootmaak en so 'n klein toets moet doen. Om vinnig 'n bewys van konsep te kry, sien dat die toepassing in Kubernetes loop sonder om 'n klomp masjiene daarvoor toe te ken. Daar is Minikube, reg?
DS: Dit lyk vir my of hierdie saak - ontplooi op een nodus - uitsluitlik oor plaaslike ontwikkeling gaan. Of een of ander manifestasie van so 'n patroon. Eet , eet , . Ons gaan na wat ons Kubernetes IN Docker sal gebruik. Nou het ons saam met hom begin werk vir toetse.
NS: Ek het vroeër gedink dat dit 'n poging is om alle peule in een Docker-beeld toe te draai. Maar dit het geblyk dat dit iets heeltemal anders is. In elk geval, daar is aparte houers, aparte peule - net in Docker.
DS: Ja. En daar is 'n nogal snaakse nabootsing gemaak, maar die betekenis is dit ... Ons het 'n ontplooiingshulpmiddel - . Ons wil 'n modus daarin maak - voorwaardelik werf up: "Kry vir my 'n plaaslike Kubernetes." En hardloop dan die voorwaardelike daar werf follow. Dan sal die ontwikkelaar in die IDE kan redigeer, en 'n proses loop in die stelsel wat die veranderinge sien en die beelde herbou, dit herontplooi na die plaaslike K8's. Dit is hoe ons die probleem van plaaslike ontwikkeling wil probeer oplos.
Foto's en databasiskloning in die realiteite van K8's
NS: As jy terugkeer na kopieer-op-skryf. Ek het opgemerk dat wolke ook kiekies het. Hulle werk anders. Byvoorbeeld, in GCP: jy het 'n multi-teragreep-instansie aan die Ooskus van die VSA. Maak periodieke foto's. Jy lig 'n kopie van die skyf aan die weskus van die momentopname af - oor 'n paar minute is alles gereed, dit werk baie vinnig, net die kas moet in die geheue gevul word. Maar hierdie klone (kiekies) is om 'n nuwe volume te 'voorsien'. Dit is gaaf as jy baie gevalle moet skep.
Maar vir toetse, lyk dit vir my, snapshots, waaroor jy in Docker praat of ek praat in ZFS, btrfs en selfs LVM ... - dit laat jou toe om nie werklik nuwe data op net een masjien te skep nie. In die wolk sal jy steeds elke keer daarvoor betaal en nie meer vir sekondes wag nie, maar vir minute (en in die geval moontlik ure).
In plaas daarvan kan jy hierdie data binne 'n sekonde of twee kry, die toets uitvoer en dit weggooi. Hierdie foto's los verskillende probleme op. In die eerste geval om op te skaal en nuwe replikas te kry, en in die tweede geval vir toetse.
DS: Ek stem nie saam nie. Die kloning van volumes is normaalweg die taak van die wolk. Ek het nie na die implementering daarvan gekyk nie, maar ek weet hoe ons dit op hardeware doen. Ons het Ceph, dit kan enige fisiese volume bevat () sê kloon en kry 'n tweede volume met dieselfde kenmerke in tien millisekondes, 'ami, ens. Jy moet verstaan dat daar 'n moeilike kopie-op-skryf binne is. Hoekom kan die wolk nie dieselfde doen nie? Ek is seker hulle probeer dit op een of ander manier doen.
NS: Maar dit sal hulle steeds sekondes, tientalle sekondes neem om die instansie te verhoog, Docker daarheen te bring, ens.
DS: Hoekom is dit nodig om 'n hele instansie te opper? Ons het 'n instansie vir 32 kerns, vir 16 ... en dit pas 'n bietjie - byvoorbeeld vier. Wanneer ons die vyfde een bestel, sal die instansie reeds styg, en dan sal dit uitgevee word.
NS: Ja, interessant genoeg, Kubernetes is 'n ander storie. Ons het 'n databasis wat nie in K8s is nie, en een geval. Maar die kloning van 'n multi-teragreep databasis neem nie meer as twee sekondes nie.
DS: Dit is wonderlik. Maar my aanvanklike boodskap is dat dit nie 'n generiese oplossing is nie. Ja, dit is gaaf, maar net geskik vir Postgres en net op een nodus.
NS: Dit is nie net geskik vir Postgres nie: hierdie planne, soos ek beskryf het, sal net daarin werk. Maar as ons nie steur aan planne nie, maar ons net al die data nodig het vir funksionele toetsing, dan is dit geskik vir enige DBBS.
DS: Baie jare gelede het ons dit op LVM-kiekies gedoen. Dit is 'n klassieke. Hierdie benadering is wyd gebruik. Dit is net dat statige nodusse 'n pyn is. Want hulle moet nie laat val word nie, altyd van hulle onthou word ...
NS: Sien jy nie een of ander hibriede moontlikheid hier nie? Kom ons sê stateful is 'n soort peul, dit werk vir verskeie mense (baie toetsers). Ons het een volume, maar danksy die lêerstelsel is die klone plaaslik. As die peul geval het, het die skyf gebly - die peul sal opstaan, inligting oor al die klone oorweeg, alles terugbring en sê: "Hier is jou klone wat op hierdie poorte loop, werk verder met hulle."
DS: Tegnies beteken dit dat dit binne Kubernetes een pod is, waarin ons baie Postgres bestuur.
NS: Ja. Hy het 'n beperking: kom ons sê nie meer as 10 mense werk gelyktydig saam met hom nie. As jy 20 nodig het, sal ons die tweede so 'n peul bekendstel. Ons kloon dit heeltemal, nadat ons die tweede volle volume ontvang het, sal dit dieselfde 10 "dun" klone hê. Sien jy nie so 'n geleentheid nie?
DS: Ons moet sekuriteitskwessies hier byvoeg. Hierdie organisasie-opsie impliseer dat hierdie pod hoë voorregte (vermoëns) het, omdat dit nie-standaard bewerkings op die lêerstelsel kan uitvoer ... Maar ek herhaal: ek glo dat Kubernetes op mediumtermyn berging sal regmaak, wolke sal die hele regmaak geskiedenis met boekdele Alles sal "net werk". Daar sal grootte verander, kloning ... Daar is 'n volume - ons sê: "Skep 'n nuwe een gebaseer op daardie een", - en binne 'n sekonde en 'n half kry ons wat ons nodig het.
NS: Ek glo nie in een en 'n half sekonde vir baie teragrepe nie. Op Ceph doen jy dit self, maar jy praat van wolke. Gaan na die wolk, maak op EC2 'n kloon van 'n EBS-volume van baie teragrepe en kyk wat die werkverrigting sal wees. Dit sal nie 'n paar sekondes neem nie. Ek stel baie belang in wanneer hulle hierdie vlak bereik. Ek verstaan waarvan jy praat, maar ek smeek om te verskil.
DSA: Ok, maar ek het gesê die medium termyn, nie die kort termyn nie. Vir etlike jare.
Oor operateur vir PostgreSQL deur Zalando
In die middel van hierdie vergadering het Alexey Klyukin, 'n voormalige ontwikkelaar van Zalando, ook aangesluit en oor die geskiedenis van die PostgreSQL-operateur gepraat:
Dit is wonderlik dat hierdie onderwerp oor die algemeen gedek word: beide Postgres en Kubernetes. Toe ons dit in 2017 by Zalando begin doen het, was dit ’n onderwerp wat almal wou doen, maar niemand het nie. Almal het reeds Kubernetes gehad, maar wanneer hulle gevra word wat om met databasisse te doen, hou selfs mense daarvan wat K8s gepreek het, het so iets gesê:
“Gaan na bestuurde dienste en gebruik dit, moenie 'n databasis in Kubernetes laat loop nie. Andersins sal jou K8's besluit om byvoorbeeld op te gradeer, al die nodusse uit te sit, en jou data sal ver, ver weg vlieg.
Ons het besluit om 'n operateur te maak wat, in teenstelling met hierdie advies, 'n Postgres-databasis in Kubernetes sal bestuur. En ons het 'n goeie grondslag gehad . Dit is 'n outomatiese failover vir PostgreSQL wat reg gedoen word, d.w.s. gebruik etcd, consul of ZooKeeper as 'n bewaarplek van inligting oor die groepering. So 'n berging wat vir almal wat byvoorbeeld vra wat nou die leier is, dieselfde inligting sal gee - ten spyte van die feit dat ons alles versprei het - sodat daar nie 'n gesplete brein is nie. Boonop het ons gehad vir hom.
Oor die algemeen het die behoefte aan outomatiese failover in die maatskappy verskyn ná die migrasie van die interne ysterdatasentrum na die wolk. Die wolk was gebaseer op sy eie PaaS (Platform-as-a-Service) oplossing. Dit is oopbron, maar dit het baie werk gekos om dit aan die gang te kry. Dit was genoem .
Aanvanklik was daar geen Kubernetes nie. Meer presies, toe hul eie oplossing ontplooi is, was K8s reeds daar, maar so rou dat dit nie geskik was vir produksie nie. Dit was na my mening 2015 of 2016. Teen 2017 het Kubernetes min of meer volwasse geword - daar was 'n behoefte om daarheen te migreer.
En ons het reeds 'n Docker-houer gehad. Daar was 'n PaaS wat Docker gebruik het. Hoekom nie K8's probeer nie? Hoekom skryf jy nie jou eie operateur nie? Murat Kabilov, wat van Avito na ons toe gekom het, het dit op eie inisiatief as ’n projek begin – “om te speel” – en die projek het “afgeskop”.
Maar oor die algemeen wou ek oor AWS praat. Hoekom was daar histories kode wat verband hou met AWS ...
Wanneer jy iets in Kubernetes bekendstel, moet jy verstaan dat K8s so aan die gang is. Dit ontwikkel voortdurend, verbeter en soms breek dit selfs af. Jy moet al die veranderinge in Kubernetes fyn dophou, jy moet gereed wees om daarin te duik ingeval iets gebeur en in detail leer hoe dit werk – dalk meer as wat jy sou wou hê. Dit is in beginsel vir enige platform waarop u u databasisse bestuur ...
So toe ons die verklaring gedoen het, het ons Postgres op 'n eksterne volume laat loop (in hierdie geval, EBS, aangesien ons op AWS gebruik het). Die databasis het gegroei, op 'n stadium was dit nodig om grootte te verander: byvoorbeeld, die aanvanklike grootte van EBS is 100 TB, die databasis het gegroei tot dit, nou wil ons EBS 200 TB maak. Hoe? Kom ons sê jy kan 'n storting / herstel na 'n nuwe instansie doen, maar dit is lank en stilstand.
Daarom wou ek 'n grootteverandering hê wat die EBS-partisie sou vergroot en dan die lêerstelsel sou vertel om die nuwe spasie te gebruik. En ons het, maar op daardie tydstip het Kubernetes geen API vir die grootteveranderingsbewerking gehad nie. Aangesien ons aan AWS gewerk het, het ons die kode vir sy API geskryf.
Niemand doen die moeite om dieselfde vir ander platforms te doen nie. Daar is geen skakel in die operateur dat dit slegs op AWS bekendgestel kan word nie, en dit sal nie op alles anders werk nie. Oor die algemeen is dit 'n oopbronprojek: as iemand die gebruik van die nuwe API wil bespoedig, is u welkom. Eet , trek versoeke - die Zalando-span probeer redelik vinnig daarop reageer en die operateur bevorder. Sover ek weet die projek in Google Summer of Code en 'n paar ander soortgelyke inisiatiewe. Zalando werk baie aktief daaraan.
PS Bonus!
As jy belangstel in die onderwerp van PostgreSQL en Kubernetes, dan gee ons ook aandag aan die feit dat die volgende Postgres Dinsdag verlede week plaasgevind het, waar ek met Nikolai gesels het Alexander Kukushkin van Zalando. Video daarvan is beskikbaar .
PPS
Lees ook op ons blog:
- «»;
- «»;
- «»;
- «".
Bron: will.com