Tavaly év végén újabb élő adásra került sor az orosz PostgreSQL közösségről , amelynek során társalapítója, Nikolai Samokhvalov a Flant műszaki igazgatójával, Dmitrij Stolyarovval beszélgetett erről a DBMS-ről a Kubernetes kontextusában.
A megbeszélés fő részének átiratát adjuk közre, és itt Teljes videó közzétéve:
Adatbázisok és Kubernetes
NS: A VÁKUUM-ról és az ELLENŐRZŐ PONTokról ma nem beszélünk. A Kubernetesről szeretnénk beszélni. Tudom, hogy sok éves tapasztalatod van. Megnéztem a videóidat, sőt néhányat újra is néztem... Térjünk is rögtön a lényegre: miért van egyáltalán Postgres vagy MySQL a K8s-ban?
DS: Erre a kérdésre nincs és nem is lehet határozott válasz. De általában ez az egyszerűség és a kényelem... lehetőség. Mindenki menedzselt szolgáltatásokat akar.
NS: Hogyan , csak otthon?
DS: Igen: mint az RDS, bárhol.
NS: A „bárhol” jó pont. A nagy cégeknél minden más-más helyen található. Akkor miért nem vállalunk kész megoldást, ha egy nagy cégről van szó? Például a Nutanix saját fejlesztésekkel rendelkezik, más cégeknél (VMware...) ugyanaz az „RDS, csak itthon”.
DS: De egy külön implementációról beszélünk, ami csak bizonyos feltételek mellett fog működni. És ha már a Kubernetesről beszélünk, akkor nagyon sokféle infrastruktúra létezik (ami a K8-ban lehet). Lényegében ez a felhő API-jainak szabványa...
NS: Ez is ingyenes!
DS: Nem olyan fontos. Az ingyenesség a piac nem túl nagy szegmensében fontos. Valami más is fontos... Valószínűleg emlékszel a jelentésre ""?
NS: Igen.
DS: Rájöttem, hogy nagyon félreérthetően fogadták. Néhányan azt hitték, hogy azt mondom: „Srácok, vigyük be az összes adatbázist a Kubernetesbe!”, míg mások úgy gondolták, hogy ezek mind szörnyű kerékpárok. De valami egészen mást akartam mondani: „Nézd, mi történik, milyen problémák vannak, és hogyan lehet ezeket megoldani. Használjunk most Kubernetes adatbázisokat? Termelés? Nos, csak ha szeret... bizonyos dolgokat csinálni. De egy fejlesztőnek azt tudom mondani, hogy ajánlom. Egy fejlesztő számára nagyon fontos a környezetek létrehozásának/törlésének dinamizmusa.”
NS: A fejlesztő alatt minden olyan környezetet értesz, amely nem prod? Színezés, minőségbiztosítás…
DS: Ha a perf standokról beszélünk, akkor valószínűleg nem, mert ott konkrétak a követelmények. Ha olyan speciális esetekről beszélünk, amikor nagyon nagy adatbázis kell a staginghez, akkor valószínűleg nem... Ha ez egy statikus, hosszú életű környezet, akkor mi az előnye annak, hogy az adatbázis a K8s-ban található?
NS: Egyik sem. De hol látunk statikus környezeteket? A statikus környezet holnaptól elavulttá válik.
DS: A rendezés lehet statikus. Vannak ügyfeleink...
NS: Igen, nekem is van. Nagy probléma, ha van egy 10 TB-os adatbázis és 200 GB-os staging...
DS: Nagyon klassz esetem van! A bemutatáskor van egy termékadatbázis, amelyen változtatásokat hajtanak végre. És van egy gomb: „roll out to production”. Ezeket a változtatásokat - deltákat - hozzáadják (úgy tűnik, egyszerűen az API-n keresztül szinkronizálják őket) a termelésben. Ez egy nagyon egzotikus lehetőség.
NS: A Valley-ben láttam olyan startupokat, akik RDS-ben vagy akár Herokuban ülnek - ezek 2-3 évvel ezelőtti történetek -, és letöltik a dump-ot a laptopjukra. Ugyanis az adatbázis még mindig csak 80 GB, és van hely a laptopon. Ezután mindenkinek vásárolnak további lemezeket, hogy legyen 3 adatbázisuk a különböző fejlesztések végrehajtásához. Ez is így történik. Azt is láttam, hogy nem félnek átmásolni a prod-ot a színpadra – ez nagyban a cégtől függ. De azt is láttam, hogy nagyon félnek, és sokszor nincs elég idejük és kezük. Mielőtt azonban rátérnénk erre a témára, szeretnék hallani a Kubernetesről. Jól értem, hogy még senki sincs prodban?
DS: Kis adatbázisaink vannak gyártásban. Több tíz gigabájtos mennyiségről és nem kritikus szolgáltatásokról beszélünk, amelyekhez lusták voltunk replikákat készíteni (és erre nincs is szükség). És feltéve, ha van normális tárhely a Kubernetes alatt. Ez az adatbázis virtuális gépen működött – feltételesen a VMware-ben, a tárolórendszer tetején. Behelyeztük és most átvihetjük gépről gépre.
NS: Az ilyen méretű, akár 100 GB-os adatbázisokat jó lemezeken és jó hálózaton pár perc alatt ki lehet gurítani, nem? A másodpercenkénti 1 GB-os sebesség már nem egzotikus.
DS: Igen, lineáris működésnél ez nem probléma.
NS: Oké, csak a prod-ra kell gondolnunk. És ha a Kubernetes-et nem prod környezetekben fontoljuk meg, mit tegyünk? Ezt látom Zalandóban , Ropogósban , van még néhány lehetőség. És van - ez a mi jó barátunk, Alvaro Spanyolországból: amit csinálnak, az lényegében nem csak , és a teljes disztribúció (), amelybe magán a Postgres mellett úgy döntöttek, hogy egy biztonsági másolatot, az Envoy proxyt is beletömnek...
DS: Minek követ? Konkrétan a Postgres forgalmat egyensúlyozni?
NS: Igen. Vagyis úgy látják, hogy ha egy Linux disztribúciót és kernelt veszünk, akkor a rendes PostgreSQL a kernel, és olyan disztribúciót szeretnének készíteni, amely felhőbarát és Kubernetesen fut. Összerakják az összetevőket (biztonsági mentések stb.), és debuggolnak, hogy jól működjenek.
DS: Nagyon cool! Lényegében ez a szoftver saját felügyelt Postgres létrehozásához.
NS: A Linux disztribúcióknak örök problémáik vannak: hogyan készítsünk illesztőprogramokat úgy, hogy minden hardver támogatott legyen. És az az elképzelésük, hogy Kubernetesben fognak dolgozni. Tudom, hogy a Zalando operátornál nemrégiben láttunk kapcsolatot az AWS-szel, és ez már nem túl jó. Nem szabad egy adott infrastruktúrához kötődni – mi értelme van akkor?
DS: Nem tudom pontosan milyen helyzetbe került Zalando, de a Kubernetesben a tárhely ma már úgy van megcsinálva, hogy nem lehet generikus módszerrel lemezmentést készíteni. Nemrég standardban - a legújabb verzióban — pillanatfelvételeket tettünk lehetővé, de hol valósítják meg? Őszintén szólva még minden olyan nyers... A CSI-t próbáljuk AWS, GCE, Azure, vSphere tetején, de amint elkezdi használni, láthatja, hogy még nincs kész.
NS: Ezért kell néha az infrastruktúrára támaszkodnunk. Azt hiszem, ez még korai szakasz - növekedési fájdalmak. Kérdés: Mit tanácsolna azoknak az újoncoknak, akik szeretnék kipróbálni a PgSQL-t K8-ban? Milyen operátor esetleg?
DS: Az a baj, hogy a Postgres nálunk 3%. A Kubernetesben is nagyon nagy listánk van a különböző szoftverekről, nem is sorolok fel mindent. Például az Elasticsearch. Sok az üzemeltető: egyesek aktívan fejlesztenek, mások nem. Felállítottunk magunknak követelményeket arra vonatkozóan, hogy mi kell egy üzemeltetőnek ahhoz, hogy komolyan vehessük. Kifejezetten Kubernetes operátorban - nem olyan "operátorban, hogy az Amazon körülményei között csináljon valamit"... Valójában elég széles körben (= szinte minden kliens) egyetlen operátort használunk - (hamarosan cikket közölünk róla).
NS: És a MySQL-hez sem? Tudom, hogy a Percona... mivel most a MySQL-en, a MongoDB-n és a Postgres-en dolgoznak, valami univerzális megoldást kell alkotniuk: minden adatbázishoz, minden felhőszolgáltatóhoz.
DS: Nem volt időnk megnézni a MySQL operátorait. Jelenleg nem ez a fő szempontunk. A MySQL jól működik önállóan. Minek használjunk operátort, ha csak egy adatbázist tudunk elindítani... Docker konténert indíthatunk Postrges-el, vagy egyszerű módon is elindíthatjuk.
NS: Ezzel kapcsolatban is volt kérdés. Egyáltalán nincs operátor?
DS: Igen, 100%-unkban a PostgreSQL fut operátor nélkül. Eddig igen. Aktívan használjuk a Prometheus és a Redis operátorát. Terveink között szerepel, hogy az Elasticsearch számára üzemeltetőt találjunk – ez az, amelyik a leginkább „égetett”, mert az esetek 100%-ában a Kubernetesbe szeretnénk telepíteni. Csakúgy, mint azt szeretnénk biztosítani, hogy a MongoDB is mindig telepítve legyen a Kubernetesben. Itt megjelennek bizonyos kívánságok – van egy érzés, hogy ezekben az esetekben lehet tenni valamit. És még csak meg sem néztük a Postgrest. Természetesen tudjuk, hogy vannak különböző lehetőségek, de valójában van egy önálló.
DB Kubernetesben való teszteléshez
NS: Térjünk át a tesztelés témájára. Az adatbázis módosításainak bevezetése - DevOps szemszögéből. Vannak mikroszolgáltatások, sok adatbázis, valahol állandóan változik valami. Hogyan biztosítható a normál CI/CD, hogy DBMS szempontból minden rendben legyen. Mi a te megközelítésed?
DS: Nem lehet egy válasz. Több lehetőség is van. Az első az alap mérete, amelyet ki szeretnénk húzni. Maga említette, hogy a vállalatok eltérően viszonyulnak ahhoz, hogy a gyártási adatbázis másolata legyen a fejlesztői és a színpadon.
NS: A GDPR körülményei között pedig szerintem egyre óvatosabbak... Elmondhatom, hogy Európában már elkezdték a bírságolást.
DS: De gyakran lehet olyan szoftvert írni, amely kihagyja a termelést, és elhomályosítja azt. Prod adatokat kap (pillanatkép, dump, bináris másolat...), de anonimizálja. Ehelyett létezhetnek generáló szkriptek: ezek lehetnek fixture-ek, vagy csak egy szkript, amely egy nagy adatbázist generál. A probléma a következő: mennyi ideig tart egy alapkép elkészítése? És mennyi ideig tart a kívánt környezetben történő telepítése?
Eljutottunk egy sémához: ha a kliensnek van fix adatkészlete (az adatbázis minimális verziója), akkor alapértelmezésben azt használjuk. Ha áttekintési környezetekről beszélünk, amikor létrehoztunk egy ágat, telepítettük az alkalmazás egy példányát - ott egy kis adatbázist teszünk közzé. De jó lett , amikor naponta egyszer (éjszaka) veszünk ki egy kiírást a termelésből, és ez alapján építünk egy Docker konténert PostgreSQL-lel és MySQL-lel ezekkel a betöltött adatokkal. Ha 50-szer kell kibővítenie az adatbázist ebből a képből, ez meglehetősen egyszerűen és gyorsan megtörténik.
NS: Egyszerű másolással?
DS: Az adatok közvetlenül a Docker-képben tárolódnak. Azok. Van egy kész képünk, igaz, 100 GB. A Docker rétegeinek köszönhetően gyorsan telepíthetjük ezt a képet, ahányszor csak szükséges. A módszer hülyeség, de jól működik.
NS: Aztán a tesztelés során a Dockeren belül megváltozik, igaz? Másolás írásra a Dockerben – dobja el, és menjen újra, minden rendben van. Osztály! És már maximálisan kihasználod?
DS: Hosszú ideje.
NS: Nagyon hasonló dolgokat csinálunk. Csak mi nem a Docker másolást használunk, hanem valami mást.
DS: Ez nem általános. A Docker pedig mindenhol működik.
NS: Elméletileg igen. De ott is vannak moduljaink, különböző modulokat készíthet, és különböző fájlrendszerekkel dolgozhat. Micsoda pillanat itt. Postgres oldaláról másképp nézzük mindezt. Most a Docker oldaláról néztem, és láttam, hogy neked minden működik. De ha hatalmas az adatbázis, pl 1 TB, akkor mindez sokáig tart: éjszakai műveletek, meg mindent a Dockerbe tömni... És ha 5 TB-ot beleraknak a Dockerbe... Vagy minden rendben?
DS: Mi a különbség: ezek blobok, csak bitek és bájtok.
NS: A különbség a következő: kiíratással és visszaállítással csinálod?
DS: Egyáltalán nem szükséges. A kép létrehozásának módjai eltérőek lehetnek.
NS: Egyes ügyfeleinknél úgy alakítottuk, hogy a rendszeres alapkép generálás helyett folyamatosan naprakészen tartjuk. Lényegében egy replika, de nem közvetlenül a mestertől kapja az adatokat, hanem egy archívumban. Egy bináris archívum, ahol minden nap letöltődnek a WAL-ok, ahol biztonsági mentések készülnek... Ezek a WAL-ok aztán kis késéssel (szó szerint 1-2 másodperc) érik el az alapképet. Bármilyen módon klónozunk belőle - most már alapból ZFS-ünk van.
DS: De a ZFS-szel egy csomópontra korlátozódik.
NS: Igen. De a ZFS-nek van egy varázslata is : vele tudsz pillanatképet küldeni, sőt (ezt még nem igazán teszteltem, de...) küldhetsz deltát kettő között PGDATA. Valójában van egy másik eszközünk is, amelyet nem igazán vettünk figyelembe az ilyen feladatokhoz. A PostgreSQL rendelkezik , ami úgy működik, mint egy „okos” rsync, sok mindent kihagyva abból, amit nem kell nézni, mert ott nem változott semmi. Gyors szinkronizálást végezhetünk a két szerver között, és ugyanúgy visszatekerhetünk.
Tehát ebből, inkább a DBA oldalról próbálunk létrehozni egy olyan eszközt, amivel ugyanazt tegyük, amit mondtál: van egy adatbázisunk, de szeretnénk valamit 50-szer, szinte egyszerre tesztelni.
DS: 50 alkalom azt jelenti, hogy 50 Spot példányt kell megrendelnie.
NS: Nem, mindent egy gépen csinálunk.
DS: De hogyan fog 50-szeresére bővíteni, ha ez az egy adatbázis mondjuk terabájt. Valószínűleg szüksége van egy feltételes 256 GB RAM-ra?
NS: Igen, néha sok memóriára van szüksége – ez normális. De ez egy példa az életből. A gyártógép 96 magos és 600 GB-os. Ugyanakkor 32 magot (most néha 16 magot is) és 100-120 GB memóriát használnak az adatbázishoz.
DS: És 50 példány belefér?
NS: Tehát csak egy példány van, akkor másolás-írás (ZFS) működik... Elmondom részletesebben.
Például van egy 10 TB-os adatbázisunk. Csináltak hozzá lemezt, a ZFS is tömörítette a méretét 30-40 százalékkal. Mivel nem végzünk terhelési tesztet, a pontos válaszidő számunkra nem fontos: legyen akár 2-szer lassabb – ez rendben van.
Lehetőséget adunk programozóknak, QA, DBA stb. végezzen tesztelést 1-2 szálon. Például futtathatnak valamilyen migrációt. Nem igényel 10 magot egyszerre - 1 Postgres háttérrendszer, 1 mag. Megindul a migráció – talán akkor is elindul, akkor a második mag kerül felhasználásra. Nálunk 16-32 mag van kiosztva, így 10 ember tud egyszerre dolgozni, nem probléma.
Mert fizikailag PGDATA ugyanez, kiderül, hogy valójában becsapjuk Postgrest. A trükk a következő: például 10 Postgre egyszerre indul el. Mi a probléma általában? Raktak , mondjuk 25%. Ennek megfelelően ez 200 GB. Ebből háromnál többet nem fog tudni elindítani, mert lemerül a memória.
De egy ponton rájöttünk, hogy erre nincs szükség: a shared_buffers-t 2 GB-ra állítottuk. A PostgreSQL rendelkezik , és valójában ez az egyetlen, amely befolyásolja . 0,5 TB-ra állítottuk. És még az sem számít, hogy valójában nem is léteznek: úgy tervez terveket, mintha léteznének.
Ennek megfelelően, amikor tesztelünk valamilyen migrációt, összegyűjthetjük az összes tervet – meglátjuk, hogyan fog ez a termelésben megvalósulni. A másodpercek ott mások lesznek (lassabbak), de a ténylegesen beolvasott adatok és maguk a tervek (milyen JOIN-ok vannak, stb.) pontosan ugyanazok, mint a termelésben. És sok ilyen ellenőrzést futtathat párhuzamosan egy gépen.
DS: Nem gondolja, hogy itt van néhány probléma? Az első egy olyan megoldás, amely csak PostgreSQL-en működik. Ez a megközelítés nagyon privát, nem általános. A második az, hogy a Kubernetes (és minden, amire a felhőtechnológiák most készülnek) sok csomópontot foglal magában, és ezek a csomópontok átmenetiek. És az Ön esetében ez egy állapottartó, állandó csomópont. Ezek a dolgok ellentmondásossá tesznek engem.
NS: Először is egyetértek, ez egy tisztán Postgres-történet. Azt hiszem, ha van valamilyen közvetlen IO és puffertárunk szinte az összes memóriához, akkor ez a megközelítés nem fog működni - a tervek mások lesznek. De egyelőre csak a Postgres-szel dolgozunk, nem gondolunk másokra.
A Kubernetesről. Ön mindenhol azt mondja nekünk, hogy állandó adatbázisunk van. Ha a példány meghiúsul, a lényeg a lemez mentése. Itt is megvan a teljes platform Kubernetesben, és a Postgres-es komponens különálló (bár egyszer ott lesz). Ezért minden a következő: a példány leesett, de elmentettük a PV-jét, és egyszerűen csatlakoztattuk egy másik (új) példányhoz, mintha mi sem történt volna.
DS: Az én szempontomból a Kubernetesben hozunk létre podokat. K8s - rugalmas: a csomókat igény szerint rendeljük. A feladat az, hogy egyszerűen hozzon létre egy pod-ot, és mondja ki, hogy X mennyiségű erőforrásra van szüksége, majd a K8s magától kitalálja. De a Kubernetes tárolási támogatása továbbra is instabil: -Ban (ez a kiadás megjelent недели ezelőtt) ezek a funkciók csak béta verzióvá válnak.
Hat hónap-egy év telik el - többé-kevésbé stabil lesz, vagy legalábbis annak nyilvánítják. Ezután a pillanatképek és az átméretezés lehetősége teljesen megoldja a problémát. Mert van alapod. Igen, lehet, hogy nem túl gyors, de a sebesség attól függ, hogy mi van a „burkolat alatt”, mert egyes implementációk képesek másolni és írásra másolni a lemez alrendszer szintjén.
NS: Az is szükséges, hogy minden motor (Amazon, Google...) elkezdje támogatni ezt a verziót - ez is eltart egy ideig.
DS: Még nem használjuk őket. A miénket használjuk.
Helyi fejlesztés Kubernetes számára
NS: Találkoztál már ilyen kívánsággal, amikor az összes podot egy gépre kell telepítened, és egy ilyen kis tesztet kell elvégezned? A koncepció gyors bizonyításához ellenőrizze, hogy az alkalmazás Kubernetesben fut-e anélkül, hogy egy csomó gépet szentelne neki. Ott van a Minikube, igaz?
DS: Számomra úgy tűnik, hogy ez az eset - egy csomóponton telepítve - kizárólag a helyi fejlesztésről szól. Vagy egy ilyen minta néhány megnyilvánulása. Eszik , van , . A Kubernetes IN Docker használata felé haladunk. Most elkezdtünk vele dolgozni a teszteken.
NS: Korábban azt hittem, hogy ez egy kísérlet az összes pod egy Docker-képbe csomagolni. De kiderült, hogy itt egészen másról van szó. Különben is vannak külön konténerek, külön hüvelyek – csak a Dockerben.
DS: Igen. És van egy meglehetősen vicces utánzat, de a jelentése ez... Van egy segédprogramunk a bevetéshez - . Feltételes módot akarunk tenni werf up: "Hozzatok nekem helyi Kuberneteset." És akkor futtassa ott a feltételes parancsot werf follow. Ezután a fejlesztő szerkesztheti az IDE-t, és elindul egy folyamat a rendszerben, amely látja a változásokat és újraépíti a képeket, áthelyezve azokat a helyi K8-asokra. Így szeretnénk megpróbálni megoldani a helyi fejlesztés problémáját.
Pillanatképek és adatbázis klónozás a K8s valóságában
NS: Ha visszatérünk a másolás-írásra. Észrevettem, hogy a felhőknek is vannak pillanatképei. Másként működnek. Például a GCP-ben: van egy több terabájtos példánya az Egyesült Államok keleti partján. Időnként pillanatfelvételeket készít. Pillanatfelvételből előveszed a nyugati parton lévő lemez másolatát - pár perc alatt minden készen van, nagyon gyorsan működik, csak a gyorsítótárat kell feltölteni a memóriába. De ezek a klónok (pillanatképek) azért vannak, hogy új kötetet „létesítsenek”. Ez nagyszerű, ha sok példányt kell létrehoznia.
De a tesztekhez nekem úgy tűnik, hogy a pillanatképek, amiről te a Dockerben beszélsz, vagy én a ZFS-ben, a btrfs-ben és még az LVM-ben is... - lehetővé teszik, hogy ne hozz létre igazán új adatokat egy gépen. A felhőben továbbra is fizetni fog értük, és nem másodperceket, hanem perceket vár (és abban az esetben , esetleg egy óra).
Ehelyett egy-két másodperc alatt megszerezheti ezeket az adatokat, futtathatja a tesztet, és kidobhatja. Ezek a pillanatképek különböző problémákat oldanak meg. Az első esetben - a méretezéshez és az új replikák beszerzéséhez, a másodikban pedig a tesztekhez.
DS: Nem értek egyet. A kötet klónozás megfelelő működése a felhő feladata. Nem néztem a megvalósításukat, de tudom, hogyan csináljuk hardveren. Ceph-unk van, bármilyen fizikai hangerőt engedélyez () mond klón és több tíz ezredmásodperc alatt kap egy második kötetet ugyanazokkal a jellemzőkkel, 'ami stb. Meg kell értened, hogy belül van egy trükkös másolás-írás. Miért ne tehetné ugyanezt a felhő? Biztos vagyok benne, hogy így vagy úgy próbálják ezt megtenni.
NS: De még így is másodpercekbe, több tíz másodpercbe fog telni egy példány felemelése, Docker odahozása stb.
DS: Miért szükséges egy egész példányt felhozni? Van egy példányunk 32 maggal, 16... és belefér - például négy. Amikor megrendeljük az ötödiket, a példány már fel lesz emelve, majd törlődik.
NS: Igen, érdekes, a Kubernetes egészen más történet. Adatbázisunk nem a K8s-ban található, és van egy példányunk. De egy több terabájtos adatbázis klónozása nem tart tovább két másodpercnél.
DS: Ez nagyszerű. De az első megjegyzésem az, hogy ez nem egy általános megoldás. Igen, klassz, de csak a Postgres számára alkalmas, és csak egy csomóponton.
NS: Nem csak a Postgreshez alkalmas: ezek a tervek, ahogy leírtam, csak abban fognak működni. De ha nem törődünk a tervekkel, és csak minden adatra van szükségünk a funkcionális teszteléshez, akkor ez bármilyen DBMS-hez megfelelő.
DS: Sok évvel ezelőtt valami hasonlót csináltunk LVM pillanatfelvételeken. Ez egy klasszikus. Ezt a megközelítést nagyon aktívan alkalmazták. Az állapotjelző csomópontok csak fájdalmat okoznak. Mert nem szabad elejteni őket, mindig emlékezni kell rájuk...
NS: Látsz itt bármilyen lehetőséget a hibridre? Mondjuk a stateful valamiféle pod, több embernél is működik (sok tesztelő). Egy kötetünk van, de a fájlrendszernek köszönhetően a klónok helyiek. Ha a pod leesik, de a lemez megmarad, a pod felemelkedik, megszámolja az összes klónról szóló információt, újra felvesz mindent, és azt mondja: „Itt futnak a klónjai ezeken a portokon, folytassa a munkát velük.”
DS: Technikailag ez azt jelenti, hogy a Kubernetesen belül ez egy pod, amelyen belül sok Postgre fut.
NS: Igen. Van egy határa: mondjuk legfeljebb 10 ember dolgozhat vele egyszerre. Ha 20-ra van szüksége, elindítunk egy második ilyen tokot. Teljesen klónozzuk, miután megkaptuk a második teljes kötetet, ugyanaz a 10 „vékony” klón lesz. Nem látod ezt a lehetőséget?
DS: Itt biztonsági problémákat kell hozzáadnunk. Az ilyen típusú szervezet azt jelenti, hogy ez a pod magas jogosultságokkal (képességekkel) rendelkezik, mert nem szabványos műveleteket tud végrehajtani a fájlrendszeren... De ismétlem: úgy gondolom, hogy középtávon megjavítják a Kubernetesben a tárolást, és a felhőket kötetekkel rögzítik az egész történetet - minden „csak működni fog”. Lesz átméretezés, klónozás... Van egy kötet - mondjuk: „Ez alapján készíts újat”, és másfél másodperc múlva megkapjuk, amire szükségünk van.
NS: Sok terabájtért nem hiszek másfél másodpercben. A Ceph-en te magad csinálod, de a felhőkről beszélsz. Menjen a felhőbe, készítsen klónt egy több terabájtos EBS-kötetről az EC2-n, és nézze meg, milyen lesz a teljesítmény. Nem fog néhány másodpercet igénybe venni. Nagyon érdekel, hogy mikor érik el ezt a szintet. Értem, amit mondasz, de kérek mást.
DS: Ok, de középtávon mondtam, nem rövid távon. Több évig.
A Zalando PostgreSQL operátoráról
A találkozó közepén Alexey Klyukin, egy korábbi zalandói fejlesztő is csatlakozott, és beszélt a PostgreSQL operátor történetéről:
Nagyszerű, hogy ezt a témát általában érintik: Postgres és Kubernetes egyaránt. Amikor 2017-ben elkezdtük csinálni a Zalandóban, ez egy olyan téma volt, amellyel mindenki foglalkozni akart, de senki sem. Mindenkinek volt már Kubernetes, de amikor megkérdezték, mit kezdjenek az adatbázisokkal, még az emberek is szeretik , aki a K8-asokat prédikálta, valami ilyesmit mondott:
„Nyissa meg a felügyelt szolgáltatásokat, és használja azokat, ne futtassa az adatbázist Kubernetesben. Ellenkező esetben a K8-asok úgy döntenek, hogy például frissítenek, kikapcsolják az összes csomópontot, és az adatok messzire, messzire repülnek.”
Úgy döntöttünk, hogy létrehozunk egy üzemeltetőt, amely ezzel a tanácstal ellentétben elindít egy Postgres adatbázist Kubernetesben. És jó okunk volt... . Ez egy automatikus feladatátvétel a PostgreSQL-hez, helyesen megtörtént, pl. az etcd, consul vagy a ZooKeeper használata a klaszterrel kapcsolatos információk tárolására. Egy ilyen tárat, ami mindenkinek, aki megkérdezi, hogy pl. hogy mi a jelenlegi vezető, ugyanazokat az információkat adja - annak ellenére, hogy mindenünk ki van osztva -, hogy ne legyen hasadt agy. Ráadásul nekünk volt neki.
Általánosságban elmondható, hogy a vállalatnak az automatikus feladatátvételi igénye azután jelent meg, hogy egy belső hardveres adatközpontból a felhőbe költöztek. A felhő egy szabadalmaztatott PaaS (Platform-as-a-Service) megoldáson alapult. Nyílt forráskódú, de sok munkát igényelt, hogy beüzemelje. Úgy hívták .
Kezdetben nem volt Kubernetes. Pontosabban a saját megoldásunk bevetésekor már léteztek K8-asok, de az annyira durva volt, hogy nem volt alkalmas gyártásra. Véleményem szerint 2015 vagy 2016 volt. 2017-re a Kubernetes többé-kevésbé kiforrott – szükség volt odavándorlásra.
És már volt egy Docker konténerünk. Volt egy PaaS, amely Dockert használt. Miért nem próbálja ki a K8-at? Miért nem ír saját operátort? Murat Kabilov, aki az Avitóból érkezett hozzánk, saját kezdeményezésére indította el ezt a projektet - "játszani" -, és a projekt "beindult".
De általában az AWS-ről akartam beszélni. Miért volt az AWS-hez kapcsolódó történelmi kód...
Amikor futtat valamit a Kubernetesben, meg kell értenie, hogy a K8s egy folyamatban lévő munka. Folyamatosan fejlődik, fejlődik, sőt időről időre meg is hibázik. Szorosan figyelemmel kell kísérnie a Kubernetes összes változását, készen kell állnia arra, hogy belemerüljön, ha valami történik, és részletesen meg kell tanulnia, hogyan működik - talán jobban, mint szeretné. Ez elvileg minden platformra vonatkozik, amelyen az adatbázisait futtatja...
Tehát amikor megtettük a nyilatkozatot, a Postgres külső köteten futott (ebben az esetben az EBS-en, mivel az AWS-en dolgoztunk). Az adatbázis nőtt, valamikor átméretezni kellett: például az EBS kezdeti mérete 100 TB volt, az adatbázis erre nőtt, most 200 TB-os EBS-t szeretnénk csinálni. Hogyan? Tegyük fel, hogy egy új példányon végezhet kiíratást/visszaállítást, de ez sokáig tart, és leállással jár.
Ezért olyan átméretezést szerettem volna, amely megnöveli az EBS partíciót, majd azt mondja a fájlrendszernek, hogy használja az új területet. És meg is tettük, de akkoriban a Kubernetes nem rendelkezett API-val az átméretezési művelethez. Mivel az AWS-en dolgoztunk, kódot írtunk az API-jához.
Senki sem akadályozza meg, hogy ugyanezt tegye más platformokon is. A nyilatkozatban nincs utalás arra, hogy csak AWS-en futtatható, és minden máson nem fog működni. Általánosságban elmondható, hogy nyílt forráskódú projektről van szó: ha valaki fel akarja gyorsítani az új API használatának megjelenését, szívesen látjuk. Eszik , pull kérések - a Zalando csapata igyekszik elég gyorsan válaszolni rájuk és előléptetni az üzemeltetőt. Amennyire én tudom, a projekt a Google Summer of Code-ban és néhány más hasonló kezdeményezésben. Zalando nagyon aktívan dolgozik ezen.
PS bónusz!
Ha érdekel a PostgreSQL és a Kubernetes téma, kérjük, vegye figyelembe, hogy a következő Postgres keddre múlt héten került sor, ahol Nikolai-val beszéltem Alexander Kukushkin Zalandóból. Videó elérhető belőle .
PPS
Olvassa el blogunkon is:
- «";
- «";
- «";
- «".
Forrás: will.com