🥇A Kubernetes PostgreSQL-operátorainak rövid áttekintése, választásunk és tapasztalataink

Az ügyfelek egyre gyakrabban kapják a következő kéréseket: „Azt akarjuk, mint az Amazon RDS-t, de olcsóbban”; „Azt akarjuk, mint az RDS-t, de mindenhol, bármilyen infrastruktúrában.” Egy ilyen felügyelt megoldás Kubernetesen való megvalósításához megvizsgáltuk a PostgreSQL legnépszerűbb operátorainak jelenlegi állapotát (Stolon, a Crunchy Data és a Zalando operátorai), és döntöttünk.

Ez a cikk mind elméleti (megoldások áttekintése), mind gyakorlati oldalról (mit választottunk, és mi jött ki belőle) tapasztalatainkat. Először azonban határozzuk meg, hogy mik az általános követelmények az RDS lehetséges cseréjéhez...

Mi az RDS

Amikor az emberek az RDS-ről beszélnek, tapasztalatunk szerint egy menedzselt DBMS-szolgáltatásra gondolnak, amely:

könnyen konfigurálható;
képes pillanatképekkel dolgozni és azokból visszaállítani (lehetőleg támogatással PITR);
lehetővé teszi mester-szolga topológiák létrehozását;
bővítmények gazdag listája van;
auditálást és felhasználói/hozzáférés-kezelést biztosít.

Általánosságban elmondható, hogy az adott feladat végrehajtásának megközelítései nagyon különbözőek lehetnek, de a feltételes Ansible útja nem áll közel hozzánk. (A 2GIS munkatársai ennek eredményeként hasonló következtetésre jutottak próbálkozását hozzon létre egy "eszközt a Postgres-alapú feladatátvevő fürt gyors üzembe helyezéséhez.")

Az operátorok a Kubernetes ökoszisztéma hasonló problémáinak megoldására általános megközelítést jelentenek. A „Flanta” műszaki igazgatója a Kubernetesen belül indított adatbázisokkal kapcsolatban már részletesebben is beszélt róluk. disztol-Ban egyik jelentését.

NB: Az egyszerű operátorok gyors létrehozásához javasoljuk, hogy fordítson figyelmet nyílt forráskódú segédprogramunkra shell-operátor. Használatával ezt megteheti a Go ismerete nélkül, de a rendszergazdák számára ismertebb módon: Bash, Python stb.

Számos népszerű K8s operátor létezik a PostgreSQL-hez:

Stolon;
Crunchy Data PostgreSQL operátor;
Zalando Postgres operátor.

Nézzük meg őket közelebbről.

Üzemeltető kiválasztása

A fentebb már említett fontos tulajdonságok mellett mi - mint Kubernetes infrastruktúra üzemeltetési mérnökök - a következőket is elvártuk az üzemeltetőktől:

telepítés a Git-ből és a vele Egyéni források;
pod anti-affinitás támogatás;
csomópont-affinitás vagy csomópontválasztó telepítése;
tűréshatárok felszerelése;
a hangolási lehetőségek elérhetősége;
érthető technológiák, sőt parancsok.

Anélkül, hogy az egyes pontok részleteibe belemennék (a teljes cikk elolvasása után kérdezze meg a megjegyzésekben, hogy van-e még kérdése velük kapcsolatban), általánosságban megjegyzem, hogy ezek a paraméterek szükségesek a fürtcsomópontok specializációjának pontosabb leírásához annak érdekében, hogy rendelje meg őket konkrét alkalmazásokhoz. Így tudjuk elérni az optimális egyensúlyt teljesítmény és költség tekintetében.

Most térjünk át magukra a PostgreSQL operátorokra.

1. Stolon

Stolon az olasz Sorint.lab cégtől in már említett jelentés egyfajta szabványnak tekintették a DBMS operátorok körében. Ez egy meglehetősen régi projekt: az első nyilvános megjelenése még 2015 novemberében (!) történt, a GitHub repository pedig közel 3000 csillaggal és 40+ közreműködővel büszkélkedhet.

