Na konci minulého roka sa uskutočnil ďalší živý prenos ruského PostgreSQL spoločenstva , v rámci ktorého jeho spoluzakladateľ Nikolaj Samochvalov hovoril s technickým riaditeľom „Flanta“ Dmitrijom Stoljarovom o tejto SÚDB v kontexte Kubernetes.
Zverejňujeme záznam hlavnej časti tejto diskusie, a na bola zverejnená kompletná video nahrávka:
Databázy a Kubernetes
NS: Dnes nebudeme hovoriť o VACUUM a CHECKPOINToch. Chceme sa rozprávať o Kubernetes. Viem, že máš už veľa rokov skúseností. Pozeral som tvoje videá a niektoré som dokonca pozeral aj v úryvkoch… Poďme rovno na vec: prečo vlastne Postgres alebo MySQL v K8s?
DS: Na túto otázku neexistuje jednoznačná odpoveď, a ani nemôže existovať. Ale vo všeobecnosti, je to jednoduchosť a pohodlie… potenciálne. Všetci chcú managed služieb.
NS: Aby to bolo ako , len u seba?
DS: Áno: aby to bolo ako RDS, len že kdekoľvek.
NS: „Kdekoľvek“ — to je dobrá poznámka. Vo veľkých firmách je všetko rozmiestnené na rôznych miestach. A prečo, ak ide o veľkú spoločnosť, nevyužiť hotové riešenie? Napríklad, Nutanix má svoje vlastné vývojové riešenia, iné spoločnosti (VMware…) majú tiež „RDS, len u seba“.
DS: Ale to hovoríme o konkrétnej implementácii, ktorá bude fungovať iba za určitých podmienok. A ak ide o Kubernetes, tak tu je obrovská rozmanitosť infraštruktúry (ktorá môže byť v K8s). V podstate to je štandard pre API do cloudu…
NS: Ešte aj zadarmo!
DS: To nie je tak dôležité. Bezplatnosť je dôležitá len pre relatívne malý segment trhu. Dôležitejšie je niečo iné… Určite si pamätáš prednášku „»?
NS: Áno.
DS: Pochopil som, že bola prijatá veľmi rozporuplne. Časť ľudí si pomyslela, že hovorím: „Chlapci, poďme s všetkými DB do Kubernetes!“, — a iní usúdili, že to sú len hrozné bicykle. A ja som vlastne chcel povedať niečo úplne iné: „Pozrite, čo sa deje, aké sú problémy a ako sa dajú riešiť. Je teraz čas ísť s databázami do Kubernetes? Na produkciu? No, iba ak máte radi… robiť určité veci. Ale pre dev’áka — môžem povedať, že odporúčam. Pre dev’áka je veľmi dôležitá dynamika vytvárania/mazania prostredí“.
NS: Pod dev’ákom máš na mysli všetky prostredia, ktoré nie sú prod? Staging, QA…
DS: Ak hovoríme o perf-stendoch, tak už asi nie, pretože tam sú špecifické požiadavky. Ak hovoríme o osobitných prípadoch, kde je na stagingu potrebná veľmi veľká DB, tak tiež asi nie… Ak je to statické prostredie, dlhodobé, tak aký je prínos, že je databáza umiestnená v K8s?
NS: Žiadny. Ale kde vidíme statické prostredia? Statické prostredie zastaralo už zajtra.
DS: Staging môže byť statický. Máme klientov...
NS: Áno, aj ja mám. Veľký problém, ak máš databázu na 10 TB, a staging — 200 GB...
DS: Mám veľmi zaujímavý prípad! Na stagingu je produkčná databáza, do ktorej sa robia zmeny. A je tam predpokladaná tlačidlo: „nasadiť do produkcie“. Tieto zmeny — delty — sa dopĺňajú (myslím, jednoducho sa synchronizujú cez API) do produkcie. To je veľmi exotická varianta.
NS: Viděl jsem startupy v Doline, které byly v RDS nebo dokonce na Heroku - to jsou příběhy z 2-3 let zpátky - a stahovali si dumpy na své laptop. Pretože databáza zatiaľ má len 80 GB a na laptope je miesto. Potom si dokupujú disky každému, aby mali 3 databázy, aby viedli rôzne vývojové projekty. Takéto prípady sa tiež dejú. Tiež som videl, že sa neboja kopírovať produkciu na staging — veľmi to závisí od spoločnosti. Ale videl som aj to, že sa veľmi boja, a že často nie je čas ani ľudí. Ale skôr, než prejdeme k tejto téme, chcem počuť o Kubernetes. Chápu správne, že v produkcii zatiaľ nikto?
DS: Máme v produkcii malé databázy. Hovoríme o objemoch v desiatkach gigabajtov a nekritických službách, pre ktoré sa neoplatilo robiť repliky (a ani neexistuje taká potreba). A pod podmienkou, že pod Kubernetesom je normálne úložisko. Táto databáza fungovala vo virtuálnom stroji — pod podmienkou v VMware, nad SAN. Umiestnili sme ju do a teraz ju môžeme prenášať z jedného stroja na druhý.
NS: Databázy takej veľkosti, do 100 GB, na dobrých diskoch a pri dobrej sieti môžeme aktualizovať za niekoľko minút, správne? Rýchlosť 1 GB za sekundu — to už nie je exotika.
DS: Áno, pre lineárnu operáciu to nie je problém.
NS: Dobre, o produkcii musíme len premýšľať. A ak zvažujeme Kubernetes pre ne-prod prostredia — ako to robiť? Vidím, že v Zalande , v Crunchy , sú aj nejaké iné možnosti. A existuje — to je náš dobrý priateľ Alvaro zo Španielska: robia vlastne nie len , ale celý distribučný balík (), do ktorého okrem samotného Postgresu chceli zahrnúť aj zálohu, proxy Envoy…
DS: Envoy na čo? Na vyvažovanie prevádzky presne Postgresu?
NS: Áno. Teda oni to vidia tak, že ak vezmeme linuxový distribučný balík a jadro, obyčajný PostgreSQL je to jadro, a oni chcú vyrobiť distribúciu, ktorá bude priateľskejšia k облакам a bežať na Kubernetes. Spojujú komponenty (zálohy a pod.) a ladenia, aby dobre fungovali.
DS: Veľmi skvelé! V podstate je to softvér, ktorý vytvorí vlastný spravovaný Postgres.
NS: Linuxové distribúcie majú večné problémy: ako robiť ovládače, aby bolo podporované všetko hardvérové. A ich myšlienka je, že budú fungovať na Kubernetes. Viem, že v operátorovi Zalando sme nedávno videli prepojenie na AWS a to už nie je veľmi dobré. Nemalo by to byť prepojené na konkrétnu infraštruktúru — aký je potom zmysel?
DS: Neviem, v akej situácii sa konkrétne Zalando prepojilo, ale v Kubernetes je teraz storage urobene tak, že nie je možné bežne urobiť diskovú zálohu. Nedávno v štandarde — v poslednej verzii — bola pridaná možnosť snapshotov, ale kde to bolo implementované? Úprimne, stále to nie je dostatočne zrelé… Skúšame CSI nad AWS, GCE, Azure, vSphere, ale hneď ako začnete používať, je jasné, že to ešte nie je pripravené.
NS: Preto je občas potrebné prepojiť sa na infraštruktúru. Myslím, že stále prebiehajú počiatočné fázy — problémy s rastom. Otázka: čo by si odporučil nováčikom, ktorí chcú vyskúšať PgSQL na K8s? Aký operátor, možno?
DS: Problém je, že Postgres pre nás predstavuje 3%. Máme ešte veľmi dlhý zoznam rôzneho softvéru na Kubernetes, ani všetko nebudem vymenovávať. Napríklad Elasticsearch. Existuje veľa operátorov: niektoré sa aktívne vyvíjajú, iné nie. Pre seba sme si vytvorili požiadavky, čo by malo byť v operátorovi, aby sme ho brali vážne. V operátoroch presne pre Kubernetes — nie v „operátore, ktorý robí niečo na podmienkách Amazonu“… Vo faktu dosť masívne (=takmer všetci klienti) používame jediný operátor — (čoskoro zverejníme aj článok o ňom).
NS: A pre MySQL tiež nie? Viem, že Percona… keďže sa teraz zaoberajú aj MySQL, aj MongoDB, aj Postgres, musia vyrobiť nejaký univerzálny systém: pre všetky databázy, pre všetkých cloudových poskytovateľov.
DS: Ešte sme nemali čas pozrieť sa na operátory pre MySQL. Pre nás to teraz nie je hlavný fokus. MySQL funguje v standalone režime. Prečo potrebovať operátora, ak môžeš jednoducho spustiť DB... Môžeš spustiť Docker kontajner s Postrges, alebo ho spustiť jednoducho.
NS: O tomto bola tiež otázka. Úplne bez operátora?
DS: Áno, v 100% máme PostgreSQL spustený bez operátora. Zatiaľ to tak je. Aktívne používame operátora pre Prometheus, pre Redis. Máme v pláne nájsť operátora pre Elasticsearch - ten najviac „horí“, pretože ho chceme mať v 100% prípadoch nainštalovaný v Kubernetes. Rovnako, ako chceme prísť k tomu, aby sme MongoDB tiež vždy inštalovali v Kubernetes. Tu sa objavujú určité požiadavky - máme pocit, že v týchto prípadoch možno niečo spraviť. O Postgres sme sa dokonca ani nepozreli. Samozrejme, vieme o existencii rôznych variantov, ale v skutočnosti máme standalone.
DB na testovanie v Kubernetes
NS: Poďme prejsť k téme testovania. Ako nasadzovať zmeny v databáze - z pohľadu DevOps perspektívy. Existujú mikroservisy, veľa databáz, neustále sa niekde niečo mení. Ako zabezpečiť normálny CI/CD, aby z pohľadu DB bolo všetko v poriadku. Aký máš prístup?
DS: Nemôže byť jednoznačná odpoveď. Existuje viacero parametrov. Prvý - to je veľkosť databázy, ktorú chceme nasadiť. Sám si spomenul, že v spoločnostiach existujú rôzne prístupy k tomu, aby existovala kópia prod databázy na dev a stage.
NS: A v podmienkach GDPR, myslím, že sa k tomu stavajú čoraz opatrnejšie... Môžem povedať, že v Európe už začali pokutovať.
DS: Ale často je možné napísať softvér, ktorý urobí dump z production a obfuskuje to. Získajú sa prod dáta (snapshot, dump, binárna kópia...), ale sú anonymizované. Namiesto toho môžu byť aj skripty generovania: môžu to byť fixtures alebo jednoducho skript, ktorý generuje veľkú databázu. Problém je aký: koľko času sa vytvorí základný obraz? A koľko času sa mu venuje v potrebnom prostredí?
Dospeli sme k schéme: ak má klient fixtúrny súbor dát (minimálna verzia databázy), tak ich používame ako predvolené. Ak ide o review prostredie, keď sme vytvorili branch, máme nasadenú inštanciu aplikácie - tam nasadzujeme malú databázu. Ale dopadlo to dobre a , keď raz denne (v noci) robíme dump z productionu a na jeho základe vytvárame Docker kontajner s PostgreSQL a MySQL s týmito načítanými dátami. Ak je potrebné tento obraz spustiť 50-krát, je to dosť jednoduché a rýchle.
NS: Jednoduchým kopírovaním?
DS: Dátové súbory sú uložené priamo v Docker obraze. T.j. máme hotový obraz, povedzme na 100 GB. Vďaka vrstvám v Dockeri môžeme rýchlo rozprestrieť tento obraz toľkokrát, koľkokrát potrebujeme. Spôsob je primitívny, ale funguje celkom dobre.
NS: Potom, keď testujete, mení sa to priamo v Dockeri, áno? Copy-on-write v Dockeri — vyhadzujeme a ideme znova, všetko je v poriadku. Skvelé! A už to naplno využívate?
DS: Už dosť dlho.
NS: Zaoberáme sa veľmi podobnými vecami. Ibaže my nevyužívame Dockerovský copy-on-write, ale niečo iné.
DS: Nie je generický. Ale Dockerovský funguje všade.
NS: Teoreticky, áno. Ale máme aj moduly, môžeme spraviť rôzne moduly a pracovať s rôznymi súborovými systémami. Tu je jedným momentom, že na PostgreSQL sa na to pozeráme inak. Teraz som sa pozrel z pohľadu Dockera a videl, že to u vás všetko funguje. Ale ak je databáza obrovská, povedzme 1 TB, tak to už trvá dlho: aj operácie v noci, aj nahadzovanie všetkého do Dockera… A ak 5 TB dávate do Dockera… Alebo je to v poriadku?
DS: Aký je rozdiel: robíte to cez dump a restore?
NS: Vôbec nie je nevyhnutné. Spôsobov na generovanie tohto obrazu môže byť viac.
DS: Pre niektorých klientov sme urobili tak, že namiesto pravidelnej generácie základného obrazu, ho neustále udržiavame aktuálny. V podstate je to replika, ale dáta nezískava priamo z majstra, ale cez archív. Binarový archív, do ktorého sa každodenne ukladajú WAL, tam sa robia aj zálohy… Tieto WAL sa potom dostanú — s malým oneskorením (doslova 1-2 sekundy) — do základného obrazu. Z neho klonujeme akýmkoľvek spôsobom — aktuálne máme predvolene ZFS.
NS: Ale so ZFS ste obmedzení na jeden uzol.
DS: Áno. Ale ZFS má aj čarovný
NS: s ním môžete poslať snapshot a dokonca (ešte som to veľmi netestoval, ale…) môžete poslať delta medzi dvoma . V skutočnosti máme ešte jeden nástroj, ktorý sme pre tieto úlohy príliš neskúmali. V PostgreSQL je PGDATApg_rewind , fungujúci ako „inteligentný“ rsync, ktorý preskočí mnohé veci, na ktoré nie je potrebné sa pozerať, pretože sa tam nič nezmenilo. Môžeme rýchlo synchronizovať medzi dvoma servermi a vrátiť sa presne späť.
Snažíme sa z tejto, viac DBA-perspektívy, vytvoriť nástroj, ktorý umožňuje robiť to isté, o čom hovoríš: máme jednu databázu, ale chceme 50-krát niečo testovať, takmer simultánene.
DS: 50-krát znamená, že musíte objednať 50 Spot instance.
NS: Nie, robíme to na jednom stroji.
DS: Ale ako nasadíte 50-krát, ak je tá jedna databáza, povedzme, terabajtová. Pravdepodobne potrebuje približne 256 GB RAM?
NS: Áno, pamäti niekedy treba veľa — to je normálne. Ale takýto príklad z praxe. Na produkčnom stroji 96 jadier a 600 GB. Z toho pre databázu používame 32 jadier (už aj 16 jadier niekedy) a pamäti 100-120 GB.
DS: A zmestí sa tam 50 kópií?
NS: Kópia je len jedna, ďalej funguje copy-on-write (ZFS)… Povedzme si viac.
Napríklad máme databázu na 10 TB. Disk pre ňu bol vytvorený, ZFS jej zmenšil veľkosť o 30-40%. Keďže nerobíme záťažové testovanie, presná doba odozvy nie je pre nás dôležitá: nech je o 2-krát pomalšia — to je v poriadku.
Umožňujeme programátorom, QA, DBA a podobným vykonávať testovanie v 1-2 vláknach. Napríklad môžu spustiť nejakú migráciu. Nevyžaduje hneď 10 jadier — potrebuje 1 backend Postgresu, 1 jadro. Migrácia sa spustí — možno, ešte sa spustí, potom sa zapne druhé jadro. Máme vyhradené 16-32 jadier, takže 10 ľudí môže pracovať súčasne, nijaké problémy nie sú.
Keďže fyzicky PGDATA je rovnaká, vychádza to tak, že v skutočnosti klameme Postgres. Čo je trik: spustí sa napríklad 10 Postgresov súčasne. Aký je zvyčajne problém? Nastavujú , povedzme, na 25%. Takže to je 200 GB. Viac ako tri už nespustíte, pretože pamäť sa minie.
Ale v istom momente sme si uvedomili, že to nie je potrebné: nastavujeme shared_buffers na 2 GB. PostgreSQL má , a v skutočnosti ovplyvňuje iba . Ten nastavujeme na 0,5 TB. A ani nie je dôležité, že ich v skutočnosti nie je: vytvára plány, akoby boli.
Keď testujeme nejakú migráciu, môžeme zhromaždiť všetky plány — uvidíme, ako to prebehne v produkcii. Sekundy budú iné (pomalšie), ale dáta, ktoré reálne čítame, a samotné plány (aké tam sú JOIN-y a pod.) vychádzajú presne také isté, ako na produkcii. A súčasne môžeme spustiť množstvo takýchto kontrol na jednom zariadení.
DS: Nemyslíš, že tu je niekoľko problémov? Prvý — je to riešenie, ktoré funguje iba na PostgreSQL. Takýto prístup je veľmi špecifický, nie je generický. Druhý — Kubernetes (a všetko, kam teraz smerujú cloudové technológie) predpokladá množstvo uzlov, a tieto uzly sú efemérne. A vo tvojom prípade je to stateful, perzistentný uzol. Tieto veci vo mne vyvolávajú rozpory.
NS: Prvé — súhlasím, toto je čisto Postgresová záležitosť. Myslím, že ak máme nejaký priamy IO a buffer pool takmer pod všetkou pamäťou, takýto prístup nebude fungovať — plány budú iné. Ale zatiaľ pracujeme len s Postgresom a o iných neuvažujeme.
O Kubernetes. Veď sám všade hovoríš, že naša databáza je perzistentná. Ak inštancia spadne, hlavné je zachovať disk. Naša celá platforma je tiež v Kubernetes, a komponent s Postgresom je oddelený (aj keď aj on tam raz bude). Preto je to tak: inštancia spadne, ale my sme jej PV zachovali a jednoducho sme ho pripojili k inej (novej) inštancii, akoby sa nič nestalo.
DS: Z môjho pohľadu vytvárame pod-y v Kubernetes. K8s je elastický: uzly sa objednávajú samy podľa potreby. Úloha je jednoducho vytvoriť pod a povedať, že potrebuje X zdrojov, a ďalej si K8s s tým poradí. Ale podpora úložísk v Kubernetes je stále nestabilná: v , v (tento release vyšiel pred týždňom) tieto funkcie sa stávajú len beta. O pol roka až rok — to by malo byť viac-menej stabilné, alebo aspoň bude vyhlásené za také. Potom možnosť snapshotov a resize-u už úplne vyrieši vašu úlohu. Pretože máte databázu. Áno, nemusí byť veľmi rýchla, ale rýchlosť závisí od toho, čo je „pod kapotou“, pretože niektoré implementácie zvládajú kopírovanie a copy-on-write na úrovni diskovej subsystémy.
: Tu je ešte potrebné, aby všetky motory (Amazon, Google…) stihli začať podporovať túto verziu — to tiež nejaký čas trvá.
NS: Zatiaľ ich nepoužívame. Používame svoje.
DSLokálna vývojová práca pod Kubernetes
Lokálny vývoj pre Kubernetes
NS: Stretol si sa s takou požiadavkou, keď treba na jednom zariadení spustiť všetky pod’y a urobiť malé testovanie. Rýchlo získať proof of concept, pozrieť sa, či aplikácia funguje v Kubernetes, bez toho aby sa vyčlenilo množstvo strojov. Existuje Minikube, že?
DS: Myslím, že tento prípad - rozbehnúť to na jednom uzle - sa týka výlučne lokálneho vývoja. Alebo nejaké prejavy takého vzoru. Existuje , je , . Ideme k tomu, že budeme používať Kubernetes IN Docker. Teraz sme začali pracovať s tým na testy.
NS: Predtým som si myslel, že to je pokus zabaliť všetky pod’y do jedného Docker obrazu. Ale ukázalo sa, že to je úplne o niečom inom. Aj tak sú tam samostatné kontajnery, samostatné pod’y - len v Dockeri.
DS: Áno. A tam je dosť zábavná imitácia, ale zmysel je taký... Máme nástroj na nasadenie - . Chceme v ňom spraviť režim - povedzme werf up: „Zdvihni mi lokálny Kubernetes“. A potom spustiť tam podmienečný werf follow. Potom bude mať vývojár možnosť upravovať v IDE, zatiaľ čo v systéme beží proces, ktorý vidí zmeny a prekompilováva obrazy, znova nasadzuje ich do lokálneho K8s. Tak chceme skúsiť vyriešiť problém lokálneho vývoja.
Snapshoty a klonovanie DB v realite K8s
NS: Ak sa vrátime k copy-on-write. Všimol som si, že aj cloudové služby majú snapshoty. Pracujú rôzne. Napríklad, v GCP: máš na východnom pobreží USA multiterabajtový inštanc. Periodicky robíš snapshoty. Vyrobíš kópiu disku zo snapshotu na západnom pobreží - za pár minút je už všetko pripravené, veľmi rýchlo, len musia sa naplniť cache v pamäti. Ale tieto klony (snapshoty) sú na to, aby si 'provision' nový objem. To je skvelé, keď potrebuješ vytvoriť veľa inštancií.
Ale pre testy, myslím, snapshoty, o ktorých hovoríš v Dockeri alebo o ktorých hovorím v ZFS, btrfs a dokonca LVM... - umožňujú naozaj na jednom zariadení nevytvárať nové dáta. V cloude za ne ešte budeš platiť každý raz a čakať už nie sekundy, ale minúty (a v prípade , možno aj hodiny).
Namiesto toho môžeš za sekundu-dve získať tieto dáta, spraviť test a zahodiť. Tieto snapshoty riešia rôzne úlohy. V prvom prípade - aby si sa mohol škálovať a získať nové repliky, a v druhom - na testy.
DS: Nesúhlasím. Zrealizovať správne klonovanie objemov je úloha pre cloud. Nevidel som ich implementáciu, ale viem, ako to robíme my na hardvéri. Máme Ceph, v ktorom môžeme akémukoľvek fyzickému objemu () povedať klon a za desiatky milisekúnd dostať druhý objem s rovnakými vlastnosťami, a podobne. Treba chápať, že tam je vnútri zložitý copy-on-write. Prečo by cloud nemohol robiť to isté? Som si istý, že sa to snažia nejako dosiahnuť.
NS: Ale aj tak im to zaberie sekundy, desiatky sekúnd, kým spustia inštanciu, dostanú tam Docker atď.
DS: Prečo musí byť nutne celá inštancia spustená? Veď máme inštanciu na 32 jadier, na 16… a do jej kapacity sa vmestí určitý počet — napríklad štyri. Keď si objednáme piatu, už sa spustí inštancia, a potom sa odstráni.
NS: Áno, zaujímavé, v Kubernetes to vyzerá inak. Naša databáza nie je v K8s a máme len jednu inštanciu. Ale na klonovanie viac terabajtovej databázy netrvá viac ako dve sekundy.
DS: To je super. Ale môj počiatočný názor je ten, že to nie je generické riešenie. Áno, je to skvelé, ale vyhovuje to len Postgresu a len na jednom uzle.
NS: Nepatronuje to len Pre Postgres: tieto plány, ako som popísal, budú fungovať takto len v ňom. Ale ak neprihliadame na plány a jednoducho potrebujeme všetky dáta na funkčné testovanie, potom to bude fungovať pre akúkoľvek DBMS.
DS: Pred mnohými rokmi sme robili niečo podobné na LVM snapshot-och. To je klasika. Tento prístup bol veľmi aktívne používaný. Proste stateful uzly sú problém. Pretože ich treba nezrútnuť, vždy na ne pamätať...
NS: Nevidíš tu nejakú možnosť hybridu? Povedzme, že stateful je nejaký pod, ktorý pracuje pre viacero ľudí (mnoho testerov). Objem máme jeden, ale vďaka súborovému systému sú klony miestne. Ak padne pod, disk ostane — znovu sa spustí pod, naberie informácie o všetkých klonoch, všetko vráti späť a povie: 'Tu sú vaše klony na týchto portoch spustené, pracujte s nimi ďalej.'
DS: Technicky to znamená, že v rámci Kubernetes to je jeden pod, v ktorom spúšťame mnoho Postgresov.
NS: Áno. Má svoje obmedzenie: povedzme, že s ním pracuje súčasne najviac 10 ľudí. Ak potrebujeme 20 — spustíme druhý taký pod. Úplne realisticky môžeme jeho sklonovať, čím získame druhý plný objem, na ktorom budú rovnaké 10 'tenkých' klonov. Nevidíš takúto možnosť?
DS: Treba pridať otázky bezpečnosti. Takáto organizácia predpokladá, že tento pod má vysoké oprávnenia (capabilities), pretože môže vykonávať netradičné operácie nad súborovým systémom... Ale opakujem: považujem, že v strednodobom horizonte v Kubernetes opravia storage, v cloude opraví celú históriu s objemami — všetko bude „jednoducho fungovať“. Bude resize, klonovanie... Je tu objem — hovoríme: „Vytvor nový na základe toho“, — a za sekundy dostávame, čo potrebujeme.
NS: Neverím v sekundy pre mnohé terabajty. Na Ceph to robíš sám, a hovoríš o cloude. Choď do cloudu, na EC2 urob klon objemu EBS mnohých terabajtov a pozri sa, aký výkon bude. To nezaberie niekoľko sekúnd. Zaujíma ma, kedy sa dostanú na takýto údaj. Rozumiem, o čom hovoríš, ale dovoľujem si nesúhlasiť.
DS: Oki, ale povedal som, že v strednodobom horizonte, nie krátkodobom. V priebehu niekoľkých rokov.
O operátorovi pre PostgreSQL od Zalando
V strede tejto porady sa k nej tiež pripojil Alexej Klyukin, bývalý разработчик z firmy Zalando, ktorý povedal o histórii operátora PostgreSQL:
Je skvelé, že sa táto téma vôbec dotkla: a Postgres, a Kubernetes. Keď sme to začínali robiť v Zalando v roku 2017, bola to taká téma, ktorou sa všetci chceli zaoberať, ale nikto to nerobil. Všetci už mali Kubernetes, ale keď sa pýtali, ako na to s databázami, tak aj takí ľudia ako , ktorí kázali o K8s, hovorili približne toto:
"Choďte do managed-služieb a používajte ich, nespúšťajte DB v Kubernetes. Inak váš K8s rozhodne, napríklad, urobiť upgrade, vypne všetky uzly a vaše dáta odletia ďaleko-daleko."
Rozhodli sme sa urobiť operátora, ktorý, v rozpore s touto radou, spustí databázu Postgres v Kubernetes. A mali sme dobrý základ — . Je to automatický failover pre PostgreSQL, urobil správne, t.j. využívajúci etcd, consul alebo ZooKeeper ako úložisko informácií o klastri. Takéto úložisko, ktoré dáva všetkým, ktorí sa pýtajú, napríklad, ktorý je teraz líder, rovnaké informácie — aj keď máme všetko distribuované, — takže nebude split brain. Navyše, mali sme preň.
Všeobecne, potreba pre auto failover sa objavila po migrácii z interného železného dátového centra do cloudu. Cloud bol založený na vlastnom riešení PaaS (Platform-as-a-Service). Je Open Source, ale na jeho nastavenie bolo potrebné veľa práce. Názov projektu je .
Pôvodne neexistoval žiadny Kubernetes. Presnejšie, keď sa budovalo vlastné riešenie, K8s už existoval, ale bol taký nezrelý, že na produkciu nebol vhodný. Podľa mňa to bol rok 2015 alebo 2016. Do roku 2017 sa Kubernetes stal viac-menej zrelým — objavila sa potreba migrácie sem.
A už sme mali Docker kontajner. Bol tu PaaS, ktorý používal Docker. Prečo nevyužiť K8s? Prečo nenapísať svojho operátora? Murat Kabilov, ktorý k nám prišiel z Avita, začal tento projekt na vlastnú iniciatívu — "pohrávať sa" — a projekt "vzlietol".
Ale vlastne som chcel rozprávať o AWS. Prečo tam bol historicky kód týkajúci sa AWS...
Keď spúšťate čokoľvek v Kubernetes, treba si uvedomiť, že K8s je stále v procese vývoja. Neustále sa vyvíja, zlepšuje a občas sa aj rozbije. Je potrebné pozorne sledovať všetky zmeny v Kubernetes, byť pripravený ponoriť sa do toho a zistiť, ako to funguje v detailoch — možno viac, ako by ste chceli. Toto platí v podstate pre každú platformu, na ktorej spúšťate svoje databázy...
Takže, keď sme robili operátora, mali sme Postgres, ktorý pracoval s externým zväzkom (v tomto prípade EBS, keďže sme pracovali v AWS). Databáza rástla, v určitom momente bolo potrebné urobiť resize: napríklad pôvodná veľkosť EBS bola 100 TB, databáza ju dosiahla a teraz chceme zväčšiť EBS na 200 TB. Ako? Predpokladajme, že je možné urobiť dump/restore na novú inštanciu, ale to trvá dlho a spôsobuje prestoj.
Preto sme chceli taký resize, ktorý by zväčšil oddiel EBS a potom povedal súborovému systému, aby využil nový priestor. A to sme urobili, ale v tom čase nemal Kubernetes žiadne API pre operáciu resize. Keďže sme pracovali na AWS, napísali sme kód pre jeho API.
Nikto nebráni tomu, aby sa to isté urobilo pre iné platformy. V operátorovi nie je viazanosť, že ho možno spustiť len na AWS, a na všetkom ostatnom nebude fungovať. V podstate ide o Open Source projekt: ak niekto chce urýchliť zavedenie nového API — ste vítaní. Existuje , pull-requesty — tím Zalando sa snaží celkom promptne na ne reagovať a posúvať operátora. Ako viem, projekt v Google Summer of Code a v niektorých iných podobných iniciatívach. Zalando na ňom veľmi aktívne pracuje.
P.S. Bonus!
Ak vás zaujíma téma PostgreSQL a Kubernetes, upozorňujeme, že minulý týždeň sa konal nasledujúci Postgres-utork, kde sa s Nikolaiom rozprával Alexander Kukuškin zo Zalando. Video z neho je dostupné .
P.P.S.
Prečítajte si tiež na našom blogu:
- «»;
- «»;
- «»;
- «».
Zdroj: habr.com
