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

Möödunud aasta lõpus toimus järgmine otseülekanne Venemaa PostgreSQLi kogukonnalt #RuPostgres, mille käigus rääkis selle kaasasutaja Nikolai Samokhvalov "Flanta" tehnilise direktori Dmitri Stolyaroviga sellest andmebaasisüsteemist Kubernetes kontekstis.

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

Andmebaasid ja Kubernetes

NS: Täna ei räägi me VACUUM'ist ega CHECKPOINT'idest. Tahame rääkida Kubernetesest. Tean, et sul on juba palju aastaid kogemust. Olen vaadanud sinu videoid ja mõned isegi uuesti läbi käinud… Alustame kohe: miks on Postgres või MySQL K8s-is üleüldse vajalik?

DS: Sellele küsimusele ei ole ühtegi kindlat vastust, ega saagi olla. Aga üldiselt on see lihtsus ja mugavus… potentsiaalselt. Kõigile meeldiks ju manageeritud teenused.

NS: Nii nagu RDS, ainult, et endal?

DS: Jah: et nagu RDS, ainult kus iganes.

NS: „Igasugustes kohtades“ on hea tähelepanek. Suurtes ettevõtetes on kõik erinevates kohtades. Miks siis, kui tegemist on suure ettevõttega, mitte kasutada valmis lahendust? Näiteks Nutanixil on oma arendus, teistel ettevõtetel (VMware…) — sama „RDS, aga enda oma“.

DS: Aga see, millest me räägime, on konkreetne teostus, mis töötab ainult teatud tingimustes. Kui rääkida Kubernetesest, siis siin on tohutu infrastruktuuri mitmekesisus (mis võib olla K8s-is). Sisuliselt on see API standard pilve jaoks…

NS: Veel tasuta!

DS: See pole nii oluline. Tasuta on oluline mitte väga suurele turusegmendile. Oluline on midagi muud… Sa ilmselt mäletad ettekannet „Andmebaasid ja Kubernetes»?

NS: Jah.

DS: Ma sain aru, et seda tõlgendati väga erinevalt. Osad inimesed arvasid, et ma ütlen: „Küsimus on, kas minna kõik andmebaasid Kubernetesesse!“, — teised aga leidsid, et see on kõik kokku jube. Aga mina tahtsin rääkida hoopis millestki muust: „Vaadake, mis toimub, millised on probleemid ja kuidas neid lahendada. Kas peaks praegu liikuma andmebaasidega Kubernetesesse? Production'isse? No, ainult juhul, kui teile meeldib… tegeleda teatud asjadega. Aga dev'ile — võin öelda, et soovitan. Dev'ile on väga tähtis keskkondade loomise ja kustutamise dünaamilisus.

NS: Pead sa dev'il silmas kõiki keskkondi, mis ei ole prod? Staging, QA…

DS: Kui räägime perf-seisakutest, siis ilmselt mitte, sest seal on nõuded spetsiifilised. Kui räägime erijuhtudest, kus staging'ul on vaja väga suurt andmebaasi, siis ka tõenäoliselt mitte… Kui see on staatiline keskkond, mis peab pikalt kestma, siis mis kasu on andmebaasist, mis asub K8s-is?

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

DS: Staging võib olla staatiline. Meil on kliente…

NS: Jah, mul on ka. Suur probleem, kui sul on 10 TB andmebaas ja staging on 200 GB…

DS: Mul on väga äge juhtum! Staging'is on prod'i andmebaas, millesse tehakse muudatusi. Samuti on olemas nupp: „viia tootmisse”. Need muudatused — deltid — lükatakse (tundub, et lihtsalt API kaudu sünkroonitakse) tootmisserverisse. See on väga eksootiline variant.

