Kubernetesentzako PostgreSQL operadoreen ikuspegi laburra, gure aukeraketa eta esperientzia

Gero eta gehiago, bezeroak eskaera hauek jasotzen ari dira: “Amazon RDS bezalakoa nahi dugu, baina merkeagoa”; "RDS bezala nahi dugu, baina nonahi, edozein azpiegituratan". Kubernetes-en kudeatutako soluzio hori ezartzeko, PostgreSQL-ren operadore ezagunenen egungo egoera aztertu dugu (Stolon, Crunchy Data eta Zalandoko operadoreak) eta gure aukera egin dugu.

Artikulu hau bai ikuspuntu teorikotik (konponbideen berrikuspena) bai alderdi praktikotik (zer aukeratu zen eta zer atera zen) lortu dugun esperientzia da. Baina lehenik eta behin, zehaztu dezagun zeintzuk diren RDS-ren ordezko potentzial baten baldintza orokorrak...

Zer da RDS

Jendeak RDSri buruz hitz egiten duenean, gure esperientziaren arabera, kudeatutako DBMS zerbitzu bat esan nahi du:

1. konfiguratzeko erraza;
2. argazkiekin lan egiteko eta haietatik berreskuratzeko gaitasuna du (hobe laguntzarekin PITR);
3. master-slave topologiak sortzeko aukera ematen du;
4. luzapenen zerrenda aberatsa du;
5. auditoria eta erabiltzaile/sarbideen kudeaketa eskaintzen du.

Orokorrean, eskuartean dugun zeregina ezartzeko planteamenduak oso desberdinak izan daitezke, baina Ansible baldintzatua duen bidea ez dago gertu. (2GISeko lankideek antzeko ondorio batera iritsi ziren ondorioz bere saiakera sortu "Postgres-en oinarritutako hutsegite-kluster bat azkar zabaltzeko tresna".)

Kubernetes ekosisteman antzeko arazoak konpontzeko ohiko ikuspegia da operadoreak. “Flanta”-ko zuzendari teknikoak dagoeneko zehatzago hitz egin du horietaz, Kubernetesen barruan abian jarritako datu-baseei dagokienez. distolin bere txostenetako bat.

NB: Operadore sinpleak azkar sortzeko, gure Kode Irekiko utilitateari arreta jartzea gomendatzen dugu shell-operadore. Erabiliz, Go-ren ezagutzarik gabe egin dezakezu, baina sistema-administratzaileentzako modu ezagunagoak: Bash-en, Python-en, etab.

K8s operadore ezagun batzuk daude PostgreSQLrako:

• Estolona;
• Crunchy Data PostgreSQL operadorea;
• Zalando Postgres Operadorea.

Ikus ditzagun hurbilagotik.

Operadorearen hautaketa

Arestian aipatutako ezaugarri garrantzitsuez gain, guk -Kuberneteseko azpiegitura-eragiketen ingeniari gisa- operadoreen partetik honako hau ere espero genuen:

• inplementazioa Git-etik eta batera Pertsonalizatutako baliabideak;
• pod-afinitatearen aurkako laguntza;
• nodo afinitatea edo nodo-hautatzailea instalatzea;
• perdoiak instalatzea;
• sintonizazio gaitasunen erabilgarritasuna;
• teknologia ulergarriak eta baita aginduak ere.

Puntu bakoitzari buruzko xehetasunetan sartu gabe (galdetu iruzkinetan artikulu osoa irakurri ondoren haiei buruzko galderarik baduzu oraindik), orokorrean ohartuko naiz parametro hauek beharrezkoak direla cluster-nodoen espezializazioa zehatzago deskribatzeko. eska itzazu aplikazio zehatzetarako. Horrela oreka optimoa lor dezakegu errendimendu eta kostu aldetik.

Orain pasa gaitezen PostgreSQL operadoreetara.

1. Estoloia

Estoloia Italiako Sorint.lab enpresatik lehen aipatutako txostena DBMSko operadoreen artean estandar modukotzat hartu zen. Proiektu nahiko zaharra da: bere lehen kaleratzea 2015eko azaroan egin zen (!), eta GitHub biltegiak ia 3000 izar eta 40 laguntzaile baino gehiago ditu.

Izan ere, Stolon arkitektura pentsakorren adibide bikaina da:

