Një përmbledhje e shkurtër e deklaratave PostgreSQL për Kubernetes, Zgjedhjet tona dhe Përvoja

Gjithnjë e më shumë, klientët po marrin kërkesat e mëposhtme: "Ne e duam atë si Amazon RDS, por më lirë"; "Ne e duam atë si RDS, por kudo, në çdo infrastrukturë." Për të zbatuar një zgjidhje të tillë të menaxhuar në Kubernetes, ne shikuam gjendjen aktuale të operatorëve më të njohur për PostgreSQL (Stolon, operatorë nga Crunchy Data dhe Zalando) dhe bëmë zgjedhjen tonë.

Ky artikull është përvoja që kemi fituar si nga pikëpamja teorike (rishikim i zgjidhjeve) ashtu edhe nga ana praktike (çfarë u zgjodh dhe çfarë doli prej saj). Por së pari, le të përcaktojmë se cilat janë kërkesat e përgjithshme për një zëvendësim të mundshëm për RDS...

Çfarë është RDS

Kur njerëzit flasin për RDS, në përvojën tonë, ata nënkuptojnë një shërbim të menaxhuar DBMS që:

1. lehtë për t'u konfiguruar;
2. ka aftësinë për të punuar me fotografi dhe për t'u rikuperuar prej tyre (mundësisht me mbështetje PITR);
3. ju lejon të krijoni topologji master-slave;
4. ka një listë të pasur zgjerimesh;
5. ofron auditim dhe menaxhim të përdoruesit/qasjes.

Në përgjithësi, qasjet për zbatimin e detyrës në fjalë mund të jenë shumë të ndryshme, por rruga me Ansible të kushtëzuar nuk është afër nesh. (Kolegët nga 2GIS arritën në një përfundim të ngjashëm si rezultat përpjekjen e tij krijoni "një mjet për vendosjen e shpejtë të një grupi dështimi të bazuar në Postgres.")

Operatorët janë një qasje e zakonshme për zgjidhjen e problemeve të ngjashme në ekosistemin Kubernetes. Drejtori teknik i “Flanta” ka folur tashmë më në detaje rreth tyre në lidhje me bazat e të dhënave të lançuara brenda Kubernetes. distol, në një nga raportet e tij.

NB: Për të krijuar shpejt operatorë të thjeshtë, ju rekomandojmë t'i kushtoni vëmendje programit tonë me burim të hapur shell-operator. Duke e përdorur atë, ju mund ta bëni këtë pa njohuri për Go, por në mënyra më të njohura për administratorët e sistemit: në Bash, Python, etj.

Ka disa operatorë të njohur K8s për PostgreSQL:

• Stolon;
• Operatori i të dhënave Crunchy PostgreSQL;
• Operator Zalando Postgres.

Le t'i shohim më nga afër.

Zgjedhja e operatorit

Përveç veçorive të rëndësishme të përmendura më lart, ne - si inxhinierë të operacioneve të infrastrukturës Kubernetes - prisnim gjithashtu sa vijon nga operatorët:

• vendosja nga Git dhe me Burimet e personalizuara;
• mbështetje kundër afinitetit të pod;
• instalimi i afinitetit të nyjeve ose përzgjedhësit të nyjeve;
• instalimi i tolerancave;
• disponueshmëria e aftësive të akordimit;
• teknologji të kuptueshme dhe madje komanda.

Pa hyrë në detaje për secilën nga pikat (pyetni në komente nëse keni akoma pyetje rreth tyre pasi të keni lexuar të gjithë artikullin), do të vërej në përgjithësi se këto parametra nevojiten për të përshkruar më saktë specializimin e nyjeve të grupimeve në mënyrë që të porositni ato për aplikime specifike. Në këtë mënyrë ne mund të arrijmë ekuilibrin optimal për sa i përket performancës dhe kostos.

Tani le të kalojmë te vetë operatorët PostgreSQL.

1. Stolon

Stolon nga kompania italiane Sorint.lab në raporti i përmendur tashmë u konsiderua si një lloj standardi midis operatorëve për DBMS. Ky është një projekt mjaft i vjetër: publikimi i tij i parë publik u zhvillua në nëntor 2015(!), dhe depoja e GitHub krenohet me pothuajse 3000 yje dhe 40+ kontribues.

Në të vërtetë, Stolon është një shembull i shkëlqyer i arkitekturës së menduar:

