🥇Postgres-teisipäev №5: «PostgreSQL ja Kubernetes. CI/CD. Testimise automatiseerimine»

Eelmisel aastal toimus taas otseülekanne Venemaa PostgreSQL-i kogukonnast #RuPostgres, mille raames rääkis selle kaasasutaja Nikolai Samohvalov Flanti tehnilise direktori Dmitri Stolyaroviga sellest andmebaasisüsteemist Kubernetes'i kontekstis.

Avaldame selle arutelu põhiosa stenogrammi ning kogukonna YouTube'i kanalil on avaldatud täielik videosalvestus:

Andmebaasid ja Kubernetes

НС: Täna ei räägi me VACUUM-ist ja CHECKPOINT'itest. Soovime rääkida Kubernetes'est. Ma tean, et sul on juba palju aastaid kogemusi. Olen vaadanud sinu videosid ja mõned neist isegi mitu korda… Alustame kohe: miks üldse Postgres või MySQL K8s-is?

ДС: Sellele küsimusele ei ole ühtegi kindlat vastust. Kuid üldiselt, see on lihtsus ja mugavus… potentsiaalsed. Kõigile meeldib managed-teenuseid saada.

НС: Kas nagu RDS, vaid enda juures?

ДС: Jah: et oleks nagu RDS, aga igal pool.

НС: "Igal pool" — see on hea märkuset. Suurtes ettevõtetes on kõik eraldi kohtades. Aga miks sel juhul, kui see on suur ettevõte, mitte võtta valmis lahendust? Näiteks Nutanix’il on oma arengud, teistel ettevõtetel (VMware…) on samuti "RDS, aga enda juures".

ДС: Kuid räägime me siiski üksikust rakendusest, mis töötab ainult kindlates tingimustes. Kui jutt on Kubernetes'est, siis siin on tohutu infrastruktuuri mitmekesisus (mis võib K8s-is olla). Sisuliselt on see standard pilve API-le...

НС: Ja veel tasuta!

ДС: See pole nii oluline. Tasuta on tähtis ainult väiksemale turusegmendile. Oluline on midagi muud… Sa kindlasti mäletad ettekannet "Andmebaasid ja Kubernetes»?

НС: Jah.

ДС: Ma sain aru, et seda võeti väga erinevalt. Osa inimesi arvas, et ma jään öelda: "Inimesed, lähme kõigi andmebaasidega Kubernetes'esse!", — ja teised leidsid, et see on kõik kohutav jalgratas. Kuid ma tahtsin öelda hoopis teistsugust: "Vaadake, mis toimub, milliseid probleeme on ja kuidas neid saab lahendada. Kas minna andmebaasidega Kubernetes'esse? Protsessis? No, ainult kui sa armastad… tegeleda teatud asjadega. Kuid arenguks – võin öelda, et soovitan. Arenguks on looduse loomine/erase või kustutamine väga oluline."

НС: Arengu all pead sa kõiki keskkondi, mis ei ole prod? Staging, QA...

ДС: Kui räägime perf-seintidest, siis tõenäoliselt mitte, kuna seal on spetsiifilised nõuded. Kui räägime erandjuhtudest, kus stagingus on väga suur andmebaas, siis ka tõenäoliselt mitte... Kui see on staatiline keskkond, mis elab kaua, siis milline on kasu, kui andmebaas asub K8s-is?

НС: Ei mingit. Aga kus me näeme staatilisi keskkondi? Staatiline keskkond on homme juba aegunud.

ДС: Staging võib olla staatiline. Meil on kliente...

НС: Jah, mul on ka. Suur probleem, kui sul on 10 TB andmebaas ja staging — 200 GB...

ДС: Mul on väga äge juhtum! Stagingus on tootmisandmebaas, kuhu tehakse muudatusi. Ja on nupp: „toota tootmisse”. Need muudatused — deltid — sünkroonitakse (näib, et lihtsalt API kaudu) tootmisse. See on väga eksootiline variant.

