Tavaly év végén újabb élő adást tartottak az orosz PostgreSQL közösség keretein belül , amelynek során az alapító, Nikolai Samokhvalov beszélgetett a Flant műszaki igazgatójával, Dmitrij Sztojarlovval erről az adatbázis-kezelőről a Kubernetes kontextusában.
A beszélgetés fő részének átiratát tesszük közzé, míg a a teljes videofelvétel található:
Adatbázisok és Kubernetes
NS: Ma nem a VACUUM-ról és CHECKPOINT-okról fogunk beszélni. A Kubernetesről szeretnénk beszélni. Tudom, hogy már sok évnyi tapasztalatod van. Néztem a videóidat, és néhányat még többször is megnéztem... Kezdjük az elejéről: miért is szükséges a Postgres vagy a MySQL a K8s-ben?
DS: Erre a kérdésre nincs egyértelmű válasz, és nem is lehet. De alapvetően a potenciális egyszerűségről és kényelmességről van szó... Mindenki szeretné a kezelt szolgáltatásokat.
NS: Hogy olyan legyen, mint , csak a saját rendszerünkben?
DS: Igen, hogy olyan legyen, mint az RDS, csak bárhol.
NS: Az, hogy "bárhol" — jó megjegyzés. Nagy cégeknél mindenhol szétszórva találhatóak a dolgok. De ha ez egy nagy cég, miért ne választanánk egy kész megoldást? Például a Nutanix saját fejlesztésekkel rendelkezik, más cégeknél (VMware...) is található "RDS, csak a saját rendszerükben".
DS: De itt egy adott megvalósításról beszélünk, amely csak bizonyos feltételek mellett fog működni. Ha Kubernetesről van szó, itt hatalmas az infrastruktúrák sokfélesége (amely K8s-ben lehet). Ez valójában egy API szabvány a felhőhöz...
NS: Ráadásul ingyenes is!
DS: Ez nem annyira fontos. Az ingyenesség csak egy kisebb piaci szegmens számára lényeges. Más a fontos... Gondolom, emlékszel a "»?
NS: Igen.
DS: Értem, hogy ezt nagyon ellentmondásosan fogadták. Egyesek azt gondolták, hogy azt mondom: "Hölgyeim, hajtsunk minden adatbázist a Kubernetesbe!", míg mások azt, hogy mindez rettenetes kerékpározás. Pedig én teljesen másról akartam beszélni: "Nézzétek, mi történik, mik a problémák és hogyan lehet őket megoldani. Most van értelme az adatbázisokat a Kubernetesbe vinni? A termelési környezetbe? Csak akkor, ha szeretsz... bizonyos dolgokkal foglalkozni. De a fejlesztéshez — azt mondhatom, javaslom. A fejlesztésnél nagyon fontos a környezetek dinamikus létrehozása/törlése."
NS: A fejlesztés alatt minden olyan környezetet értesz, ami nem termelési (prod) környezet? Staging, QA...
DS: Ha a perf-standokról beszélünk, akkor valószínűleg nem, mert ott a követelmények speciálisak. Ha különleges esetekről van szó, ahol a staginghez nagyon nagy adatbázis szükséges, akkor sem, valószínűleg... Ha ez egy statikus környezet, ami hosszú életű, akkor mi az előnye annak, hogy az adatbázis K8s-ben található?
NS: Semmi. De hol látunk statikus környezeteket? A statikus környezet már holnap elavult.
DS: A staging lehet statikus. Vannak ügyfeleink...
NS: Igen, nekem is van. Nagy probléma, ha van egy 10 TB-os adatbázisod, míg a staging csak 200 GB...
DS: Van egy nagyon menő esetem! A stagingen a prod adatbázisa található, amelybe változtatásokat hajtanak végre. Van egy gomb is: „kibocsátás a production-be”. Ezek a változtatások – delta - szinkronizálva vannak (úgy tűnik, csak API-n keresztül) a production-be. Ez egy nagyon egzotikus lehetőség.
NS: Láttam startupokat a Völgyben, amelyek RDS-ben vagy még Heroku-ban ülnek – ezek 2-3 éves történetek, – és ők letöltik a dumpot a laptopjukra. Mert az adatbázis még csak 80 GB, a laptopon pedig van hely. Aztán mindenki vásárol lemezeket, hogy 3 adatbázist tudjon használni, hogy különböző fejlesztéseket folytathasson. Így is érdekes, látom, hogy nem félnek a prod-ot stagingre másolni – ez nagyon attól függ, hogy melyik cégről van szó. De láttam, hogy nagyon félnek tőle, és hogy gyakran nincs elég idő és ember. De mielőtt áttérnénk erre a témára, szeretném hallani, mit mondasz a Kubernetesről. Jól értem, hogy a prod-ban még senkinek nincs?
DS: Nálunk van néhány kis adatbázis a prod-ban. Az összegek néhány tíz gigabájt, és nem kritikus szolgáltatások, ahol lusta voltam replikákat csinálni (meg nem is volt olyan igény). És feltéve, hogy a Kubernetes alatt van normális tárolás. Ez az adatbázis egy virtuális gépen futott – mondjuk VMware alatt, egy tároló rendszer felett. Áthelyeztük az – és most tudjuk vinni egyik gépről a másikra.
NS: Az ilyen méretű adatbázisokat, 100 GB-ig, jó lemezeken és jó hálózaton néhány perc alatt el lehet indítani, igaz? Az 1 GB sebesség már nem egzotikus.
DS: Igen, lineáris művelet esetén ez nem probléma.
NS: Rendben, a prod-ról csak gondolkodnunk kell. De ha a Kubernetes alkalmazását nem prod környezetekhez vizsgáljuk – hogy csináljuk? Látom, hogy a Zalando , a Crunchy , vannak még más lehetőségek is. És ott van – ez a jó ismerősünk Alvaro Spanyolországból: ők lényegében nemcsak , hanem egy teljes disztribúciót (), amelybe maga a Postgres mellett még a mentések is beletartoznak, proxy Envoy…
DS: Mire való az Envoy? A Postgres forgalom kiegyensúlyozására?
NS: Igen. Tehát ők úgy látják, hogy ha van egy Linux disztribúció és kernel, akkor a hagyományos PostgreSQL a kernel, de ők szeretnének egy disztribúciót létrehozni, ami felhőbarát és Kubernetes alatt fut. Összeillesztik a komponenseket (mentések stb.) és finomhangolják, hogy jól működjenek.
DS: Nagyon klassz! Lényegében ez egy szoftver, amely lehetővé teszi, hogy saját kezelt Postgres-ünk legyen.
NS: A Linux disztribúcióknak állandó problémái vannak: hogyan készítsenek drivereket, hogy minden hardver támogasson. Az ő elképzelésük, hogy Kubernetes alatt fognak működni. Tudom, hogy a Zalando operátoránál nemrég láttunk egy AWS kapcsolódást, ami már nem annyira jó. Nem lenne szabad, hogy konkrét infrastruktúrához kötődjenek — mi értelme akkor?
DS: Nem tudom, konkrétan milyen helyzetben kötődött a Zalando, de a Kubernetes jelenlegi tárolása úgy van kialakítva, hogy nem lehet általános módon lemezmentést készíteni. Nemrég a legutolsó verzióban a CSI specifikációban — bevezették a pillanatképek lehetőségét, de hol van ez megvalósítva? Őszintén szólva, még mindig olyan nyers, hogy… Próbálkozunk a CSI-val AWS, GCE, Azure, vSphere fölött, de amikor elkezded használni, látszik, hogy még nincs kész.
NS: Ezért néha kötődni kell az infrastruktúrához. Azt hiszem, ez még mindig a korai szakasz — növekedési problémák vannak. Kérdés: mit javasolnál a kezdőknek, akik ki szeretnék próbálni a PgSQL-t K8s alatt? Milyen operátort ajánlanál?
DS: A probléma az, hogy a Postgres számunkra csak 3%. Van egy nagyon hosszú listánk sok különféle szoftverrel Kubernetes alatt, nem is sorolnám fel mindet. Például Elasticsearch. Sok operátor létezik: egyesek aktívan fejlődnek, mások nem. Mi összeállítottunk egy követelménylistát, hogy mi legyen az operátorban, hogy komolyan vegyük. Az operátor kifejezetten a Kubernetes számára — nem Amazon körülmények között… A ténylegesen használatban lévő operátorunk szinte minden ügyfelünknél (hamarosan megosztunk róla egy cikket is).
NS: De MySQL-hez sincs? Tudom, hogy a Percona… mivel most már a MySQL-t, MongoDB-t és Postgres-t is foglalkoznak, kell, hogy készítsenek egy univerzális megoldást: minden adatbázisra, minden felhőszolgáltatóra.
DS: Nem néztük meg a MySQL operátorokat. Jelenleg ez nem a fő fókuszunk. A MySQL jól működik önállóan. Miért szükséges az operátor, ha egyszerűen elindíthatod az adatbázist… Indíthatsz egy Docker-konténert a Postgres-zel, vagy egyszerűen elindíthatod.
NS: Erről is volt kérdés. Teljesen operátor nélkül?
DS: Igen, 100%-ban a PostgreSQL operátor nélkül fut. Jelenleg így van. Aktívan használunk operátort a Prometheus-hoz, a Redis-hez. Terveink között szerepel, hogy találjunk operátort az Elasticsearch-hez — ez a legfontosabb, mert 100%-ban Kubernetesen szeretnénk telepíteni. Akárcsak a MongoDB-t is mindig Kubernetesen szeretnénk telepíteni. Itt megjelennek bizonyos igények — van egy érzésem, hogy ezekben az esetekben lehetne valamit tenni. A Postgres-ről pedig még csak nem is néztünk. Természetesen tudunk a különböző lehetőségek létezéséről, de valójában önállóan fut.
Adatbázis teszteléshez Kubernetesen
NS: Nézzük meg a tesztelés témáját. Hogyan terjesztjük ki a változásokat az adatbázisban — a DevOps nézőpontjából. Vannak mikroszolgáltatások, sok adatbázis, folyamatosan valahol valami változik. Hogyan biztosítjuk a normális CI/CD-t, hogy az adatbázis szempontjából minden rendben legyen. Mi a te megközelítésed?
DS: Nincs egyértelmű válasz. Számos tényező van. Az első a mérete az adatbázisnak, amelyet ki akarunk terjeszteni. Te is említetted, hogy a cégeknél különbözően viszonyulnak ahhoz, hogy a prod adatbázis másolata dev és stage környezeten legyen.
NS: GDPR keretein belül úgy gondolom, egyre körültekintőbben járnak el… Azt tudom mondani, hogy Európában már elkezdtek büntetni.
DS: De gyakran lehet olyan szoftvert írni, amely dumpot készít a production-ból, és obfuszkálja azt. Az adatok (snapshot, dump, bináris másolat…) anonim módon keletkeznek. Helyette lehetnek generáló szkriptek is: ezek lehetnek fixture-ök vagy egyszerűen csak egy szkript, amely nagy adatbázist generál. A probléma pedig az: mennyi idő alatt készül el az alap kép? És mennyi időbe telik ezt a szükséges környezetben telepíteni?
Eljutottunk ahhoz a sémához: ha az ügyfélnek van fixture adathalmazon (minimum verzió az adatbázisból), akkor alapértelmezés szerint használjuk őket. Ha a review-környezetekről van szó, amikor létrehoztunk egy branchet, és telepítettünk egy példányt az alkalmazásból — ide telepítjük a kicsi adatbázist. De jól megoldottuk és , amikor éjfélkor, naponta egyszer készítünk biztonsági mentést a production-ból, és annak alapján létrehozunk egy Docker-konténert PostgreSQL és MySQL adatbázisokkal ezekkel az adatokkal. Ha ebből a képből 50 alkalommal kell telepíteni az adatbázist, az elég egyszerűen és gyorsan megoldható.
NS: Egyszerű másolással?
DS: Az adatok közvetlenül a Docker-képben tárolódnak. Tehát van egy kész képünk, mondjuk 100 GB méretben. A Docker rétegeinek köszönhetően gyorsan telepíthetjük ezt a képet a szükséges alkalmak számban. Ez egy primitív módszer, de jól működik.
NS: Továbbá, amikor tesztel, az tényleg a Docker-en belül változik, nem? A Docker-en belüli copy-on-write — kiválasztjuk és újra kezdjük, minden rendben. Klassz! Ezt már teljes mértékben használják?
DS: Régen.
NS: Nagyon hasonló dolgokkal foglalkozunk. Csak mi nem a Docker-féle copy-on-write-ot használjuk, hanem valami mást.
DS: Az nem általános. De a Docker-es működik mindenhol.
NS: Elvileg, igen. De nálunk is vannak modulok, lehet különböző modulokat készíteni és különböző fájlrendszerekkel dolgozni. Itt egy dolog van. A Postgres szempontjából erre másképp tekintünk. Most a Docker szempontjából néztem, és láttam, hogy nálatok minden működik. De ha az adatbázis hatalmas, mondjuk 1 TB, akkor az már sokáig tart: mind az éjszakai műveletek, mind pedig mindent Dockerbe pakolni… És ha 5 TB-ot pakolunk Dockerbe… Vagy minden rendben?
DS: Mi a különbség: ezek blobok, csak bitek és byte-ok.
NS: A különbség az, hogy ezt dump és restore útján csináljátok?
DS: Egyáltalán nem szükséges. Az ennek a képnek a generálására szolgáló módszerek különbözőek lehetnek.
NS: Bizonyos ügyfelek számára úgy oldottuk meg, hogy ahelyett, hogy rendszeresen generálnánk alapképet, folyamatosan naprakészen tartjuk. Ez alapvetően egy replikához hasonlít, de az adatokat nem közvetlenül a mestertől kapja, hanem egy archívumon keresztül. Egy bináris archívum, ahová a WAL-ok naponta beérkeznek, ott készülnek a mentések… Ezek a WAL-ok késlekedéssel (mindössze 1-2 másodperc) érkeznek el az alapképre. Ebből bármilyen módon klónozhatunk — most alapértelmezés szerint ZFS-t használunk.
DS: De a ZFS-zel egy csomóban korlátozott vagy.
NS: Igen. De a ZFS-nek van még egy varázslatos : amivel az instant képet el lehet küldeni, és akár (ezt még nem teszteltem igazán, de…) lehet küldeni a delta-t a két között. PGDATA. Valójában van még egy eszközünk, amit nem igazán vizsgáltunk ilyen feladatokra. A PostgreSQL-ben van , amely mint „okos” rsync működik, kihagyva mindent, amit nem érdemes megnézni, mert ott valóban semmi sem változott. Gyors szinkronizálást végezhetünk két szerver között, és pontosan úgy vissza tudunk csavarni.
Úgyhogy azon dolgozunk, hogy ebből a DBA-s oldalról egy olyan eszközt készítsünk, amely lehetővé teszi ugyanazt, amiről beszéltél: van egy adatbázisunk, de 50-szer szeretnénk valamit tesztelni, szinte egyszerre.
DS: 50-szer azt jelenti, hogy 50 Spot példányt kell megrendelni.
NS: Nem, mindent egy gépen csinálunk.
DS: De hogyan telepítesz 50 alkalommal, ha ez az egy adatbázis mondjuk terabájtos? Valószínűleg szüksége van feltételezve 256 GB RAM-ra?
NS: Igen, néha sok memóriára van szükség — ez rendben van. De egy példa az életből. A production gépen 96 mag és 600 GB van. Ebből az adatbázis számára 32 magot használnak (most már 16 mag is néha elég) és 100-120 GB memóriát.
DS: És oda belesűríthető 50 másolat?
NS: De a másolat az egy, továbbra is copy-on-write működik (ZFS-es)… Mesélek bővebben.
Nálunk például egy 10 TB adatbázis van. A számára készített lemez ZFS-sel még 30-40%-kal összenyomta a méretét. Mivel nem végzünk terheléses tesztelést, számunkra a pontos válaszidő nem fontos: legyen akár kétszer lassabb — az rendben van.
Lehetőséget adunk a programozóknak, QA-nak, DBA-nak, stb. hogy 1-2 szálon végezzenek tesztelést. Például elindíthatnak valamilyen migrációt. Ehhez nem kell azonnal 10 mag — egy backend Postgres-re van szükség, 1 mag. A migráció el fog indulni — lehet, még elindul, akkor a második mag bekapcsolódik. 16-32 mag van elkülönítve, így 10 ember egyszerre dolgozhat, nincsenek problémák.
Mivel fizikailag PGDATA ugyanaz, valójában megtévesztjük a Postgres-t. A lényeg abban rejlik: például 10 Postgres-t indítunk el egyszerre. Mi a kérdés általában? Beállítás , mondjuk, 25%-ra. Ennek megfelelően ez 200 GB. Három ilyen példányt már nem indíthat el, mert elfogy a memória.
De egy pillanatban rájöttünk, hogy erre nincs szükség: a shared_buffers-t 2 GB-ra állítjuk. A PostgreSQL-nek van , és valójában csak ez befolyásolja a . Ezt 0,5 TB-ra állítjuk. És még az sem számít, hogy valójában nincsenek: terveket épít, mintha lennének.
Tehát amikor migrációt tesztelünk, összegyűjthetjük az összes tervet - láthatjuk, hogyan fog zajlani a produkciós környezetben. A másodpercek lassabbak lesznek, de az adatok, amelyeket valójában olvasunk, és a tervek (milyen JOIN-ok stb.) pontosan olyanok lesznek, mint a produkciós környezetben. Emellett több ilyen ellenőrzést is párhuzamosan indíthatunk egy gépen.
DS: Nem gondolod, hogy itt van néhány probléma? Az első - ez a megoldás csak PostgreSQL-en működik. Ez a megközelítés nagyon specifikus, nem általánosítható. A második - a Kubernetes (és minden, amerre a felhőtechnológiák tartanak) számos csomópontot feltételez, és ezek a csomópontok efemeriek. A te esetedben viszont ez állandó, tartós csomópont. Ezek a dolgok ellentmondásokat okoznak számomra.
NS: Az első - egyetértek, ez tisztán a Postgres története. Gondolom, ha van valamilyen közvetlen IO és a puffertároló majdnem az egész memóriát lefedi, akkor ez a megközelítés nem működik - a tervek mások lesznek. De mi egyelőre csak a Postgres-szel foglalkozunk, másokkal nem gondolkozunk.
A Kubernetesről. Te is mindenütt elmondod, hogy az adatbázisunk tartós. Ha az instance összeomlik, a legfontosabb a lemezkép megőrzése. Nálunk is az egész platform Kubernetesben működik, és a Postgres összetevő külön van (bár egyszer az is ott lesz). Tehát így van: az instance összeomlott, de megőriztük a PV-t, és egyszerűen csatlakoztattuk egy másik (új) instance-hez, mintha mi sem történt volna.
DS: Véleményem szerint podokat hozunk létre a Kubernetesben. A K8s rugalmas: a csomópontok önállóan rendelik meg magukat, ahogy szükséges. A feladat egyszerűen egy pod létrehozása és annak megmondása, hogy X erőforrásra van szüksége, a többi a K8s-ra bízva. De a tárolástámogatás a Kubernetesben még mindig instabil: a , in (ez a kiadás megjelent hetet ezelőtt) ezek a funkciók csak béta állapotúak.
Eltelik fél év-egy év - az már többé-kevésbé stabil lesz, vagy legalábbis úgy fogják hirdetni. Akkor a pillanatfelvételek és a méretezés lehetősége teljes mértékben megoldja a problémádat. Mert van egy adatbázisod. Igen, lehet, hogy nem éppen gyors, de a sebesség attól függ, hogy mi van a 'motorháztető alatt', mert egyes megvalósítások képesek a másolásra és a copy-on-write-ra a lemezkörnyezet szintjén.
NS: Itt még azt is figyelembe kell venni, hogy minden motor (Amazon, Google…) elmondása szerint elkezdje támogatni ezt a verziót - ez is eltart egy ideig.
DS: Jelenleg nem használjuk őket. A sajátunkat használjuk.
Helyi fejlesztés Kubernetes alatt
NS: Találkoztál már olyan igénnyel, hogy egy gépen kellene felállítanod az összes podot, és egy kis tesztet végezni? Hogy gyorsan proof of concept-et kapj, megnézni, hogy az alkalmazás működik Kubernetes alatt, anélkül, hogy sok gépet foglalkoznál vele. Van Minikube, ugye?
DS: Szerintem ez az eset — egy csomóponton történő üzemeltetés — kifejezetten a helyi fejlesztésről szól. Vagy valamilyen megnyilvánulása ennek a mintának. Van , van , . Arra megyünk, hogy Kubernetes in Docker-t használjunk. Most kezdtünk el dolgozni vele tesztekhez.
NS: Régen azt hittem, hogy ez az összes podot egy Docker-képre próbálja becsomagolni. De kiderült, hogy egészen másról van szó. Úgyis tesztelünk különböző konténerekkel, külön podokkal — csak Docker alatt.
DS: Igen. Ott elég szórakoztató utánzat készült, de a lényeg az... Van egy eszközünk a telepítéshez — . Azt akarjuk, hogy legyen egy mód — mondjuk, werf up: „Állítsd fel nekem a helyi Kubernetes-t”. Aztán indítsd el ott feltételesen a werf follow. Akkor a fejlesztő IDE-ben tud szerkeszteni, miközben a rendszerben fut egy folyamat, ami észleli a változásokat és újraépíti a képeket, újra telepíti őket a helyi K8s-be. Így próbáljuk megoldani a helyi fejlesztés problémáját.
A snapshotok és az adatbázis klónozás a K8s valóságában
NS: Ha visszatérünk a copy-on-write-hoz. Észrevettem, hogy a felhőszolgáltatóknak is vannak snapshotjaik. Ezek különbözően működnek. Például a GCP-n: van egy több terabájtos instance-od az Egyesült Államok keleti partján. Időnként készítesz snapshotokat. A snapshotból felállítasz egy másolatot a nyugati parton — néhány perc múlva már minden kész, nagyon gyorsan működik, csak a gyorsítótárat kell feltölteni a memóriába. De ezek a klónok (snapshotok) arra valók, hogy „provision”-ölj egy új kötetet. Ez nagyszerű, amikor sok instance-ot kell létrehozni.
De a tesztekhez, úgy érzem, a snapshotok, amikről te beszélsz Dockerben, vagy amikről én beszélek ZFS, btrfs és akár LVM... — ezek éppen arra szolgálnak, hogy egy gépen valójában ne kelljen új adatokat létrehozni. A felhőben viszont minden alkalommal fizetni fogsz értük, és nem másodpercekben, hanem percekben fogod várni (és a , lehet, hogy órákban is).
Helyette másodpercek alatt megkaphatod ezeket az adatokat, futhatsz egy tesztet és eldobhatod. Ezek a snapshotok különböző feladatokat oldanak meg. Az első esetben, hogy skálázzunk és új replikákat kapjunk, míg a második esetben — teszteléshez.
DS: Nem értek egyet. A megfelelő kötetklónozás feladata a felhőé. Nem néztem meg a megvalósításukat, de tudom, hogy mi hogyan csináljuk vasalaton. Van Ceph-ünk, amiben bárkinek meg lehet mondani egy fizikai kötetet () és néhány tizedmásodperc alatt megkapja a második kötetet azonos jellemzőkkel, clone IOPS : De nekik akkor is másodpercek, tizedmásodpercek fognak eltelni, hogy felállítsák az instanszt, a Docker-t stb.
NS: Miért kell feltétlenül egy egész instansz? Van nálunk egy 32 magos instansz, 16… és abba belefér néhány — például négy. Amikor az ötödiket kérjük, már új instansz jön létre, aztán el fog tűnni.
DS: Igen, érdekes, a Kubernetes-ben más a helyzet. Nálunk az adatbázis nem fut K8s-en, és ez egy instansz. Viszont a több terabájtos adatbázis klónozása nem tart tovább két másodpercnél.
NS: Ez menő. De az alapvető gondolatom az, hogy ez nem általános megoldás. Igen, klassz, de csak a Postgreshez megfelelő, és csak egy node-on.
DS: Nem csak a Postgreshez jó: ezek a tervek, ahogy leírtam, csak benne fognak így működni. De ha nem foglalkozunk a tervekkel, és csak az adatokat akarjuk a funkcionális teszteléshez, akkor ez bármilyen DBMS-re megfelelő lesz.
NS: Sok évvel ezelőtt hasonlót csináltunk LVM snapshotokkal. Ez klasszikus. Ez a megközelítés nagyon aktívan alkalmazva volt. Csak a stateful node-ok — ez fájdalom. Mert őket sosem szabad elfelejteni, mindig emlékezni kell rájuk...
DS: Nem látsz itt valami hibrid lehetőséget? Tegyük fel, a stateful — ez egy pod, ami több ember (sok tesztelő) munkáját szolgálja ki. Egy kötetünk van, de a fájlrendszernek köszönhetően a klónok — helyi. Ha a pod leáll, a lemez megmarad — a pod újraérkezik, az összes klónról információt olvas be, mindent visszaállít és azt mondja: „Íme, a klónjaid ezekkel a portokkal elindultak, dolgozz velük tovább”.
NS: Technikai értelemben ez azt jelenti, hogy Kubernetes keretein belül ez egy pod, amely belsejében sok Postgres-t futtatunk.
DS: Igen. Van egy korlátja: például egyszerre nem dolgozhat vele több mint 10 ember. Ha 20-ra van szükség — akkor elindítunk egy második podot. Teljesen reális úgy klónozni, hogy kapunk egy második teljes kötetet, amelyen ugyanolyan 10 „vékony” klón lesz. Nem látsz ilyen lehetőséget?
NS: Igen. Van egy korlátja: például egyszerre nem dolgozhat vele több mint 10 ember. Ha 20-ra van szükség — akkor elindítunk egy második podot. Teljesen reális úgy klónozni, hogy kapunk egy második teljes kötetet, amelyen ugyanolyan 10 „vékony” klón lesz. Nem látsz ilyen lehetőséget?
DS: Biztonsági kérdéseket kell hozzáadni ide. Ez a szervezési választási lehetőség azt feltételezi, hogy ennek a podnak magas jogosultságai (capabilities) vannak, mert nem szabványos operációkat végezhet a fájlrendszeren... De megismétlem: úgy gondolom, hogy középtávon a Kubernetes javítani fogja a tárolást, a felhőben megoldják a kötetekkel kapcsolatos összes problémát - minden „egyszerűen működni fog”. Lesz méretezés, klónozás... Van egy kötet - azt mondjuk: „Hozd létre az újat az alap alapján”, és másfél másodperc múlva megkapjuk, amire szükség van.
NS: Nem hiszek az másfél másodpercben sok terabájt esetében. A Ceph-on te csinálod magad, de a felhőről beszélsz. Menj a felhőbe, az EC2-n klónozz egy EBS kötetet sok terabájtnyi adatból, és nézd meg, milyen teljesítmény lesz. Ez nem fog néhány másodpercet igénybe venni. Nagyon érdekel, mikor érik el ezt a teljesítményt. Értem, mire gondolsz, de megengedem magamnak, hogy ne értsünk egyet.
DS: Rendben, de azt mondtam, hogy középtávon, nem rövidtávon. Néhány éven belül.
A Zalando PostgreSQL operátoráról
A találkozó közepén Alexey Klyukin, a Zalando volt fejlesztője is csatlakozott, aki elmesélte a PostgreSQL operátor történetét:
Remek, hogy egyáltalán felvetődött ez a téma: mind a Postgres, mind a Kubernetes. Amikor 2017-ben elkezdtük csinálni a Zalando-nál, ez olyan téma volt, amely iránt mindenki érdeklődött, de senki sem foglalkozott vele. Mindenkinek már volt Kubernetes-e, de amikor megkérdezték, mi legyen az adatbázisokkal, olyan emberek, mint , akik a K8s-t hirdették, körülbelül a következőket mondták:
„Menjetek a kezelt szolgáltatásokhoz és használjátok azokat, ne indítsátok el az adatbázist Kubernetes alatt. Ellenkező esetben a K8s például úgy dönt, hogy frissítést végez, leállít minden csomópontot, és az adatait messzire repíti.”
Úgy döntöttünk, hogy készítünk egy operátort, amely, ellentétben ezzel a tanáccsal, PostgreSQL adatbázisokat futtat Kubernetes alatt. És jó alapunk volt - . Ez egy automatikus failover PostgreSQL-hez, helyesen megvalósítva, azaz az etcd, consul vagy ZooKeeper használatával cluster információk tárolására. Olyan tárolóra van szükség, amely mindenki számára, aki kérdez, például a jelenlegi vezetőről, ugyanazt az információt adja - annak ellenére, hogy mindez elosztott - hogy ne legyen split brain. Plusz, volt nekünk számára.
A vállalatnak az auto failover iránti igénye a belső adatközpontból a felhőbe való migráció után merült fel. A felhő egy saját PaaS (Platform-as-a-Service) megoldáson alapult. Nyílt forráskódú, de eléggé meg kellett dolgozni annak beüzemeléséhez. Így hívták .
Kezdetben nem volt Kubernetes. Pontosabban, amikor a saját megoldásunkat telepítettük, a K8s már létezett, de annyira kezdetleges volt, hogy a production környezetben nem használható. Úgy vélem, ez 2015 vagy 2016 volt. 2017-re a Kubernetes viszonylag éretté vált – felmerült a migráció szükségessége.
Már volt Docker-konténerünk. Volt egy PaaS, ami Docker-t használt. Miért ne próbálnánk ki a K8s-t? Miért ne írnánk saját operátort? Murat Kabilov, aki az Avitótól érkezett hozzánk, ezt egy saját kezdeményezésű projektként kezdte — hogy "játsszon", — és a projekt "megszületett".
De valójában az AWS-ről akartam mesélni. Miért volt ott történetileg AWS-hez kapcsolódó kód...
Amikor valamit indítasz a Kubernetes-ben, figyelembe kell venni, hogy a K8s egy folyamatosan fejlődő rendszer. Folyamatosan fejlődik, javul, és időnként még meg is hibásodik. Gondosan figyelni kell minden változásra a Kubernetes-ben, készen kell állni arra, hogy amennyiben szükséges, mélyebben megismerkedjen vele és kiderítse, hogyan működik részleteiben — lehet, hogy többet, mint szeretnéd. Ez általában minden platform esetében így van, amelyen az adatbázisaidat futtatod...
Tehát, amikor operátort készítettünk, volt egy Postgresünk, amely egy külső tárolóval működött (jelen esetben EBS, mivel AWS-en dolgoztunk). Az adatbázis nőtt, és egy adott pillanatban szükségessé vált a méretezés: például az eredeti EBS méret 100 TB volt, az adatbázis elérte ezt a méretet, most pedig 200 TB-os EBS-t szeretnénk. Hogyan? Mondjuk, meg lehetne csinálni a dump/restore-t egy új példányra, de ez hosszú ideig tart és leállással jár.
Ezért olyan méretezést akartunk, ami növeli az EBS partíciót, majd figyelmezteti a fájlrendszert, hogy használja az új területet. Ezt megcsináltuk, de akkoriban a Kubernetes-nek nem volt API-ja a méretezési művelethez. Mivel az AWS-en dolgoztunk, kódot írtunk az API-jához.
Senki sem akadályoz meg abban, hogy ugyanazt más platformokra is megcsinálja. Az operátor nem kötődik ahhoz, hogy csak AWS-en futtatható, hanem másutt is működhet. Ez egy nyílt forráskódú projekt: ha valaki szeretné felgyorsítani az új API használatának megjelenését — szívesen látjuk. , a pull request — a Zalando csapata igyekszik elég gyorsan reagálni rájuk és előmozdítani az operátort. Amennyire tudom, a projekt a Google Summer of Code-ban és hasonló kezdeményezésekben. A Zalando nagyon aktívan dolgozik rajta.
P.S. Bónusz!
Ha érdeklik a PostgreSQL és Kubernetes témák, akkor figyeljenek, hogy múlt héten megrendezésre került a következő Postgres-kedd, ahol Nikolajjal beszélgetett Alexander Kukushkin a Zalandoffól. A videó elérhető .
P.P.S.
Olvasson további információkat a blogunkban:
- «»;
- «»;
- «»;
- «».
Forrás: habr.com