Operadore honen gailua xehetasunez aurki daiteke txostenean edo proiektuaren dokumentazioa. Orokorrean, nahikoa da deskribatutako guztia egin dezakeela esatea: hutsegitea, bezeroen sarbide gardenerako proxyak, babeskopiak... Gainera, proxy-ek amaierako zerbitzu baten bidez ematen dute sarbidea -behean aztertutako beste bi soluzioek ez bezala (bi zerbitzu dituzte bakoitzak. oinarria sartzeko).

Hala ere, Stolon Ez dago pertsonalizatutako baliabiderik, hori dela eta, ezin da zabaldu modu erraz eta bizkorra den - "opil beroa bezala" - Kubernetes-en DBMS instantziak sortzea. Kudeaketa utilitatearen bidez egiten da stolonctl, hedapena Helm diagramaren bidez egiten da, eta pertsonalizatuak definitzen eta zehazten dira ConfigMap-en.

Batetik, operadorea ez dela benetan operadorea gertatzen da (azken finean, ez du CRD erabiltzen). Baina, bestalde, sistema malgua da, K8etan baliabideak egoki deritzon moduan konfiguratzeko aukera ematen duena.

Laburbilduz, guri pertsonalki ez zitzaigun egokiena iruditu datu-base bakoitzerako taula bereizi bat sortzea. Horregatik, alternatibak bilatzen hasi ginen.

2. Crunchy Data PostgreSQL Operadorea

Crunchy Data-ren operadorea, amerikar startup gazte bat, alternatiba logikoa zirudien. Bere historia publikoa 2017ko martxoan lehen kaleratzearekin hasten da, orduz geroztik GitHub biltegiak 1300 izar baino gutxiago eta 50 laguntzaile baino gehiago jaso ditu. Iraileko azken bertsioa Kubernetes 1.15-1.18, OpenShift 3.11+ eta 4.4+, GKE eta VMware Enterprise PKS 1.3+ekin funtzionatzeko probatu zen.

Crunchy Data PostgreSQL Operator-en arkitekturak ere adierazitako baldintzak betetzen ditu:

Kudeaketa utilitatearen bidez gertatzen da pgo, hala ere, Kubernetesentzako Baliabide Pertsonalizatuak sortzen ditu. Hori dela eta, operadoreak gustura egon gintuen erabiltzaile potentzial gisa:

• CRD bidez kontrola dago;
• erabiltzaileen kudeaketa erosoa (CRD bidez ere);
• beste osagai batzuekin integratzea Crunchy Data Container Suite — PostgreSQL-rako edukiontzien irudien bilduma espezializatua eta harekin lan egiteko utilitateak (pgBackRest, pgAudit, contrib-en luzapenak, etab. barne).

Hala ere, Crunchy Data-ko operadorea erabiltzen hasteko saiakerek hainbat arazo agerian utzi zituzten:

• Ez zegoen tolerantziarik izateko aukerarik - nodeSelector bakarrik eskaintzen da.
• Sortutako podak Deployment-en parte ziren, egoera-aplikazio bat zabaldu genuen arren. StatefulSets ez bezala, Deployments-ek ezin du diskorik sortu.

Azken eragozpenak une dibertigarriak dakartza: proba-ingurunean 3 erreplika disko batekin exekutatu ditugu. tokiko biltegiratzea, operadoreak 3 erreplikak funtzionatzen ari zirela jakinaraziz (nahiz eta ez zeuden).

Operadore honen beste ezaugarri bat sistema osagarri ezberdinekin prest egindako integrazioa da. Esate baterako, erraza da pgAdmin eta pgBounce instalatzea eta barne dokumentazioa aurrez konfiguratutako Grafana eta Prometheus kontuan hartzen dira. Azkenaldian askatu 4.5.0-beta1 Proiektuarekiko integrazio hobetua bereizita nabarmentzen da pgMonitor, horri esker, operadoreak PgSQL neurketen bistaratzea argia eskaintzen du kutxatik kanpo.

Hala ere, Kubernetes-ek sortutako baliabideen aukera arraroak beste irtenbide bat bilatu beharra ekarri gintuen.

3. Zalando Postgres Operadorea

Aspalditik ezagutzen ditugu Zalando produktuak: esperientzia dugu Zalenium erabiltzen eta, jakina, saiatu gara Patroni PostgreSQL-rako HA irtenbide ezaguna da. Enpresak sortzeko duen ikuspegiari buruz Postgres operadorea bere egileetako batek, Alexey Klyukinek, esan zuen airean Postgres-asteartea #5, eta gustatu zitzaigun.

