Stutt yfirlit yfir PostgreSQL yfirlýsingar fyrir Kubernetes, val okkar og reynslu

Í auknum mæli fá viðskiptavinir eftirfarandi beiðnir: „Við viljum hafa það eins og Amazon RDS, en ódýrara“; „Við viljum hafa það eins og RDS, en alls staðar, í hvaða innviði sem er. Til að innleiða slíka stýrða lausn á Kubernetes skoðuðum við núverandi stöðu vinsælustu rekstraraðila fyrir PostgreSQL (Solon, rekstraraðilar frá Crunchy Data og Zalando) og gerðum okkar val.

Þessi grein er sú reynsla sem við höfum öðlast bæði frá fræðilegu sjónarhorni (endurskoðun lausna) og frá hagnýtri hlið (hvað var valið og hvað varð úr því). En fyrst skulum við ákveða hverjar almennu kröfurnar eru fyrir hugsanlegan staðgengil fyrir RDS...

Hvað er RDS

Þegar fólk talar um RDS, í okkar reynslu, meina það stýrða DBMS þjónustu sem:

1. auðvelt að stilla;
2. hefur getu til að vinna með skyndimyndir og jafna sig á þeim (helst með stuðningi PITR);
3. gerir þér kleift að búa til meistara-þræla svæðisfræði;
4. hefur ríkan lista yfir viðbætur;
5. veitir endurskoðun og notenda-/aðgangsstjórnun.