NS: Olen näinud idufirmasid oru alal, kes on veel RDS'is või isegi Herokus — need on 2-3 aastat vanad lood — ja nad laadivad dump'i oma sülearvutisse. Sest andmebaas on vaid 80 GB ja sülearvutis on ruumi. Siis ostavad nad igale ühele kettaid juurde, et oleks kolm andmebaasi, et erinevaid arendusi teha. Nii ka juhtub. Olen ka näinud, et ei karda tootmist staging'isse kopeerida — see sõltub väga palju ettevõttest. Kuid olen näinud ka, et kardetakse väga, ja tihti ei jätku aega ja käsi. Kuid enne kui me selle teema juurde läheme, tahaksin kuulda Kubernetesest. Kas ma õigesti aru saan, et tootmises ei ole seda veel kellelgi?

DS: Meil on väiksed andmebaasid prod' is. Räägime kümnete gigabaitide mahtudest ja mitte kriitilistest teenustest, mille jaoks ei viitsinud koopiaid teha (ja pole ka tõelist vajadust). Ja eeldusel, et Kubernetes'i all on normaalne salvestus. See andmebaas töötas virtuaalmasinas — tinglikult VMware-is, andmehoidla peal. Me panime selle PV ja nüüd saame seda ühest masinast teise üle viia.

NS: Sellise suurusega andmebaasid, kuni 100 GB, headel ketastel ja hea võrgu korral, saab paigaldada paarikümne minuti jooksul, eks? Kiirus 1 GB sekundis — see ei ole enam eksootika.

DS: Jah, lineaarse operatsiooni puhul ei ole see probleem.

NS: Okei, prod'ist peame vaid mõtlema. Aga kui me kaalume Kuberneteset mitte-prod'i keskkondade jaoks — kuidas tegutseda? Ma näen, et Zalando teeb operaatorit, Crunchy arendab, on veel mõned variandid. Ja on OnGres — meie hea tuttav Alvaro Hispaaniast: nad teevad sisuliselt mitte lihtsalt operaator, vaid kogu distributsiooni (StackGres), kuhu lisaks Postgres'le on nad otsustanud panna ka varukoopia, proksi Envoy…

DS: Envoy milleks? Just Postgres'i liikluse tasakaalustamiseks?

NS: Jah. See tähendab, et nad näevad seda nii: kui võtta Linuxi jaotamine ja tuum, siis tavaline PostgreSQL on tuum, kuid nad tahavad luua jaotuse, mis on pilvesõbralik ja töötab Kuberneteses. Nad ühendavad komponente (varukoopiad jne) ja kohandavad, et need hästi töötaksid.

DS: Tõeliselt äge! Sisuliselt on see tarkvara, et teha oma hallatud Postgres.

NS: Linuxi jaotustel on pidevalt probleeme: kuidas teha draivereid, et kogu riistvara toetataks. Neil on idee, et nad töötavad Kuberneteses. Ma tean, et operaatorel Zalando puhul nägime hiljuti sõltuvust AWS-st ja see pole enam eriti hea. Ei peaks olema sõltuvust konkreetsest infrastruktuurist — mis siis on selle mõte?

DS: Ei tea, millises konkreetses olukorras Zalando sõltus, aga Kuberneteses on praegu salvestus tehtud nii, et ei saa üldiselt ketta varukoopiat teha. Hiljuti lisati standardisse — viimases versioonis CSI spetsifikatsioonid — tehti võimalus hetkepilte, aga kus see on rakendatud? Ausalt, see on endiselt nii toores… Me proovime CSI-d AWS, GCE, Azure, vSphere peal, aga kui hakkad kasutama, siis on kohe näha, et see pole veel valmis.

NS: Seetõttu peab mõnikord infrastruktuuri külge siduma. Usun, et see on endiselt varajane staadium - kasvu probleemid. Küsimus: mida sa soovitaksid algajatele, kes tahavad proovida PgSQL K8s-is? Milline operaator, võib-olla?

DS: Probleme on selles, et Postgres meie jaoks on 3%. Meil on veel väga pikk nimekiri erinevast tarkvarast Kuberneteses, ei hakka isegi kõike loetlema. Näiteks Elasticsearch. Operaatorite hulk on suur: mõned arenevad aktiivselt, teised mitte. Oleme endale koostanud nõuded, mis peavad operaatoris olema, et me võtaksime selle tõsiselt. Operaator Kuberneteses - mitte „operaator, et midagi Amazoni tingimustes teha“... Tegelikult kasutame me piisavalt laialdaselt (= peaaegu kõigil klientidel) ühte operaatorit - Redisile (varsti avaldame ka temast artikli).