Valójában Stolon az átgondolt építészet kiváló példája:

Ennek a kezelőnek a készüléke részletesen megtalálható a jelentésben ill projektdokumentáció. Általánosságban elég annyit mondani, hogy mindent meg tud csinálni, ami leírt: feladatátvétel, proxy az átlátható kliens eléréshez, biztonsági mentések... Sőt, a proxyk egy végponti szolgáltatáson keresztül biztosítanak hozzáférést - ellentétben az alábbiakban tárgyalt másik két megoldással (mindegyiknek két szolgáltatása van bázis elérése).

Azonban Stolon nincsenek egyéni erőforrások, ezért nem telepíthető úgy, hogy egyszerűen és gyorsan – „mint a forró sütemény” – DBMS-példányokat lehessen létrehozni a Kubernetesben. Az irányítás a segédprogramon keresztül történik stolonctl, a telepítés a Helm diagramon keresztül történik, az egyéniek pedig a ConfigMap-ben vannak meghatározva és megadva.

Egyrészt kiderül, hogy az operátor valójában nem operátor (elvégre nem használ CRD-t). Másrészt azonban ez egy rugalmas rendszer, amely lehetővé teszi a K8s erőforrásainak tetszés szerint konfigurálását.

Összefoglalva, számunkra személy szerint nem tűnt optimálisnak minden adatbázishoz külön diagramot készíteni. Ezért elkezdtünk alternatívákat keresni.

2. Crunchy Data PostgreSQL operátor

Operátor a Crunchy Data-tól, egy fiatal amerikai startup logikus alternatívának tűnt. Nyilvános története a 2017 márciusi első kiadással kezdődik, azóta a GitHub adattár alig 1300 csillagot és több mint 50 közreműködőt kapott. A legújabb, szeptemberi kiadást a Kubernetes 1.15-1.18, az OpenShift 3.11+ és 4.4+, a GKE és a VMware Enterprise PKS 1.3+ verzióival tesztelték.

A Crunchy Data PostgreSQL Operator architektúrája is megfelel a megadott követelményeknek:

A kezelés a segédprogramon keresztül történik pgoviszont egyéni erőforrásokat generál a Kubernetes számára. Ezért az üzemeltető örömmel fogadott bennünket, mint potenciális felhasználókat:

van vezérlés CRD-n keresztül;
kényelmes felhasználókezelés (CRD-n keresztül is);
integráció más komponensekkel Crunchy Data Container Suite — a PostgreSQL-hez és a vele való munkavégzéshez szükséges segédprogramok speciális gyűjteménye (beleértve a pgBackRest, pgAudit, a contrib bővítményeit stb.).

A Crunchy Data operátorának használatára tett kísérletek azonban több problémát is feltártak:

Tűrésekre nem volt lehetőség - csak a nodeSelector biztosított.
A létrehozott pod-ok a Telepítés részei voltak, annak ellenére, hogy állapottartó alkalmazást telepítettünk. A StatefulSets-szel ellentétben a Deployments nem hozhat létre lemezeket.

Az utolsó hátrány vicces pillanatokhoz vezet: a tesztkörnyezetben 3 replikát sikerült futtatnunk egy lemezzel helyi raktár, ami miatt a kezelő azt jelentette, hogy 3 replika működik (bár nem működtek).

Ennek a kezelőnek egy másik jellemzője a különféle segédrendszerekkel való kész integráció. Például könnyen telepíthető a pgAdmin és a pgBounce, és in dokumentáció előre konfigurált Grafana és Prometheus tekinthető. Az utóbbi 4.5.0-beta1 kiadás A projekttel való jobb integrációt külön megjegyezzük pgMonitor, aminek köszönhetően az operátor a PgSQL-metrikák egyértelmű megjelenítését kínálja a dobozból.

A Kubernetes által generált források furcsa megválasztása azonban oda vezetett, hogy más megoldást kellett találnunk.

3. Zalando Postgres operátor

