Kratki pregled PostgreSQL naredbi za Kubernetes, naši izbori i iskustvo

Klijenti sve češće dobivaju sljedeće zahtjeve: “Želimo kao Amazon RDS, ali jeftinije”; "Želimo to kao RDS, ali posvuda, u bilo kojoj infrastrukturi." Kako bismo implementirali takvo upravljano rješenje na Kubernetes, pogledali smo trenutačno stanje najpopularnijih operatora za PostgreSQL (Stolon, operateri iz Crunchy Data i Zalando) i odabrali.

Ovaj članak je iskustvo koje smo stekli kako s teorijske strane (pregled rješenja) tako i s praktične strane (što je odabrano i što je iz toga proizašlo). Ali prvo, odredimo koji su opći zahtjevi za potencijalnu zamjenu za RDS...

Što je RDS

Kada ljudi govore o RDS-u, prema našem iskustvu, misle na upravljanu DBMS uslugu koja:

1. lako se konfigurira;
2. ima sposobnost rada sa snimkama i oporavka od njih (po mogućnosti uz podršku PITR);
3. omogućuje stvaranje master-slave topologija;
4. ima bogat popis ekstenzija;
5. pruža reviziju i upravljanje korisnicima/pristupom.

Općenito govoreći, pristupi provedbi zadatka koji je pred nama mogu biti vrlo različiti, ali put s uvjetnim Ansibleom nije nam blizak. (Kolege iz 2GIS-a su kao rezultat toga došli do sličnog zaključka njegov pokušaj stvoriti "alat za brzu implementaciju failover klastera temeljenog na Postgresu.")

Operatori su uobičajeni pristup za rješavanje sličnih problema u ekosustavu Kubernetes. Tehnički direktor “Flanta” već je detaljnije govorio o njima u vezi s bazama podataka pokrenutim unutar Kubernetesa. distolU jedan od njegovih izvještaja.

NB: Za brzo stvaranje jednostavnih operatora, preporučujemo da obratite pozornost na naš uslužni program otvorenog koda ljuska-operator. Koristeći ga, možete to učiniti bez znanja Go-a, ali na načine poznatije administratorima sustava: u Bashu, Pythonu itd.

Postoji nekoliko popularnih K8s operatora za PostgreSQL:

• Stolon;
• Crunchy Data PostgreSQL Operator;
• Zalando Postgres operater.

Pogledajmo ih pobliže.

Izbor operatera

Uz već gore navedene važne značajke, mi - kao operativni inženjeri Kubernetes infrastrukture - također smo od operatera očekivali sljedeće:

• implementacija iz Gita i sa Prilagođeni resursi;
• podpora protiv afiniteta;
• instaliranje afiniteta čvora ili selektora čvora;
• ugradnja tolerancija;
• dostupnost mogućnosti podešavanja;
• razumljive tehnologije pa čak i naredbe.

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

Sada prijeđimo na same PostgreSQL operatore.

1. Stolon

Stolon od talijanske tvrtke Sorint.lab in već spomenuti izvještaj se smatrao nekom vrstom standarda među operatorima za DBMS. Ovo je prilično star projekt: njegovo prvo javno izdanje dogodilo se u studenom 2015. (!), a GitHub repozitorij može se pohvaliti s gotovo 3000 zvjezdica i 40+ suradnika.

Doista, Stolon je izvrstan primjer promišljene arhitekture:

Uređaj ovog operatera možete detaljno pronaći u izvješću odn projektna dokumentacija. Općenito, dovoljno je reći da može raditi sve što je opisano: failover, proxy za transparentan pristup klijenta, sigurnosne kopije... Štoviše, proxy pruža pristup putem jedne usluge krajnje točke - za razliku od druga dva rješenja o kojima se govori u nastavku (svaki ima dvije usluge za pristupa bazi).

Međutim, Stolon nema prilagođenih resursa, zbog čega se ne može implementirati na način da se jednostavno i brzo – „kao alva“ – kreiraju DBMS instance u Kubernetesu. Upravljanje se provodi putem uslužnog programa stolonctl, implementacija se vrši kroz Helm grafikon, a prilagođeni su definirani i specificirani u ConfigMap.