НС: Olen näinud startupe Silikoni orus, mis istuvad RDS-is või isegi Herokus — need on 2-3 aasta tagused lood — ja nad laadivad dumpi oma sülearvutisse. Sest andmebaas on alles 80 GB ja sülearvutis on ruumi. Siis ostavad nad igale ühele kõvakettaid, et kolme andmebaasi omada, et erinevaid arendusi teha. Nii ka juhtub. Olen näinud, et tootmist kopeeritakse stagingusse — see sõltub väga palju ettevõttest. Aga olen näinud ka, et kardetakse seda, ja et tihti ei ole aega ja käsi piisavalt. Aga enne, kui me selle teema juurde jõuame, tahaksin kuulda Kubernetese kohta. Kas ma mõistan õigesti, et tootmises pole hetkel kellelgi?

ДС: Meil on tootmises mõned väikesed andmebaasid. Räägime kümnete gigabaitide mahtudest ja mitte-kriitilistest teenustest, mille replikate tegemiseks oli laiskus (ja ei olnud ka sellist vajadust). Ja tingimusel, et Kubernetese all on normaalne salvestus. See andmebaas töötas virtuaalmasinas — tinglikult VMware'is, salvestusseadmest üle. Me panime selle PV ja nüüd saame seda masinast masinasse liigutada.

НС: Sellise suurusega, kuni 100 GB andmebaasid, headel ketastel ja hea võrgu korral saab eetrisse panna paarikümne minutiga, eks? Kiirus 1 GB sekundis — see ei ole enam eksootika.

ДС: Jah, lineaarse operatsiooni jaoks ei ole see probleem.

НС: Selge, tootmise kohta peame vaid mõtlema. Aga kui me kaalume Kuberneteset mitte-prod-keskkondade jaoks - kuidas seda teha? Näen, et Zalando teeb operaatorit, Crunchy arendab, on veel mõned variandid. Ja on OnGres — see on meie hea sõber Alvaro Hispaaniast: nad teevad mitte lihtsalt operaatorit, vaid tervet distributsiooni (StackGres), kuhu peale PostgreSQL’i tuleb veel varukoopia ja proxy Envoy...

ДС: Miks on vaja Envoy’d? Täpselt PostgreSQL’i liikluse tasakaalustamiseks?

НС: Jah. Nad näevad seda nii: kui võtta Linuxi distributiiv ja tuum, siis tavaline PostgreSQL on tuum, aga nad tahavad teha distributiivi, mis oleks pilvele sõbralik ja saaks Kuberneteses töötada. Nad siduvad komponente (varukoopiad jne) ja häälestavad, et need töötaksid hästi.

ДС: Tõeliselt äge! Sisuliselt on see tarkvara, et luua oma hallatud PostgreSQL.

НС: Linuxi distributiivide jaoks on igavene probleem: kuidas teha draivereid, et kogu riistvara oleks toetatud. Neil on idee, et nad töötavad Kuberneteses. Tean, et Zalando operaatoris nägime hiljuti seotust AWS-iga ja see ei ole just eriti hea. See ei tohiks sõltuda konkreetsest infrastruktuurist — siis milleks see on?

ДС: Ei tea, milles konkreetselt Zalando seondus, aga Kuberneteses on praegu nii, et salvestus on tehtud niimoodi, et ei saa üldiselt kettavarukoopiaid teha. Hiljuti viimases versioonis loodi standardile CSI, specifikatsioonide CSI — lisati võimalus snapshots’teks, aga kus see on rakendatud? Ausalt öeldes, see on ikka veel nii toores... Proovime CSI-d AWS, GCE, Azure, vSphere peal, aga kui hakkad kasutama, siis on kohe näha, et see ei ole veel valmis.

НС: Seetõttu on vahel kohustuslik sõltuda infrastruktuurist. Arvan, et see on ikka varases arenguetapis — kasvuprobleemid. Küsimus: mida sa soovitaksid algajatele, kes tahavad proovida PgSQL-i K8s-is? Milline operaator, võib-olla?