Hau da artikuluan eztabaidatzen den irtenbiderik gazteena: lehen kaleratzea 2018ko abuztuan izan zen. Hala ere, kaleratze formal kopuru txikia izan arren, proiektuak bide luzea egin du, dagoeneko ospea gainditu du Crunchy Data-ren irtenbidea, GitHub-en 1300 izar baino gehiagorekin eta kolaboratzaile gehien (70+).

"Kanpaiaren azpian" operadore honek denboran probatutako soluzioak erabiltzen ditu:

• Patroni eta Spilo Gidatzeko,
• WAL-E - babeskopiak egiteko,
• PgBouncer - konexio igerileku gisa.

Honela aurkezten da Zalandoko operadorearen arkitektura:

Operadoreak baliabide pertsonalizatuen bidez guztiz kudeatzen du, automatikoki StatefulSet bat sortzen du edukiontzietatik, gero pertsonalizatu ahal izateko hainbat sidecar gehituz. Hau guztia abantaila nabarmena da Crunchy Data-ko operadorearekin alderatuta.

Kontuan hartzen ditugun 3 aukeren artean Zalandoren irtenbidea aukeratu genuenez, jarraian bere gaitasunen deskribapen gehiago aurkeztuko da, aplikazioaren praktikarekin batera.

Praktikatu Zalandoko Postgres operadorearekin

Operadorearen inplementazioa oso erraza da: deskargatu uneko bertsioa GitHub-etik eta aplikatu direktorioko YAML fitxategiak. manifestuak. Bestela, erabil dezakezu operadore-hub.

Instalatu ondoren, konfigurazioaz kezkatu beharko zenuke erregistroak eta babeskopiak gordetzeko. Hau ConfigMap bidez egiten da postgres-operator operadorea instalatu duzun izen-espazioan. Biltegiak konfiguratuta daudenean, zure lehen PostgreSQL klusterra zabaldu dezakezu.

Esate baterako, gure inplementazio estandarra honelakoa da:

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

Manifestu honek 3 instantziako multzo bat zabaltzen du inprimakian sidecar batekin postgres_exporter, eta hortik hartzen ditugu aplikazioen neurketak. Ikusten duzun bezala, dena oso erraza da, eta nahi baduzu, literalki kluster kopuru mugagabea sor dezakezu.

Merezi du arreta jartzea web administrazio panela - postgres-operadore-ui. Operadorearekin dator eta klusterrak sortu eta ezabatzeko aukera ematen du, baita operadoreak egindako babeskopiekin lan egiteko ere.

PostgreSQL klusterren zerrenda

Babeskopia kudeatzea

Beste ezaugarri interesgarri bat euskarria da Teams APIa. Mekanismo honek automatikoki sortzen du rolak PostgreSQL-n, sortutako erabiltzaile-izenen zerrendan oinarrituta. Ondoren, APIak rolak automatikoki sortzen diren erabiltzaileen zerrenda itzultzeko aukera ematen du.

Arazoak eta irtenbideak

Hala ere, operadorearen erabilerak laster hainbat gabezia nabarmen agerian utzi zituen:

1. nodeSelector laguntza falta;
2. babeskopiak desgaitzeko ezintasuna;
3. datu-basea sortzeko funtzioa erabiltzean, lehenetsitako pribilegioak ez dira agertzen;
4. Aldian behin, dokumentazioa falta da edo zaharkituta dago.

Zorionez, horietako asko konpondu daitezke. Has gaitezen amaieratik - arazoak dokumentazioa.

Seguruenik, beti ez dagoela argi segurtasun kopia bat nola erregistratu eta babeskopia kuboa Operator UI-ra nola konektatu aurkituko duzu. Dokumentazioak honetaz hitz egiten du iraganean, baina benetako deskribapena bertan dago PR:

1. sekretu bat egin behar;
2. pasa ezazu operadoreari parametro gisa pod_environment_secret_name CRDn operadorearen ezarpenekin edo ConfigMap-en (operadorea instalatzea erabakitzen duzunaren arabera).

