🥇Kratak pregled PostgreSQL operatora za Kubernetes, naš izbor i iskustvo

Sve češće klijenti dobijaju sledeće zahteve: „Želimo kao Amazon RDS, ali jeftinije“; “Želimo ga kao RDS, ali svuda, u bilo kojoj infrastrukturi.” Da bismo implementirali takvo upravljano rješenje na Kubernetes, pogledali smo trenutno stanje najpopularnijih operatera za PostgreSQL (Stolon, operatori iz Crunchy Data i Zalando) i napravili svoj izbor.

Ovaj članak je iskustvo koje smo stekli i sa teorijske tačke gledišta (pregled rješenja) i s praktične strane (šta je odabrano i šta je iz toga proizašlo). Ali prvo, hajde da utvrdimo koji su opšti zahtevi za potencijalnu zamenu za RDS...

Šta je RDS?

Kada ljudi govore o RDS-u, prema našem iskustvu, misle na upravljani DBMS servis koji:

lako se konfiguriše;
ima mogućnost rada sa snimcima i oporavak od njih (po mogućnosti uz podršku PITR);
omogućava vam da kreirate master-slave topologije;
ima bogatu listu ekstenzija;
pruža reviziju i upravljanje korisnicima/pristupom.

Uopšteno govoreći, pristupi implementaciji zadatka mogu biti veoma različiti, ali put sa uslovnim Ansibleom nije nam blizak. (Kolege iz 2GIS-a su kao rezultat došle do sličnog zaključka njegov pokušaj kreirajte "alat za brzo postavljanje klastera za prevazilaženje greške zasnovanog na Postgresu.")

Operatori su uobičajen pristup za rješavanje sličnih problema u Kubernetes ekosistemu. Tehnički direktor “Flante” je već govorio detaljnije o njima u vezi sa bazama podataka pokrenutim unutar Kubernetesa. distol, in jedan od njegovih izveštaja.

NB: Za brzo kreiranje jednostavnih operatora, preporučujemo da obratite pažnju na naš Open Source uslužni program shell-operator. Koristeći ga, to možete učiniti bez znanja o Go-u, ali na načine koji su sistemski administratori poznatiji: u Bash, Python, itd.

Postoji nekoliko popularnih K8s operatera za PostgreSQL:

Stolon;
Crunchy Data PostgreSQL Operator;
Zalando Postgres Operator.

Pogledajmo ih pobliže.

Izbor operatera

Pored već pomenutih važnih karakteristika, mi - kao inženjeri za operativne operacije Kubernetes infrastrukture - očekujemo i sledeće od operatera:

implementacija iz Gita i sa Prilagođeni resursi;
Podrška protiv afiniteta;
instaliranje afiniteta čvora ili selektora čvorova;
ugradnja tolerancija;
dostupnost mogućnosti podešavanja;
razumljive tehnologije, pa čak i komande.

Ne ulazeći u detalje o svakoj od tačaka (pitajte u komentarima imate li još pitanja o njima nakon čitanja cijelog članka), primijetit ću općenito da su ovi parametri potrebni za preciznije opisivanje specijalizacije čvorova klastera kako bi se naručite ih za određene primjene. Na taj način možemo postići optimalnu ravnotežu u pogledu performansi i troškova.

Sada pređimo na same PostgreSQL operatore.

1. Stolon

Stolon iz italijanske kompanije Sorint.lab u već pomenuti izveštaj smatran je svojevrsnim standardom među operaterima za DBMS. Ovo je prilično star projekat: njegovo prvo javno objavljivanje održano je u novembru 2015. (!), a GitHub spremište ima skoro 3000 zvjezdica i 40+ saradnika.

Zaista, Stolon je odličan primjer promišljene arhitekture:

Uređaj ovog operatera možete detaljno pronaći u izvještaju ili projektnu dokumentaciju. Uopšteno govoreći, dovoljno je reći da može da radi sve što je opisano: prelazak preko greške, proksiji za transparentan pristup klijentu, pravljenje rezervnih kopija... Štaviše, proksiji obezbeđuju pristup preko jedne usluge krajnje tačke – za razliku od druga dva rešenja koja se razmatraju u nastavku (svaki imaju po dve usluge za pristup bazi).

Međutim, Stolon nema prilagođenih resursa, zbog čega se ne može implementirati na način da je lako i brzo – „kao vrući kolači“ – kreirati DBMS instance u Kubernetesu. Upravljanje se vrši preko komunalnog preduzeća stolonctl, implementacija se vrši kroz Helm grafikon, a prilagođeni su definirani i specificirani u ConfigMap-u.