S jedne strane, ispada da operater zapravo i nije operater (uostalom, ne koristi CRD). Ali s druge strane, to je fleksibilan sustav koji vam omogućuje da konfigurirate resurse u K8s kako vam odgovara.

Ukratko, nama se osobno nije činilo optimalnim kreirati zaseban 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, činio se kao logična alternativa. Njegova javna povijest počinje s prvim izdanjem u ožujku 2017., od tada je GitHub repozitorij dobio nešto manje od 1300 zvjezdica i 50+ suradnika. Najnovije izdanje iz rujna testirano je za rad s Kubernetesom 1.15-1.18, OpenShift 3.11+ i 4.4+, GKE i VMware Enterprise PKS 1.3+.

Arhitektura Crunchy Data PostgreSQL Operator također ispunjava navedene zahtjeve:

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

• postoji kontrola putem CRD-a;
• praktično upravljanje korisnicima (također putem CRD-a);
• integracija s drugim komponentama Crunchy Data Container Suite — specijalizirana zbirka slika spremnika za PostgreSQL i pomoćnih programa za rad s njim (uključujući pgBackRest, pgAudit, proširenja iz contrib, itd.).

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

• Nije bilo mogućnosti tolerancija - dostupan je samo nodeSelector.
• Stvorene jedinice bile su dio implementacije, unatoč činjenici da smo implementirali aplikaciju s praćenjem stanja. Za razliku od StatefulSets-a, Deployments ne mogu stvoriti diskove.

Posljednji nedostatak dovodi do smiješnih trenutaka: na testnom okruženju uspjeli smo pokrenuti 3 replike s jednim diskom lokalna pohrana, zbog čega operater javlja da 3 replike rade (iako nisu).

Još jedna značajka ovog operatora je njegova gotova integracija s raznim pomoćnim sustavima. Na primjer, lako je instalirati pgAdmin i pgBounce i u dokumentacija u obzir dolaze unaprijed konfigurirani Grafana i Prometheus. U posljednje vrijeme izdanje 4.5.0-beta1 Posebno je istaknuta poboljšana integracija s projektom pgMonitor, zahvaljujući kojem operater nudi jasnu vizualizaciju PgSQL metrike odmah po otvaranju.

Međutim, čudan izbor resursa koje je generirao Kubernetes doveo nas je do potrebe da pronađemo drugačije rješenje.

3. Zalando Postgres operator

Zalando proizvode poznajemo već dugo: imamo iskustva s korištenjem Zaleniuma i, naravno, pokušali smo pokrovitelj je njihovo popularno HA rješenje za PostgreSQL. O pristupu tvrtke stvaranju Postgres operator rekao je u eteru jedan od njegovih autora Aleksej Kljukin Postgres-utorak #5, i svidjelo nam se.

Ovo je najmlađe rješenje o kojem se govori u članku: prvo izdanje dogodilo se u kolovozu 2018. Međutim, čak i usprkos malom broju formalnih izdanja, projekt je daleko dogurao, već premašivši popularnosti rješenje iz Crunchy Data s 1300+ zvjezdica na GitHubu i maksimalnim brojem suradnika (70+).

"Ispod haube" ovaj operater koristi rješenja koja su testirana vremenom:

• Patroni i Spilo Za vožnju,
• WAL-E - za sigurnosne kopije,
• PgBouncer - kao skup veza.

Ovako je predstavljena operatorska arhitektura iz Zalanda:

Operater je u potpunosti upravljan putem Custom Resources, automatski stvara StatefulSet iz spremnika, koji se zatim može prilagoditi dodavanjem različitih bočnih prikolica u kapsulu. Sve je to značajna prednost u usporedbi s operaterom iz Crunchy Data.

Budući da smo među 3 razmatrane mogućnosti odabrali Zalandovo rješenje, daljnji opis njegovih mogućnosti bit će prikazan u nastavku, odmah uz praksu primjene.

Vježbajte s Postgres Operatorom iz Zalanda