Pajisja e këtij operatori mund të gjendet në detaje në raport ose dokumentacionin e projektit. Në përgjithësi, mjafton të thuhet se mund të bëjë gjithçka që përshkruhet: dështimi, proxies për akses transparent të klientit, kopje rezervë... Për më tepër, proxies ofrojnë akses përmes një shërbimi fundor - ndryshe nga dy zgjidhjet e tjera të diskutuara më poshtë (secila kanë dy shërbime për hyrje në bazë).

Megjithatë, Stolon nuk ka burime të personalizuara, kjo është arsyeja pse nuk mund të vendoset në atë mënyrë që të jetë e lehtë dhe e shpejtë - "si ëmbëlsira të nxehta" - të krijohen shembuj DBMS në Kubernetes. Menaxhimi kryhet përmes ndërmarrjes stolonctl, vendosja bëhet përmes grafikut Helm, dhe ato të personalizuara përcaktohen dhe specifikohen në ConfigMap.

Nga njëra anë, rezulton se operatori nuk është me të vërtetë një operator (në fund të fundit, ai nuk përdor CRD). Por nga ana tjetër, është një sistem fleksibël që ju lejon të konfiguroni burimet në K8 siç e shihni të arsyeshme.

Për ta përmbledhur, për ne personalisht nuk na dukej optimale krijimi i një grafiku të veçantë për secilën bazë të dhënash. Prandaj, filluam të kërkojmë alternativa.

2. Operatori i të dhënave Crunchy PostgreSQL

Operator nga Crunchy Data, një startup i ri amerikan, dukej si një alternativë logjike. Historia e tij publike fillon me lëshimin e parë në Mars 2017, që atëherë depoja e GitHub ka marrë pak më pak se 1300 yje dhe 50+ kontribues. Lëshimi i fundit nga shtatori u testua për të punuar me Kubernetes 1.15-1.18, OpenShift 3.11+ dhe 4.4+, GKE dhe VMware Enterprise PKS 1.3+.

Arkitektura e Operatorit Crunchy Data PostgreSQL gjithashtu plotëson kërkesat e deklaruara:

Menaxhimi ndodh përmes shërbimeve pgo, megjithatë, ai nga ana tjetër gjeneron Burime të personalizuara për Kubernetes. Prandaj, operatori na kënaqi si përdorues të mundshëm:

• ka kontroll nëpërmjet CRD;
• menaxhim i përshtatshëm i përdoruesit (gjithashtu nëpërmjet CRD);
• integrimi me komponentë të tjerë Suite e kontejnerëve të të dhënave crunchy — një koleksion i specializuar i imazheve të kontejnerëve për PostgreSQL dhe shërbimeve për të punuar me të (përfshirë pgBackRest, pgAudit, shtesa nga kontributi, etj.).

Sidoqoftë, përpjekjet për të filluar përdorimin e operatorit nga Crunchy Data zbuluan disa probleme:

• Nuk kishte asnjë mundësi për tolerime - ofrohet vetëm nodeSelector.
• Pod-et e krijuara ishin pjesë e Deployment, pavarësisht nga fakti që ne vendosëm një aplikacion shtetëror. Ndryshe nga StatefulSets, Deployments nuk mund të krijojnë disqe.

Pengesa e fundit çon në momente qesharake: në mjedisin e provës arritëm të ekzekutonim 3 kopje me një disk ruajtje lokale, duke bërë që operatori të raportojë se 3 kopje po funksiononin (edhe pse nuk ishin).

Një veçori tjetër e këtij operatori është integrimi i tij i gatshëm me sisteme të ndryshme ndihmëse. Për shembull, është e lehtë të instaloni pgAdmin dhe pgBounce, dhe në dokumentacionin Konsiderohen Grafana dhe Prometheus të para-konfiguruara. Aktualisht lëshimi 4.5.0-beta1 Përmirësimi i integrimit me projektin vihet re veçmas pgMonitor, falë të cilit operatori ofron një vizualizim të qartë të metrikës PgSQL jashtë kutisë.

Sidoqoftë, zgjedhja e çuditshme e burimeve të krijuara nga Kubernetes na çoi në nevojën për të gjetur një zgjidhje tjetër.

3. Operator Zalando Postgres

Ne i njohim produktet Zalando për një kohë të gjatë: kemi përvojë në përdorimin e Zalenium dhe, natyrisht, kemi provuar Patroni është zgjidhja e tyre popullore HA për PostgreSQL. Rreth qasjes së kompanisë ndaj krijimit Operatori Postgres Një nga autorët e saj, Alexey Klyukin, tha në transmetim Postgres-E martë #5, dhe na pëlqeu.