Hala ere, ikusten denez, gaur egun hori ezinezkoa da. Horregatik bildu dugu zure operadorearen bertsioa hirugarrenen garapen gehigarri batzuekin. Horri buruzko informazio gehiago lortzeko, ikus behean.

Babeskopia egiteko parametroak operadoreari pasatzen badituzu, hots - wal_s3_bucket eta sarbide-gakoak AWS S3-n, eta gero guztiaren babeskopia egingo du: ekoizpenean oinarriak ez ezik, eszenaratzeak ere bai. Hau ez zitzaigun komeni.

Spilo-ren parametroen deskribapenean, hau da, PgSQL-ren oinarrizko Docker wrapper-a operadorea erabiltzean, hauxe da: parametro bat pasa dezakezu WAL_S3_BUCKET hutsik, horrela babeskopiak desgaitu. Gainera, poz handirako, aurkitu nuen PR prest, berehala onartu genuen gure sardexka. Orain gehitu besterik ez duzu egin behar enableWALArchiving: false PostgreSQL kluster baliabide batera.

Bai, modu ezberdinean egiteko aukera zegoen 2 operadore exekutatuta: bat eszenaratzeko (kopia babesik gabe), eta bigarrena ekoizpenerako. Baina batekin konformatu ahal izan ginen.

Ados, S3-rako datu-baseetarako sarbidea nola transferitzen ikasi genuen eta babeskopiak biltegiratzean sartzen hasi ziren. Nola egin segurtasun-kopia orriak Operator UI-n?

3 aldagai gehitu beharko dituzu Operator UI-ra:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Horren ondoren, babeskopien kudeaketa eskuragarri egongo da, eta horrek gure kasuan eszenaratzearekin lana erraztuko du, produkzioko xerrak bertan script gehigarririk gabe entregatzeko aukera emanez.

Beste abantaila bat Teams APIarekin lan egitea eta operadore-tresnak erabiliz datu-baseak eta rolak sortzeko aukera zabalak izan ziren. Hala ere, sortua rolek ez zuten eskubiderik berez. Horren arabera, irakurtzeko eskubideak dituen erabiltzaile batek ezin izan ditu taula berriak irakurri.

Zergatik da hori? Kodean izan arren dago beharrezkoa GRANT, ez dira beti erabiltzen. 2 metodo daude: syncPreparedDatabases и syncDatabases. Urtean syncPreparedDatabases - atalean izan arren preparedDatabases dago baldintza bat dago defaultRoles и defaultUsers rolak sortzeko, lehenetsitako eskubideak ez dira aplikatzen. Adabaki bat prestatzen ari gara, eskubide horiek automatikoki aplikatzeko.

Eta guretzat garrantzitsuak diren hobekuntzen azken puntua - adabaki, sorturiko StatefulSet-era Node Affinity gehitzen duena. Gure bezeroek sarritan nahiago dute kostuak murriztea lekuko instantzien bidez, eta argi dago ez dutela merezi datu-baseen zerbitzuak ostatatzeko. Arazo hau tolerantziaren bidez konpondu liteke, baina Node Affinity egoteak konfiantza handiagoa ematen du.

Zer gertatu zen?

Goiko problemak ebazteko emaitzetan oinarrituta, Zalandoko Postgres Operator sartu dugu zure biltegia, non halako adabaki baliagarriekin biltzen den. Eta erosotasun handiagoa lortzeko, bildu ere egin dugu Docker irudia.

Sardexketan onartutako PRen zerrenda:

• Docker-en operadorearentzat irudi arin segurua eraikitzea;
• babeskopiak desgaituz;
• k8s-en egungo bertsioetarako baliabideen bertsioak eguneratzea;
• Node Affinity-ren ezarpena.

Oso ona izango da komunitateak PR hauek onartzen baditu, operadorearen hurrengo bertsioarekin (1.6) igo daitezen.

Hobaria! Ekoizpen migrazioaren arrakasta-istorioa

Patroni erabiltzen baduzu, zuzeneko produkzioa operadoreari migratu ahal izango da geldialdi gutxirekin.

Spilo-k S3 biltegiratze-rekin egonean klusterrak sortzeko aukera ematen du Wal-E, PgSQL erregistro bitarra lehenik S3-n gordetzen denean eta gero erreplikak ponpatzen duenean. Baina zer egin baduzu ez Wal-E-k erabilitako azpiegitura zaharretan? Arazo honen konponbidea dagoeneko dago iradoki zen ardatzean.