NS: Ent MySQLi jaoks ei ole ka? Ma tean, et Percona… kuna nad nüüd tegelevad nii MySQL, MongoDB kui ka Postgresiga, peavad nad looma mingi universaalse lahenduse: kõigi andmebaaside jaoks, kõigi pilveteenuse pakkujate jaoks.

DS: Me ei jõudnud vaadata MySQL operaatorite peale. See ei ole meie peamine fookus. MySQL töötab iseseisvalt normaalselt. Miks operaator, kui saad lihtsalt DB käivitada… Sa saad käivitada Docker-konteineri Postgresiga, või siis veel lihtsamalt.

NS: Selle kohta oli ka küsimus. Täiesti ilma operaatorita?

DS: Jah, 100% meie PostgreSQL töötab ilma operaatorita. Praegu on see nii. Me kasutame operaatorit aktiivselt Prometheuse ja Redis'e jaoks. Meil on plaanis leida operaator Elasticsearch'i jaoks — see on kõige põletavam, sest tahame seda 100% juhtudel Kubernetesesse paigutada. Nii nagu tahame, et MongoDB oleks alati Kuberneteses. Siin tekivad teatud soovid — on tunne, et seda on võimalik teha. Ja Postgres'i osas me isegi ei vaadanud. Loomulikult teame, et erinevaid variante on olemas, aga tegelikult on meil standalone.

Andmebaas testimiseks Kuberneteses

NS: Liigume testimise teema juurde. Kuidas teha andmebaasis muudatusi — DevOpsi perspektiivist. On mikroteenuseid, palju andmebaase, pidevalt muutub midagi. Kuidas tagada normaalne CI/CD, et DB seisukohalt oleks kõik korras. Mis on sinu lähenemine?

DS: Ühte vastust ei saa olla. On mitu parameetrit. Esimene on andmebaasi suurus, mille me tahame avada. Sa mainisid, et erinevad ettevõtted suhtuvad erinevalt sellesse, et prod-andmebaasi koopia oleks dev- ja stage-vkes.

NS: GDPR-i tingimustes arvan, et nad käituvad üha ettevaatlikumalt... Võin öelda, et Euroopas on juba hakatud trahve määrama.