A Zalando termékeket régóta ismerjük: van tapasztalatunk a Zalenium használatában, és természetesen kipróbáltuk Patroni a népszerű HA-megoldásuk a PostgreSQL-hez. A cég alkotáshoz való hozzáállásáról Postgres operátor – mondta az egyik szerzője, Alekszej Klyukin Postgres-kedd #5, és tetszett nekünk.

Ez a cikkben tárgyalt legfiatalabb megoldás: az első kiadás 2018 augusztusában történt. A projekt azonban a formális megjelenések csekély száma ellenére is nagy utat tett meg, népszerűségében már túlszárnyalta a Crunchy Data megoldását a GitHubon 1300+ csillaggal és a maximális közreműködői számmal (70+).

„A motorháztető alatt” ez a kezelő jól bevált megoldásokat használ:

Patroni és Spilo Vezetéshez,
WAL-E - biztonsági mentésekhez,
PgBouncer - összekötő medenceként.

Így kerül bemutatásra a Zalando kezelői architektúrája:

Az üzemeltető teljes mértékben az egyéni erőforrásokon keresztül van felügyelve, automatikusan létrehoz egy StatefulSet-et a konténerekből, amely aztán testreszabható különféle oldalkocsik hozzáadásával a podhoz. Mindez jelentős előnyt jelent a Crunchy Data kezelőjéhez képest.

Mivel a 3 vizsgált lehetőség közül a Zalando megoldását választottuk, az alábbiakban egy további leírást mutatunk be a képességeiről, az alkalmazás gyakorlatával együtt.

Gyakoroljon a zalandói Postgres Operatorral

Az operátor telepítése nagyon egyszerű: csak töltse le az aktuális kiadást a GitHubról, és alkalmazza a YAML fájlokat a könyvtárból megnyilvánul. Alternatív megoldásként használhatja is operatorhub.

A telepítés után aggódnia kell a beállítás miatt naplók és biztonsági másolatok tárolása. Ez a ConfigMap segítségével történik postgres-operator abban a névtérben, ahová az operátort telepítette. A tárolók konfigurálása után telepítheti az első PostgreSQL-fürtöt.

A szabványos telepítésünk például így néz ki:

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

Ez a jegyzék egy 3 példányból álló fürtöt telepít oldalkocsival az űrlapon postgres_exporter, amelyből alkalmazási mutatókat veszünk. Amint látja, minden nagyon egyszerű, és ha akarja, szó szerint korlátlan számú klasztert hozhat létre.

Érdemes odafigyelni webes adminisztrációs panel - postgres-operator-ui. Az operátorral együtt érkezik, és lehetővé teszi fürtök létrehozását és törlését, valamint az operátor által készített biztonsági mentések kezelését.

PostgreSQL-fürtök listája

Biztonsági mentés kezelése

Egy másik érdekes funkció a támogatás Teams API. Ez a mechanizmus automatikusan létrehozza szerepek a PostgreSQL-ben, a kapott felhasználónevek listája alapján. Az API ezután lehetővé teszi, hogy visszaadja azon felhasználók listáját, akik számára automatikusan létrejön a szerepkör.

Problémák és megoldások

Az operátor használata azonban hamarosan több jelentős hiányosságot is feltárt:

a nodeSelector támogatás hiánya;
a biztonsági mentések letiltásának képtelensége;
az adatbázis-létrehozó funkció használatakor az alapértelmezett jogosultságok nem jelennek meg;
Időnként hiányzik vagy elavult a dokumentáció.

Szerencsére ezek közül sok megoldható. Kezdjük a végéről - problémák dokumentáció.

Valószínűleg találkozni fog azzal a ténnyel, hogy nem mindig világos, hogyan kell biztonsági másolatot regisztrálni, és hogyan kell csatlakoztatni a biztonsági mentési tárolót a kezelői felülethez. A dokumentáció mellékesen beszél erről, de a valódi leírás benne van PR:

titkot kell csinálnod;
paraméterként adja át az operátornak pod_environment_secret_name a CRD-ben a kezelői beállításokkal vagy a ConfigMap-ben (attól függően, hogy hogyan dönt az operátor telepítéséről).