ДС: Probleem on selles, et Postgres on meie jaoks 3%. Meil on veel väga suur loetelu erinevast tarkvarast Kuberneteses, ei hakka isegi kõike üles lugema. Näiteks Elasticsearch. Operaatorite hulk on tohutu: mõned arenevad aktiivselt, teised mitte. Me oleme endale koostanud nõudmised, mis peaksid operaatoris olema, et me võtaksime seda tõsiselt. Just Kuberneteses mõeldud operaator — mitte «operaator, et teha midagi Amazoni tingimustes»... Tegelikult kasutame me piisavalt laialdaselt (= peaaegu kõigil klientidel) ainult ühte operaatorit — Redis’i jaoks (varsti avaldame ka artikli selle kohta).

НС: Aga MySQL-i jaoks pole ka? Tean, et Percona... kuna nad tegelevad nüüd nii MySQLi, MongoDB kui ka PostgreSQL-iga, peavad nad ju midagi universaalset välja töötama: kõigi andmebaaside jaoks, kõigi pilveteenuse pakkujate jaoks.

ДС: Me ei jõudnud vaadata MySQL operaatorite peale. Meie jaoks pole see praegu peamine fookus. MySQL töötab korralikult iseseisvalt. Miks operaator, kui saad lihtsalt andmebaasi käivitada… Sa saad käivitada Docker konteineri Postrgesiga, või saad selle käivitada lihtsalt.

НС: Sellest oli ka küsimus. Üldse ilma operaatorita?

ДС: Jah, meil on 100% PostgreSQL käivitunud ilma operaatorita. Praegu nii. Me kasutame operaatorit aktiivselt Prometheuse ja Redis'e jaoks. Meil on plaanis leida operaator Elasticsearch'i jaoks — see on kõige põletavam teema, kuna soovime seda 100% juhtudel Kubernetesesse paigaldada. Nii nagu soovime, et MongoDB oleks ka alati Kuberneteses. Siin tekivad kindlad soovid — on tunne, et nendes olukordades on midagi teha. PostgreSQL'i osas me isegi ei vaadanud. Loomulikult teame erinevate variantide olemasolust, aga tegelikult on meil iseseisev lahendus.

Andmebaas testimiseks Kuberneteses

НС: Liigume testimise teema juurde. Kuidas rakendada muudatusi andmebaasis — DevOps'i perspektiivist. On mikroteenused, palju andmebaase, pidevalt kuskil midagi muutub. Kuidas tagada normaalne CI/CD, et andmebaasi poolest oleks kõik korras. Mis on sinu lähenemine?

ДС: Ühte vastust ei saa olla. On mitu parameetrit. Esiteks, kui suur on andmebaas, mida soovime rakendada. Sa ise mainisid, et ettevõttes on erinevad lähenemised, kuidas prod-andmebaasi koopia olla dev- ja stage'is.

НС: GDPR-i tingimustes, ma arvan, nad on järjest ettevaatlikumad... Võin öelda, et Euroopas on juba alustanud trahvimist.

ДС: Aga sageli saab kirjutada tarkvara, mis teeb kopia tootmisest ja obfuskeerib selle. Tulemuseks on tootmisandmed (snapshood, dump, binaarne koopia...), kuid need on anonüümseks muutunud. Selle asemel võivad olla ka genereerimise skriptid: need võivad olla fikstuuri või lihtsalt skript, mis genereerib suure andmebaasi. Probleem on aga: kui palju aega kulub põhifoto loomisele? Ja kui palju aega kulub selle suure keskkonna peal paigutamiseks?

Oleme jõudnud skeemile: kui kliendil on fikstuuri andmekogum (minimaalne versioon andmebaasist), siis kasutame neid vaikimisi. Kui asi puudutab ülevaatekeskkondi, kui oleme loonud haru, meie rakenduse eksemplar käivitub — me paneme sinna väikese andmebaasi. Aga see tuli hästi välja ning variant, kui me production’ist öösel kord päevas varundame ja selle alusel loome Docker-konteineri PostgreSQL ja MySQL-iga nende laaditud andmete põhjal. Kui sellest kujundist tuleb 50 korda andmebaas välja arendada, siis seda on piisavalt lihtne ja kiire teha.