DS: Kuid tihti on võimalik kirjutada tarkvara, mis teeb dump'i production'ist ja obfuskeerib seda. Saame prod-andmed (snapšoti, dump'i, binaarse koopia...), kuid need on anonüümsed. Selle asemel võivad olla ka genereerimise skriptid: need võivad olla fikstuurid või lihtsalt skript, mis genereerib suure andmebaasi. Probleem on see: kui palju aega kulub põhivormi loomisele? Ja kui palju aega kulub selle rakendamiseks soovitud keskkonnas?

Oleme jõudnud skeemi: kui kliendil on fikstuurikomplekt (minimum andmebaasi versioon), siis kasutame neid vaikimisi. Kui räägime review-keskkondadest, kui oleme loonud haru ja meil on rakendus käivitatud — tõstame sinna väikese andmebaasi. Aga see õnnestus hästi ja variant, kui production’st teeme kord päevas (öösel) dump'i ja kogume selle põhjal Docker-konteineri PostgreSQL ja MySQL'iga koos nende laaditud andmetega. Kui sellest pildist on vaja 50 korda andmebaasi üles seada, siis see käib piisavalt lihtsalt ja kiiresti.

NS: Lihtsa kopeerimisega?

DS: Andmed on otse Docker'i pildis. St meil on valmis pilt, olgu see 100 GB. Tänu Docker'i kihtidele saame seda pilti kiiresti vajaliku arvu kordi üles seada. Meetod on võib-olla lihtne, aga töötab hästi.

NS: Edasi, kui testite, siis see muutub otse Docker'is, eks? Copy-on-write Docker'is — viskame välja ja lähme taas teele, kõik on korras. Hinne! Ja kas te juba kasutate seda täies mahus?

DS: Ammu.

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

DS: See ei ole üldine. Aga Docker'i variant töötab igal pool.

NS: Idee järgi, jah. Kuid meil on seal ka moodulid, saame luua erinevaid mooduleid ja töötada erinevate failisüsteemidega. Siin on üks hetk: me vaatame seda Postgres'i poolest täiesti erinevalt. Nüüd olen vaadanud Docker'i poolt ja näinud, et teil kõik töötab. Kuid kui andmebaas on hiiglaslik, näiteks 1 TB, siis see juba võtab aega: nii öised operatsioonid kui ka kõik Dockerisse paigutamine... Ent kui 5 TB paigutada Dockerisse... Või on kõik korras?

DS: Mis vahet seal on: need on ju blobid, lihtsalt bitid ja baitid.

NS: Kas vahe on selles, et teete seda dump'i ja restore'iga?

DS: Sugugi mitte vajalik. Selle pildi genereerimise meetodid võivad olla erinevad.

NS: Mõnedele klientidele oleme teinud nii, et regulaarselt generatiivse baaspildi asemel hoiame seda pidevalt ajakohasena. See on põhimõtteliselt replikatsioon, kuid andmed ei tule mitte otse peaharu kaudu, vaid arhiivi kaudu. Binaarne arhiiv, kuhu WAL'id laetakse igapäevaselt, seal tehakse ka varukoopiaid... Need WAL'id jõuavad seejärel - väikese viivitusega (täpselt 1-2 sekundit) - baaspildini. Sealt kloneerime me igal viisil - nüüd on meid vaikimisi ZFS.

DS: Kuid ZFS-iga olete piiratud ühe sõlme kasutamisega.

NS: Jah. Kuid ZFS-l on veel üks maagia send: selle abil saab saata snapshot'i ja isegi (ma ei ole seda veel eriti testinud, aga...) saab saata delta kahte erineva vahel PGDATA. Tegelikult on meil veel üks tööriist, mida me selliste ülesannete jaoks ei ole eriti uurinud. PostgreSQL-s on pg_rewind, mis töötab nagu 'nutikas' rsync, vahele jättes palju sellist, millele ei pea tähelepanu pöörama, sest seal ei ole midagi muutunud. Me saame kiire senkroniseerimise teha kahel serveril ja tagasi rullida täpselt samamoodi.

Nii et me proovime selle DBA-maisema külje pealt luua tööriista, mis võimaldab teha sama, millest sa rääkisid: meil on üks andmebaas, kuid me tahame 50 korda midagi testida, peaaegu samal ajal.

DS: 50 korda tähendab, et peate tellima 50 Spot'ainstantsse.

NS: Ei, teeme kõik ühel masinal.

DS: Aga kuidas te paigutate 50 korda, kui see üks andmebaas on, ütleme, terabaidine. Tõenäoliselt vajab see tinglikult 256 GB RAM-i?

NS: Jah, mõnikord on mälu tõesti palju — see on normaalne. Aga selline näide elust. Toote masinal on 96 tuuma ja 600 GB. Samas kasutatakse andmebaasi jaoks 32 tuuma (isegi 16 tuuma vahel on nüüd mõnikord) ja mälu 100-120 GB.

DS: Ja sinna mahub 50 koopiat?

NS: Nii et koopia on üks, edasi töötab copy-on-write (ZFS-iga)… Räägin lähemalt.

Meil on näiteks 10 TB andmebaas. Selle jaoks tehtud kett, ZFS surus selle suurust veel 30-40% võrra kokku. Kuna me ei teosta koormustestimist, ei ole meile täpne reageerimisaeg oluline: olgu see ka kahe korda aeglasem — see on okei.

Pakume võimaluse arendajatele, QA-le, DBA-dele jne testida 1-2 voos. Näiteks saavad nad käivitada mingi migratsiooni. See ei vaja kohe 10 tuuma — selleks on vajalik 1 Postgresi taust, 1 tuum. Migratsioon käivitub — võib-olla, autovacuum veel käivitub, siis kasutatakse teist tuuma. Meil on eraldatud 16-32 tuuma, nii et 10 inimest saavad samal ajal töötada, probleeme ei ole.

Kuna füüsiliselt PGDATA on sama, selgub, et tegelikult petame Postgresi. Näiteks käivitub samaaegselt 10 Postgresit. Mis on tavaliselt probleem? Panakse shared_buffers, oletame, 25%. Vastavalt sellele on see 200 GB. Rohkem kui kolm sellist ei saa enam käivitada, kuna mälu saab otsa.

Aga mingil hetkel mõistsime, et see pole vajalik: seadistame shared_buffers 2 GB. PostgreSQL-l on effective_cache_size, ja tegelikult mõjutab see ainult plaane.. Me paigaldame selle 0,5 TB. Ja isegi ei ole oluline, et neid tegelikult ei ole: ta koostab plaane, nagu oleks need olemas.

Seega, kui testime mingit migratsiooni, saame koguda kõik plaanid — näeme, kuidas see production'is toimuma hakkab. Sekundid võivad olla teised (aeglasemad), kuid andmed, mida me tõeliselt loeme, ja enda plaanid (millised JOIN'id ja nii edasi) on täpselt sellised nagu production'is. Ja samal ajal saab töötada mitme sellise kontrolliga ühel masinal.