PostgreSQL erreplikazio logikoa erreskatatu egiten da. Hala ere, ez dugu argitalpenak eta harpidetzak nola sortu xehetasunetan sartuko, zeren... gure plana fiasko bat izan zen.

Kontua da datu-baseak milioika errenkada dituzten hainbat taula kargatuta zituela, eta, gainera, etengabe berritu eta ezabatzen ziren. Harpidetza sinplea с copy_data, erreplika berriak maisuaren eduki guztiak kopiatzen dituenean, ezin du maisuarekin jarraitu. Edukiak kopiatzea astebetez funtzionatu zuen, baina ez zen inoiz maisua harrapatu. Azkenean, arazoa konpontzen lagundu zidan artikuluan Avitoko lankideak: datuak transferi ditzakezu erabiliz pg_dump. Algoritmo honen gure bertsioa (apur bat aldatuta) deskribatuko dut.

Ideia da desgaitutako harpidetza bat erreplikatzeko zirrikitu zehatz bati lotuta egin dezakezula eta, ondoren, transakzio-zenbakia zuzendu. Erreplikak zeuden ekoizpen lanetarako. Hau garrantzitsua da erreplikak iraulketa koherentea sortzen lagunduko duelako eta maisuaren aldaketak jasotzen jarraituko duelako.

Migrazio-prozesua deskribatzen duten ondorengo komandoek ostalari-nota hauek erabiliko dituzte:

1. master — iturri zerbitzaria;
2. erreplika1 — erreplika erreprodukzio zaharrean;
3. erreplika2 - Erreplika logiko berria.

Migrazio plana

1. Sortu harpidetza maisuan eskemako taula guztietarako public oinarria dbname:

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

2. Sortu erreplikazio-zirrikitua maisuan:

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

3. Gelditu erreplika zaharrean:

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

4. Lortu transakzio-zenbakia maisuarengandik:

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

5. Kendu zabortegia erreplika zaharretik. Hau hainbat haritan egingo dugu, eta horrek prozesua bizkortzen lagunduko du:

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

6. Kargatu zabortegia zerbitzari berrira:

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

7. Zabortegia deskargatu ondoren, erreplika erreproduzitzen has zaitezke:

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

7. Sortu dezagun harpidetza erreplika logiko berri batean:

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. Lor gaitezen oid harpidetzak:

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

9. Demagun jaso zela oid=1000. Aplikatu diezaiogun transakzio-zenbakia harpidetzari:

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

10. Has gaitezen errepikapena:

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

11. Egiaztatu harpidetzaren egoera, erreplikazioak funtzionatu beharko luke:

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. Erreplikazioa hasi eta datu-baseak sinkronizatu ondoren, alda dezakezu.

13. Erreplikazioa desgaitu ondoren, sekuentziak zuzendu behar dituzu. Hau ondo deskribatuta dago wiki.postgresql.org artikuluan.

Plan horri esker, aldaketa gutxieneko atzerapenekin egin zen.

Ondorioa

Kubernetes-eko operadoreek hainbat ekintza sinplifikatzeko aukera ematen dute, K8s baliabideen sorkuntzara murriztuz. Hala ere, haien laguntzarekin automatizazio nabarmena lortu ondoren, ustekabeko ñabardura ugari ere ekar ditzakeela gogoratzea merezi du, beraz, aukeratu zure operadoreak zuhurki.

PostgreSQL-rako Kubernetes-en hiru operadore ezagunenak kontuan harturik, Zalando-ren proiektua aukeratu dugu. Eta zenbait zailtasun gainditu behar izan genituen horrekin, baina emaitza benetan atsegina izan zen, beraz, esperientzia hau beste PgSQL instalazio batzuetara zabaltzeko asmoa dugu. Antzeko irtenbideak erabiltzen esperientzia baduzu, poz-pozik egongo gara xehetasunak iruzkinetan!

PS

Irakurri ere gure blogean:

• «Datu-baseak eta Kubernetes (berrikuspena eta bideo-txostena)»;
• «Postgres Asteartea #5: PostgreSQL eta Kubernetes. CI/CD. Proba automatizazioa»;
• «Istorio bat Redis operadorearekin K8s-en eta datu-base honetako datuak aztertzeko utilitateen mini-berrikuspena'.

Iturria: www.habr.com