S jedne strane, ispada da operator zapravo nije operator (na kraju krajeva, ne koristi CRD). Ali s druge strane, to je fleksibilan sistem koji vam omogućava da konfigurišete resurse u K8s kako vam odgovara.

Da rezimiramo, nama lično se nije činilo optimalnim da kreiramo poseban grafikon za svaku bazu podataka. Stoga smo počeli tražiti alternative.

2. Crunchy Data PostgreSQL Operator

Operater iz Crunchy Data, mladi američki startup, izgledao je kao logična alternativa. Njegova javna istorija počinje prvim izdanjem u martu 2017. godine, od tada je GitHub spremište dobio nešto manje od 1300 zvjezdica i 50+ saradnika. Najnovije izdanje iz septembra testirano je za rad sa Kubernetes 1.15-1.18, OpenShift 3.11+ i 4.4+, GKE i VMware Enterprise PKS 1.3+.

Arhitektura Crunchy Data PostgreSQL Operator takođe ispunjava navedene zahteve:

Upravljanje se odvija preko uslužnog programa pgo, međutim, on zauzvrat generiše prilagođene resurse za Kubernetes. Stoga nas je operater obradovao kao potencijalne korisnike:

postoji kontrola preko CRD-a;
praktično upravljanje korisnicima (također putem CRD-a);
integracija sa ostalim komponentama Crunchy Data Container Suite — specijalizovana kolekcija slika kontejnera za PostgreSQL i uslužnih programa za rad sa njim (uključujući pgBackRest, pgAudit, ekstenzije iz contrib, itd.).

Međutim, pokušaji da se počne koristiti operater iz Crunchy Data otkrili su nekoliko problema:

Nije bilo mogućnosti tolerancije - obezbeđen je samo nodeSelector.
Kreirani podovi su bili dio Deploymenta, uprkos činjenici da smo implementirali aplikaciju s stanjem. Za razliku od StatefulSets, Deployments ne mogu kreirati diskove.

Posljednji nedostatak dovodi do smiješnih trenutaka: na testnom okruženju uspjeli smo pokrenuti 3 replike s jednim diskom lokalno skladište, što je dovelo do toga da operater prijavi da 3 replike rade (iako nisu).

Još jedna karakteristika ovog operatera je njegova gotova integracija sa različitim sistemima podrške. Na primjer, lako je instalirati pgAdmin i pgBounce i u dokumentaciju razmatraju se unaprijed konfigurirani Grafana i Prometheus. Nedavno izdanje 4.5.0-beta1 Posebno je istaknuta poboljšana integracija sa projektom pgMonitor, zahvaljujući čemu operater nudi jasnu vizualizaciju PgSQL metrika iz kutije.

Međutim, čudan izbor resursa generisanih Kubernetesom doveo nas je do potrebe da pronađemo drugačije rešenje.

3. Zalando Postgres Operator

Zalando proizvode poznajemo dugo: imamo iskustva u korištenju Zaleniuma i, naravno, probali smo Patroni je njihovo popularno HA rješenje za PostgreSQL. O pristupu kompanije kreiranju Postgres Operator jedan od njenih autora, Aleksej Kljukin, rekao je u eteru Postgres-Utorak #5, i svidjelo nam se.

Ovo je najmlađe rješenje o kojem se govori u članku: prvo izdanje održano je u avgustu 2018. Međutim, čak i uprkos malom broju formalnih izdanja, projekat je prešao dug put, već premašivši po popularnosti rešenje iz Crunchy Data sa 1300+ zvezdica na GitHubu i maksimalnim brojem saradnika (70+).

“Ispod haube” ovaj operater koristi provjerena rješenja:

Patroni and Spilo za vožnju,
WAL-E - za rezervne kopije,
PgBouncer - kao spojni bazen.

Ovako je predstavljena arhitektura operatera iz Zalanda:

Operaterom se u potpunosti upravlja preko prilagođenih resursa, automatski kreira StatefulSet iz kontejnera, koji se zatim može prilagoditi dodavanjem različitih pomoćnih kola u pod. Sve je to značajna prednost u odnosu na operatera iz Crunchy Data.

Budući da smo među 3 razmatrane opcije odabrali rješenje iz Zalanda, u nastavku će biti predstavljen daljnji opis njegovih mogućnosti, odmah uz praksu primjene.

Vježbajte sa Postgres Operatorom iz Zalanda

Postavljanje operatera je vrlo jednostavno: samo preuzmite trenutno izdanje sa GitHub-a i primijenite YAML datoteke iz direktorija manifestuje. Alternativno, također možete koristiti operatorhub.

Nakon instalacije, trebali biste brinuti o postavljanju pohrana za logove i sigurnosne kopije. Ovo se radi preko ConfigMap-a postgres-operator u imenskom prostoru u koji ste instalirali operatera. Nakon što su spremišta konfigurirana, možete postaviti svoj prvi PostgreSQL klaster.