DS: Kas sa ei arva, et siin on mitu probleemi? Esiteks — see lahendus töötab ainult PostgreSQL-is. Selline lähenemine on väga spetsiifiline, see ei ole generiline. Teiseks — Kubernetes (ja kõik, kuhu nüüd pilvetehnoloogiad lähevad) eeldab mitmeid sõlme, ja need sõlmed on efemeersed. Aga sinu puhul on see stateful, püsiv sõlm. Need asjad tekitavad minus vastuolusid.

NS: Esmalt — olen nõus, see on puhtalt Postgres'i lugu. Arvan, et kui meil on mingisugune direct IO ja puhverpood peaaegu kogu mälu jaoks, siis selline lähenemine ei sobi — plaanid oleksid teised. Aga praegu töötame ainult Postgres'iga, teisest ei mõtle.

Kubernetesest. Sa ju räägid igal pool, et meie andmebaas on püsiv. Kui instants kukkus kokku, on peamine — säilitada ketas. Meie kogu platvorm on samuti Kuberneteses, ning Postgres'i komponent on eraldi (kuigi ka see kunagi seal olema hakkab). Seega on asi nii: instants kukkus kokku, aga me säilitasime selle PV ja ühendasime lihtsalt uue instantsi külge, nagu polekski midagi juhtunud.

DS: Minu arvates loome me pod'e Kuberneteses. K8s on elastne: sõlmed tellitakse ise vastavalt vajadusele. Ülesanne on lihtsalt luua pod ja öelda, et tal on vaja X ressursse, ning edasi K8s korraldab kõik ise. Kuid salvestuste tugi Kuberneteses on endiselt ebastabiilne: 1.16, in 1.17 (see väljaanne ilmus nädalat tagasi) need funktsioonid on alles beetaversioonis.

Kuu või aasta pärast — see muutub enam-vähem stabiilseks, või vähemalt on nii kuulutatud. Siis lahendab snapshot’ide ja resize'i võimalus teie ülesande täielikult. Sest teil on andmebaas. Jah, see võib olla mitte eriti kiire, aga kiirus sõltub sellest, mis on "kaane all", sest mõned teostused suudavad kopeerida ja copy-on-write-diskisüsteemi tasemel.

NS: Siin on veel asjaolu, et kõik mootorid (Amazon, Google…) peavad selle versiooni toetamisega tegelema — see võtab samuti aega.

DS: Praegu me neid ei kasuta. Me kasutame oma lahendust.

