Koncem loňského roku proběhlo další živé vysílání ruské komunity PostgreSQL , během níž její spoluzakladatel Nikolaj Samokhvalov hovořil s technickým ředitelem Flant Dmitrijem Stolyarovem o tomto DBMS v kontextu Kubernetes.
Zveřejňujeme přepis hlavní části této diskuse a na Zveřejněno celé video:
Databáze a Kubernetes
NA: O VAKUUM a CHECKPOINTech se dnes bavit nebudeme. Chceme mluvit o Kubernetes. Vím, že máte dlouholeté zkušenosti. Sledoval jsem vaše videa a některá z nich jsem dokonce zhlédl znovu... Pojďme rovnou k věci: proč Postgres nebo MySQL v K8 vůbec?
DS: Na tuto otázku neexistuje a nemůže být jednoznačná odpověď. Ale obecně jde o jednoduchost a pohodlí... potenciál. Každý chce řízené služby.
NA: Jak , jen doma?
DS: Ano: jako RDS, prostě kdekoli.
NA: „Kdekoliv“ je dobrý bod. Ve velkých firmách se vše nachází na různých místech. Proč tedy, když se jedná o velkou společnost, nevzít hotové řešení? Například Nutanix má svůj vlastní vývoj, jiné společnosti (VMware...) mají stejné „RDS, jen doma“.
DS: Ale bavíme se o samostatné implementaci, která bude fungovat jen za určitých podmínek. A pokud mluvíme o Kubernetes, pak existuje obrovská rozmanitost infrastruktury (která může být v K8). V podstatě se jedná o standard pro API do cloudu...
NA: Je to také zdarma!
DS: To není tak důležité. Bezplatnost je důležitá pro nepříliš velký segment trhu. Důležité je něco jiného... Pravděpodobně si vzpomínáte na reportáž “"?
NA: Ano.
DS: Uvědomil jsem si, že to bylo přijato velmi nejednoznačně. Někteří lidé si mysleli, že říkám: „Kluci, pojďme dostat všechny databáze do Kubernetes!“, zatímco jiní usoudili, že to všechno jsou hrozná kola. Chtěl jsem ale říci něco úplně jiného: „Podívejte se, co se děje, jaké jsou problémy a jak je lze řešit. Měli bychom nyní používat databáze Kubernetes? Výroba? No, jen když rád...děláš určité věci. Ale pro vývojáře mohu říci, že doporučuji. Pro vývojáře je dynamika vytváření/mazání prostředí velmi důležitá.“
NS: Tím dev máte na mysli všechna prostředí, která nejsou prod? Staging, QA…
DS: Pokud mluvíme o výkonových stojanech, pak pravděpodobně ne, protože požadavky tam jsou specifické. Pokud mluvíme o speciálních případech, kdy je pro staging potřeba velmi velká databáze, pak pravděpodobně ne... Pokud se jedná o statické prostředí s dlouhou životností, jakou výhodu má umístění databáze v K8?
NA: Žádný. Kde ale vidíme statická prostředí? Statické prostředí zítra zastará.
DS: Inscenace může být statická. Máme klienty...
NA: Ano, taky jeden mám. Je to velký problém, pokud máte 10 TB databázi a 200 GB staging...
DS: Mám velmi skvělý případ! Při stagingu existuje databáze produktů, ve které se provádějí změny. A je tam tlačítko: „vydat do výroby“. Tyto změny - delty - jsou přidány (zdá se, že jsou jednoduše synchronizovány přes API) ve výrobě. Toto je velmi exotická možnost.
NA: Viděl jsem startupy ve Valley, které sedí v RDS nebo dokonce v Heroku – to jsou příběhy z doby před 2-3 lety – a stahují si výpis do svého notebooku. Protože databáze má stále jen 80 GB a na notebooku je místo. Pak pro všechny dokoupí další disky, aby měli 3 databáze k provádění různého vývoje. Tak se to také děje. Taky jsem viděl, že se nebojí zkopírovat prod do stagingu - hodně záleží na firmě. Ale také jsem viděl, že se velmi bojí, a že často nemají dost času a rukou. Ale než přejdeme k tomuto tématu, chci slyšet o Kubernetes. Chápu to správně, že ještě nikdo není v prod?
DS: Máme malé databáze v prod. Bavíme se o objemech desítek gigabajtů a nekritických službách, u kterých jsme byli líní dělat repliky (a taková potřeba není). A to za předpokladu, že pod Kubernetes je normální úložiště. Tato databáze fungovala ve virtuálním stroji – podmíněně ve VMware, nad úložným systémem. Vložili jsme to a teď to můžeme přenést ze stroje na stroj.
NA: Databáze této velikosti, až 100 GB, lze na dobrých discích a dobré síti spustit během několika minut, ne? Rychlost 1 GB za vteřinu už není exotická.
DS: Ano, pro lineární provoz to není problém.
NA: Dobře, jen musíme myslet na prod. A pokud uvažujeme o Kubernetes pro neprodukční prostředí, co bychom měli dělat? Vidím to na Zalandu , v Crunchy , existují další možnosti. A existuje - to je náš dobrý přítel Alvaro ze Španělska: to, co dělají, není v podstatě jen a celá distribuce (), do kterého se kromě samotného Postgresu rozhodli nacpat i zálohu, Envoy proxy...
DS: Vyslanec za co? Konkrétně vyvažování provozu Postgres?
NA: Ano. To znamená, že to vidí takto: když vezmete linuxovou distribuci a jádro, pak jádro je běžný PostgreSQL a chtějí vytvořit distribuci, která bude přátelská ke cloudu a bude fungovat na Kubernetes. Dávají dohromady komponenty (zálohy atd.) a ladí je tak, aby dobře fungovaly.
DS: Skvělý! V podstatě se jedná o software pro vytvoření vlastního spravovaného Postgresu.
NA: Linuxové distribuce mají věčné problémy: jak udělat ovladače tak, aby byl podporován veškerý hardware. A mají představu, že budou pracovat v Kubernetes. Vím, že u operátora Zalando jsme nedávno viděli spojení s AWS a to už není moc dobré. Neměla by existovat vazba na konkrétní infrastrukturu – jaký to má potom smysl?
DS: Nevím přesně, do jaké situace se Zalando dostal, ale úložiště Kubernetes je nyní vytvořeno tak, že není možné provést zálohu disku pomocí obecné metody. Nedávno ve standardu - v nejnovější verzi — umožnili jsme snímky, ale kde je to implementováno? Upřímně, všechno je ještě takové syrové... Zkoušíme CSI nad AWS, GCE, Azure, vSphere, ale jakmile to začnete používat, vidíte, že to ještě není hotové.
NA: Proto se někdy musíme spolehnout na infrastrukturu. Myslím, že je to ještě rané stádium - růstové bolesti. Otázka: Jakou radu byste dal nováčkům, kteří chtějí vyzkoušet PgSQL v K8? Jaký operátor asi?
DS: Problém je, že Postgres je pro nás 3 %. V Kubernetes máme také velmi velký seznam různého softwaru, nebudu ani vyjmenovávat všechno. Například Elasticsearch. Operátorů je mnoho: někteří se aktivně rozvíjejí, jiní ne. Sestavili jsme na sebe požadavky, co by mělo být v operátorovi, abychom to brali vážně. V operátorovi speciálně pro Kubernetes - ne v "operátorovi, který dělá něco v podmínkách Amazonu"... Ve skutečnosti poměrně široce (= téměř všichni klienti) používáme jediného operátora - (brzy o něm zveřejníme článek).
NA: A pro MySQL taky ne? Vím, že Percona... protože nyní pracují na MySQL, MongoDB a Postgres, budou muset vytvořit nějaké univerzální řešení: pro všechny databáze, pro všechny poskytovatele cloudu.
DS: Neměli jsme čas podívat se na operátory pro MySQL. To teď není naše hlavní zaměření. MySQL funguje dobře samostatně. Proč používat operátora, když stačí spustit databázi... Kontejner Docker můžete spustit pomocí Postrges, nebo jej můžete spustit jednoduchým způsobem.
NA: Na to byl taky dotaz. Vůbec žádný operátor?
DS: Ano, 100% z nás má PostgreSQL spuštěný bez operátora. Zatím ano. Aktivně využíváme operátora pro Prometheus a Redis. Máme v plánu najít operátora pro Elasticsearch – ten je nejvíce „v plamenech“, protože ho chceme do Kubernetes nainstalovat ve 100 % případů. Stejně jako chceme zajistit, aby byl MongoDB také vždy nainstalován v Kubernetes. Zde se objevují určitá přání - existuje pocit, že v těchto případech lze něco udělat. A to jsme se ani nepodívali na Postgres. Samozřejmě víme, že existují různé možnosti, ale ve skutečnosti máme samostatný.
DB pro testování v Kubernetes
NA: Přejděme k tématu testování. Jak zavést změny do databáze – z pohledu DevOps. Existují mikroslužby, mnoho databází, neustále se někde něco mění. Jak zajistit normální CI/CD, aby bylo z pohledu DBMS vše v pořádku. Jaký je váš přístup?
DS: Nemůže existovat jedna odpověď. Možností je několik. První je velikost základny, kterou chceme vyválet. Sám jste zmínil, že společnosti mají různé přístupy k tomu, aby měly kopii databáze produktů na vývojáři a na jevišti.
NA: A v podmínkách GDPR si myslím, že jsou čím dál opatrnější... Můžu říct, že v Evropě už začali pokutovat.
DS: Ale často můžete napsat software, který vezme výpis z výroby a zatemní ho. Získávají se data produktu (snímek, výpis, binární kopie...), ale jsou anonymizována. Místo toho mohou existovat generační skripty: mohou to být přípravky nebo jen skript, který generuje velkou databázi. Problém je: jak dlouho trvá vytvoření základního obrázku? A jak dlouho trvá jeho nasazení v požadovaném prostředí?
Došli jsme ke schématu: pokud má klient fixní datovou sadu (minimální verzi databáze), pak je standardně používáme. Pokud se bavíme o recenzních prostředích, když jsme vytvořili větev, nasadili jsme instanci aplikace – tam nasadíme malou databázi. Ale dopadlo to dobře , kdy si jednou denně (v noci) vezmeme dump z výroby a na jeho základě postavíme Docker kontejner s PostgreSQL a MySQL s těmito načtenými daty. Pokud potřebujete z tohoto obrázku rozšířit databázi 50x, uděláte to zcela jednoduše a rychle.
NA: Jednoduchým kopírováním?
DS: Data jsou uložena přímo v obrazu Dockeru. Tito. Máme hotový obraz, i když 100 GB. Díky vrstvám v Dockeru můžeme tento obrázek rychle nasadit tolikrát, kolikrát potřebujeme. Metoda je hloupá, ale funguje dobře.
NA: Potom, když testujete, změní se to přímo v Dockeru, že? Copy-on-write uvnitř Dockeru - zahoďte to a jděte znovu, vše je v pořádku. Třída! A využíváte ho už naplno?
DS: Na dlouhou dobu.
NA: Děláme velmi podobné věci. Pouze nepoužíváme Dockerův copy-on-write, ale nějaký jiný.
DS: Není to generické. A Docker funguje všude.
NA: Teoreticky ano. Ale máme tam i moduly, můžete dělat různé moduly a pracovat s různými systémy souborů. Co chvíli tady. Ze strany Postgresu se na to všechno díváme jinak. Teď jsem se podíval ze strany Dockeru a viděl jsem, že vám vše funguje. Ale pokud je databáze obrovská, např. 1 TB, tak to všechno trvá dlouho: operace v noci, a cpát všechno do Dockeru... A když se do Dockeru nacpe 5 TB... Nebo je vše v pořádku?
DS: Jaký je rozdíl: jsou to bloby, jen bity a bajty.
NA: Rozdíl je tento: děláte to pomocí výpisu a obnovení?
DS: Není to vůbec nutné. Způsoby generování tohoto obrázku mohou být různé.
NA: U některých klientů jsme to udělali tak, že místo pravidelného generování základního obrazu jej neustále aktualizujeme. Je to v podstatě replika, ale data nepřijímá přímo od hlavního serveru, ale prostřednictvím archivu. Binární archiv, kde se každý den stahují WAL, kde se pořizují zálohy... Tyto WAL se pak dostanou k základnímu obrazu s mírným zpožděním (doslova 1-2 sekundy). Klonujeme z něj jakýmkoliv způsobem – nyní máme standardně ZFS.
DS: Ale se ZFS jste omezeni na jeden uzel.
NA: Ano. Ale ZFS má také kouzlo : s ním můžete poslat snímek a dokonce (ještě jsem to pořádně netestoval, ale...) můžete poslat deltu mezi dvěma PGDATA. Ve skutečnosti máme další nástroj, který jsme pro takové úkoly opravdu nezvažovali. PostgreSQL má , který funguje jako „chytrý“ rsync a přeskakuje spoustu toho, co sledovat nemusíte, protože se tam nic nezměnilo. Můžeme provést rychlou synchronizaci mezi dvěma servery a přetočit stejným způsobem.
Takže z této, více DBA strany, se snažíme vytvořit nástroj, který nám umožní dělat to samé, co jste řekli: máme jednu databázi, ale chceme něco otestovat 50krát, téměř současně.
DS: 50krát znamená, že musíte objednat 50 instancí Spot.
NA: Ne, děláme vše na jednom stroji.
DS: Ale jak se rozšíříte 50krát, když je tato databáze řekněme terabajtová. S největší pravděpodobností potřebuje podmíněných 256 GB RAM?
NA: Ano, někdy potřebujete hodně paměti – to je normální. Ale to je příklad ze života. Produkční stroj má 96 jader a 600 GB. Pro databázi je přitom použito 32 jader (nyní někdy i 16 jader) a 100-120 GB paměti.
DS: A vešlo se tam 50 kopií?
NA: Takže existuje pouze jedna kopie, pak funguje kopírování při zápisu (ZFS)... Řeknu vám to podrobněji.
Máme například 10TB databázi. Udělali na to disk, ZFS také komprimoval jeho velikost o 30-40 procent. Vzhledem k tomu, že neprovádíme zátěžové testování, není pro nás přesná doba odezvy důležitá: nechte ji být až 2krát pomalejší – to je v pořádku.
Dáváme příležitost programátorům, QA, DBA atd. proveďte testování v 1-2 vláknech. Mohou například spustit nějaký druh migrace. Nevyžaduje 10 jader najednou - potřebuje 1 Postgres backend, 1 jádro. Začne migrace – možná se stále spustí, pak se použije druhé jádro. Máme přiděleno 16-32 jader, takže může pracovat 10 lidí současně, žádný problém.
Protože fyzicky PGDATA stejně se ukazuje, že ve skutečnosti klameme Postgres. Trik je v tomto: například 10 Postgres je spuštěno současně. V čem je obvykle problém? Dali , řekněme 25 %. Podle toho se jedná o 200 GB. Nebudete moci spustit více než tři z nich, protože dojde paměť.
Ale v určitém okamžiku jsme si uvědomili, že to není nutné: nastavili jsme shared_buffers na 2 GB. PostgreSQL má a ve skutečnosti je to jediné, co ovlivňuje . Nastavili jsme to na 0,5 TB. A nezáleží ani na tom, že ve skutečnosti neexistují: dělá plány, jako by existovaly.
Podle toho, když otestujeme nějakou migraci, můžeme shromáždit všechny plány - uvidíme, jak to bude ve výrobě. Vteřiny tam budou jiné (pomalejší), ale data, která skutečně čteme, a samotné plány (jaké tam jsou JOINy atd.) vycházejí úplně stejně jako ve výrobě. A na jednom počítači můžete paralelně provádět mnoho takových kontrol.
DS: Nemyslíš, že je tady pár problémů? První je řešení, které funguje pouze na PostgreSQL. Tento přístup je velmi soukromý, není obecný. Druhým je, že Kubernetes (a vše, k čemu se nyní cloudové technologie chystají) zahrnuje mnoho uzlů a tyto uzly jsou pomíjivé. A ve vašem případě je to stavový, trvalý uzel. Tyto věci ve mně vyvolávají konflikty.
NA: Za prvé, souhlasím, toto je čistě příběh Postgres. Myslím, že pokud budeme mít nějaké přímé IO a buffer pool pro téměř veškerou paměť, tento přístup nebude fungovat – plány budou jiné. Ale zatím pracujeme jen s Postgres, na ostatní nemyslíme.
O Kubernetes. Sami nám všude říkáte, že máme trvalou databázi. Pokud instance selže, hlavní věcí je uložit disk. Tady máme také celou platformu v Kubernetes a komponenta s Postgresem je samostatná (i když tam jednou bude). Vše je tedy takové: instance spadla, ale my jsme její PV uložili a jednoduše ji připojili k jiné (nové) instanci, jako by se nic nestalo.
DS: Z mého pohledu vytváříme pody v Kubernetes. K8s - elastické: uzly se objednávají dle potřeby. Úkolem je jednoduše vytvořit modul a říct, že potřebuje X množství zdrojů, a pak na to K8s přijdou samy. Ale podpora úložiště v Kubernetes je stále nestabilní: V (tato verze byla vydána недели před) se tyto funkce stávají pouze beta.
Uplyne šest měsíců až rok – víceméně se to ustálí, nebo to tak bude alespoň deklarováno. Pak možnost snímků a změny velikosti váš problém zcela řeší. Protože máte základnu. Ano, nemusí to být příliš rychlé, ale rychlost závisí na tom, co je „pod kapotou“, protože některé implementace mohou kopírovat a kopírovat při zápisu na úrovni diskového subsystému.
NA: Je také nutné, aby všechny enginy (Amazon, Google...) začaly podporovat tuto verzi - to také nějakou dobu trvá.
DS: Zatím je nepoužíváme. My používáme naše.
Místní vývoj pro Kubernetes
NA: Narazili jste na takové přání, když potřebujete nainstalovat všechny pody na jeden stroj a udělat takový malý test. Chcete-li rychle získat důkaz o konceptu, podívejte se, že aplikace běží v Kubernetes, aniž byste pro ni vyhradili spoustu strojů. Je tam Minikube, že?
DS: Zdá se mi, že tento případ - nasazený na jeden uzel - je výhradně o místním rozvoji. Nebo nějaké projevy takového vzoru. Jíst , tam je , . Směřujeme k používání Kubernetes IN Docker. Nyní jsme s tím začali pracovat na testy.
NA: Dříve jsem si myslel, že jde o pokus zabalit všechny moduly do jednoho obrázku Dockeru. Jenže se ukázalo, že tady jde o něco úplně jiného. Každopádně existují samostatné kontejnery, samostatné pody - prostě v Dockeru.
DS: Ano. A vznikla docela vtipná napodobenina, ale smysl je takový... Máme utilitu pro nasazení - . Chceme z toho udělat podmíněný režim werf up: "Dejte mi místní Kubernetes." A pak tam spusťte podmínku werf follow. Poté bude vývojář schopen upravit IDE a v systému bude spuštěn proces, který uvidí změny a přestaví obrazy a znovu je nasadí na místní K8. Takto se chceme pokusit vyřešit problém místního rozvoje.
Snímky a klonování databáze v realitě K8s
NA: Pokud se vrátíme ke kopírování při zápisu. Všiml jsem si, že mraky mají také snímky. Fungují jinak. Například v GCP: máte multiterabajtovou instanci na východním pobřeží Spojených států. Pravidelně pořizujete snímky. Kopii disku na západním pobřeží si vyzvednete ze snapshotu – za pár minut je vše připraveno, funguje to velmi rychle, jen je potřeba vyplnit mezipaměť. Ale tyto klony (snímky) jsou proto, aby „poskytly“ nový svazek. To je skvělé, když potřebujete vytvořit mnoho instancí.
Ale pro testy se mi zdá, že snapshoty, o kterých mluvíte v Dockeru nebo já v ZFS, btrfs a dokonce i LVM... - umožňují nevytvářet na jednom stroji skutečně nová data. V cloudu za ně budete stále platit pokaždé a čekat ne sekundy, ale minuty (a v případě , případně hodinky).
Místo toho můžete tato data získat během sekundy nebo dvou, spustit test a zahodit je. Tyto snímky řeší různé problémy. V prvním případě - pro zvětšení a získání nových replik a ve druhém - pro testy.
DS: Nesouhlasím. Zajistit, aby klonování objemu fungovalo správně, je úkolem cloudu. Nedíval jsem se na jejich implementaci, ale vím, jak to děláme na hardwaru. Máme Ceph, umožňuje jakýkoli fyzický objem () říct klonovat a získat druhý svazek se stejnými vlastnostmi za desítky milisekund, 'ami atd. Musíte pochopit, že uvnitř je složité kopírování na zápis. Proč by totéž neměl dělat cloud? Jsem si jistý, že se o to pokoušejí tak či onak.
NA: Ale stejně jim bude trvat sekundy, desítky sekund, než vzbudí instanci, přivedou tam Dockera atd.
DS: Proč je nutné vyvolávat celou instanci? Máme instanci s 32 jádry, 16... a vejde se do ní - třeba čtyři. Když objednáme pátou, instance již bude vyvolána a poté bude smazána.
NA: Ano, zajímavé, Kubernetes se ukazuje jako jiný příběh. Naše databáze není v K8 a máme jednu instanci. Ale klonování multiterabajtové databáze netrvá déle než dvě sekundy.
DS: To je skvělé. Ale můj počáteční bod je, že to není obecné řešení. Ano, je to skvělé, ale je vhodné pouze pro Postgres a pouze na jednom uzlu.
NA: Hodí se nejen pro Postgres: tyto plány, jak jsem popsal, budou fungovat pouze v něm. Pokud se ale nestaráme o plány a potřebujeme všechna data pro funkční testování, pak je to vhodné pro jakýkoli DBMS.
DS: Před mnoha lety jsme udělali něco podobného na snímcích LVM. Tohle je klasika. Tento přístup byl velmi aktivně využíván. Stavové uzly jsou jen bolest. Protože byste je neměli upustit, měli byste si je vždy pamatovat...
NA: Vidíte zde nějakou možnost hybridu? Řekněme, že stavový je nějaký druh modulu, který funguje pro několik lidí (mnoho testerů). Máme jeden svazek, ale díky souborovému systému jsou klony lokální. Pokud modul spadne, ale disk zůstane, modul se zvedne, spočítá informace o všech klonech, vše znovu vyzvedne a řekne: „Tady jsou vaše klony běžící na těchto portech, pokračujte v práci s nimi.“
DS: Technicky to znamená, že v rámci Kubernetes je to jeden modul, ve kterém provozujeme mnoho Postgres.
NA: Ano. Má limit: řekněme, že s ním nepracuje více než 10 lidí současně. Pokud potřebujete 20, spustíme druhý takový modul. Plně jej naklonujeme, po obdržení druhého plného svazku bude mít stejných 10 „tenkých“ klonů. Nevidíte tuto příležitost?
DS: Zde musíme přidat bezpečnostní problémy. Z tohoto typu organizace vyplývá, že tento pod má vysoká privilegia (schopnosti), protože může provádět nestandardní operace na souborovém systému... Ale opakuji: věřím, že ve střednědobém horizontu opraví úložiště v Kubernetes a v mraky opraví celý příběh svazky - vše bude „prostě fungovat“. Dojde ke změně velikosti, klonování... Existuje svazek – řekneme: „Na základě toho vytvořte nový,“ a po sekundě a půl dostaneme, co potřebujeme.
NA: Nevěřím v jeden a půl sekundy na mnoho terabajtů. Na Cephu to děláš sám, ale mluvíš o oblacích. Přejděte do cloudu, vytvořte klon víceterabajtového svazku EBS na EC2 a uvidíte, jaký bude výkon. Nezabere to pár sekund. Velmi mě zajímá, kdy dosáhnou této úrovně. Rozumím tomu, co říkáte, ale dovoluji si se odlišit.
DS: Dobře, ale řekl jsem střednědobě, ne krátkodobě. Již několik let.
O operátorovi pro PostgreSQL od Zalanda
Uprostřed tohoto setkání se připojil také Alexey Klyukin, bývalý vývojář ze Zalanda, a hovořil o historii operátora PostgreSQL:
Je skvělé, že se toto téma dotýká obecně: Postgres i Kubernetes. Když jsme to v roce 2017 na Zalandu začali dělat, bylo to téma, které chtěl dělat každý, ale nikdo to neudělal. Každý už měl Kubernetes, ale když se zeptali, co dělat s databázemi, i lidem se to líbí , který kázal K8, řekl něco takového:
„Přejděte na spravované služby a používejte je, nespouštějte databázi v Kubernetes. Jinak se vaše K8 rozhodnou například provést upgrade, vypnout všechny uzly a vaše data poletí daleko, daleko.“
Rozhodli jsme se udělat operátora, který oproti této radě spustí databázi Postgres v Kubernetes. A měli jsme dobrý důvod - . Jedná se o automatické převzetí služeb při selhání pro PostgreSQL, provedené správně, tzn. pomocí etcd, consul nebo ZooKeeper jako úložiště informací o clusteru. Takové úložiště, které dá každému, kdo se například zeptá, jaký je současný lídr, stejné informace – navzdory tomu, že máme vše rozdané – aby nedošlo k rozštěpení mozku. Navíc jsme měli pro něj.
Obecně platí, že potřeba společnosti po automatickém převzetí služeb při selhání se objevila po migraci z interního hardwarového datového centra do cloudu. Cloud byl založen na proprietárním řešení PaaS (Platform-as-a-Service). Je to Open Source, ale jeho zprovoznění dalo hodně práce. Říkalo se tomu .
Zpočátku neexistoval žádný Kubernetes. Přesněji řečeno, když bylo nasazeno naše vlastní řešení, K8 již existovaly, ale byly tak hrubé, že nebyly vhodné pro výrobu. Podle mého názoru to byl rok 2015 nebo 2016. Do roku 2017 se Kubernetes stal víceméně dospělým – bylo potřeba migrovat tam.
A už jsme měli kontejner Docker. Existoval PaaS, který používal Docker. Proč nezkusit K8? Proč nenapsat vlastního operátora? Murat Kabilov, který k nám přišel z Avita, to začal jako projekt z vlastní iniciativy – „to play“ – a projekt „se rozjel“.
Ale obecně jsem chtěl mluvit o AWS. Proč existoval historický kód související s AWS...
Když něco spustíte v Kubernetes, musíte pochopit, že K8s je taková práce ve vývoji. Neustále se vyvíjí, zdokonaluje a čas od času i bourá. Musíte bedlivě sledovat všechny změny v Kubernetes, musíte být připraveni se do toho ponořit, pokud se něco stane, a naučit se podrobně, jak to funguje – možná víc, než byste chtěli. To v zásadě platí pro jakoukoli platformu, na které provozujete své databáze...
Když jsme tedy provedli prohlášení, nechali jsme Postgres běžet na externím svazku (v tomto případě EBS, protože jsme pracovali na AWS). Databáze se rozrůstala, v určitém okamžiku bylo nutné její velikost: například počáteční velikost EBS byla 100 TB, databáze na ni narostla, nyní chceme udělat EBS 200 TB. Jak? Řekněme, že můžete provést výpis/obnovu na nové instanci, ale bude to trvat dlouho a bude to vyžadovat prostoje.
Proto jsem chtěl změnu velikosti, která by zvětšila oddíl EBS a pak řekla systému souborů, aby použil nový prostor. A udělali jsme to, ale Kubernetes v té době neměl žádné API pro operaci změny velikosti. Protože jsme pracovali na AWS, napsali jsme kód pro jeho API.
Nikdo vám nebrání udělat totéž pro jiné platformy. V prohlášení není žádný náznak, že jej lze spustit pouze na AWS a nebude fungovat na všem ostatním. Obecně se jedná o Open Source projekt: pokud chce někdo urychlit nástup používání nového API, jste vítáni. Jíst , pull requesty - tým Zalando se na ně snaží celkem rychle reagovat a propagovat operátora. Pokud vím, tak projekt na Google Summer of Code a některých dalších podobných iniciativách. Zalando na tom velmi aktivně pracuje.
PS Bonus!
Pokud vás zajímá téma PostgreSQL a Kubernetes, pak si prosím také uvědomte, že minulý týden proběhlo další Postgres Tuesday, kde jsem mluvil s Nikolajem Alexander Kukushkin ze Zalanda. Video z něj je k dispozici .
PPS
Přečtěte si také na našem blogu:
- «";
- «";
- «";
- «".
Zdroj: www.habr.com