Kjo është zgjidhja më e re e diskutuar në artikull: lëshimi i parë u zhvillua në gusht 2018. Megjithatë, edhe përkundër numrit të vogël të publikimeve formale, projekti ka bërë një rrugë të gjatë, duke tejkaluar tashmë në popullaritet zgjidhjen nga Crunchy Data me 1300+ yje në GitHub dhe numrin maksimal të kontribuesve (70+).

"Nën kapuç" ky operator përdor zgjidhje të testuara me kohë:

• Patroni dhe Lojë Për vozitje,
• UAL-E - për kopje rezervë,
• PgBouncer - si një pishinë lidhjeje.

Kështu paraqitet arkitektura e operatorit nga Zalando:

Operatori menaxhohet plotësisht përmes Burimeve të personalizuara, krijon automatikisht një StatefulSet nga kontejnerët, i cili më pas mund të personalizohet duke shtuar karrige anësore të ndryshme në pod. E gjithë kjo është një avantazh i rëndësishëm në krahasim me operatorin nga Crunchy Data.

Meqenëse zgjodhëm zgjidhjen nga Zalando midis 3 opsioneve në shqyrtim, një përshkrim i mëtejshëm i aftësive të tij do të paraqitet më poshtë, menjëherë së bashku me praktikën e aplikimit.

Praktikoni me Operatorin Postgres nga Zalando

Vendosja e operatorit është shumë e thjeshtë: thjesht shkarkoni versionin aktual nga GitHub dhe aplikoni skedarët YAML nga drejtoria manifestohet. Përndryshe, ju gjithashtu mund të përdorni operator qendër.

Pas instalimit, duhet të shqetësoheni për konfigurimin ruajtje për regjistrat dhe kopjet rezervë. Kjo bëhet përmes ConfigMap postgres-operator në hapësirën e emrave ku keni instaluar operatorin. Pasi të konfigurohen depot, mund të vendosni grupin tuaj të parë PostgreSQL.

Për shembull, vendosja jonë standarde duket si kjo:

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

Ky manifest vendos një grup prej 3 shembujsh me një karrige anësore në formë postgres_eksportues, nga i cili marrim metrikat e aplikimit. Siç mund ta shihni, gjithçka është shumë e thjeshtë, dhe nëse dëshironi, mund të krijoni një numër fjalë për fjalë të pakufizuar grupimesh.

Ia vlen t'i kushtohet vëmendje paneli i administrimit të uebit - postgres-operator-ui. Ai vjen me operatorin dhe ju lejon të krijoni dhe fshini grupe, si dhe të punoni me kopje rezervë të bëra nga operatori.

Lista e grupimeve PostgreSQL

Menaxhimi i kopjeve rezervë

Një tjetër veçori interesante është mbështetja API e ekipeve. Ky mekanizëm krijon automatikisht rolet në PostgreSQL, bazuar në listën që rezulton me emrat e përdoruesve. Më pas API ju lejon të ktheni një listë të përdoruesve për të cilët rolet krijohen automatikisht.

Problemet dhe zgjidhjet

Sidoqoftë, përdorimi i operatorit shpejt zbuloi disa mangësi të rëndësishme:

1. mungesa e mbështetjes së nyjeveSelektor;
2. pamundësia për të çaktivizuar kopjet rezervë;
3. kur përdorni funksionin e krijimit të bazës së të dhënave, privilegjet e paracaktuara nuk shfaqen;
4. Ndonjëherë dokumentacioni mungon ose është i vjetëruar.

Për fat të mirë, shumë prej tyre mund të zgjidhen. Le të fillojmë nga fundi - problemet me dokumentacionin.

Me shumë mundësi, do të hasni në faktin se nuk është gjithmonë e qartë se si të regjistroni një kopje rezervë dhe si të lidhni kovën rezervë me ndërfaqen e operatorit. Dokumentacioni flet për këtë në kalim, por përshkrimi i vërtetë është në PR:

1. nevoja për të bërë një sekret;
2. ia kaloni operatorit si parametër pod_environment_secret_name në CRD me cilësimet e operatorit ose në ConfigMap (në varësi të mënyrës se si vendosni të instaloni operatorin).