Ez azonban, mint kiderült, jelenleg lehetetlen. Ezért gyűjtöttünk az operátor verziója néhány további harmadik féltől származó fejlesztéssel. További információért lásd alább.

Ha átadja a biztonsági mentés paramétereit az operátornak, nevezetesen - wal_s3_bucket és hozzáférési kulcsokat az AWS S3-ban, majd azt mindenről biztonsági másolatot készít: nem csak a gyártás alapjai, hanem a színpadra állítás is. Ez nekünk nem jött be.

A Spilo paramétereinek leírásából, amely a PgSQL alap Docker burkolója az operátor használatakor, kiderült: átadhat egy paramétert WAL_S3_BUCKET üres, ezáltal letiltja a biztonsági mentést. Sőt, nagy örömömre rájöttem kész PR, amit azonnal elfogadtunk a villánkba. Most már csak hozzá kell adnia enableWALArchiving: false egy PostgreSQL-fürt erőforráshoz.

Igen, volt lehetőség másként csinálni 2 operátor futtatásával: az egyik az állomásozásra (mentések nélkül), a másik pedig a termelésre. De eggyel be tudtunk érni.

Rendben, megtanultuk, hogyan vihetjük át az S3 adatbázisaihoz való hozzáférést, és a biztonsági másolatok elkezdtek bekerülni a tárolóba. Hogyan lehet a biztonsági oldalakat működésre bírni a kezelői felületen?

3 változót kell hozzáadnia a kezelői felülethez:

SPILO_S3_BACKUP_BUCKET
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

Ezt követően válik elérhetővé a mentések kezelése, ami esetünkben leegyszerűsíti az állomásoztatással való munkát, lehetővé téve, hogy további szkriptek nélkül szállíthassunk oda szeleteket a termelésből.

További előnyt jelentett a Teams API-val való munka, valamint az adatbázisok és szerepkörök operátori eszközökkel történő létrehozásának bőséges lehetősége. Azonban a teremtett a szerepeknek alapértelmezés szerint nem voltak jogai. Ennek megfelelően egy olvasási joggal rendelkező felhasználó nem tudott új táblákat olvasni.

Miert van az? Annak ellenére, hogy a kódban van szükséges GRANT, nem mindig használják őket. 2 módszer létezik: syncPreparedDatabases и syncDatabases. -Ban syncPreparedDatabases - annak ellenére, hogy a szakaszban preparedDatabases van van egy feltétel defaultRoles и defaultUsers szerepek létrehozásához az alapértelmezett jogok nincsenek alkalmazva. Folyamatban van a javítás előkészítése, hogy ezek a jogok automatikusan alkalmazásra kerüljenek.

És az utolsó pont a számunkra releváns fejlesztésekben - tapasz, amely hozzáadja a csomópont-affinitást a létrehozott StatefulSethez. Ügyfeleink gyakran előszeretettel csökkentik a költségeket a spot példányok használatával, és nyilvánvalóan nem érik meg nekik az adatbázis-szolgáltatást. Ez a probléma megoldható tűrésekkel, de a Node Affinity jelenléte nagyobb magabiztosságot ad.

Mi történt?

A fenti problémák megoldásának eredményei alapján a zalandói Postgres Operatort a telephelyre építettük a tárhelyed, ahol olyan hasznos foltokkal gyűjtik össze. És a nagyobb kényelem kedvéért gyűjtöttünk is Docker kép.

A villába fogadott PR-k listája:

Nagyszerű lenne, ha a közösség támogatja ezeket a PR-okat, hogy az operátor következő verziójával (1.6) felfelé kerüljenek.

Bónusz! A termelés migrációjának sikertörténete

Ha a Patronit használja, az élő gyártás minimális állásidővel migrálható az üzemeltetőhöz.

A Spilo lehetővé teszi készenléti fürtök létrehozását az S3 tárolón keresztül Wal-E, amikor a PgSQL bináris naplót először az S3 tárolja, majd a replika kiszivattyúzza. De mi a teendő, ha van nincs a Wal-E használta a régi infrastruktúrán? A probléma megoldása már megvan azt javasolták az agyon.