НС: Lihtsa kopeerimisega?

ДС: Andmed salvestatakse otse Docker-pildis. St meil on valmis pilt, olgu see 100 GB. Tänu Docker'i kihtidele saame seda pilti kiiresti vajalikul hulgal arendada. Meetod on primitiivne, kuid töötab hästi.

НС: Edasi, kui testite, siis see muutub otse Docker’is, eks? Copy-on-write Docker’is — viskame välja ja alustame uuesti, kõik on korras. Suurepärane! Ja te kasutate seda juba aktiivselt?

ДС: Juba pikka aega.

НС: Me tegeleme väga sarnaste asjadega. Ainult et me ei kasuta Docker’i copy-on-write’i, vaid midagi muud.

ДС: See ei ole generiline. Kuid Docker’i versioon töötab igal pool.

НС: Idee on küll nii. Kuid meil on seal ka moodulid, saab teha erinevaid mooduleid ja töötada erinevate failisüsteemidega. Siin on üks punkt. Me vaatame Postgres’i poolelt kogu sellele teisele moodi. Nüüd vaatasin Docker’i poolelt ja nägin, et teil on kõik toimib. Kuid kui andmebaas on väga suur, näiteks 1 TB, siis see juba võtab aega: nii öised operatsioonid kui ka kõik Docker’isse surumine… Aga kui 5 TB suruda Docker’isse… Või on kõik korras?

ДС: Mis vahet seal on: need on ju blob'id, lihtsalt bitid ja baitid.

НС: Vahe on selline: teete seda dump'i ja restore'iga?

ДС: Üldse ei pea. Selle pildi genereerimise meetodid võivad olla erinevad.

НС: Mõne kliendi jaoks oleme teinud nii, et selle asemel, et regulaarselt genereerida baaspilti, hoiame me seda pidevalt värskena. See on sisuliselt koopiana, kuid andmeid ei saadud otse meistrilt, vaid arhiivi kaudu. Binaarset arhiivi, kuhu WAL'id kantakse iga päev, seal tehakse ka varukoopiad… Need WAL'id jõuavad seejärel — väikese viivitusega (päris 1-2 sekundit) — baaspildini. Sellest kloonime me igasuguseid viise — praegu on meil vaikimisi ZFS.

ДС: Kuid ZFS-i puhul olete piiratud ühe sõlmega.

НС: Jah. Kuid ZFS-il on ka maagiline send: selle abil saab saata snapshots ja isegi (ma ei ole seda veel väga testinud, kuid…) saab edasi saata deltat kahe vahel PGDATA. Tegelikult on meil veel üks tööriist, mida me ei ole selliste ülesannete jaoks eriti vaadanud. PostgreSQL-is on pg_rewind, töötades nagu „nutikas” rsync, jättes vahele palju, mida pole vaja vaadata, sest seal pole tõeliselt midagi muutunud. Saame kahe serveri vahel kiiresti sünkroonida ja tagasi kerida täpselt samamoodi.

Nii et me püüame selle, DBA-poolsest, vaatenurgast luua tööriista, mis võimaldab teha seda, millest sa rääkisid: meil on üks andmebaas, kuid me tahame 50 korda midagi testida, peaagu samaaegselt.

ДС: 50 korda tähendab, et peate tellima 50 Spot instantsi.

НС: Ei, teeme kõik ühel masinal.

ДС: Aga kuidas te juurutate 50 korda, kui see üks andmebaas on, ütleme, terabaidi suurune? Tõenäoliselt vajab see umbes 256 GB RAM-i?

НС: Jah, mälu vajatakse mõnikord palju — see on normaalne. Kuid selline näide elust. Tootmismasinal on 96 tuuma ja 600 GB. Samas andmebaasi jaoks kasutatakse 32 tuuma (isegi 16 tuuma nüüd mõnikord) ja mälu 100-120 GB.

ДС: Kas sinna mahub 50 koopiat?

НС: Kuid koopiat on vaid üks, edasi töötab copy-on-write (ZFS-i)… Räägin lähemalt.