Kohalik arendus Kubernetes'ile

NS: Kas oled kunagi kokku puutunud sooviga käivitada kõik pod'id ühel masinal ja teha väikest testimist. Et kiiresti saada tõend kontseptsioonist, vaadata, kuidas rakendus Kubernetes'is töötab, ilma et peaksime sellele palju masinaid eraldama. On olemas Minikube, eks?

DS: Minu arvates on see juhtum — ühel sõlmel üles seadmine — puhtalt kohaliku arenduse teema. Või mingid selle mustri ilmingud. On Minikube, on k3s, KIND. Me oleme suundumas selle poole, et hakkame Kubernetes'i Docker'i sees kasutama. Oleme hakanud sellega katsetama.

NS: Ma arvasin varem, et see on katse pakkida kõik pod'id ühe Docker'i pildina. Aga osutus, et see on hoopis midagi muud. Seal on endiselt eraldi konteinerid, eraldi pod'id — lihtsalt Docker'is.

DS: Jah. Ja seal on üsna naljakas imitatsioon tehtud, aga mõte on selline... Meil on tööriist, et rakendusi üles seada — werf. Me tahame sellesse teha režiimi — tinglikult werf up: „Käivita mulle kohalik Kubernetes“. Ja seejärel käivitada seal tinglik werf follow. Siis saab arendaja IDE-s redigeerida, samal ajal kui süsteemis on tööprotsess, mis näeb muudatusi ja uuesti koostab pildid, deponeerib need kohalikku K8s-süsteemi. Just nii püüame lahendada kohaliku arenduse probleemi.

Snapshots ja andmebaasi kloonimine K8s-i kontekstis

NS: Kui rääkida copy-on-write'ist. Olen märganud, et ka pilveteenustel on snapshots. Need töötavad erinevalt. Näiteks GCP-s: sul on USA idakaldal mitme terabaiti instants. Teed regulaarselt snapshots. Tõstad snapshots'ist koopia ketas läänekaldale — mõne minutiga on kõik valmis, töötab väga kiiresti, ainult cache tuleb mälu täita. Kuid need kloonid (snapshots) on mõeldud uue mahu 'provision'imiseks. See on lahe, kui pead looma palju instantsse.