Implementacija operatera vrlo je jednostavna: samo preuzmite trenutno izdanje s GitHuba i primijenite YAML datoteke iz direktorija manifestira. Alternativno, također možete koristiti operatorhub.

Nakon instalacije trebali biste se pobrinuti za postavljanje pohrana za zapisnike i sigurnosne kopije. To se radi putem ConfigMapa postgres-operator u prostoru imena gdje ste instalirali operator. Nakon što su repozitoriji konfigurirani, 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 implementira klaster od 3 instance s prikolicom u obrascu postgres_exporter, iz kojeg preuzimamo metriku aplikacije. Kao što vidite, sve je vrlo jednostavno, a ako želite, možete stvoriti doslovno neograničen broj klastera.

Vrijedno je pažnje panel web administracije - postgres-operator-ui. Dolazi s operaterom i omogućuje vam stvaranje i brisanje klastera, kao i rad sa sigurnosnim kopijama koje je napravio operater.

Popis PostgreSQL klastera

Upravljanje sigurnosnom kopijom

Još jedna zanimljiva značajka je podrška API timova. Ovaj mehanizam automatski stvara uloge u PostgreSQL-u, na temelju rezultirajućeg popisa korisničkih imena. API vam zatim omogućuje vraćanje popisa korisnika za koje su uloge automatski stvorene.

Problemi i rješenja

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

1. nedostatak podrške za nodeSelector;
2. nemogućnost onemogućavanja sigurnosnih kopija;
3. kada koristite funkciju stvaranja baze podataka, zadane privilegije se ne pojavljuju;
4. Ponekad dokumentacija nedostaje ili je zastarjela.

Na sreću, mnoge od njih mogu se riješiti. Krenimo od kraja – problemi sa dokumentacija.

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

1. potreba za tajnom;
2. proslijedite ga operateru kao parametar pod_environment_secret_name u CRD-u s postavkama operatera ili u ConfigMap-u (ovisno kako se odlučite instalirati operatera).

Međutim, kako se pokazalo, to je trenutno nemoguće. Zato smo skupljali svoju verziju operatera s nekim dodatnim razvojem trećih strana. Više informacija o tome potražite u nastavku.

Ako operateru proslijedite parametre za backup, naime - wal_s3_bucket i pristupne ključeve u AWS S3, zatim ga sigurnosno će kopirati sve: ne samo baze u produkciji, već i inscenacija. Ovo nam nije odgovaralo.

U opisu parametara za Spilo, koji je osnovni Docker omotač za PgSQL kada se koristi operator, pokazalo se: možete proslijediti parametar WAL_S3_BUCKET prazna, čime se onemogućuju sigurnosne kopije. Štoviše, na veliku radost, pronašao sam spreman PR, koju smo odmah prihvatili u svoju vilicu. Sada samo trebate dodati 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 mogli smo se zadovoljiti s jednim.

U redu, naučili smo kako prenijeti pristup bazama podataka za S3 i sigurnosne kopije su počele ulaziti u pohranu. Kako omogućiti rad sigurnosnih stranica u korisničkom sučelju operatera?

Morat ćete dodati 3 varijable u korisničko sučelje operatera:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Nakon toga postat će dostupno upravljanje sigurnosnim kopijama, što će u našem slučaju pojednostaviti rad s insceniranjem, omogućujući nam da tamo isporučimo isječke iz proizvodnje bez dodatnih skripti.

Još jedna prednost bio je rad s Teams API-jem i široke mogućnosti za kreiranje baza podataka i uloga pomoću operatorskih alata. Međutim, stvoreno uloge prema zadanim postavkama nisu imale prava. Sukladno tome, korisnik s pravima čitanja nije mogao čitati nove tablice.

Zašto je to? Unatoč tome što u kodu tu je potrebno GRANT, ne koriste se uvijek. Postoje 2 metode: syncPreparedDatabases и syncDatabases. U syncPreparedDatabases - usprkos tome što je u odsj preparedDatabases tu je postoji uvjet defaultRoles и defaultUsers za stvaranje uloga, zadana prava se ne primjenjuju. U procesu smo pripreme zakrpe kako bi se ta prava automatski primijenila.