Na primjer, naša standardna implementacija izgleda ovako:

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

Ovaj manifest raspoređuje klaster od 3 instance sa prikolicom u obrascu postgres_exporter, iz koje uzimamo metriku aplikacije. Kao što vidite, sve je vrlo jednostavno, a ako želite, možete kreirati doslovno neograničen broj klastera.

Vrijedi obratiti pažnju web administrativni panel - postgres-operator-ui. Dolazi sa operaterom i omogućava vam kreiranje i brisanje klastera, kao i rad sa rezervnim kopijama koje je napravio operater.

Lista PostgreSQL klastera

Upravljanje rezervnim kopijama

Još jedna zanimljiva karakteristika je podrška Teams API. Ovaj mehanizam se automatski kreira uloge u PostgreSQL-u, na osnovu rezultirajuće liste korisničkih imena. API vam tada omogućava da vratite listu korisnika za koje se uloge automatski kreiraju.

Problemi i rješenja

Međutim, korištenje operatera ubrzo je otkrilo nekoliko značajnih nedostataka:

nedostatak podrške za nodeSelector;
nemogućnost onemogućavanja rezervnih kopija;
kada koristite funkciju kreiranja baze podataka, podrazumevane privilegije se ne pojavljuju;
Ponekad dokumentacija nedostaje ili je zastarjela.

Srećom, mnoge od njih se mogu riješiti. Počnimo od kraja - problemi sa dokumentaciju.

Najvjerovatnije ćete se susresti s činjenicom da nije uvijek jasno kako registrirati rezervnu kopiju i kako povezati rezervnu kopiju s korisničkim sučeljem operatera. Dokumentacija o tome govori usputno, ali pravi opis je tu PR:

potreba da se napravi tajna;
proslijediti ga operatoru kao parametar pod_environment_secret_name u CRD-u sa postavkama operatera ili u ConfigMap (ovisno o tome kako se odlučite za instaliranje operatera).

Međutim, kako se ispostavilo, to je trenutno nemoguće. Zato smo skupljali vašu verziju operatera sa nekim dodatnim razvojem trećih strana. Za više informacija o tome, pogledajte u nastavku.

Ako operatoru prosledite parametre za backup, odnosno - wal_s3_bucket i pristupne ključeve u AWS S3, a zatim to napraviće sigurnosnu kopiju svega: ne samo baze u proizvodnji, već i scenski. Ovo nam nije odgovaralo.

U opisu parametara za Spilo, koji je osnovni Docker omot za PgSQL kada se koristi operator, pokazalo se: možete prenijeti parametar WAL_S3_BUCKET prazan, čime se onemogućuju sigurnosne kopije. Štaviše, na veliku radost, otkrio sam spreman PR, koji smo odmah prihvatili u našu viljušku. Sada samo treba da dodate enableWALArchiving: false na resurs klastera PostgreSQL.

Da, postojala je prilika da se to učini drugačije pokretanjem 2 operatera: jedan za staging (bez rezervnih kopija), a drugi za proizvodnju. Ali uspjeli smo se zadovoljiti jednim.

Ok, naučili smo kako prenijeti pristup bazama podataka za S3 i sigurnosne kopije su počele ulaziti u skladište. Kako napraviti rezervne stranice da rade u korisničkom sučelju operatera?

Morat ćete dodati 3 varijable korisničkom sučelju operatera:

SPILO_S3_BACKUP_BUCKET
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

Nakon toga će postati dostupno upravljanje rezervnim kopijama, što će u našem slučaju pojednostaviti rad sa stagingom, omogućavajući nam da tamo isporučimo rezove iz produkcije bez dodatnih skripti.

Još jedna prednost je bio rad sa Teams API-jem i obilje mogućnosti za kreiranje baza podataka i uloga pomoću alata operatera. Međutim, stvoreno uloge nisu imale prava po defaultu. Shodno tome, korisnik s pravima čitanja nije mogao čitati nove tabele.

Žašto je to? Uprkos činjenici da je u kodu je neophodno GRANT, ne koriste se uvijek. Postoje 2 metode: syncPreparedDatabases и syncDatabases. The syncPreparedDatabases - uprkos činjenici da je u sek preparedDatabases je postoji uslov defaultRoles и defaultUsers za kreiranje uloga, podrazumevana prava se ne primenjuju. U procesu smo pripreme zakrpe kako bi se ova prava automatski primijenila.