Meil on näiteks 10 TB andmebaas. Disk selle jaoks tehtud, ZFS veel tihendas selle suurust 30-40 protsendi võrra. Kuna me ei tee koormustestimist, ei ole meil täpset reageerimisaega oluline: olgu see kuni 2 korda aeglasem — see on okei.

Anname võimaluse programmeerijatele, QA-le, DBA-le jne. teha testimist 1-2 lõimes. Näiteks saavad nad käivitada mingi migreerimise. See ei vaja kohe 10 tuuma — talle piisab ühest Postgres'i taustast, 1 tuumast. Migratsioon käivitub — võib-olla, autovacuum käivitub veel, siis kasutatakse teist tuuma. Meil on eraldatud 16-32 tuuma, nii et 10 inimest saavad samal ajal töötada, probleeme pole.

Kuna füüsiliselt PGDATA on sama, selgub, et petame tegelikult Postgres’t. Küsimus on selles: käivitatakse näiteks 10 Postgres’i samal ajal. Milline probleem tavaliselt on? Seavad shared_buffers, oletame, 25% suuruseks. Seega on see 200 GB. Rohkem kui kolm sellist juba ei käivita, sest mälu lõpeb.

Aga mõnes hetkes mõistsime, et see ei ole vajalik: seame shared_buffers 2 GB peale. PostgreSQL-il on effective_cache_size, ja tegelikult mõjutab ainult see plaane. Seega seadistame selle 0,5 TB-ks. Ja isegi ei ole oluline, et neid tegelikult ei ole: ta koostab plaane, nagu need oleksid olemas.

