Na konci minulého roku proběhlo další živé vysílání ruské komunity PostgreSQL, , během něhož jeho spoluzakladatel Nikolaj Samochvalov hovořil s technickým ředitelem společnosti „Flant“ Dmitrijem Stolyarovem o této DBMS v kontextu Kubernetes.
Publikujeme přepis hlavní části této diskuse, a na byl zveřejněn kompletní videozáznam:
Databáze a Kubernetes
NS: Dnes nebudeme mluvit o VACUUM a CHECKPOINTech. Chceme hovořit o Kubernetes. Vím, že máš už mnoho let zkušeností. Díval jsem se na tvá videa a některá jsem dokonce koukal několikrát... Pojďme rovnou k věci: proč vlastně Postgres nebo MySQL v K8s?
DS: Na tuto otázku není jednoznačná odpověď a ani nemůže být. Ale obecně to jsou jednoduchost a pohodlnost… potenciální. Všichni chtějí managed služby.
NS: Aby to bylo , jen u sebe?
DS: Ano: aby to bylo jako RDS, jen kdekoli.
NS: „Kdekoli“ — to je dobrá poznámka. Ve velkých firmách je vše rozmístěno na různých místech. A proč tedy, pokud je to velká firma, nevzít hotové řešení? Například Nutanix má své vlastní vývoje, u jiných společností (VMware…) je to stejné „RDS, jen u sebe“.
DS: Ale mluvíme o konkrétní implementaci, která bude fungovat pouze za určitých podmínek. A pokud jde o Kubernetes, existuje obrovská rozmanitost infrastruktury (která může být v K8s). V podstatě je to standard pro API k cloudu…
NS: A navíc zdarma!
DS: To není tak důležité. Bezplatnost je důležitá pro velmi malý segment trhu. Důležité je něco jiného… Určitě si vzpomínáš na můj příspěvek „»?
NS: Ano.
DS: Uvědomil jsem si, že byl přijat velmi rozporuplně. Část lidí si myslela, že říkám: „Lidi, pojeďme se všemi DB do Kubernetes!“, — a jiní se domnívali, že jde o strašné kola. A já chtěl říct úplně něco jiného: „Podívejte se, co se děje, jaké jsou problémy a jak je lze řešit. Teď jít s databázemi do Kubernetes? Do produkce? No, jen pokud máte rádi… zabývat se určitými věcmi. Ale pro dev… mohu říct, že doporučuji. Pro dev je velmi důležitá dynamika vytváření/mazání prostředí.“
NS: Pod dev máš na mysli všechna prostředí, která nejsou prod? Staging, QA…
DS: Když mluvíme o perf-standech, tak už asi ne, protože tam jsou specifické požadavky. Pokud mluvíme o zvláštních případech, kde je na staging potřeba velmi velká DB, tak také asi ne... Pokud je to statické prostředí, které dlouho žije, jaký má smysl, že je databáze umístěna v K8s?
NS: Žádný. Ale kde vidíme statická prostředí? Statické prostředí je už zítra zastaralé.
DS: Staging může být statický. Máme klienty...
NS: Ano, já také. Je to velký problém, pokud máte databázi o velikosti 10 TB a staging — 200 GB...
DS: Mám velmi skvělý případ! Na staging je produkční databáze, do které jsou prováděny změny. A je zde tlačítko: „nasadit do produkce“. Tyto změny — delty — se přidávají (myslím, že se jednoduše synchronizují přes API) do produkce. To je velmi exotičt variant.
NS: Viděl jsem startupy v údolí, které sedí v RDS nebo dokonce v Heroku ještě — to jsou příběhy z před 2-3 lety, — a stahují si dump na svůj notebook. Protože databáze má zatím jen 80 GB a na notebooku je místo. Potom každý dokupuje disky, aby měl 3 databáze na různé projekty. Také jsem viděl, že se nebojí kopírovat prod do staging — hodně to záleží na firmě. Ale viděl jsem i to, že se velmi bojí, a že často chybí čas a ruce. Ale než se dostaneme k tomuto tématu, rád bych slyšel něco o Kubernetes. Chápu správně, že v produktech to zatím nikdo nemá?
DS: Máme malé databáze v produktech. O jakých objemech mluvíme? O desítkách gigabajtů a nekritických službách, pro které se nevyplatilo dělat repliky (a ani není potřeba). A za podmínky, že jsou pod Kubernetesem normální úložiště. Tato databáze pracovala na virtuálním stroji — řekněme v VMware, na vrchu SAN. Umístili jsme ji do a teď ji můžeme přesouvat z jedné mašiny na druhou.
NS: Databáze takové velikosti, do 100 GB, na kvalitních discích a při dobré síti lze rozvinout za několik minut, je to správně? Rychlost 1 GB za sekundu — to už není exotika.
DS: Ano, pro lineární operaci to není problém.
NS: Dobře, o produktech musíme pouze přemýšlet. A pokud uvažujeme o Kubernetes pro ne-prod prostředí — jak to udělat? Vidím, že v Zalando , v Crunchy , existují ještě nějaké varianty. A je zde — to je náš dobrý známý Alvaro ze Španělska: oni dělají v podstatě nejen , ale celou distribuci (), do kterého kromě samotného Postgresu chtěli zahrnout také zálohu, proxy Envoy…
DS: Envoy k čemu? K vyvažování právě provozu Postgresu?
NS: Ano. To znamená, že to vidí takto: pokud vezmeme linuxovou distribuci a jádro, tak obvyklý PostgreSQL je jádro, a oni chtějí vytvořit distribuci, která bude přívětivá pro cloud a poběží v Kubernetes. Spojují komponenty (zálohy apod.) a ladí je, aby dobře pracovaly.
DS: Velmi zajímavé! V podstatě je to software pro vytvoření vlastního spravovaného Postgresu.
NS: U linuxových distribucí jsou věčné problémy: jak vyrobit ovladače, aby byla podporována veškerá hardware. A jejich myšlenka je, že budou fungovat v Kubernetes. Vím, že v operátoru Zalando jsme nedávno viděli vazbu na AWS a to už není příliš dobré. Neměla by být vazba na konkrétní infrastrukturu — v čem je pak smysl?
DS: Nevím, v jaké situaci se konkrétně Zalando dostalo do vazby, ale v Kubernetes je nyní storage uděláno tak, že nelze mít generický způsob, jak udělat diskovou zálohu. Nedávno bylo v poslední verzi standardu — — představena možnost snímků, ale kde je realizována? Čestně, stále je to tak nedokončené… Zkoušíme CSI nad AWS, GCE, Azure, vSphere, ale sotva začnete používat, je jasné, že to ještě není připravené.
NS: Proto se někdy musíte vazat na infrastrukturu. Myslím, že stále pokračuje raná fáze — problémy s růstem. Otázka: co bys doporučil nováčkům, kteří chtějí vyzkoušet PgSQL v K8s? Jaký operátor, možná?
DS: Problém je, že Postgres pro nás představuje 3%. Máme ještě velmi dlouhý seznam různých softwarů v Kubernetes, ani nebudu všechno vyjmenovávat. Například Elasticsearch. Operátorů je spousta: některé se aktivně vyvíjejí, jiné ne. Pro sebe jsme si stanovili požadavky, co by mělo být v operátoru, abychom ho brali vážně. V operátoru určeném výhradně pro Kubernetes — ne v „operátoru, který něco udělá v podmínkách Amazonu“… Fakticky používáme masově (= skoro u všech klientů) jediný operátor — (brzy zveřejníme článek i o něm).
NS: A pro MySQL také není? Vím, že Percona… protože se teď věnují jak MySQL, tak MongoDB a Postgres, musí vyvinout nějakou univerzální variantu: pro všechny databáze, pro všechny cloudové poskytovatele.
DS: Nestihli jsme se podívat na operátory pro MySQL. To není v současnosti náš hlavní fokus. MySQL funguje normálně v standalone. Proč potřebovat operátora, když můžeš prostě spustit databázi… Můžeš spustit Docker kontejner s PostgreSQL, nebo to udělat jednoduše.
NS: O tom byla taky otázka. Opravdu bez operátora?
DS: Ano, 100% máme PostgreSQL spuštěný bez operátora. Zatím to tak je. Aktivně používáme operátora pro Prometheus a Redis. Plánujeme najít operátora pro Elasticsearch – ten je nejvíc „naléhavý“, protože ho chceme vždy rozšiřovat v Kubernetes. Také se snažíme nastavit MongoDB vždy v Kubernetes. Objevil se tady určitý zájem – zdá se, že v těchto případech lze něco udělat. A ohledně Postgresu jsme se ani nedívali. Samozřejmě víme o různých variantách, ale ve skutečnosti máme standalone.
DB pro testování v Kubernetes
NS: Pojďme se přesunout na téma testování. Jak nasazovat změny v databázi – z pohledu DevOps. Jsou tu mikroservisy, hodně databází, pořád někde něco mění. Jak zajistit normální CI/CD, aby z pohledu DB bylo všechno v pořádku. Jaký máš přístup?
DS: Nemůže existovat jediné odpovědi. Je tu několik parametrů. První – to je velikost databáze, kterou chceme nasadit. Sám jsi zmínil, že společnosti se různě staví k tomu, aby kopie produkční databáze byla na dev a staging.
NS: A v kontextu GDPR, myslím, že se k tomu staví čím dál opatrněji… Můžu říct, že v Evropě už začali s tím penalizovat.
DS: Ale často je možné napsat software, který udělá dump z produkce a anonymizuje ho. Získáváš produkční data (snapshot, dump, binární kopii…), ale ta jsou anonymizována. Místo toho mohou být i skripty pro generování: mohou to být fixture nebo jen skript, který generuje velkou databázi. Problém je, jak dlouho trvá vytvoření základního obrazu? A kolik času zabere jeho nasazení na požadovaném prostředí?
Dospěli jsme k schématu: pokud má klient sadu fixture dat (minimální verzi databáze), tak defaultně používáme je. Pokud jde o review prostředí, když jsme vytvořili branch, rozeběhl se nám instance aplikace - tam nasazujeme malou databázi. Ale vyšlo to dobře i tak. , když každý den v noci stahujeme dump z production a na jeho základě vytváříme Docker kontejner s PostgreSQL a MySQL, obsahující těmito nahranými daty. Pokud je třeba z tohoto obrazu nasadit databázi 50krát, dělá se to docela jednoduše a rychle.
NS: Jednoduchým kopírováním?
DS: Data jsou uložena přímo v Docker obraze. Tedy máme hotový obraz, dejme tomu 100 GB. Díky vrstvám v Dockeru můžeme rychle nasazovat tento obraz potřebný početkrát. Způsob je primitivní, ale funguje dobře.
NS: Další, když testujete, mění se to přímo uvnitř Dockeru, že? Copy-on-write v Dockeru — vyhodíme a znovu začneme, vše je v pořádku. Super! A už to naplno používáte?
DS: Už dlouho.
NS: Zabýváme se velmi podobnými věcmi. Pouze my nepoužíváme Dockerovský copy-on-write, ale něco jiného.
DS: Není to generické. Ale Docker funguje všude.
NS: Teoreticky ano. Ale máme tam také moduly, můžeme vytvářet různé moduly a pracovat s různými souborovými systémy. Tady je jeden aspekt. Na PostgreSQL na to všechno nahlížíme jinak. Teď jsem se podíval ze strany Dockeru a viděl, že to u vás funguje. Ale pokud je databáze obrovská, například 1 TB, tak to už trvá dlouho: jak operace v noci, tak nahrávání všeho do Dockeru… A když 5 TB nahráváte do Dockeru… Je to normální?
DS: Jaký je rozdíl: to jsou přece blobové objekty, prostě bity a bajty.
NS: Rozdíl je v tom, že to děláte přes dump a restore?
DS: Vůbec to není nutné. Metody generování tohoto obrazu mohou být různé.
NS: Pro některé klienty jsme to udělali tak, že místo pravidelného generování základního obrazu ho neustále udržujeme v aktuálním stavu. V podstatě je to replikát, ale data nedostává přímo z mastera, ale přes archiv. Binární archiv, do kterého se každý den nasazují WAL soubory, tam se také provádějí zálohy… Tyto WAL soubory poté dorazí — s malým zpožděním (doslova 1-2 sekundy) — do základního obrazu. Z něj klonujeme jakýmkoli způsobem — aktuálně většinou používáme ZFS.
DS: Ale u ZFS jste omezeni jedním uzlem.
NS: Ano. Ale ZFS má také kouzelný : s ním můžete poslat snapshot a dokonce (to jsem ještě moc netestoval, ale…) lze posílat delta mezi dvěma PGDATA. Ve skutečnosti máme ještě jeden nástroj, který jsme neprověřovali pro takové úkoly. V PostgreSQL je , fungující jako „inteligentní“ rsync, který vynechává mnoho z toho, co není potřeba sledovat, protože se tam určitě nic nezměnilo. Můžeme provést rychlou synchronizaci mezi dvěma servery a vrátit se zpět stejným způsobem.
Snažíme se tedy z této, více DBA stránky, vytvořit nástroj, který umožňuje udělat to stejné, o čem jsi mluvil: máme jednu databázi, ale chceme něco testovat 50krát, téměř zároveň.
DS: 50krát znamená, že potřebujete objednat 50 Spot instance.
NS: Ne, všechno děláme na jednom stroji.
DS: Jak ale nasadíte 50krát, pokud je ta jedna databáze například terabajtová. Pravděpodobně potřebuje zhruba 256 GB RAM?
NS: Ano, paměti je občas potřeba hodně — to je normální. Ale takový příklad z praxe. Na produkčním stroji máme 96 jader a 600 GB. Přitom pro databázi používáme 32 jader (dokonce nyní někdy 16 jader) a paměť 100-120 GB.
DS: A tam se vejde 50 kopií?
NS: Ale kopie je jen jedna, dále funguje copy-on-write (ZFS)… Povědět více.
Máme například databázi o velikosti 10 TB. Disk pro ni jsme udělali, ZFS ji ještě zkomprimoval o 30-40%. Protože neděláme zátěžové testování, není pro nás přesný čas odezvy důležitý: může to být dvakrát pomalejší — to je v pořádku.
Dáváme možnost programátorům, QA, DBA atd. provádět testování v 1-2 vláknech. Například mohou spustit nějakou migraci. Ta nevyžaduje okamžitě 10 jader — potřebuje 1 backend Postgresu, 1 jádro. Migrace se spustí — možná, ještě se spustí, potom se využije druhé jádro. Máme vyhrazeno 16-32 jader, takže 10 lidí může pracovat současně, žádné problémy nejsou.
Protože fyzicky PGDATA je to stejné, vychází to tak, že ve skutečnosti klameme Postgres. Jaká je trik: například se spouští 10 Postgresů současně. Jaký je obvykle problém? Nastaví , dejme tomu 25%. Odpovídá to tedy 200 GB. Více než tři z nich už nespustíte, protože paměť dojde.
Ale v nějakém okamžiku jsme pochopili, že to není nutné: nastavujeme shared_buffers na 2 GB. PostgreSQL má , a ve skutečnosti ovlivňuje pouze on . Ten nastavujeme na 0,5 TB. A ani nezáleží na tom, že ve skutečnosti nejsou: staví plány, jako by byly.
Pokud tedy testujeme nějakou migraci, můžeme shromáždit všechny plány — uvidíme, jak to proběhne na produkci. Časové prodlevy budou jiné (pomalejší), ale data, která skutečně čteme, a samotné plány (jaké tam jsou JOINy atd.) vypadají zcela stejně jako na produkci. A zároveň můžeme spustit mnoho takových kontrol na jednom stroji.
DS: Nemyslíš, že tu jsou některé problémy? Za prvé — je to řešení, které funguje pouze na PostgreSQL. Takový přístup je velmi specifický, není univerzální. Za druhé — Kubernetes (a vše, kam nyní směřují cloudové technologie) předpokládá více uzlů, a tyto uzly jsou efemérní. A ve tvém případě se jedná o stateful, perzistentní uzel. Tyto věci ve mně vzbuzují rozpory.
NS: Za prvé — souhlasím, to je čistě postgresová záležitost. Myslím, že pokud máme nějaký direct IO a vyrovnávací paměť téměř pro celou paměť, takový přístup nebude fungovat — plány budou jiné. Ale zatím pracujeme pouze s Postgres, na ostatní nemyslíme.
Co se týče Kubernetes. Všude říkáš, že naše databáze je perzistentní. Pokud instance spadne, hlavní je zachovat disk. My máme také celou platformu v Kubernetes, a komponent s Postgres je odděleně (i když tam jednou bude). Takže to funguje takto: instance spadla, ale zachovali jsme její PV a jednoduše připojili k jiné (nové) instanci, jako by se nic nestalo.
DS: Z mého pohledu vytváříme pod v Kubernetes. K8s je elastický: uzly se objednávají samy podle potřeby. Úkolem je jednoduše vytvořit pod a říct, kolik zdrojů potřebuje, a dál se o to postará K8s. Ale podpora úložišť v Kubernetes je stále nestabilní: v , v (tato verze vyšla před týdnem ) tyto funkce se teprve stávají betou.
Uplyne půl roku až rok — stane se to více či méně stabilním, nebo alespoň takto bude prohlášeno. Tehdy možnost snapshotů a resize již plně vyřeší váš problém. Protože máte databázi. Ano, nemusí být příliš rychlá, ale rychlost závisí na tom, co je 'pod kapotou', protože některé implementace umí kopírování a copy-on-write na úrovni diskového subsystému.
NS: Je také potřeba, aby všechny motory (Amazon, Google…) stihly začít podporovat tuto verzi — to přece také nějaký čas trvá.
DS: Zatím je nepoužíváme. Používáme své vlastní.
Místní vývoj pod Kubernetes
NS: Setkal jsi se někdy s takovou touhou, že bys chtěl spustit všechny podů na jednom stroji a provést malý test. Abychom rychle získali důkaz konceptu a ověřili, že aplikace funguje v Kubernetes, aniž bychom na to museli vyčlenit spoustu strojů. Existuje Minikube, že?
DS: Myslím, že tento případ — nasazení na jednom uzlu — se týká výhradně místního vývoje. Nebo některé projevy takového vzoru. Existuje , existuje , . Jdeme k tomu, že budeme používat Kubernetes ve Dockeru. Teď jsme začali s ním pracovat na testy.
NS: Dříve jsem si myslel, že se jedná o pokus zabalit všechny pody do jednoho Docker obrazu. Ale ukázalo se, že je to úplně o něčem jiném. Pořád jsou tam oddělené kontejnery, oddělené pody — jen v Dockeru.
DS: Ano. A tam je udělána docela zajímavá simulace, ale smysl je takový… Máme utilitu pro nasazení — . Chceme v ní udělat režim — tak posledně werf up: „Zvedni mi lokální Kubernetes“. A poté spustit nějaký werf follow. Takto bude moci vývojář upravovat v IDE, zatímco v systému poběží proces, který sleduje změny a rebuildí obrazy, redeployuje je do lokálního K8s. Takto se chceme pokusit vyřešit problém místního vývoje.
Snímky a klonování databází v realitě K8s
NS: Pokud se vrátíme k copy-on-write. Všiml jsem si, že cloudové služby také nabízejí snímky. Pracují různě. Například v GCP: máš na východním pobřeží USA více než terabytový instance. Pravidelně děláš snímky. Z něj vytváříš kopii disku na západním pobřeží — za pár minut už je vše připraveno, funguje to velmi rychle, jen musíš naplnit cache v paměti. Ale tyto klony (snímky) — jsou na to, abys zprovisionoval nový svazek. To je skvělé, když potřebuješ vytvořit více instancí.
Ale pro testy, zdá se mi, že snímky, o kterých mluvíš v Dockeru nebo já mluvím v ZFS, btrfs a dokonce LVM… — ty umožňují na jednom stroji skutečně netvořit nové data. V cloudu za ně pak budeš muset platit pokaždé a čekání už nebude pár sekund, ale minuty (a v případě , možná i hodiny).
Místo toho můžeš za sekundu-dvě získat tato data, spustit test a vyhodit je. Tyto snímky řeší různé úkoly. V prvním případě — aby se rozšířil a získal nové repliky, a ve druhém — pro testy.
DS: Nesouhlasím. Správně provést klonování objemů je úkol pro cloud. Nezkoumal jsem jejich realizaci, ale vím, jak to děláme my na hardwaru. Máme Ceph, kde můžeme jakémukoli fyzickému objemu () říct clone a získat během desítek milisekund druhý objem se stejnými vlastnostmi, atd. Je třeba chápat, že uvnitř se skrývá složitý copy-on-write. Proč by to cloud nemohl udělat stejně? Jsem si jistý, že se o to snaží různými způsoby.
NS: Ale i tak jim to zabere sekundy, desítky sekund, než zvednou instanci, přinesou tam Docker atd.
DS: Proč nutně zvedat celou instanci? My máme instanci na 32 jader, na 16... a do ní se vejde určité množství — například čtyři. Když objednáváme pátou, už se instanci zvedne, a pak se odstraní.
NS: Ano, zajímavé, v Kubernetes to byl jiný příběh. Naše DB není v K8s a máme jen jednu instanci. Přesto na klonování mnohaterrabytové databáze netrvá více než dvě sekundy.
DS: To je skvělé. Ale můj původní záměr je, že to není generic-řešení. Ano, je to skvělé, ale hodí se pouze pro Postgres a pouze na jednom uzlu.
NS: Nehodí se to jen pro Postgres: to, co popisuji, bude fungovat takto pouze v něm. Ale pokud se nebudeme zabývat plány a potřebujeme jen všechny údaje pro funkční testování, pak to bude vyhovovat jakékoli DBMS.
DS: Před mnoha lety jsme něco podobného dělali na LVM snapshot. To je klasika. Tento přístup byl velmi aktivně používán. Jenže stateful uzly — to je problém. Protože je nesmíte shazovat, musíte je mít neustále na paměti…
NS: Nevidíš zde nějakou možnost hybridu? Dejme tomu, stateful — to je nějaký pod, funguje na více lidech (mnoho testerů). Máme jeden objem, ale díky souborovému systému jsou klony — místní. Pokud pod spadne, disk zůstane — pod se zvedne, informace o všech clonech se načtou, všechno se vrátí zpět a řekne: „Tady jsou vaše klony spuštěny na těchto portech, pracujte s nimi dál.“
DS: Technicky to znamená, že v rámci Kubernetes je to jeden pod, uvnitř kterého spouštíme mnoho Postgresů.
NS: Ano. Má to limit: dejme tomu, současně s ním pracuje maximálně 10 lidí. Pokud potřebujeme 20 — spustíme druhý takový pod. Úplně reálně ho zklonujeme a dostaneme druhý kompletní objem, na něm budou stejné 10 „tenkých“ klonů. Nevidíš takovou možnost?
DS: Je třeba přidat sem otázky bezpečnosti. Tato forma organizace předpokládá, že tento pod má vysoká oprávnění (capabilities), protože může provádět nestandardní operace nad souborovým systémem… Ale opakuji: myslím, že ve střednědobém horizontu Kubernetes opraví storage, v cloudech se vyřeší celé to téma s objemy — všechno bude „jednoduše fungovat“. Bude resize, klonování… Je objem — říkáme: „Vytvoř nový na základě toho“, — a za sekundu a půl dostaneme, co potřebujeme.
NS: Nevím, jestli věřím v sekundu a půl pro mnohá terabajty. Na Ceph to děláš sám, a ty mluvíš o cloudech. Jdi do cloudu, na EC2 udělej klon objemu EBS mnoha terabajtů a podívej se, jaká bude výkonnost. To nezabere několik sekund. Velmi mě zajímá, kdy k takovému výkonu dospějí. Rozumím, o čem mluvíš, ale dovolím si nesouhlasit.
DS: Dobře, ale říkal jsem, že ve střednědobém horizontu, ne krátkodobém. V průběhu několika let.
O operatoru pro PostgreSQL od Zalando
Ve střední části této schůzky se k ní připojil také Alexey Klyukin, bývalý vývojář z firmy Zalando, který pověděl o historii operatora PostgreSQL:
Je skvělé, že se vůbec toto téma dotklo: a Postgres, a Kubernetes. Když jsme začínali tuto věc dělat v Zalando v roce 2017, bylo to takové téma, kterému chtěl každý věnovat, ale nikdo to nedělal. Všichni už měli Kubernetes, ale když se ptali, co s databázemi, tak i takoví lidé jako , kteří hlásali K8s, říkali zhruba toto:
„Jděte do managed služeb a používejte je, nespouštějte DB v Kubernetes. Jinak váš K8s rozhodne, například, provést upgrade, vypne všechny uzly a vaše data poletí daleko, daleko.“
Rozhodli jsme se udělat operatora, který bude, navzdory této radě, spouštět DB Postgres v Kubernetes. A měli jsme dobrý základ — . To je automatický failover pro PostgreSQL, udělaný správně, t.j. používající etcd, consul nebo ZooKeeper jako úložiště informací o clusteru. Takové úložiště, které poskytne všem, kdo se ptají, například, kdo je nyní vůdce, stejnou informaci — i když máme všechno distribuované — aby nedošlo ke split brainu. Navíc, měli jsme pro něj.
Poptávka po auto failoveru u společnosti vznikla po migraci z interního železného datacentra do cloudu. Cloud byl založen na vlastním PaaS (Platform-as-a-Service) řešení. Je open source, ale jeho spuštění si vyžadovalo značné úsilí. Nazývalo se .
Původně žádný Kubernetes nebyl. Přesněji řečeno, když bylo nasazováno vlastní řešení, K8s již existoval, ale byl tak syrový, že na produkci nebyl použitelný. Bylo to, myslím, v roce 2015 nebo 2016. K roku 2017 se Kubernetes stal více méně zralým — vznikla potřeba migrace tam.
A už jsme měli Docker kontejner. Měli jsme PaaS, která používala Docker. Proč to nezkusit s K8s? Proč nenapsat svého operátora? Murat Kabilov, který k nám přišel z Avita, začal s tímto projektem na vlastní iniciativu — 'pohrát si' — a projekt 'vzletěl'.
Ale vlastně jsem chtěl mluvit o AWS. Proč tam byl historicky kód spojený s AWS…
Když spouštíte cokoli v Kubernetes, musíte chápat, že K8s je tak trochu work in progress. Stále se vyvíjí, zlepšuje a občas se i rozbije. Je třeba pečlivě sledovat všechny změny v Kubernetes, být připraven, v případě potřeby se do toho ponořit a zjistit, jak to funguje do detailu — možná více, než byste chtěli. To platí vlastně pro jakoukoli platformu, na které spouštíte své DB…
Takže, když jsme dělali operátora, měli jsme Postgres, který pracoval s externím svazkem (v tomto případě EBS, protože jsme pracovali v AWS). Databáze rostla, v určitém okamžiku bylo potřeba provést resize: například původní velikost EBS byla 100 TB, databáze se k tomu dostala, teď chceme udělat EBS na 200 TB. Jak? Můžete udělat dump/restore na nový instanci, ale to je časově náročné a zpožděné.
Proto jsme chtěli resize, který by zvýšil oddíl EBS a poté říkal souborovému systému, aby využíval nový prostor. A to jsme udělali, ale v té době Kubernetes neměl žádné API pro operaci resize. Protože jsme pracovali na AWS, napsali jsme kód pro jeho API.
Nikdo nebrání udělat totéž pro jiné platformy. V operátoru není žádné závislost, že by mohl běžet pouze na AWS, a na všem ostatním by nefungoval. Celkově je to open source projekt: pokud někdo chce urychlit použití nového API — vítejte. , pull-requests – tým Zalando se snaží na ně reagovat poměrně rychle a propagovat operátora. Jak vím, projekt na Google Summer of Code a dalších podobných iniciativách. Zalando na něm pracuje velmi aktivně.
P.S. Bonus!
Pokud vás zajímá téma PostgreSQL a Kubernetes, věnujte prosím pozornost tomu, že minulý týden proběhl další Postgres-úterý, kde s Nikolajem diskutoval Alexander Kukushkin ze Zalando. Video z něj je k dispozici .
P.P.S.
Přečtěte si také náš blog:
- «»;
- «»;
- «»;
- «».
Zdroj: habr.com
