Klienti stále častěji dostávají následující požadavky: „Chceme to jako Amazon RDS, ale levnější“; "Chceme to jako RDS, ale všude, v jakékoli infrastruktuře." Při implementaci takto spravovaného řešení na Kubernetes jsme se podívali na aktuální stav nejoblíbenějších operátorů pro PostgreSQL (Stolon, operátoři z Crunchy Data a Zalando) a vybrali jsme si.
Tento článek je zkušenostmi, které jsme získali jak z teoretického hlediska (přehled řešení), tak z praktické stránky (co bylo vybráno a co z toho vzešlo). Nejprve si ale ujasněme, jaké jsou obecné požadavky na potenciální náhradu RDS...
Co je RDS
Když lidé mluví o RDS, podle našich zkušeností mají na mysli spravovanou službu DBMS, která:
- snadné nastavení;
- má schopnost pracovat se snímky a obnovovat z nich (nejlépe s podporou );
- umožňuje vytvářet topologie master-slave;
- má bohatý seznam rozšíření;
- poskytuje audit a správu uživatelů/přístupů.
Obecně řečeno, přístupy k realizaci daného úkolu mohou být velmi odlišné, ale cesta s podmíněným Ansible nám není blízká. (Kolegové z 2GIS ve výsledku došli k podobnému závěru vytvořit "nástroj pro rychlé nasazení clusteru s podporou převzetí služeb při selhání založeného na Postgres.")
Operátoři jsou běžným přístupem k řešení podobných problémů v ekosystému Kubernetes. Technický ředitel „Flanta“ o nich již mluvil podrobněji v souvislosti s databázemi spuštěnými uvnitř Kubernetes. V .
NB: Pro rychlé vytvoření jednoduchých operátorů doporučujeme věnovat pozornost naší utilitě Open Source . S jeho pomocí to můžete udělat bez znalosti Go, ale způsoby, které jsou správcům systému známější: v Bash, Pythonu atd.
Existuje několik oblíbených operátorů K8s pro PostgreSQL:
- Odnož;
- Crunchy Data Operator PostgreSQL;
- Provozovatel Zalando Postgres.
Pojďme se na ně podívat blíže.
Výběr operátora
Kromě již zmíněných důležitých funkcí jsme – jako provozní inženýři infrastruktury Kubernetes – od operátorů očekávali také následující:
- nasazení z Git a s ;
- anti-afinitní podpora pod;
- instalace afinity uzlů nebo selektoru uzlů;
- instalace tolerancí;
- dostupnost možností ladění;
- srozumitelné technologie a dokonce i příkazy.
Aniž bych se pouštěl do podrobností o každém z bodů (zeptejte se v komentářích, pokud k nim máte po přečtení celého článku stále otázky), obecně poznamenám, že tyto parametry jsou potřebné k přesnějšímu popisu specializace uzlů clusteru, aby bylo možné objednat je pro konkrétní aplikace. Tímto způsobem můžeme dosáhnout optimální rovnováhy z hlediska výkonu a nákladů.
Nyní přejděme k samotným operátorům PostgreSQL.
1. Stolon
od italské společnosti Sorint.lab in byl považován za jakýsi standard mezi operátory pro DBMS. Jedná se o poměrně starý projekt: jeho první veřejné vydání proběhlo v listopadu 2015(!) a úložiště GitHub se může pochlubit téměř 3000 40 hvězdičkami a více než XNUMX přispěvateli.
Stolon je skutečně vynikajícím příkladem promyšlené architektury:
Zařízení tohoto operátora najdete podrobně ve zprávě popř . Obecně postačí říci, že umí vše popsané: failover, proxy pro transparentní klientský přístup, zálohování... Proxy navíc poskytují přístup přes jednu službu koncového bodu - na rozdíl od dalších dvou řešení diskutovaných níže (každý má dvě služby pro přístupová základna).
Nicméně Stolon , proto jej nelze nasadit tak, aby bylo snadné a rychlé – „jako horké koláče“ – vytvářet instance DBMS v Kubernetes. Správa se provádí prostřednictvím utility stolonctl, nasazení se provádí prostřednictvím diagramu Helm a vlastní jsou definovány a specifikovány v ConfigMap.
Na jednu stranu se ukazuje, že operátor ve skutečnosti operátorem není (koneckonců nepoužívá CRD). Ale na druhou stranu je to flexibilní systém, který vám umožňuje konfigurovat zdroje v K8, jak uznáte za vhodné.
Abych to shrnul, pro nás osobně se nezdálo optimální vytvářet pro každou databázi samostatný graf. Proto jsme začali hledat alternativy.
2. Crunchy Data PostgreSQL Operator
, mladý americký startup, se jevil jako logická alternativa. Jeho veřejná historie začíná prvním vydáním v březnu 2017, od té doby repozitář GitHub získal necelých 1300 50 hvězdiček a 1.15+ přispěvatelů. Nejnovější vydání ze září bylo testováno, aby fungovalo s Kubernetes 1.18-3.11, OpenShift 4.4+ a 1.3+, GKE a VMware Enterprise PKS XNUMX+.
Architektura Crunchy Data PostgreSQL Operator také splňuje uvedené požadavky:
Správa probíhá prostřednictvím nástroje pgo, ale zase generuje vlastní zdroje pro Kubernetes. Operátor nás proto jako potenciální uživatele potěšil:
- existuje ovládání přes CRD;
- pohodlná správa uživatelů (i přes CRD);
- integrace s dalšími komponentami — specializovaná kolekce obrázků kontejnerů pro PostgreSQL a utilit pro práci s ním (včetně pgBackRest, pgAudit, rozšíření z contrib atd.).
Pokusy začít používat operátor z Crunchy Data však odhalily několik problémů:
- Neexistovala žádná možnost tolerancí - je poskytován pouze nodeSelector.
- Vytvořené moduly byly součástí Deployment, přestože jsme nasadili stavovou aplikaci. Na rozdíl od StatefulSets nemohou Deployments vytvářet disky.
Poslední nedostatek vede k vtipným momentům: na testovacím prostředí se nám podařilo spustit 3 repliky s jedním diskem místní úložiště, což způsobí, že operátor hlásí, že 3 repliky fungují (i když ne).
Další vlastností tohoto operátoru je jeho hotová integrace s různými pomocnými systémy. Například je snadné nainstalovat pgAdmin a pgBounce a in jsou brány v úvahu předem nakonfigurované Grafana a Prometheus. V nedávném Samostatně je zmíněna zlepšená integrace s projektem , díky čemuž operátor nabízí přehlednou vizualizaci PgSQL metrik hned z krabice.
Podivný výběr zdrojů generovaných Kubernetes nás však vedl k nutnosti najít jiné řešení.
3. Provozovatel Zalando Postgres
Produkty Zalando známe již dlouho: s používáním Zalenium máme zkušenosti a samozřejmě jsme je vyzkoušeli je jejich oblíbené HA řešení pro PostgreSQL. O přístupu firmy k tvorbě řekl ve vysílání jeden z jeho autorů Alexej Klyukin , a líbilo se nám to.
Toto je nejmladší řešení diskutované v článku: první vydání proběhlo v srpnu 2018. I přes malý počet formálních vydání však projekt ušel dlouhou cestu a již nyní předčil v popularitě řešení od Crunchy Data s 1300+ hvězdičkami na GitHubu a maximálním počtem přispěvatelů (70+).
„Pod kapotou“ tento operátor používá časem prověřená řešení:
- Patroni a pro řízení,
- - pro zálohy,
- - jako spojovací bazén.
Takto je prezentována operátorská architektura od Zalando:
Operátor je plně spravován prostřednictvím vlastních zdrojů, automaticky vytváří StatefulSet z kontejnerů, které lze poté přizpůsobit přidáním různých postranních vozíků do modulu. To vše je výrazná výhoda ve srovnání s operátorem z Crunchy Data.
Vzhledem k tomu, že jsme mezi 3 zvažovanými možnostmi vybrali řešení od Zalando, další popis jeho schopností bude uveden níže, bezprostředně spolu s praxí aplikace.
Cvičte s Postgres Operator ze Zalanda
Nasazení operátora je velmi jednoduché: stačí stáhnout aktuální verzi z GitHubu a použít soubory YAML z adresáře . Případně můžete také použít .
Po instalaci byste se měli starat o nastavení . To se provádí pomocí ConfigMap postgres-operator ve jmenném prostoru, kam jste nainstalovali operátora. Jakmile jsou úložiště nakonfigurována, můžete nasadit svůj první cluster PostgreSQL.
Naše standardní nasazení vypadá například takto:
apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
name: staging-db
spec:
numberOfInstances: 3
patroni:
synchronous_mode: true
postgresql:
version: "12"
resources:
limits:
cpu: 100m
memory: 1Gi
requests:
cpu: 100m
memory: 1Gi
sidecars:
- env:
- name: DATA_SOURCE_URI
value: 127.0.0.1:5432
- name: DATA_SOURCE_PASS
valueFrom:
secretKeyRef:
key: password
name: postgres.staging-db.credentials
- name: DATA_SOURCE_USER
value: postgres
image: wrouesnel/postgres_exporter
name: prometheus-exporter
resources:
limits:
cpu: 500m
memory: 100Mi
requests:
cpu: 100m
memory: 100Mi
teamId: staging
volume:
size: 2Gi
Tento manifest nasadí shluk 3 instancí s postranním vozíkem ve formuláři , ze kterého bereme metriky aplikace. Jak vidíte, vše je velmi jednoduché a pokud si přejete, můžete vytvořit doslova neomezené množství clusterů.
Stojí za to věnovat pozornost webový administrační panel - . Dodává se s operátorem a umožňuje vytvářet a mazat clustery a také pracovat se zálohami vytvořenými operátorem.
Seznam clusterů PostgreSQL
Správa zálohování
Další zajímavou funkcí je podpora . Tento mechanismus automaticky vytváří role v PostgreSQLna základě výsledného seznamu uživatelských jmen. Rozhraní API pak umožňuje vrátit seznam uživatelů, pro které jsou role automaticky vytvořeny.
Problémy a řešení
Použití operátora však brzy odhalilo několik významných nedostatků:
- nedostatek podpory nodeSelector;
- nemožnost zakázat zálohování;
- při použití funkce vytváření databáze se neobjeví výchozí oprávnění;
- Někdy dokumentace chybí nebo je zastaralá.
Naštěstí mnohé z nich lze vyřešit. Začněme od konce – problémy s dokumentace.
S největší pravděpodobností se setkáte s tím, že ne vždy je jasné, jak zálohu zaregistrovat a jak připojit záložní bucket do uživatelského rozhraní operátora. Dokumentace o tom mluví mimochodem, ale skutečný popis je in :
- potřeba udělat tajemství;
- předat operátorovi jako parametr
pod_environment_secret_namev CRD s nastavením operátora nebo v ConfigMap (podle toho, jak se rozhodnete operátor nainstalovat).
Jak se však ukázalo, v současnosti je to nemožné. Proto jsme inkasovali s některým dalším vývojem třetích stran. Další informace o něm naleznete níže.
Pokud operátorovi předáte parametry pro zálohování, konkrétně - wal_s3_bucket a přístupové klíče v AWS S3, pak to vše zálohuje: nejen základy ve výrobě, ale i inscenování. Tohle nám nevyhovovalo.
V popisu parametrů pro Spilo, což je základní Docker wrapper pro PgSQL při použití operátoru, se ukázalo: můžete předat parametr WAL_S3_BUCKET prázdný, a tím deaktivovat zálohování. Navíc jsem k velké radosti našel , kterou jsme okamžitě přijali do našeho vidle. Nyní stačí přidat enableWALArchiving: false do klastrového prostředku PostgreSQL.
Ano, naskytla se příležitost udělat to jinak spuštěním 2 operátorů: jednoho pro staging (bez zálohování) a druhého pro produkci. Ale dokázali jsme si vystačit s jedním.
Dobře, naučili jsme se, jak přenést přístup k databázím pro S3 a zálohy se začaly dostávat do úložiště. Jak zajistit, aby záložní stránky fungovaly v uživatelském rozhraní operátora?
Do uživatelského rozhraní operátora budete muset přidat 3 proměnné:
-
SPILO_S3_BACKUP_BUCKET -
AWS_ACCESS_KEY_ID -
AWS_SECRET_ACCESS_KEY
Poté bude k dispozici správa záloh, což v našem případě zjednoduší práci se stagingem a umožní nám tam dodávat řezy z produkce bez dalších skriptů.
Další výhodou byla práce s Teams API a dostatek možností pro tvorbu databází a rolí pomocí operátorských nástrojů. Nicméně stvořené role ve výchozím nastavení neměly žádná práva. Uživatel s právy čtení tedy nemohl číst nové tabulky.
proč tomu tak je? Nehledě na to, že v kodexu nutné GRANT, nejsou vždy používány. Existují 2 způsoby: syncPreparedDatabases и syncDatabases. V syncPreparedDatabases - přesto, že v odd preparedDatabases je tam podmínka defaultRoles и defaultUsers pro vytvoření rolí se nepoužijí výchozí práva. Připravujeme opravu, aby se tato práva automaticky uplatnila.
A poslední bod vylepšení, která jsou pro nás relevantní – , který přidá Node Affinity do vytvořené StatefulSet. Naši klienti často upřednostňují snížení nákladů pomocí spotových instancí a hostování databázových služeb se zjevně nevyplatí. Tento problém by mohl být vyřešen tolerancí, ale přítomnost Node Affinity dává větší jistotu.
Co se stalo?
Na základě výsledků řešení výše uvedených problémů jsme forkovali Postgres Operator ze Zalanda , kde se shromažďuje s tak užitečnými náplastmi. A pro větší pohodlí jsme také sbírali .
Seznam PR přijatých do forku:
- ;
- ;
- ;
- .
Bude skvělé, když komunita tyto PR podpoří, aby se dostaly upstream s další verzí operátora (1.6).
Bonus! Příběh úspěchu migrace výroby
Pokud používáte Patroni, lze živou produkci migrovat k operátorovi s minimálními prostoji.
Spilo vám umožňuje vytvářet pohotovostní clustery prostřednictvím úložiště S3 s , kdy je binární log PgSQL nejprve uložen v S3 a poté čerpán replikou. Ale co dělat, když máte ne používá Wal-E na staré infrastruktuře? Řešení tohoto problému již existuje na náboji.
Na pomoc přichází logická replikace PostgreSQL. Nebudeme se však podrobně věnovat tomu, jak vytvářet publikace a předplatné, protože... náš plán byl fiasko.
Faktem je, že databáze měla několik načtených tabulek s miliony řádků, které byly navíc neustále doplňovány a mazány. с copy_data, když nová replika zkopíruje veškerý obsah z předlohy, prostě s předlohou nestíhá. Kopírování obsahu fungovalo týden, ale nikdy nedostihlo předlohu. Nakonec mi to pomohlo problém vyřešit kolegové z Avito: data můžete přenášet pomocí pg_dump. Popíšu naši (mírně upravenou) verzi tohoto algoritmu.
Myšlenka je taková, že můžete zablokované předplatné svázat s konkrétním replikačním slotem a poté opravit číslo transakce. Pro produkční práci byly k dispozici repliky. To je důležité, protože replika pomůže vytvořit konzistentní výpis a nadále přijímat změny z hlavního serveru.
Následující příkazy popisující proces migrace budou používat následující notace hostitele:
- mistr — zdrojový server;
- replika1 — streamovaná replika staré produkce;
- replika2 - nová logická replika.
Migrační plán
1. Vytvořte předplatné na hlavním serveru pro všechny tabulky ve schématu public základy dbname:
psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"
2. Vytvořte replikační slot na hlavním serveru:
psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"
3. Zastavte replikaci na staré replice:
psql -h replica1 -c "select pg_wal_replay_pause();"
4. Získejte číslo transakce od hlavního serveru:
psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"
5. Odstraňte výpis ze staré repliky. Uděláme to v několika vláknech, což pomůže urychlit proces:
pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname
6. Nahrajte výpis na nový server:
pg_restore -h replica2 -F d -j 8 -d dbname dump/
7. Po stažení výpisu můžete spustit replikaci na repliku streamování:
psql -h replica1 -c "select pg_wal_replay_resume();"
7. Vytvořme předplatné na nové logické replice:
psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"
8. Pojďme oid odběry:
psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"
9. Řekněme, že to bylo přijato oid=1000. Aplikujme na předplatné číslo transakce:
psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"
10. Začněme replikaci:
psql -h replica2 -d dbname -c "alter subscription oldprod enable;"
11. Zkontrolujte stav předplatného, replikace by měla fungovat:
psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"
psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"
12. Po spuštění replikace a synchronizaci databází můžete přepnout.
13. Po zakázání replikace je třeba opravit sekvence. To je dobře popsáno .
Díky tomuto plánu proběhl přechod s minimálním zpožděním.
Závěr
Operátoři Kubernetes vám umožňují zjednodušit různé akce jejich omezením na vytváření zdrojů K8s. Po dosažení pozoruhodné automatizace s jejich pomocí však stojí za to pamatovat na to, že může přinést také řadu nečekaných nuancí, takže své operátory vybírejte moudře.
Po zvážení tří nejoblíbenějších operátorů Kubernetes pro PostgreSQL jsme vybrali projekt od Zalanda. A museli jsme s tím překonat určité potíže, ale výsledek byl opravdu potěšující, takže plánujeme rozšířit tuto zkušenost na některé další instalace PgSQL. Pokud máte zkušenosti s používáním podobných řešení, rádi se s nimi seznámíme v komentářích!
PS
Přečtěte si také na našem blogu:
- «";
- «";
- «".
Zdroj: www.habr.com