Seega, kui me testime mingit migratsiooni, saame koguda kõik plaanid — me näeme, kuidas see toimub tootmises. Sekundid võivad olla teised (aeglasemad), kuid andmed, mida me reaalselt loeme, ja plaanid (millised JOIN'id ja sarnased) on samad nagu tootmises. Ja samal ajal saame käivitada palju selliseid kontrolle ühel masinal.

ДС: Kas sa ei arva, et siin on mõned probleemid? Esiteks — see lahendus töötab ainult PostgreSQL'is. Selline lähenemine on väga spetsiifiline, mitte üldine. Teiseks — Kubernetes (ja kõik, kuhu tänapäeval piloodid lähevad) eeldab palju sõlmi, ja need sõlmed on efemeersed. Ent sinu puhul on see stateful, püsiv sõlm. Need asjad tekitavad minus vastuolusid.

НС: Esiteks — olen nõus, see on puhtalt PostgreSQL'i lugu. Arvan, et kui meil on mingi otse IO ja vahemälu praktiliselt kogu mälule, siis see lähenemine ei sobi — plaanid oleksid teised. Aga me töötame praegu ainult PostgreSQL'iga, teistest ei mõtle.

Kubernetese kohta. Sa ise räägid, et meie andmebaas on püsiv. Kui instants kukub, on peamine säilitada ketas. Meie platvorm on samuti Kubernetesis, kuid PostgreSQL'i komponent on eraldi (kuigi ka see kunagi sinna tuleb). Seetõttu on asi nii: instants kukkus, kuid meie säilitasime selle PV ja lihtsalt ühendasime uue instantsi nagu poleks midagi juhtunud.

ДС: Minu vaatenurgast loome me pod'e Kubernetesis. K8s on elastne: sõlmed tellitakse vajadusel. Ülesanne on lihtsalt luua pod ja öelda, et talle on vajalik X ressursse, ja edasi tegeleb K8s ise. Kuid ladustuse tugi Kubernetesis on endiselt ebastabiilne: 1.16, in 1.17 (see versioon ilmus nädalat tagasi) need funktsioonid on alles beetaversioonis.

Aasta jooksul — see muutub enam-vähem stabiilseks või vähemalt nii väidetakse. Siis snapshotide ja resize'i võimalus lahendab teie probleemi täielikult. Sest teil on andmebaas. Jah, see ei pruugi olla väga kiire, kuid kiirus sõltub sellest, mis on 'kapoti all', seetõttu oskavad mõned teostused kopeerimist ja copy-on-write'i diskisüsteemi tasemel.

НС: Siin peab ka olema, et kõik mootorid (Amazon, Google…) oleksid suutnud hakata seda versiooni toetama — see võtab samuti aega.

ДС: Seni me neid ei kasuta. Me kasutame oma.

Kohalik arendus Kubernetese all

НС: Kas oled kunagi kokku puutunud sooviga, et ühe masina peal tõsta kõik pod'id ja teha väikest testimist. Et kiirelt saada kontseptsiooni tõestust, vaadata, kuidas rakendus Kuberneteses töötab, eraldamata selleks hulk masinaid. On olemas Minikube, eks?

ДС: Tundub, et see juhtum — ühel sõlmel käivitamine — on puhtalt kohalike arenduste jaoks. Või mingid sellised ilmingud. On Minikube, on k3s, KIND. Me liigume suunas, et hakkame Kuberneteset Dockeris kasutama. Oleme nüüd hakanud sellega testimiseks töötama.

НС: Ma arvasin varem, et see on katse panna kõik pod'id ühte Docker'i pilti. Kuid selgus, et see on midagi hoopis muud. Seal on endiselt eraldi konteinerid, eraldi pod'id — lihtsalt Docker'is.

ДС: Jah. Seal on päris naljakas imitatsioon, aga idee on selline... Meil on deployment'i utiliit — werf. Taha, et teeksime seal režiimi — ütleme, werf up: "Tõsta mulle kohalik Kubernetes üles". Ja seejärel käivitada seal tingimuslik werf follow. Siis saab arendaja IDE's redigeerida, ja süsteemis töötab protsess, mis näeb muudatusi ja ehitab pildid uuesti ning deponeerib need kohalikku K8s-i. Nii soovime proovida lahendada kohaliku arenduse probleemi.

Snapshotid ja andmebaasi kloonimine K8s-i tingimustes

НС: Kui rääkida copy-on-write’st. Olen märkand, et ka pilvedel on snapshotid. Need töötavad erinevalt. Näiteks GCP: Sul on USA idas rikka terabaidi instants. Teed perioodiliselt snapshot'e. Tõstad snapshot'ist koopia ketast lääne rannikule — paar minuti pärast on kõik valmis, töötab väga kiiresti, ainult vahemälu tuleb mälu täita. Kuid need kloonid (snapshot'id) — on selleks, et „provision’ida“ uus maht. See on äge, kui on vaja palju instantsse luua.

Aga testide jaoks tundub, et snapshotid, millest sa räägid Docker'is või millest mina räägin ZFS-is, btrfs-is ja isegi LVM-is… — need võimaldavad tõesti ühel masinal anda uued andmed. Pilves pead sa nende eest maksma ja pead ootama mitte sekundeid, vaid minuteid (ja juhul, kui lazy load’i, võib-olla isegi tunde).

Selle asemel saad sekundi-kahega need andmed, jookse test läbi ja viska need minema. Need snapshotid lahendavad erinevaid ülesandeid. Esimesel juhul — et skaleerida ja saada uusi replikaate, teisel — testideks.

ДС: Ma ei nõustu. Hästi toimiva mahutite kloonimise tegemine on pilve ülesanne. Ma ei ole nende teostust vaadanud, aga tean, kuidas me seda riistvaral teeme. Meil on Ceph, milles võib igale füüsilisele mahutile (RBD) öelda clone ja saada mõne kümne millisekundi jooksul teine maht sama iseloomuga, IOPSjne. Tuleb mõista, et seal sees on keeruline copy-on-write. Miks pilv ei üritada samasugust lahendust teha? Olen kindel, et nad üritavad seda kuidagi saavutada.

НС: Kuid neil lähevad ikkagi sekundid, kümned sekundid, et instants üles tõsta, Docker sinna tuua jne.

ДС: Miks peab tingimata üles tõstma terve instantsi? Meil on ju instants 32 tuuma, 16... ja sellesse mahub teatud arv — näiteks neli. Kui tellime viienda, siis tõuseb instants ja siis kustutatakse see.

НС: Jah, huvitav, Kuberneteses on lugu teistsugune. Meie andmebaas ei ole K8s-is ja meil on üks instants. Kuid mitme terabaidi andmebaasi kloonimiseks kulub mitte rohkem kui kaks sekundit.

ДС: See on äge. Aga minu algne mõte on see, et see ei ole üldine lahendus. Jah, see on kaunis, kuid sobib ainult Postgres’ile ja ainult ühes sõlmest.

НС: See sobib mitte ainult Postgres’ile: need plaanid, nagu ma kirjeldasin, töötavad nii ainult seal. Kuid kui plaanide pärast ei muretse, vaid vajame lihtsalt kõiki andmeid funktsionaalseks testimiseks, siis sobib see iga andmebaassi jaoks.

ДС: Palju aastaid tagasi tegime sarnast LVM-snapšottidega. See on klassika. Sellist lähenemist kasutati väga aktiivselt. Lihtsalt stateful sõlmed — see on valu. Sest neid ei tohi kukutada, neist tuleb alati meeles pidada...

НС: Kas sa ei näe siin mingit hübriidi võimalust? Oletame, et stateful on mingi pod, see töötab mitme inimese peal (palju testijaid). Meil on üks maht, aga tänu failisüsteemile on kloonid — kohalikes. Kui pod kukub, jääb kettale järgi — pod tõuseb üles, loeb kõigi kloonide teavet, tõstab kõik tagasi ja ütleb: „Siin on teie kloonid nende portides, töötage nendega edasi.”

ДС: Tehniliselt tähendab see, et Kuberneteses on see üks pod, mille sees käitame mitut Postgres’i.

НС: Jah. Tal on piir: oletame, et samal ajal töötavad temaga mitte rohkem kui 10 inimest. Kui on vaja 20 — käivitame teise sellise podi. Täiesti on võimalik, et kloonime selle, saades teise täis mahu, millel on samad 10 „õhukest” klooni. Kas sa ei näe sellist võimalust?

ДС: Siin tuleb lisada turvaküsimused. Tüüporganisatsiooni puhul eeldatakse, et sellel pod’il on suured priviliegid (capabilities), kuna see võib faili süsteemis teha mittestandardseid toiminguid... Aga siiski, ma usun, et keskpikas perspektiivis parandatakse Kubernetes storage'i, pilvedes tehakse kõik volüümide ajalugu korda – kõik töötab lihtsalt. Olemas on resize, kloonimine... On maht - ütleme: „Loo uus selle põhjal” - ja poolteise sekundi pärast saame, mida vajame.

НС: Ma ei usu, et paljude terabaitide puhul on poolteist sekundit võimalik. Cephis teed ise, aga räägid pilvedest. Mine pilve, tee EC2-s kloon EBS mahust paljude terabaitide ulatuses ja vaata, milliseks jõudluseks see muutub. See ei kesta paar sekundit. Mind huvitab, millal nad sellise tasemeni jõuavad. Ma saan aru, millisest sa räägid, aga luban endal mitte nõustuda.

ДС: Okei, aga ma ütlesin, et keskpikas perspektiivis, mitte lühikese. Paari aasta jooksul.

Zalando PostgreSQL operaatori kohta

Selle kohtumise keskpaiku liitus temaga ka Aleksei Kljukin, endine arendaja Zalando’st, kes rääkis PostgreSQL operaatori ajaloost:

Hea, et see teema üldse üles kerkis: nii Postgres kui Kubernetes. Kui me alustasime selle loomist Zalando's 2017. aastal, oli see teema, mille eest kõik soovisid tegeleda, kuid keegi ei teinud. Kõigil hakkas Kubernetes tekkima, aga kui küsiti, kuidas andmebaasidega olla, siis isegi sellised inimesed nagu Kelsey Hightower, kes propageerisid K8s-i, ütlesid umbes järgmist:
„Minge haldusteenustele ja kasutage neid, ärge käitage DB-d Kuberneteses. Muul juhul otsustab teie K8s näiteks teha uuenduse, sulgeb kõik sõlmed ja teie andmed lähevad kaugele- kaugele.”
Me otsustasime teha operaatori, mis vastupidiselt sellele nõuandele käivitab PostgreSQL andmebaasi Kuberneteses. Ja meil oli hea alus - Patronit. See on automaatne failover PostgreSQL jaoks, mis on õigesti tehtud, st kasutades etcd, consul või ZooKeeper’t klastrite info hoidmiseks. Selline salvestus, mis jagab kõigile, kes küsivad, näiteks, kes on praegu juht, sama teavet - sõltumata sellest, et meil on kõik jaotatud - et split brain’i ei tekiks. Pluss, meil oli Docker-ima selle jaoks.
Tegelikult tekkis vajadus auto failover'i järele ettevõttel pärast sisemise riistvara andmekeskusest pilve üleminekut. Pilv põhines enda PaaS (Platform-as-a-Service) lahendusel. See oli avatud allikaga, kuid selle ülesseadmisega tuli kõvasti vaeva näha. Selle nimi oli STUPS.
Alguses ei olnud mingeid Kubernetes'e. Tegelikult, kui oma lahendust üles seati, oli K8s juba olemas, kuid see oli nii toores, et produktsiooniks ei sobinud. See oli minu arvates 2015. või 2016. aasta. 2017. aastaks oli Kubernetes enam-vähem küps — tekkis vajadus migratsiooni järele sinna.
Ja meil oli juba Docker-konteiner. Oli PaaS, mis kasutas Dockerit. Miks mitte proovida K8s? Miks mitte kirjutada oma operaator? Murat Kabilov, kes tuli meie juurde Avitost, alustas seda projekti isikliku algatuse põhjal — "mängimiseks" — ja projekt "lendas".
Aga tegelikult tahtsin ma rääkida AWS-ist. Miks seal oli ajalooliselt kood, mis oli seotud AWS-iga…
Kui te käivate oma midagi Kubernetes'es, peate mõistma, et K8s on töö käigus. See areneb pidevalt, täiustatakse ja perioodiliselt isegi puruneb. Tuleb hoolikalt jälgida kõiki muudatusi Kubernetes'es, olla valmis süvenema ja välja selgitama, kuidas see detailides töötab — võib-olla rohkem, kui sooviksite. See on põhimõtteliselt igal platvormil, millel te oma andmebaase käitate…
Nii et kui me tegime operaatorit, oli meil Postgres, mis töötas välise mahuga (antud juhul — EBS, kuna me tegutsesime AWS-is). Andmebaas kasvas, ja mingil hetkel tuli teha resize: näiteks, algne EBS suurus — 100 Tb, andmebaas jõudis selleni, nüüd tahame EBS-i 200 Tb. Kuidas? Oletame, et võib teha dump/restore uuele instantsile, kuid see on aeglane ja aeglane.
Seega soovisime sellist resize'i, mis suurendaks EBS-i osa ja seejärel ütleb failisüsteemile, et kasutada uut ruumi. Ja me tegime seda, kuid sel ajal ei olnud Kubernetes'es ühtegi API-d resize'i operatsiooni jaoks. Kuna me tegutsesime AWS-is, kirjutasime oma API koodi.
Keegi ei takista sama teha teiste platvormide jaoks. Operaatoril ei ole sõltuvust, et seda saab käitada ainult AWS-is, või et see ei tööta mujal. Ühesõnaga, see on avatud allikaga projekt: kui kellegil on soov kiirendada uue API kasutuselevõttu — olete teretulnud. On GitHub, pull-requests — Zalando meeskond püüab neile üsna kiiresti vastata ja operaatorit edendada. Nii palju kui ma tean, projekt osales Google Summer of Code'i ja mõnedes teistes sarnastes algatustes. Zalando töötab selle kallal väga aktiivselt.

P.S. Boonus!

Kui teid huvitab PostgreSQL ja Kubernetes, siis juhtime tähelepanu, et eelmisel nädalal toimus järgmine Postgres-teisipäev, kus Nikolai suhtles Alexander Kukushkiniga Zalando's. Video temast on saadaval siin.