I poslednja tačka u poboljšanjima koja su za nas relevantna - patch, koji dodaje afinitet čvora kreiranom StatefulSet-u. Naši klijenti često preferiraju smanjenje troškova korištenjem spot instanci, a očito im nije vrijedno hostiranja usluga baze podataka. Ovaj problem bi se mogao riješiti tolerancijama, ali prisustvo Node Affinity daje veće samopouzdanje.

Šta se desilo?

Na osnovu rezultata rješavanja navedenih problema, račvali smo Postgres Operator iz Zalanda vaše spremište, gdje se skuplja sa tako korisnim zakrpama. A za veću udobnost, prikupili smo i mi Docker slika.

Lista PR-ova prihvaćenih u fork:

Bilo bi sjajno ako zajednica podrži ove PR-ove tako da se uzvodno postave sa sljedećom verzijom operatora (1.6).

Bonus! Priča o uspjehu migracije proizvodnje

Ako koristite Patroni, proizvodnja uživo može se prenijeti na operatera uz minimalno vrijeme zastoja.

Spilo vam omogućava da kreirate standby klastere putem S3 memorije sa Wal-E, kada se PgSQL binarni dnevnik prvo pohranjuje u S3, a zatim ispumpava replika. Ali šta da radite ako imate ne koristi Wal-E na staroj infrastrukturi? Rješenje za ovaj problem već postoji bilo je predloženo na čvorištu.

PostgreSQL logička replikacija dolazi u pomoć. Međutim, nećemo ulaziti u detalje o tome kako kreirati publikacije i pretplate, jer... naš plan je bio fijasko.

Činjenica je da je baza podataka imala nekoliko učitanih tabela sa milionima redova, koje su se, osim toga, stalno dopunjavale i brisale. Jednostavna pretplata с copy_data, kada nova replika kopira sav sadržaj sa mastera, jednostavno ne može pratiti master. Kopiranje sadržaja je radilo nedelju dana, ali nikada nije sustiglo majstora. Na kraju mi je to pomoglo da riješim problem članak kolege iz Avita: možete prenositi podatke koristeći pg_dump. Opisaću našu (malo modifikovanu) verziju ovog algoritma.

Ideja je da možete napraviti onemogućenu pretplatu vezanu za određeni slot za replikaciju, a zatim ispraviti broj transakcije. Bile su dostupne replike za proizvodni rad. Ovo je važno jer će replika pomoći u kreiranju konzistentnog dump-a i nastaviti primati promjene od mastera.

Sljedeće naredbe koje opisuju proces migracije će koristiti sljedeće notacije hosta:

majstor — izvorni server;
replika1 — streaming replika na staroj produkciji;
replika2 - nova logička replika.

Plan migracije

1. Kreirajte pretplatu na masteru za sve tablice u shemi public baza dbname:

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

2. Kreirajte slot za replikaciju na glavnom:

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

3. Zaustavite replikaciju na staroj replici:

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

4. Dobijte broj transakcije od mastera:

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

5. Uklonite dump sa stare replike. To ćemo učiniti u nekoliko niti, što će pomoći ubrzanju procesa:

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

6. Učitajte dump na novi server:

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

7. Nakon preuzimanja dump-a, možete započeti replikaciju na replici za streaming:

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

7. Kreirajmo pretplatu na novu logičku repliku:

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. Idemo oid pretplate:

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

9. Recimo da je primljeno oid=1000. Primijenimo broj transakcije na pretplatu:

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

10. Počnimo replikaciju:

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

11. Provjerite status pretplate, replikacija bi trebala raditi:

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. Nakon što se replikacija pokrene i baze podataka se sinkroniziraju, možete se prebaciti.

13. Nakon onemogućavanja replikacije, trebate ispraviti sekvence. Ovo je dobro opisano u članku na wiki.postgresql.org.

Zahvaljujući ovom planu, prelazak je obavljen sa minimalnim kašnjenjima.

zaključak

Kubernetes operateri vam omogućavaju da pojednostavite različite radnje svodeći ih na kreiranje K8s resursa. Međutim, nakon što su uz njihovu pomoć postigli izvanrednu automatizaciju, vrijedi zapamtiti da ona također može donijeti niz neočekivanih nijansi, pa mudro birajte svoje operatere.

Uzimajući u obzir tri najpopularnija Kubernetes operatera za PostgreSQL, odabrali smo projekat iz Zalanda. I morali smo savladati određene poteškoće s tim, ali rezultat je bio zaista zadovoljan, pa planiramo proširiti ovo iskustvo na neke druge PgSQL instalacije. Ako imate iskustva s korištenjem sličnih rješenja, bit će nam drago vidjeti detalje u komentarima!

PS

Pročitajte i na našem blogu:

izvor: www.habr.com

Kratak pregled PostgreSQL operatora za Kubernetes, naš izbor i iskustvo