Aga testide jaoks, mulle tundub, et snapshote, millest sa räägid Dockeris või millest mina räägin ZFS, btrfs ja isegi LVM… — need võimaldavad sama masinaga mitte teha tõeliselt uusi andmeid. Pilves pead sa ka igakord nende eest maksma ja ootama ei mitte sekundeid, vaid minuteid (ja juhtudel lazy load'ist, võib-olla isegi tunde).

Selle asemel saab need andmed sekunditega kätte, testi läbi viia ja kõrvaldada. Need kiirülevaated lahendavad erinevaid ülesandeid. Esimeses olukorras — et skaleerida ja uusi koopiaid saada, teises — testide jaoks.

DS: Ma ei nõustu. Korraliku mahutite kloonimise tegemine on pilve ülesanne. Ma ei ole nende teostust vaadanud, aga tean, kuidas me seda riistvaral teeme. Meil on Ceph, kus on võimalik igale füüsilisele mahutile (RBD) öelda clone ja saada juba kümnete millisekunditega teine mahuti, millel on samad omadused, IOPSjne. Tuleb mõista, et seal sees on keeruline copy-on-write. Miks ei võiks pilv ka nii teha? Olen kindel, et nad püüavad seda mingil moel saavutada.

NS: Kuid neil kulub ikkagi sekundeid, kümneid sekundeid, et instantsi üles tõsta, Docker sinna tuua jne.

DS: Miks peaks kohe terve instantsi tõstma? Meil on ju instants 32 südamikuga, 16… ja sinna mahub mitmeid — näiteks neli. Kui tellime viienda, tõuseb juba instants, mis siis kaotatakse.

NS: Jah, huvitav, et Kuberneteses on hoopis teine lugu. Meie andmebaas ei ole K8s-is ja on üks instants. Küll aga läheb mitme terabaidi andmebaasi kloonimiseks maksimaalselt kaks sekundit.

DS: See on äge. Aga minu algne mõte oli, et see ei ole üldine lahendus. Jah, see on lahe, aga sobib ainult Postgresile ja ainult ühel sõlmel.

NS: See sobib mitte ainult Postgresile: nagu ma kirjeldasin, töötavad need plaanid ainult selles. Aga kui me ei muretse plaanide pärast ja vajame lihtsalt kõiki andmeid funktsionaalseteks testideks, siis sobib see igasuguste andmebaaside jaoks.

DS: Palju aastaid tagasi tegime me sarnast LVM-snapshottide peal. See on klassika. Sellist lähenemist kasutati väga aktiivselt. Stateful-sõlmed on lihtsalt valus. Sest neid ei tohi kukutada, neist tuleb alati meeles pidada...

NS: Kas sa ei näe siin mingisugust hübriidi võimalust? Oletame, et stateful on mingi pod, mis töötab mitme inimese peal (palju testijate). Meil on üks maht, aga tänu failisüsteemile on kloonid kohalikud. Kui pod kukub, jääb ketas alles — pod tõuseb tagasi, loeb kogu teabest kloonide kohta, tõstab kõik tagasi üles ja ütleb: «Siin on teie kloonid nende portide peal, jätkake nendega tööd».

DS: Tehniliselt tähendab see, et Kuberneteses on see üks pod, mille sees käivitame palju Postgres'e.

NS: Jah. Tal on piirmäär: oletame, et samal ajal saab selle juures töötada mitte rohkem kui 10 inimest. Kui on vaja 20 — käivitame teise sellise pod’i. Täiesti reaalne on seda kopeerida, saades teise täis mahtu, millel on sama 10 „õhukest“ klooni. Kas sa ei näe sellist võimalust?

DS: Siia tuleb lisada turvaküsimused. Selline korraldus tähendab, et sellel pod'il on suured privileegid (capabilities), sest see võib teha mittestandardsed toimingud failisüsteemiga… Kuid ma kordaksin, et usun, et Kubernetes parandab keskpikas perspektiivis storage'i, pilved parandavad kogu mahtude teema — kõik hakkab lihtsalt tööle. Olemas on resize, kloonimine… Kui maht on olemas — me ütleme: „Loo uus selle põhjal“, — ja poolteise sekundi jooksul saame, mida vajame.

NS: Ma ei usu poolteise sekundi saavutamisse paljude terabyte'ide jaoks. Ceph'is teed ise, aga räägid pilvedest. Mine pilve, tee EC2-s kloon terabyte'ide EBS mahust ja vaata, milline jõudlus tuleb. See ei võta paar sekundit. Mind huvitab väga, millal nad selleni jõuavad. Ma saan aru, millest sa räägid, aga luba endal mitte nõustuda.

DS: Okei, aga ma ütlesin, et keskpikas perspektiivis, mitte lühikeses. Aastaid kestvaks.

PostgreSQL operaatorist Zalando poolt

Kohtumise keskel liitus temaga ka Aleksei Kliukin, endine arendaja firmast Zalando, kes rääkis PostgreSQL operaatori ajaloost:

Hea, et see teema üldse tõstatati: nii Postgres kui Kubernetes. Kui me hakkasime Zalandos seda 2017. aastal tegema, oli see teema, mida kõik tahtsid teha, aga keegi ei teinud. Kõigil hakkas juba Kubernetes olemas olema, aga kui küsiti, kuidas andmebaasidega olla, siis isegi sellised inimesed nagu Kelsey Hightower, kes propageerisid K8s, ütlesid umbes niimoodi:
„Minge halduskeskkondadesse ja kasutage neid, ärge käitage andmebaase Kuberneteses. Muul juhul otsustab teie K8s näiteks uuendada, sulgeb kõik sõlmed ja teie andmed kaovad kaugele kaugele.”
Me otsustasime teha operaatori, mis käivitab Postgresi andmebaasi Kuberneteses, sellele nõuandele vaatamata. Ja meil oli selleks hea alus — Patroni. See on automaatne failover PostgreSQL-le, mis on korralikult üles ehitatud, st kasutab etcd, consul või ZooKeeper andmekogumisena klastriteavet. Selline andmekogum, mis annab kõigile, kes küsivad, näiteks, kes on hetkel juht, sama teabe — hoolimata meie jaotatud struktuurist — et vältida split brain’i. Lisaks olime me Docker-image selle jaoks.
Tegelikult tekkis ettevõttel vajadus automaatse failover'i järele pärast üleminekut siseandmekeskuse lahendustelt pilvelahendusele. Pilv põhines ettevõtte enda PaaS (Platform-as-a-Service) lahendusel. See oli avatud lähtekoodiga, kuid selle üles seadmine nõudis palju vaeva. See kandis nime STUPS.
Alguses ei olnud ühtegi Kubernetes'i. Täpsemalt öeldes, kui ettevõtte omandatud lahendust kasutusele võeti, oli K8s juba olemas, kuid nii toores, et tootmisvõimeks ei sobinud. See oli, minu meelest, 2015. või 2016. aasta. 2017. aastaks oli Kubernetes muutunud enam-vähem küpseks — tekkis vajadus sinna migratsiooni järele.
Ja meil oli juba Docker-konteiner. Oli PaaS, mis kasutas Dockerit. Miks mitte proovida K8s-i? Miks mitte kirjutada oma operaator? Murat Kabilov, kes tuli meile Avitost, alustas seda projektina oma algatusel — "looma mängida" — ja projekt "tõusis".
Aga üldiselt tahtsin rääkida AWS-ist. Miks seal oli ajalooliselt kood, mis oli seotud AWS-iga…
Kui käivitate midagi Kuberneteses, tuleb aru saada, et K8s on pidevas arengus. See areneb pidevalt, paraneb ja perioodiliselt isegi rikneb. Tuleb hoolikalt jälgida kõiki muudatusi Kuberneteses, olema valmis vajadusel süvenema sellesse ja õppima, kuidas kõik detailid töötavad — võib-olla rohkem, kui sooviksite. See kehtib põhimõtteliselt iga platvormi kohta, millel te oma andmebaase käivitate...
Nüüd, kui me tegime operaatorit, oli meil Postgres, mis töötas välise mahuga (antud juhul EBS, kuna töötasime AWS-is). Andmebaas kasvas ja mingil hetkel tuli teha muudatused: näiteks, algne EBS-i suurus oli 100 TB, andmebaas ulatus sellele, nüüd soovime EBS-i suurust muuta 200 TB-ks. Kuidas? Eeldame, et võiks teha dump/restore uuele instantsile, kuid see on aeglane ja toob kaasa seisaku.
Seetõttu soovisime sellist muudatust, mis suurendaks EBS-i partitsiooni ja siis annaks failisüsteemile käsu kasutada uut ruumi. Ja me tegime seda, kuid sel ajal ei olnud Kubernetesel mingit API-d resize operatsiooni jaoks. Kuna töötasime AWS-is, kirjutasime koodi selle API jaoks.
Keegi ei takista teha sama ka teiste platvormide jaoks. Operaator ei ole seotud ainult AWS-iga, see töötab ka teistel platvormidel. See on avatud lähtekoodiga projekt: kui keegi soovib kiirendada uue API kasutuselevõttu — olete teretulnud. On GitHub, pull-päringuid — Zalando meeskond püüab neile üsna kiiresti reageerida ja operaatorit edendada. Niipalju kui tean, projekt osales Google Summer of Code'i ja teiste sarnaste algatuste kohta. Zalando töötab selle nimel väga aktiivselt.

P.S. Boonus!

Kui teid huvitab PostgreSQL ja Kubernetes, tasub märkida, et eelmisel nädalal toimus järgmine Postgres-teisipäev, kus Nikolai kohtus Alexander Kukushkiniga Zalando's. Video on saadaval siit.