A PostgreSQL logikai replikációja segít. A kiadványok és előfizetések létrehozásának módját azonban nem részletezzük, mert... tervünk kudarc volt.

Az tény, hogy az adatbázisban több millió soros betöltött tábla volt, amelyeket ráadásul folyamatosan feltöltöttek és töröltek. Egyszerű előfizetés с copy_data, amikor az új replika az összes tartalmat másolja a mesterről, egyszerűen nem tud lépést tartani a mesterrel. A tartalom másolása egy hétig működött, de soha nem érte utol a mester. Végül segített megoldani a problémát cikk kollégái az Avito-tól: segítségével adatátvitelt végezhet pg_dump. Leírom ennek az algoritmusnak a mi (kissé módosított) verzióját.

Az ötlet az, hogy letiltott előfizetést köthet egy adott replikációs helyhez, majd javíthatja a tranzakció számát. A gyártási munkákhoz másolatok álltak rendelkezésre. Ez azért fontos, mert a replika segít konzisztens kiíratás létrehozásában, és továbbra is megkapja a változtatásokat a mestertől.

Az áttelepítési folyamatot leíró további parancsok a következő gazdagép-jelöléseket fogják használni:

mester — forrásszerver;
replika1 — replika streamelése a régi produkción;
replika2 - új logikai replika.

Migrációs terv

1. Hozzon létre egy előfizetést a főkiszolgálón a séma összes táblájához public bázis dbname:

psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"

2. Hozzon létre egy replikációs nyílást a főkiszolgálón:

psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"

3. Állítsa le a replikációt a régi replikán:

psql -h replica1 -c "select pg_wal_replay_pause();"

4. Kérje le a tranzakciószámot a mestertől:

psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"

5. Távolítsa el a kiíratot a régi replikáról. Ezt több szálban fogjuk megtenni, ami segít felgyorsítani a folyamatot:

pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname

6. Töltse fel a kiíratást az új szerverre:

pg_restore -h replica2 -F d -j 8 -d dbname dump/

7. A dump letöltése után megkezdheti a replikációt a streaming replikán:

psql -h replica1 -c "select pg_wal_replay_resume();"

7. Hozzon létre előfizetést egy új logikai replikán:

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. Vegyük oid előfizetések:

psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"

9. Tegyük fel, hogy megérkezett oid=1000. Alkalmazzuk a tranzakciószámot az előfizetésre:

psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"

10. Kezdjük el a replikációt:

psql -h replica2 -d dbname -c "alter subscription oldprod enable;"

11. Ellenőrizze az előfizetés állapotát, a replikációnak működnie kell:

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. A replikáció elindítása és az adatbázisok szinkronizálása után átválthat.

13. A replikáció letiltása után ki kell javítania a sorozatokat. Ez jól le van írva a wiki.postgresql.org cikkben.

Ennek a tervnek köszönhetően az átállás minimális csúszással ment végbe.

Következtetés

A Kubernetes operátorok lehetővé teszik a különféle műveletek egyszerűsítését azáltal, hogy azokat a K8s erőforrások létrehozására redukálják. Azonban, miután a segítségükkel figyelemreméltó automatizálást értünk el, érdemes észben tartani, hogy ez számos váratlan árnyalatot is hozhat, ezért okosan válasszon kezelőket.

A PostgreSQL három legnépszerűbb Kubernetes operátorát figyelembe véve a Zalando projektjét választottuk. És bizonyos nehézségeket le kellett küzdenünk vele, de az eredmény igazán tetszetős volt, ezért tervezzük, hogy ezt a tapasztalatot kiterjesztjük néhány más PgSQL-telepítésre is. Ha van tapasztalatod hasonló megoldások használatában, szívesen látjuk a részleteket kommentben!

PS

Olvassa el blogunkon is:

Forrás: will.com

A Kubernetes PostgreSQL-nyilatkozatainak rövid áttekintése, választásaink és tapasztalataink