I posljednja točka u poboljšanjima koja su relevantna za nas - zakrpa, koji dodaje afinitet čvora stvorenom StatefulSet-u. Naši klijenti često radije smanjuju troškove korištenjem spot instanci, a one očito nisu vrijedne hostinga usluga baze podataka. Ovaj bi se problem mogao riješiti tolerancijama, ali prisutnost afiniteta čvora daje veće povjerenje.

Što se dogodilo?

Na temelju rezultata rješavanja gore navedenih problema, račvali smo Postgres Operator iz Zalanda u vaše spremište, gdje se skuplja s takvim korisnim zakrpama. A za veću praktičnost, također smo prikupili Docker slika.

Popis PR-ova koji su prihvaćeni u fork:

• izgradnja sigurne lagane slike za operatera u Dockeru;
• onemogućavanje sigurnosnih kopija;
• ažuriranje verzija resursa za trenutne verzije k8s;
• implementacija Node Affinity.

Bilo bi sjajno ako zajednica podrži ove PR-ove kako bi dobili sljedeću verziju operatora (1.6).

Bonus! Priča o uspjehu migracije proizvodnje

Ako koristite Patroni, produkcija uživo može se prenijeti operateru uz minimalno vrijeme zastoja.

Spilo vam omogućuje stvaranje standby klastera putem S3 pohrane s Wal-E, kada se PgSQL binarni zapisnik najprije pohranjuje u S3, a zatim ga ispumpava replika. Ali što učiniti ako imate ne koristi Wal-E na staroj infrastrukturi? Rješenje ovog problema je već bilo je predloženo na čvorištu.

PostgreSQL logička replikacija dolazi u pomoć. Međutim, nećemo ići 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 tablica s milijunima redaka, koji su se, osim toga, stalno nadopunjavali i brisali. Jednostavna pretplata с copy_data, kada nova replika kopira sav sadržaj s mastera, jednostavno ne može pratiti master. Kopiranje sadržaja radilo je tjedan dana, ali nikad nije sustiglo majstora. Na kraju mi ​​je to pomoglo da riješim problem članak kolege iz Avita: podatke možete prenositi pomoću pg_dump. Opisat ću našu (malo modificiranu) verziju ovog algoritma.

Ideja je da možete napraviti onemogućenu pretplatu vezanu uz određeni utor za replikaciju, a zatim ispraviti broj transakcije. Za rad u proizvodnji bile su dostupne replike. Ovo je važno jer će replika pomoći u stvaranju dosljednog ispisa i nastaviti primati promjene od glavnog.

Sljedeće naredbe koje opisuju proces migracije koristit će sljedeće oznake hosta:

1. majstor — izvorni poslužitelj;
2. replika1 — replika strujanja na staroj produkciji;
3. 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. Napravite utor za replikaciju na glavnom uređaju:

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 glavnog računa:

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 ubrzati proces:

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

6. Učitajte dump na novi poslužitelj:

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

7. Nakon preuzimanja dumpa, možete pokrenuti replikaciju na replici za strujanje:

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. Započ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 je replikacija pokrenuta i baze podataka sinkronizirane, možete se prebaciti.

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

Zahvaljujući ovom planu, prijelaz se odvijao uz minimalna kašnjenja.

Zaključak

Operatori Kubernetes omogućuju vam da pojednostavite različite radnje reducirajući ih na stvaranje K8s resursa. Međutim, nakon što smo uz njihovu pomoć postigli izvanrednu automatizaciju, vrijedno je zapamtiti da ona također može donijeti niz neočekivanih nijansi, stoga mudro birajte svoje operatere.

Uzimajući u obzir tri najpopularnija Kubernetes operatora za PostgreSQL, odabrali smo Zalandov projekt. I s njim smo morali prevladati određene poteškoće, ali rezultat je bio jako ugodan, 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:

• «Baze podataka i Kubernetes (recenzija i video izvješće)»;
• «Postgres utorak #5: PostgreSQL i Kubernetes. CI/CD. Automatizacija testiranja»;
• «Jedna priča s Redis operatorom u K8s i mini pregled uslužnih programa za analizu podataka iz ove baze podataka".

Izvor: www.habr.com