Almennt séð geta aðferðir við útfærslu verkefnisins verið mjög mismunandi, en leiðin með skilyrtum Ansible er ekki nálægt okkur. (Samstarfsmenn frá 2GIS komust að svipaðri niðurstöðu í kjölfarið tilraun hans búa til "tól til að dreifa á fljótlegan hátt Postgres-undirstaða failover þyrping."

Rekstraraðilar eru algeng nálgun til að leysa svipuð vandamál í Kubernetes vistkerfinu. Tæknistjóri „Flanta“ hefur þegar talað nánar um þá í tengslum við gagnagrunna sem hleypt er af stokkunum í Kubernetes. distólÍ ein af skýrslum hans.

NB: Til að búa til einfalda rekstraraðila fljótt mælum við með að þú fylgist með Open Source tólinu okkar skel-rekstraraðili. Með því að nota það geturðu gert þetta án vitneskju um Go, en á þann hátt sem kerfisstjórar þekkja betur: í Bash, Python osfrv.

Það eru nokkrir vinsælir K8s rekstraraðilar fyrir PostgreSQL:

• Stolon;
• Crunchy Data PostgreSQL Operator;
• Zalando Postgres rekstraraðili.

Við skulum skoða þær nánar.

Val rekstraraðila

Til viðbótar við mikilvægu eiginleikana sem þegar eru nefndir hér að ofan, bjuggumst við - sem Kubernetes innviða rekstrarverkfræðingar - einnig eftirfarandi frá rekstraraðilum:

• dreifing frá Git og með Sérsniðnar auðlindir;
• stuðningur við fræbelg gegn sækni;
• setja upp hnútsækni eða hnútaval;
• uppsetning á vikmörkum;
• framboð á stillingarmöguleikum;
• skiljanlega tækni og jafnvel skipanir.

Án þess að fara í smáatriði um hvert atriði (spurðu í athugasemdum ef þú hefur enn spurningar um þá eftir að hafa lesið alla greinina), mun ég taka það almennt fram að þessar færibreytur eru nauðsynlegar til að lýsa nákvæmari sérhæfingu klasahnúta til að panta þær fyrir sérstakar umsóknir. Þannig getum við náð besta jafnvægi hvað varðar frammistöðu og kostnað.

Nú skulum við halda áfram að PostgreSQL rekstraraðilanum sjálfum.

1. Stolon

Stolon frá ítalska fyrirtækinu Sorint.lab í þegar nefnd skýrsla var talinn eins konar staðall meðal rekstraraðila fyrir DBMS. Þetta er frekar gamalt verkefni: fyrsta opinbera útgáfan þess fór fram í nóvember 2015(!), og GitHub geymslan státar af næstum 3000 stjörnum og 40+ þátttakendum.

Reyndar er Stolon frábært dæmi um ígrundaða arkitektúr:

Tæki þessa rekstraraðila er að finna í smáatriðum í skýrslunni eða verkefnisskjöl. Almennt er nóg að segja að það getur gert allt sem lýst er: bilun, umboð fyrir gagnsæjan aðgang viðskiptavinar, afrit... Þar að auki veita umboðsmenn aðgang í gegnum eina endapunktaþjónustu - ólíkt hinum tveimur lausnunum sem fjallað er um hér að neðan (þeir hafa hvor um sig tvær þjónustur fyrir aðgangsstöð).

Hins vegar Stolon engin sérsniðin tilföng, þess vegna er ekki hægt að nota það þannig að auðvelt og fljótlegt sé – „eins og heitar lummur“ – að búa til DBMS-tilvik í Kubernetes. Stjórnun fer fram í gegnum veituna stolonctl, dreifing er gerð í gegnum Helm töfluna og sérsniðnar eru skilgreindar og tilgreindar í ConfigMap.

Annars vegar kemur í ljós að rekstraraðilinn er í raun ekki rekstraraðili (enda notar hann ekki CRD). En á hinn bóginn er það sveigjanlegt kerfi sem gerir þér kleift að stilla auðlindir í K8s eins og þér sýnist.

Til að draga saman, fyrir okkur persónulega virtist það ekki ákjósanlegt að búa til sérstakt töflu fyrir hvern gagnagrunn. Þess vegna fórum við að leita að valkostum.

2. Crunchy Data PostgreSQL Operator

Rekstraraðili frá Crunchy Data, ungt amerískt sprotafyrirtæki, virtist vera rökrétt val. Opinber saga þess hefst með fyrstu útgáfu í mars 2017, síðan þá hefur GitHub geymslan fengið tæplega 1300 stjörnur og 50+ þátttakendur. Nýjasta útgáfan frá september var prófuð til að virka með Kubernetes 1.15-1.18, OpenShift 3.11+ og 4.4+, GKE og VMware Enterprise PKS 1.3+.

Arkitektúr Crunchy Data PostgreSQL Operator uppfyllir einnig tilgreindar kröfur:

Stjórnun fer fram í gegnum veituna pgo, hins vegar býr það aftur til sérsniðna tilföng fyrir Kubernetes. Þess vegna gladdi rekstraraðilinn okkur sem hugsanlega notendur:

• það er stjórn í gegnum CRD;
• þægileg notendastjórnun (einnig með CRD);
• samþættingu við aðra hluti Crunchy Data Container Suite — sérhæft safn gámamynda fyrir PostgreSQL og tóla til að vinna með það (þar á meðal pgBackRest, pgAudit, viðbætur frá contrib, osfrv.).

Hins vegar, tilraunir til að byrja að nota símafyrirtækið frá Crunchy Data leiddu í ljós nokkur vandamál:

• Það var enginn möguleiki á þolmörkum - aðeins nodeSelector er til staðar.
• Stofnuðu belgirnir voru hluti af Deployment, þrátt fyrir að við sendum inn staðbundið forrit. Ólíkt StatefulSets getur Deployments ekki búið til diska.

Síðasti gallinn leiðir til fyndna augnablika: í prófunarumhverfinu tókst okkur að keyra 3 eftirlíkingar með einum diski staðbundin geymsla, sem olli því að rekstraraðilinn tilkynnti að 3 eftirlíkingar væru að virka (jafnvel þó þær væru það ekki).

Annar eiginleiki þessa rekstraraðila er tilbúin samþætting hans við ýmis aukakerfi. Til dæmis er auðvelt að setja upp pgAdmin og pgBounce og inn skjöl Forstillt Grafana og Prometheus koma til greina. Nýlega útgáfa 4.5.0-beta1 Bætt samþætting við verkefnið er sérstaklega tekið fram pgMonitor, þökk sé því sem rekstraraðilinn býður upp á skýra mynd af PgSQL mæligildum úr kassanum.

Hins vegar, hið undarlega val á Kubernetes-mynduðum auðlindum leiddi okkur til þess að við þurftum að finna aðra lausn.

3. Zalando Postgres rekstraraðili

Við höfum þekkt Zalando vörur í langan tíma: við höfum reynslu af notkun Zalenium og auðvitað reyndum við Patroni er vinsæl HA lausn þeirra fyrir PostgreSQL. Um nálgun fyrirtækisins við að skapa Postgres rekstraraðili einn af höfundum þess, Alexey Klyukin, sagði í loftinu Postgres-þriðjudagur #5, og okkur líkaði það.

Þetta er yngsta lausnin sem fjallað er um í greininni: fyrsta útgáfan átti sér stað í ágúst 2018. Hins vegar, þrátt fyrir fáan fjölda formlegra útgáfur, hefur verkefnið náð langt og hefur þegar farið fram úr í vinsældum lausninni frá Crunchy Data með 1300+ stjörnum á GitHub og hámarksfjölda þátttakenda (70+).

„Undir hettunni“ notar þessi rekstraraðili tímaprófaðar lausnir:

• Patroni og Leikur Fyrir akstur,
• WAL-E - fyrir öryggisafrit,
• PgBouncer - sem tengilaug.

Svona er stjórnendaarkitektúrinn frá Zalando kynnt:

Rekstraraðili er að fullu stjórnað í gegnum Custom Resources, býr sjálfkrafa til StatefulSet úr gámum, sem síðan er hægt að aðlaga með því að bæta ýmsum hliðarvagnum við belginn. Allt er þetta verulegur kostur í samanburði við rekstraraðilann frá Crunchy Data.

Þar sem við völdum lausnina frá Zalando meðal 3 valmöguleika sem eru til skoðunar, verður frekari lýsing á getu hennar kynnt hér að neðan, strax ásamt notkunarmöguleikum.

Æfðu með Postgres Operator frá Zalando

Uppsetning rekstraraðila er mjög einföld: halaðu bara niður núverandi útgáfu frá GitHub og notaðu YAML skrárnar úr möppunni birtist. Að öðrum kosti geturðu líka notað rekstrarmiðstöð.

Eftir uppsetningu ættir þú að hafa áhyggjur af uppsetningu geymsla fyrir annála og öryggisafrit. Þetta er gert í gegnum ConfigMap postgres-operator í nafnarýminu þar sem þú settir upp símafyrirtækið. Þegar geymslurnar hafa verið stilltar geturðu sent inn fyrsta PostgreSQL þyrpinguna þína.

Til dæmis lítur staðlað uppsetning okkar svona út:

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

Þessi upplýsingaskrá dreifir þyrpingu af 3 tilfellum með hliðarvagni í formi postgres_exporter, þaðan sem við tökum umsóknarmælingar. Eins og þú sérð er allt mjög einfalt og ef þú vilt geturðu búið til bókstaflega ótakmarkaðan fjölda klasa.

Það er þess virði að gefa gaum vefstjórnborð - postgres-operator-ui. Það kemur með símafyrirtækinu og gerir þér kleift að búa til og eyða klösum, auk þess að vinna með afrit sem símafyrirtækið gerir.

Listi yfir PostgreSQL klasa

Afritunarstjórnun

Annar áhugaverður eiginleiki er stuðningurinn Teams API. Þessi vélbúnaður skapar sjálfkrafa hlutverk í PostgreSQL, byggt á listanum yfir notendanöfn. API gerir þér síðan kleift að skila lista yfir notendur sem hlutverk eru sjálfkrafa búin til fyrir.

Vandamál og lausnir

Hins vegar leiddi notkun símafyrirtækisins fljótlega í ljós nokkra verulega annmarka:

1. skortur á nodeSelector stuðningi;
2. vanhæfni til að slökkva á öryggisafritum;
3. þegar þú notar aðgerðina til að búa til gagnagrunn birtast sjálfgefin réttindi ekki;
4. Stundum vantar skjöl eða þau eru úrelt.

Sem betur fer er hægt að leysa mörg þeirra. Við skulum byrja á endanum - vandamál með skjöl.

Líklegast muntu lenda í þeirri staðreynd að það er ekki alltaf ljóst hvernig á að skrá öryggisafrit og hvernig á að tengja öryggisafritið við notendaviðmótið. Skjölin tala um þetta í framhjáhlaupi, en raunveruleg lýsing er inn PR:

1. þarf að gera leyndarmál;
2. sendu það til rekstraraðila sem færibreytu pod_environment_secret_name í CRD með stjórnandastillingum eða í ConfigMap (fer eftir því hvernig þú ákveður að setja upp símafyrirtækið).

Hins vegar, eins og það kemur í ljós, er þetta ómögulegt eins og er. Þess vegna söfnuðum við þín útgáfa af símafyrirtækinu með nokkrum viðbótarþróun þriðja aðila. Fyrir frekari upplýsingar um það, sjá hér að neðan.

Ef þú sendir breytur fyrir öryggisafrit til símafyrirtækisins, þ.e. wal_s3_bucket og aðgangslykla í AWS S3, þá er það mun taka öryggisafrit af öllu: ekki aðeins bækistöðvar í framleiðslu, heldur einnig sviðsetningu. Þetta hentaði okkur ekki.

Í lýsingu á breytum fyrir Spilo, sem er grunn Docker umbúðirnar fyrir PgSQL þegar stjórnandi er notaður, kom í ljós: þú getur sent færibreytu WAL_S3_BUCKET tóm, þar með óvirkt afrit. Þar að auki fann ég til mikillar gleði tilbúið PR, sem við þáðum strax í gaffalinn okkar. Nú þarf bara að bæta við enableWALArchiving: false í PostgreSQL klasatilföng.

Já, það var tækifæri til að gera það öðruvísi með því að keyra 2 rekstraraðila: einn fyrir sviðsetningu (án öryggisafrita) og hinn fyrir framleiðslu. En við gátum látið okkur nægja einn.

Allt í lagi, við lærðum hvernig á að flytja aðgang að gagnagrunnum fyrir S3 og afrit fóru að komast í geymslu. Hvernig á að láta varasíður virka í Operator UI?

Þú þarft að bæta 3 breytum við rekstrarviðmótið:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Eftir þetta verður stjórnun öryggisafrita í boði, sem í okkar tilfelli mun einfalda vinnuna við sviðsetningu, sem gerir okkur kleift að afhenda sneiðar úr framleiðslu þangað án viðbótarforskrifta.

Annar kostur var vinnan með Teams API og næg tækifæri til að búa til gagnagrunna og hlutverk með því að nota rekstrartæki. Hins vegar skapaði hlutverk höfðu engin réttindi sjálfgefið. Samkvæmt því gat notandi með lesréttindi ekki lesið nýjar töflur.

Afhverju er það? Þrátt fyrir þá staðreynd að í kóðanum есть nauðsynlegt GRANT, þau eru ekki alltaf notuð. Það eru 2 aðferðir: syncPreparedDatabases и syncDatabases. Í syncPreparedDatabases - þrátt fyrir að í þáltill preparedDatabases есть það er skilyrði defaultRoles и defaultUsers til að búa til hlutverk eru sjálfgefin réttindi ekki notuð. Við erum að undirbúa plástur þannig að þessi réttindi verði sjálfkrafa beitt.

Og síðasti punkturinn í endurbótunum sem eiga við okkur - plástur, sem bætir Node Affinity við stofnað StatefulSet. Viðskiptavinir okkar kjósa oft að draga úr kostnaði með því að nota staðsetningartilvik og þeir eru greinilega ekki þess virði að hýsa gagnagrunnsþjónustu. Þetta mál gæti verið leyst með umburðarlyndi, en tilvist Node Affinity gefur meira sjálfstraust.

Hvað gerðist?

Byggt á niðurstöðum úr því að leysa ofangreind vandamál, gafluðum við Postgres Operator frá Zalando inn geymsluna þína, þar sem því er safnað með svo gagnlegum plástrum. Og til meiri þæginda söfnuðum við líka Docker mynd.

Listi yfir PR sem samþykktir eru í gaffalinn:

• byggja upp örugga létta mynd fyrir rekstraraðilann í Docker;
• slökkva á öryggisafritum;
• að uppfæra auðlindaútgáfur fyrir núverandi útgáfur af k8s;
• innleiðing á Node Affinity.

Það verður frábært ef samfélagið styður þessa PR svo að þeir komist í andstreymis með næstu útgáfu af símafyrirtækinu (1.6).

Bónus! Árangurssaga framleiðsluflutninga

Ef þú notar Patroni er hægt að flytja lifandi framleiðslu til rekstraraðila með lágmarks niður í miðbæ.

Spilo gerir þér kleift að búa til biðklasa í gegnum S3 geymslu með Wal-E, þegar PgSQL tvíundarskráin er fyrst geymd í S3 og síðan dælt út af eftirmyndinni. En hvað á að gera ef þú hefur ekki notað af Wal-E á gömlum innviðum? Lausnin á þessu vandamáli er nú þegar það var lagt til á miðstöðinni.

PostgreSQL rökrétt afritun kemur til bjargar. Hins vegar munum við ekki fara í smáatriði um hvernig eigi að búa til útgáfur og áskriftir, því ... áætlun okkar var misheppnuð.

Staðreyndin er sú að gagnagrunnurinn hafði nokkrar hlaðnar töflur með milljónum raða, sem þar að auki var stöðugt endurnýjað og eytt. Einföld áskrift с copy_data, þegar nýja eftirmyndin afritar allt innihald frá meistaranum getur hún einfaldlega ekki haldið í við meistarann. Afritun efnis virkaði í viku en náði aldrei meistaranum. Að lokum hjálpaði það mér að leysa vandamálið grein samstarfsmenn frá Avito: þú getur flutt gögn með því að nota pg_dump. Ég mun lýsa (örlítið breyttri) útgáfu okkar af þessu reikniriti.

Hugmyndin er sú að þú getur búið til óvirka áskrift sem er bundin við ákveðna afritunarlotu og leiðrétt síðan færslunúmerið. Það voru eftirlíkingar í boði fyrir framleiðsluvinnu. Þetta er mikilvægt vegna þess að eftirmyndin mun hjálpa til við að búa til stöðugt sorp og halda áfram að fá breytingar frá skipstjóranum.

Síðari skipanir sem lýsa flutningsferlinu munu nota eftirfarandi hýsilmerkingar:

1. húsbóndi - frumþjónn;
2. eftirmynd 1 — streymandi eftirmynd af gömlu framleiðslunni;
3. eftirmynd 2 - ný rökrétt eftirmynd.

Flutningaáætlun

1. Búðu til áskrift á master fyrir allar töflur í skema public stöð dbname:

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

2. Búðu til afritunarrauf á masternum:

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

3. Stöðva afritun á gömlu eftirmyndinni:

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

4. Fáðu viðskiptanúmerið frá skipstjóra:

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

5. Fjarlægðu sorphauginn af gömlu eftirmyndinni. Við munum gera þetta í nokkrum þræði, sem mun hjálpa til við að flýta ferlinu:

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

6. Hladdu upp sorpinu á nýja netþjóninn:

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

7. Eftir að hafa hlaðið niður afritinu geturðu byrjað að afrita á straumafrituninni:

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

7. Búum til áskrift á nýrri rökréttri eftirmynd:

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. Við skulum fá oid áskrift:

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

9. Segjum að það hafi borist oid=1000. Notum færslunúmerið á áskriftina:

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

10. Byrjum á afritun:

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

11. Athugaðu áskriftarstöðuna, afritun ætti að virka:

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. Eftir að afritun er hafin og gagnagrunnar eru samstilltir geturðu skipt yfir.

13. Eftir að hafa slökkt á endurtekningu þarftu að leiðrétta raðirnar. Þessu er vel lýst í greininni á wiki.postgresql.org.

Þökk sé þessari áætlun fór breytingin fram með lágmarks töfum.

Ályktun

Kubernetes rekstraraðilar leyfa þér að einfalda ýmsar aðgerðir með því að draga úr þeim til að búa til K8s auðlindir. Hins vegar, eftir að hafa náð ótrúlegri sjálfvirkni með hjálp þeirra, er þess virði að muna að það getur einnig komið með fjölda óvæntra blæbrigða, svo veldu rekstraraðila þína skynsamlega.

Eftir að hafa skoðað þrjá vinsælustu Kubernetes rekstraraðilana fyrir PostgreSQL, völdum við verkefnið frá Zalando. Og við þurftum að sigrast á ákveðnum erfiðleikum með það, en niðurstaðan var virkilega ánægjuleg, svo við ætlum að víkka þessa upplifun yfir í nokkrar aðrar PgSQL uppsetningar. Ef þú hefur reynslu af því að nota svipaðar lausnir munum við vera ánægð með að sjá upplýsingarnar í athugasemdunum!

PS

Lestu líka á blogginu okkar:

• «Gagnagrunnar og Kubernetes (endurskoðun og myndbandsskýrsla)»;
• «Postgres þriðjudagur #5: PostgreSQL og Kubernetes. CI/CD. Prófa sjálfvirkni»;
• «Ein saga með Redis rekstraraðilanum í K8s og smáúttekt á tólum til að greina gögn úr þessum gagnagrunni'.

Heimild: www.habr.com