Megjithatë, siç rezulton, kjo aktualisht është e pamundur. Prandaj kemi mbledhur versionin tuaj të operatorit me disa zhvillime shtesë të palëve të treta. Për më shumë informacion në lidhje me të, shihni më poshtë.

Nëse i kaloni parametrat për kopje rezervë operatorit, domethënë - wal_s3_bucket dhe çelësat e aksesit në AWS S3, pastaj atë do të rezervojë gjithçka: jo vetëm bazat në prodhim, por edhe në skenë. Kjo nuk na shkonte.

Në përshkrimin e parametrave për Spilo, i cili është mbështjellësi bazë Docker për PgSQL kur përdorni operatorin, doli: mund të kaloni një parametër WAL_S3_BUCKET bosh, duke çaktivizuar kështu kopjet rezervë. Për më tepër, për gëzim të madh, gjeta PR gati, të cilin e pranuam menjëherë në pirun tonë. Tani ju vetëm duhet të shtoni enableWALArchiving: false në një burim grupi PostgreSQL.

Po, kishte një mundësi për ta bërë atë ndryshe duke drejtuar 2 operatorë: një për skenë (pa kopje rezervë) dhe i dyti për prodhim. Por ne ishim në gjendje të mjaftoheshim me një.

Në rregull, mësuam se si të transferonim aksesin në bazat e të dhënave për S3 dhe kopjet rezervë filluan të futeshin në ruajtje. Si t'i bëni faqet rezervë të funksionojnë në Operator UI?

Ju do të duhet të shtoni 3 variabla në ndërfaqen e operatorit:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Pas kësaj, menaxhimi i kopjeve rezervë do të bëhet i disponueshëm, i cili në rastin tonë do të thjeshtojë punën me skenën, duke na lejuar të dorëzojmë feta nga prodhimi atje pa skripta shtesë.

Një avantazh tjetër ishte puna me Teams API dhe mundësitë e shumta për krijimin e bazave të të dhënave dhe roleve duke përdorur veglat e operatorit. Megjithatë, e krijuar rolet nuk kishin të drejta si parazgjedhje. Prandaj, një përdorues me të drejta leximi nuk mund të lexonte tabela të reja.

Pse eshte ajo? Pavarësisht se në kod ka e nevojshme GRANT, ato nuk përdoren gjithmonë. Ka 2 metoda: syncPreparedDatabases и syncDatabases. Në syncPreparedDatabases - pavarësisht se në rubrikën preparedDatabases ka ka një kusht defaultRoles и defaultUsers për të krijuar role, të drejtat e paracaktuara nuk zbatohen. Jemi në procesin e përgatitjes së një patch në mënyrë që këto të drejta të zbatohen automatikisht.

Dhe pika e fundit në përmirësimet që janë të rëndësishme për ne - patch, i cili shton Node Affinity në StatefulSet të krijuar. Klientët tanë shpesh preferojnë të zvogëlojnë kostot duke përdorur instanca të rastit, dhe qartësisht nuk ia vlen të presin shërbimet e bazës së të dhënave. Kjo çështje mund të zgjidhej përmes tolerimeve, por prania e Node Affinity jep besim më të madh.

Cfare ndodhi?

Bazuar në rezultatet e zgjidhjes së problemeve të mësipërme, ne futëm Operatorin Postgres nga Zalando në depoja juaj, ku mblidhet me arna të tilla të dobishme. Dhe për lehtësi më të madhe, ne gjithashtu grumbulluam Imazhi i dokerit.

Lista e PR-ve të pranuara në fork:

• ndërtimi i një imazhi të sigurt të lehtë për operatorin në Docker;
• çaktivizimi i kopjeve rezervë;
• përditësimi i versioneve të burimeve për versionet aktuale të k8s;
• zbatimi i Afinitetit të Nyjeve.

Do të jetë mirë nëse komuniteti i mbështet këto PR në mënyrë që ato të kalojnë në rrjedhën e sipërme me versionin tjetër të operatorit (1.6).

Bonus! Historia e suksesit të migrimit të prodhimit

Nëse përdorni Patroni, prodhimi i drejtpërdrejtë mund të migrohet te operatori me kohë minimale joproduktive.

Spilo ju lejon të krijoni grupe gatishmërie përmes ruajtjes S3 me Wal-E, kur regjistri binar PgSQL ruhet fillimisht në S3 dhe më pas pompohet nga kopja. Por çfarë të bëni nëse keni jo përdorur nga Wal-E në infrastrukturën e vjetër? Zgjidhja për këtë problem është tashmë u sugjerua në qendër.

