Kërkesat nga klientët po bëhen gjithnjë e më të shpeshta: "Duam diçka si Amazon RDS, por më të lirë"; "Duam si RDS, por kudo, në çdo infrastrukturë". Për të realizuar një zgjidhje të tillë të menaxhuar në Kubernetes, kemi shqyrtuar situatën aktuale të operatorëve më të njohur për PostgreSQL (Stolon, operatorët nga Crunchy Data dhe Zalando) dhe kemi bërë zgjedhjen tonë.
Ky artikull Ă«shtĂ« pĂ«rvoja jonĂ« e fituar si nga kĂ«ndvĂ«shtrimi teorik (pĂ«rmbledhje e zgjidhjeve), ashtu edhe nga ana praktike (çfarĂ« u zgjodh dhe çfarĂ« rezultati u arrit). Por pĂ«rpara se tĂ« fillojmĂ«, le tĂ« pĂ«rcaktojmĂ« se cilat janĂ« kĂ«rkesat pĂ«r njĂ« zĂ«vendĂ«sim potencial tĂ« RDSâŠ
ĂfarĂ« Ă«shtĂ« RDS?
Kur njerëzit flasin për RDS, sipas përvojës tonë, ata nënkuptojnë një shërbim të menaxhuar (managed) DB që:
- është lehtësisht e konfigurueshme;
- ka mundësinë për të punuar me snapshot-et dhe për t'u rikthyer nga ato (preferohet - me mbështetje për );
- lejon krijimin e topologjive master-slave;
- ka një listë të pasur zgjerimesh;
- ofron audit dhe menaxhim të përdoruesve/qasjeve.
Nëse flasim në përgjithësi, qasjet për realizimin e detyrës së caktuar mund të jenë mjaft të ndryshme, por rruga me Ansible-in nuk na përshtatet. (Në një përfundim të ngjashëm arritën edhe kolegët nga 2GIS në rezultat për të krijuar një «mjet për shpërndarjen e shpejtë të një klasteri që nuk dështojnë, të bazuar në Postgres».)
Precisht operatorĂ«t â Ă«shtĂ« qasja e pranuar gjerĂ«sisht pĂ«r zgjidhjen e kĂ«tij lloji situatash nĂ« ecosistemin Kubernetes. MĂ« shumĂ« rreth tyre nĂ« lidhje me bazat e tĂ« dhĂ«nave qĂ« janĂ« zbatuar brenda Kubernetes, tashmĂ« e kishte pĂ«rmendur drejtori teknik i «Flant», , nĂ« .
NB: Për krijimin e shpejtë të operatorëve të thjeshtë, rekomandojmë të kushtoni vëmendje utilitarit tonë Open Source . Përdorimi i tij e lehtëson atë pa njohuri për Go, në mënyra që janë më të njohura për sistem administratorët: në Bash, Python etj.
Për PostgreSQL ekzistojnë disa operatorë të njohur K8s:
- Stolon;
- Operatori PostgreSQL i Crunchy Data;
- Operatori Postgres i Zalando.
Le të shohim ata më me kujdes.
Zgjedhja e operatorit
PĂ«rveç atyre mundĂ«sive tĂ« rĂ«ndĂ«sishme qĂ« tashmĂ« pĂ«rmendĂ«m mĂ« lart, ne â si inxhinierĂ« tĂ« operacioneve nĂ« infrastruktura Kubernetes â gjithashtu prisnim nga operatorĂ«t tĂ« kishin:
- shpërndarje nga Git dhe me ;
- mbështetje për pod anti-affinity;
- vendosjen e node affinity ose node selector;
- vendosjen e tolerances;
- prania e mundësive për optimizim;
- teknologji dhe madje ekipe të kuptueshme.
Përveç detajeve të çdo pika (pyetni në komentet nëse mbeten pyetje për to pas leximit të artikullit të gjithë), do të theksoj se këto parametra janë të nevojshëm për një përshkrim më delikat të specializimit të nyjeve të klasterit në mënyrë që të mund të porositen për aplikacione specifike. Kështu mund të arrijmë një balancë optimale në çështjet e performancës dhe kostos.
Tani â pĂ«r vetĂ« operatorĂ«t e PostgreSQL.
1. Stolon
nga kompania italiane Sorint.lab në u shqyrtua si një etalon mes operatorëve për SGBD. Ky është një projekt mjaft i vjetër: lëshimi i tij publik i parë ndodhi ende në nëntor 2015(!), ndërsa depoja në GitHub mund të tërheqë pothuajse 3000 yje dhe 40+ kontribues.
Dhe me të vërtetë, Stolon është një shembull i shkëlqyer i arkitekturës së menduar:
Me pajisjen e kĂ«tij operatori mund tĂ« njiheni nĂ« detaje nĂ« raport ose . NĂ« pĂ«rgjithĂ«si, mjafton tĂ« thuhet se ai di tĂ« bĂ«jĂ« gjithçka tĂ« pĂ«rshkruar: failover, proxy pĂ«r qasje tĂ« transparentĂ« tĂ« klientĂ«ve, backup⊠PĂ«r mĂ« tepĂ«r, proxy ofrojnĂ« akses pĂ«rmes njĂ« endpoint-i shĂ«rbimi â ndryshe nga dy zgjidhjet e tjera tĂ« shqyrtuara mĂ« pas (ata kanĂ« dy shĂ«rbime pĂ«r qasje nĂ« bazĂ«).
MegjithatĂ«, Stolon , pĂ«r shkak tĂ« tĂ« cilave nuk mund tĂ« krijohet thjesht dhe shpejt â «si byrekĂ«t e nxehtë» â instanca tĂ« DB nĂ« Kubernetes. Menaxhimi bĂ«het pĂ«rmes utilitarit stolonctl, dhe vendosja bĂ«het pĂ«rmes Helm-chart, ndĂ«rsa pĂ«rdoruesit pĂ«rcaktohen nĂ« ConfigMap.
Nga njĂ«ra anĂ«, duket se operatori nuk Ă«shtĂ« shumĂ« operues (sepse ai nuk pĂ«rdor CRD). Por nga ana tjetĂ«r â kjo Ă«shtĂ« njĂ« sistem fleksibĂ«l, i cili lejon tĂ« konfigurosh burimet nĂ« K8s ashtu siç tĂ« duket mĂ« e pĂ«lqyeshme.
Përmbledhës, për ne nuk duket optimal të krijojmë një chart të veçantë për çdo DB. Prandaj ne filluam të kërkojmë alternativa.
2. Operator PostgreSQL i Crunchy Data
, njĂ« fillim logjik i njĂ« startup-i tĂ« ri amerikan. Historia e tij publike fillon me lansimin e parĂ« mĂ« mars 2017; dhe qĂ« atĂ«herĂ«, depoja nĂ« GitHub ka marrĂ« pak mĂ« pak se 1300 yje dhe mbi 50 kontribuues. Lansimi mĂ« i fundit nga shtatori Ă«shtĂ« testuar pĂ«r punĂ« me Kubernetes 1.15â1.18, OpenShift 3.11+ dhe 4.4+, GKE dhe VMware Enterprise PKS 1.3+.
Arkitektura e Crunchy Data PostgreSQL Operator gjithashtu i përmbush kërkesat e shpallura:
Menaxhimi bëhet nëpërmjet utilitarit pgo, megjithatë, kjo gjithashtu gjeneron Resurset e Personalizuara për Kubernetes. Prandaj, na gëzoi si përdorues potencialë operatori:
- ka menaxhim përmes CRD;
- menaxhim të lehtë të përdoruesve (po ashtu përmes CRD);
- integrimi me komponentĂ« tĂ« tjerĂ« â njĂ« koleksion i specializuar i imazhesh tĂ« kontejnerĂ«ve pĂ«r PostgreSQL dhe utilitarĂ«ve pĂ«r punĂ« me tĂ« (pĂ«rfshirĂ« pgBackRest, pgAudit, zgjerimet nga contrib etj.).
Megjithatë, përpjekjet për të filluar përdorimin e operatorit nga Crunchy Data zbuloi disa probleme:
- Nuk kishte mundĂ«si tolerances â Ă«shtĂ« parashikuar vetĂ«m nodeSelector.
- PodâĂ«t e krijuara ishin pjesĂ« e Deployment-it, megjithĂ«se ne po implementonim aplikacione stateful. Ndryshe nga StatefulSet, Deployment-et nuk dinĂ« tĂ« krijojnĂ« disqe.
Këtu është një mangësi tjetër që çon në momente interesante: në ambientin e testimit arritëm të ekzekutonim 3 replika me një disku. storage lokal, për sa kohë që operatori raportonte se 3 replika ishin në funksion (edhe pse kjo nuk ishte e vërtetë).
Një veçori tjetër e këtij operatori është integrimi i tij i gatshëm me sisteme të ndryshme mbështetëse. Për shembull, është shumë e lehtë të instalosh pgAdmin dhe pgBounce, dhe në po shqyrtohen Grafana dhe Prometheus të parakonfigurueshme. Në lëshimin e fundit vlerësohet integrimi i përmirësuar me projektin , duke lejuar që operatori të ofrojë vizualizim të qartë të metrikave për PgSQL "nga kutia".
Megjithatë, zgjedhja e çuditshme e resurseve Kubernetes të gjeneruar na çoi të kërkojmë një zgjidhje tjetër.
3. Zalando Postgres Operator
Produktet e Zalando na janĂ« njohur prej kohĂ«sh: kemi pĂ«rvojĂ« nĂ« pĂ«rdorimin e Zalenium dhe natyrisht, kemi provuar â zgjidhjen e tyre tĂ« njohur HA pĂ«r PostgreSQL. PĂ«r qasjen e kompanisĂ« nĂ« krijimin e fliste njĂ« nga autorĂ«t e tij â Alexey Klyukin â nĂ« transmetimin , dhe na pĂ«lqeu.
Ky është zgjidhja më e re nga ato të shqyrtuara në artikull: lansimi i parë ndodhi në gusht 2018. Megjithatë, edhe pse numri formal i lëshimeve është i vogël, projekti ka bërë një rrugë të madhe, duke e tejkaluar zgjidhjen nga Crunchy Data me mbi 1300 yje në GitHub dhe numrin maksimal të kontribuesve (70+).
«Nën kapak» këtë operator përdor zgjidhje të provuara me kohën:
- Patroni dhe për menaxhim,
- â pĂ«r backup,
- â si njĂ« pool lidhjesh.
Ja si është paraqitur arkitektura e operatorit nga Zalando:
Operatori menaxhohet plotësisht përmes Burimeve të Personalizuara, krijon automatikisht një StatefulSet nga kontejnerët, të cilët mund të personalizohen më pas duke shtuar në pod ndryshime të ndryshme. E gjithë kjo është një përfitim i konsiderueshëm krahasuar me operatorin nga Crunchy Data.
Për shkak se zgjidhja nga Zalando u zgjodh ndër 3 opsionet e shqyrtuara, përshkrimi i mëtejshëm i aftësive të saj do të paraqitet më poshtë, menjëherë së bashku me praktikën e aplikimit.
Praktika me Postgres Operator nga Zalando
Instalimi i operatorit ndodh shumë lehtë: mjafton të shkarkoni lansimin aktual nga GitHub dhe të aplikoni skedarët YAML nga direktorja . Si preferoni, mund të përdorni gjithashtu .
Pas instalimit, është e rëndësishme të mendoni për konfigurimin . Kjo bëhet përmes ConfigMap postgres-operator në hapësirën e emrave ku keni instaluar operatorin. Kur depozitat janë konfiguruar, mund të vendosni klasterin e parë PostgreSQL.
Për shembull, një deploy standard tek ne duket si më poshtë:
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 depolon një klaster prej 3 kopjeve me sidecar si , nga i cili marrim metrikat e aplikacionit. Siç e shihni, gjithçka është shumë e thjeshtë dhe nëse dëshironi mund të krijoni në mënyrë të pakufizuar klastera.
Duhet tĂ« kushtoni vĂ«mendje edhe pĂ«r panelin web pĂ«r administrim â . Ai sjellĂ« me operatorin dhe lejon krijimin dhe fshirjen e grupeve, si dhe punimin me backup-et qĂ« bĂ«n operatori.
Lista e grupeve PostgreSQL
Menaxhimi i backup-eve
Një karakteristikë tjetër interesante është mbështetja . Ky mekanizëm krijon automatikisht rollet në PostgreSQL, bazuar në listën e emrave të përdoruesve të marrë. Pas kësaj, API lejon kthimin e listës së përdoruesve, për të cilët krijohen automatikisht rolet.
Problemet dhe zgjidhjet e tyre
Megjithatë, përdorimi i operatorit shpejgoi disa disavantazhe të rëndësishme:
- mungesa e mbështetjes për nodeSelector;
- pamundësia për të çaktivizuar backup-et;
- në përdorimin e funksionit të krijimit të bazave nuk shfaqen privilegjet e zakonshme;
- herë pas here mungon dokumentacioni ose ai është në një gjendje të jashtme.
FatmirĂ«sisht, shumĂ« prej tyre mund tĂ« zgjidhen. Le tĂ« fillojmĂ« nga fundi â problemet me dokumentacionin.
Mundësisht do të përballeni me faktin se nuk është gjithmonë e qartë se si të shkruani backup-in dhe si të lidhni bucket-in e backup-it me Operator UI. Këtë përmend dokumentacioni vetëm në kalim, kurse përshkrimi i saktë është në :
- duhet të krijoni një sekret;
- ta përcillni atë operatorit si parametër
emri_i_secretit_të_pod_ambientitnë CRD me cilësimet e operatorit ose në ConfigMap (varet se si vendosni të instaloni operatorin).
MegjithatĂ«, siç ka rezultuar, aktualisht kjo nuk Ă«shtĂ« e mundur. PikĂ«risht pĂ«r kĂ«tĂ« arsye, ne grumbulluam me disa pĂ«rmirĂ«sime shtesĂ« nga palĂ« tĂ« treta. MĂ« shumĂ« pĂ«r kĂ«tĂ« â shih mĂ« poshtĂ«.
NĂ«se i kaloni operatorit parametrat pĂ«r backup, konkretisht â wal_s3_bucket dhe çelĂ«sat e qasjes nĂ« AWS S3, atĂ«herĂ« ai do tĂ« bĂ«jĂ« backup tĂ« gjithçkaje: jo vetĂ«m bazat nĂ« production, por edhe nĂ« staging. KĂ«tĂ« nuk e pranuam.
Në përshkrimin e parametrave për Spilo, e cila është mbështjellja bazë Docker për PgSQL kur përdorni operatorin, u zbulua: është e mundur të kaloni parametrin WAL_S3_BUCKET si bosh, kështu që të çaktivizoni backup-et. Më shumë se kaq, për kënaqësinë tonë u gjet një , të cilin ne e pranuam menjëherë në fork-un tonë. Tani mjafton të shtoni enableWALArchiving: false në burimin e klasterit PostgreSQL.
Po, kishte mundĂ«si tĂ« bĂ«hej ndryshe, duke e nisur 2 operatorĂ«: njĂ« pĂ«r staging (pa backup), dhe tjetri â pĂ«r production. Por kĂ«shtu arritĂ«m ta bĂ«jmĂ« me njĂ«.
Ok, mësuam të kalojmë në bazat e të dhënave qasjen për S3 dhe backup-et filluan të shkojnë në depo. Si ta bëjmë që faqet e backup-eve të funksionojnë në Operator UI?
Në UI-në e Operatorit do të nevojiten të shtohen 3 variabla:
-
SPILO_S3_BACKUP_BUCKET -
AWS_ACCESS_KEY_ID -
AWS_SECRET_ACCESS_KEY
Pas kësaj, menaxhimi i backup-eve do të jetë i disponueshëm, duke e lehtësuar punën me staging, duke lejuar dorëzimin e kopjeve nga production pa skripte shtesë.
Si një tjetër përfitim, u përmend puna me API e Teams dhe mundësitë e shkëputura për krijimin e bazave dhe roleve përmes operatorit. Megjithatë, rolet e krijuara nuk kishin të drejta të paracaktuara. Prandaj, një përdorues me të drejta leximi nuk mund të lexohej tabelat e reja.
Pse kĂ«shtu? Edhe pse nĂ« kodin e nevojshme GRANT, ato nuk aplikohet gjithmonĂ«. Ka 2 metoda: syncPreparedDatabases dhe syncDatabases. NĂ« syncPreparedDatabases â pavarĂ«sisht se nĂ« seksionin preparedDatabases ka njĂ« kusht defaultRoles dhe defaultUsers pĂ«r krijimin e roleve, â tĂ« drejtat e paracaktuara nuk aplikohen. Ne jemi nĂ« procesin e pĂ«rgatitjes sĂ« patch-it pĂ«r tĂ« siguruar qĂ« kĂ«to tĂ« drejta tĂ« aplikohen automatikisht.
Dhe momenti i fundit nĂ« pĂ«rmirĂ«simet aktuale pĂ«r ne â , duke Node Affinity nĂ« StatefulSet qĂ« po krijohet. KlientĂ«t tanĂ« shpesh preferojnĂ« tĂ« kursejnĂ« shpenzimet, duke pĂ«rdorur spot-instanca, dhe nuk Ă«shtĂ« e kĂ«shillueshme tĂ« vendosen shĂ«rbime DB aty. Ky problem mund tĂ« zgjidhet edhe pĂ«rmes tolerancave, por pranimi i Node Affinity ofron siguri mĂ« tĂ« madhe.
ĂfarĂ« dolĂ«n?
Pas zgjidhjes së problemeve të përmendura, ne fork-ëm Postgres Operator nga Zalando në , ku mbledh me patches kaq të dobishme. Për më shumë lehtësi, ne gjithashtu .
Lista e PR-ve, të pranuara në fork:
- ;
- ;
- ;
- .
Do të ishte e shkëlqyer, nëse komuniteti mbështet këto PR, që ato të kalojnë në upstream me versionin e ardhshëm të operatorit (1.6).
Bonus! Historia e suksesit me migrimin e production-it
Nëse përdorni Patroni, mund të migroni një production aktiv në operator me minimumin e ndërprerjeve.
Spilo lejon krijimin e klasterëve standby përmes magazinave S3 me , kur logu binar PgSQL ruhet më parë në S3 dhe më pas shkarkohet nga riprodhuesi. Por çfarë të bëni nëse keni nuk përdorur Wal-E në infrastrukturën e vjetër? Zgjidhja e këtij problemi është tashmë në Habra.
Replikimi logjik i PostgreSQL vjen në ndihmë. Megjithatë, nuk do të merremi me detaje se si të krijojmë publikime dhe abonime, sepse⊠plani ynë kishte dështuar.
Problemi është se në DB kishte disa tabela me ngarkesë të lartë të cilat kishin milionë rreshta, të cilat, për më tepër, vazhdimisht plotësoheshin dhe fshiheshin. me copy_data, kur një replikë e re kopjon të gjitha përmbajtjet nga masteri, thjesht nuk arrinte të zhvillohej pas masterit. Kopjimi i përmbajtjes punoi për një javë, por nuk arriti kurrë të arrinte masterin. Si rezultat, u zgjidh problemi me ndihmën e kolegëve nga Avito: mund të transferoni të dhënat duke përdorur pg_dump. Do të përshkruaj variantin tonë (pak të rregulluar) të këtij algoritmi.
Ideja është se mund të krijoni një abonim të fikur, të lidhur me një slot të caktuar të replikimit, dhe më pas të korrigjoni numrin e transaksionit. Kishim replika për punën e prodhimit. Kjo është e rëndësishme, sepse replika do të ndihmojë në krijimin e një dump të qëndrueshëm dhe në vazhdimin e marrjes së ndryshimeve nga masteri.
Në komandat e mëposhtme, që përshkruajnë procesin e migrimit, do të përdoren këto shënime për hostet:
- master â serveri burim;
- replica1 â replika logjike nĂ« prodhim tĂ« vjetĂ«r;
- replica2 â replika e re logjike.
Plani i migrimit
1. Të krijojmë një abonim në të gjitha tabelat në skemën e masterit publike baza dbname:
psql -h master -d dbname -c "KRIJO PUBLIKIM dbname PĂR TĂ GJITHA TABELAT;"
2. Të krijojmë një slot replikimi në master:
psql -h master -c "selekto pg_create_logical_replication_slot('repl', 'pgoutput');"
3. Të ndalim replikimin në replika e vjetër:
psql -h replica1 -c "selekto pg_wal_replay_pause();"
4. TĂ« marrim numrin e transaksionit nga masteri:
psql -h master -c "selekto replay_lsn nga pg_stat_replication ku client_addr = 'replica1';"
5. Të marrim dump nga replika e vjetër. Do ta bëjmë këtë në disa rrjedha, gjë që do të ndihmojë në përshpejtimin e procesit:
pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname
6. Të ngarkojmë dump në serverin e ri:
pg_restore -h replica2 -F d -j 8 -d dbname dump/
7. Pasi të ngarkohet dump-i, mund të fillojmë replikimin në replika të rrjedhës:
psql -h replica1 -c "selekto pg_wal_replay_resume();"
7. Të krijojmë një abonim në replika e re logjike:
psql -h replica2 -c "krijo abonim oldprod lidhja 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publikimi dbname me (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"
8. TĂ« marrim oid abonimet:
psql -h replica2 -d dbname -c "selekto oid, * nga pg_subscription;"
9. Le të themi, u mor oid=1000. Të aplikojmë numrin e transaksionit në abonim:
psql -h replica2 -d dbname -c "selekto pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"
10. TĂ« nisim replikimin:
psql -h replica2 -d dbname -c "alter subscription oldprod enable;"
11. Të kontrollojmë statusin e abonimit, replikimi 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. Pasi replikimi të nisë dhe bazat të jenë sinkronizuar, mund të bëhet kalimi.
13. Pasi të ndërpritet replikimi, duhet të korrigjohen sekuencat. Kjo është përshkruar mirë .
Falë këtij plani, kalimi u realizua me vonesa minimale.
PĂ«rfundimi
Operatorët e Kubernetes lejojnë thjeshtimin e veprimeve të ndryshme, duke i reduktuar ato në krijimin e resurseve K8s. Megjithatë, pasi të arrini një automatizim të shkëlqyer me ndihmën e tyre, është e rëndësishme të mbani mend se ajo mund të sjellë gjithashtu disa nuanca të papritura, prandaj qasuni me kujdes për zgjedhjen e operatorëve.
Pas shqyrtimit të tri operatorëve më të njohur Kubernetes për PostgreSQL, ne zgjodhëm projektin nga Zalando. Pavarësisht se u përballëm me disa sfida, rezultati na kënaqoi vërtet, kështu që planifikojmë ta zgjerim këtë përvojë edhe në disa instalime të tjera PgSQL. Nëse keni përvojë me zgjidhje të ngjashme, do të ishim të lumtur të shihnim detaje në komentet!
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «».
Burimi: habr.com