Replikimi logjik i PostgreSQL vjen në shpëtim. Megjithatë, ne nuk do të hyjmë në detaje se si të krijojmë botime dhe abonime, sepse... plani ynë ishte një fiasko.

Fakti është se baza e të dhënave kishte disa tabela të ngarkuara me miliona rreshta, të cilat, për më tepër, rimbusheshin dhe fshiheshin vazhdimisht. Abonim i thjeshtë с copy_data, kur kopja e re kopjon të gjithë përmbajtjen nga masteri, thjesht nuk mund të vazhdojë me masterin. Kopjimi i përmbajtjes funksionoi për një javë, por nuk arriti kurrë me masterin. Në fund, më ndihmoi ta zgjidh problemin artikull kolegët nga Avito: mund të transferoni të dhëna duke përdorur pg_dump. Unë do të përshkruaj versionin tonë (pak të modifikuar) të këtij algoritmi.

Ideja është që ju mund të bëni një abonim me aftësi të kufizuara të lidhur me një vend të caktuar riprodhimi dhe më pas të korrigjoni numrin e transaksionit. Kishte kopje në dispozicion për punë prodhimi. Kjo është e rëndësishme sepse kopja do të ndihmojë në krijimin e një deponie të qëndrueshme dhe do të vazhdojë të marrë ndryshime nga master.

Komandat pasuese që përshkruajnë procesin e migrimit do të përdorin shënimet e mëposhtme të hostit:

1. mjeshtër — serveri i burimit;
2. kopje 1 — kopje e transmetimit në prodhimin e vjetër;
3. kopje 2 - kopje e re logjike.

Plani i migrimit

1. Krijoni një abonim në master për të gjitha tabelat në skemë public baze dbname:

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

2. Krijo një vend të replikimit në master:

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

3. Ndalo përsëritjen në kopjen e vjetër:

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

4. Merrni numrin e transaksionit nga master:

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

5. Hiqni deponinë nga kopja e vjetër. Ne do ta bëjmë këtë në disa tema, të cilat do të ndihmojnë në përshpejtimin e procesit:

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

6. Ngarko hale në serverin e ri:

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

7. Pas shkarkimit të hale, mund të filloni përsëritjen në kopjen e transmetimit:

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

7. Le të krijojmë një abonim në një kopje të re logjike:

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. Le të marrim oid abonimet:

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

9. Le të themi se është marrë oid=1000. Le të aplikojmë numrin e transaksionit në pajtim:

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

10. Le të fillojmë përsëritjen:

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

11. Kontrolloni statusin e abonimit, përsëritja duhet të funksionojë:

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. Pas fillimit të riprodhimit dhe sinkronizimit të bazave të të dhënave, mund të kaloni.

13. Pas çaktivizimit të replikimit, duhet të korrigjoni sekuencat. Kjo është përshkruar mirë në artikullin në wiki.postgresql.org.

Falë këtij plani, kalimi u bë me vonesa minimale.

Përfundim

Operatorët Kubernetes ju lejojnë të thjeshtoni veprime të ndryshme duke i reduktuar ato në krijimin e burimeve të K8s. Sidoqoftë, pasi të keni arritur një automatizim të jashtëzakonshëm me ndihmën e tyre, ia vlen të mbani mend se ai gjithashtu mund të sjellë një numër nuancash të papritura, kështu që zgjidhni operatorët tuaj me mençuri.

Duke marrë parasysh tre operatorët më të njohur Kubernetes për PostgreSQL, ne zgjodhëm projektin nga Zalando. Dhe na u desh të kapërcenim disa vështirësi me të, por rezultati ishte vërtet i këndshëm, kështu që ne planifikojmë ta zgjerojmë këtë përvojë në disa instalime të tjera PgSQL. Nëse keni përvojë në përdorimin e zgjidhjeve të ngjashme, do të jemi të lumtur t'i shohim detajet në komente!

PS

Lexoni edhe në blogun tonë:

• «Bazat e të dhënave dhe Kubernetes (rishikim dhe raport video)"?
• «Postgres e martë #5: PostgreSQL dhe Kubernetes. CI/CD. Testoni automatizimin"?
• «Një histori me operatorin Redis në K8s dhe një mini-rishikim i shërbimeve për analizimin e të dhënave nga kjo bazë të dhënash'.

Burimi: www.habr.com