🥇 'n Kort oorsig van PostgreSQL-operateurs vir Kubernetes, ons keuse en ervaring

Kliënte ontvang toenemend die volgende versoeke: "Ons wil dit soos Amazon RDS hê, maar goedkoper"; "Ons wil dit soos RDS hê, maar oral, in enige infrastruktuur." Om so 'n bestuurde oplossing op Kubernetes te implementeer, het ons gekyk na die huidige stand van die gewildste operateurs vir PostgreSQL (Solon, operateurs van Crunchy Data en Zalando) en ons keuse gemaak.

Hierdie artikel is die ervaring wat ons opgedoen het beide vanuit 'n teoretiese oogpunt (oorsig van oplossings) en van 'n praktiese kant (wat gekies is en wat daarvan gekom het). Maar eers, kom ons bepaal wat die algemene vereistes is vir 'n potensiële vervanging vir RDS ...

Wat is RDS

As mense oor RDS praat, bedoel ons volgens ons ervaring 'n bestuurde DBMS-diens wat:

maklik om te konfigureer;
het die vermoë om met foto's te werk en daarvan te herstel (verkieslik met ondersteuning PITR);
laat jou toe om meester-slaaf-topologieë te skep;
het 'n ryk lys van uitbreidings;
verskaf ouditering en gebruikers/toegangsbestuur.

Oor die algemeen kan benaderings tot die implementering van die taak op hande baie anders wees, maar die pad met voorwaardelike Ansible is nie naby ons nie. (Kollegas van 2GIS het gevolglik tot 'n soortgelyke gevolgtrekking gekom sy poging skep "'n instrument om 'n Postgres-gebaseerde failover-kluster vinnig te ontplooi.")

Operateurs is 'n algemene benadering om soortgelyke probleme in die Kubernetes-ekosisteem op te los. Die tegniese direkteur van "Flanta" het reeds in meer besonderhede oor hulle gepraat met betrekking tot databasisse wat binne Kubernetes bekendgestel is. distolIn een van sy verslae.

NB: Om vinnig eenvoudige operateurs te skep, beveel ons aan dat u aandag gee aan ons Oopbron-nutsding dop-operateur. Deur dit te gebruik, kan jy dit doen sonder kennis van Go, maar op maniere wat meer bekend is vir stelseladministrateurs: in Bash, Python, ens.

Daar is verskeie gewilde K8s-operateurs vir PostgreSQL:

Stolon;
Crunchy Data PostgreSQL-operateur;
Zalando Postgres Operator.

Kom ons kyk van nader na hulle.

Operator seleksie

Benewens die belangrike kenmerke wat reeds hierbo genoem is, het ons - as Kubernetes-infrastruktuurbedryfsingenieurs - ook die volgende van operateurs verwag:

ontplooiing vanaf Git en met Pasgemaakte hulpbronne;
peul teen affiniteit ondersteuning;
die installering van nodus affiniteit of nodus kieser;
installering van toleransies;
beskikbaarheid van instelvermoëns;
verstaanbare tegnologieë en selfs opdragte.

Sonder om in besonderhede oor elk van die punte in te gaan (vra in die kommentaar as jy nog vrae daaroor het nadat jy die hele artikel gelees het), sal ek in die algemeen daarop let dat hierdie parameters nodig is om die spesialisasie van klusternodusse meer akkuraat te beskryf ten einde bestel dit vir spesifieke toepassings. Op hierdie manier kan ons die optimale balans in terme van prestasie en koste bereik.

Kom ons gaan nou aan na die PostgreSQL-operateurs self.

1. Stolon

Stolon van die Italiaanse maatskappy Sorint.lab in reeds genoemde verslag is beskou as 'n soort standaard onder operateurs vir DBMS. Dit is 'n redelik ou projek: die eerste openbare vrystelling daarvan het in November 2015(!) plaasgevind, en die GitHub-bewaarplek spog met byna 3000 40 sterre en XNUMX+ bydraers.

Inderdaad, Stolon is 'n uitstekende voorbeeld van deurdagte argitektuur:

Die toestel van hierdie operateur kan in detail gevind word in die verslag of projek dokumentasie. In die algemeen is dit genoeg om te sê dat dit alles kan doen wat beskryf word: failover, gevolmagtigdes vir deursigtige kliënttoegang, rugsteun... Boonop bied gevolmagtigdes toegang deur een eindpuntdiens - anders as die ander twee oplossings wat hieronder bespreek word (hulle het elkeen twee dienste vir toegang tot basis).

Stolon egter geen pasgemaakte hulpbronne nie, en daarom kan dit nie op so 'n manier ontplooi word dat dit maklik en vinnig is - "soos soetkoek" - om DBMS-instansies in Kubernetes te skep. Bestuur word deur die nutsprogram uitgevoer stolonctl, ontplooiing word deur die Helm-kaart gedoen, en pasgemaakte word in ConfigMap gedefinieer en gespesifiseer.

Aan die een kant blyk dit dat die operateur nie regtig 'n operateur is nie (dit gebruik immers nie CRD nie). Maar aan die ander kant is dit 'n buigsame stelsel wat jou toelaat om hulpbronne in K8s op te stel soos jy goeddink.

Om op te som, vir ons persoonlik het dit nie optimaal gelyk om 'n aparte grafiek vir elke databasis te skep nie. Daarom het ons na alternatiewe begin soek.

2. Crunchy Data PostgreSQL-operateur

Operator van Crunchy Data, 'n jong Amerikaanse beginonderneming, het na 'n logiese alternatief gelyk. Die openbare geskiedenis daarvan begin met die eerste vrystelling in Maart 2017, sedertdien het die GitHub-bewaarplek net minder as 1300 50 sterre en 1.15+ bydraers ontvang. Die jongste vrystelling van September is getoets om te werk met Kubernetes 1.18-3.11, OpenShift 4.4+ en 1.3+, GKE en VMware Enterprise PKS XNUMX+.

Die argitektuur van Crunchy Data PostgreSQL Operator voldoen ook aan die gestelde vereistes:

Bestuur vind plaas deur die hulpprogram pgo, dit genereer egter op sy beurt pasgemaakte hulpbronne vir Kubernetes. Daarom het die operateur ons as potensiële gebruikers behaag:

daar is beheer via CRD;
gerieflike gebruikersbestuur (ook via CRD);
integrasie met ander komponente Crunchy Data Container Suite - 'n gespesialiseerde versameling houerbeelde vir PostgreSQL en nutsprogramme om daarmee te werk (insluitend pgBackRest, pgAudit, uitbreidings van bydrae, ens.).

Pogings om die operateur van Crunchy Data te begin gebruik het egter verskeie probleme aan die lig gebring:

Daar was geen moontlikheid van tolerasies nie - slegs nodeSelector word verskaf.
Die geskepde peule was deel van Ontplooiing, ten spyte van die feit dat ons 'n statige toepassing ontplooi het. In teenstelling met StatefulSets, kan Deployments nie skywe skep nie.

Die laaste nadeel lei tot snaakse oomblikke: in die toetsomgewing het ons daarin geslaag om 3 replikas met een skyf te laat loop plaaslike stoorplek, wat veroorsaak dat die operateur rapporteer dat 3 replikas werk (al was hulle nie).

Nog 'n kenmerk van hierdie operateur is sy klaargemaakte integrasie met verskeie hulpstelsels. Byvoorbeeld, dit is maklik om pgAdmin en pgBounce te installeer, en in dokumentasie vooraf-gekonfigureerde Grafana en Prometheus word oorweeg. In onlangse vrystelling 4.5.0-beta1 Daar word afsonderlik kennis geneem van verbeterde integrasie met die projek pgMonitor, waardeur die operateur 'n duidelike visualisering van PgSQL-metrieke uit die boks bied.

Die vreemde keuse van Kubernetes-gegenereerde hulpbronne het ons egter daartoe gelei dat ons 'n ander oplossing moes vind.

3. Zalando Postgres Operator

Ons ken Zalando-produkte al lank: ons het ondervinding met die gebruik van Zalenium en ons het natuurlik probeer Patroni is hul gewilde HA-oplossing vir PostgreSQL. Oor die maatskappy se benadering tot die skep Postgres-operateur een van die skrywers daarvan, Alexey Klyukin, op die lug gesê Postgres-Dinsdag #5, en ons het daarvan gehou.

Dit is die jongste oplossing wat in die artikel bespreek word: die eerste vrystelling het in Augustus 2018 plaasgevind. Selfs ten spyte van die klein aantal formele vrystellings, het die projek egter 'n lang pad gevorder en het reeds die oplossing van Crunchy Data met 1300+ sterre op GitHub en die maksimum aantal bydraers (70+) in gewildheid oortref.

"Onder die enjinkap" gebruik hierdie operateur beproefde oplossings:

Patroni en Spilo Vir bestuur,
WAL-E - vir rugsteun,
PgBouncer - as 'n verbindingspoel.

Dit is hoe die operateur-argitektuur van Zalando aangebied word:

Die operateur word ten volle bestuur deur Custom Resources, skep outomaties 'n StatefulSet uit houers, wat dan aangepas kan word deur verskeie syspan by die peul te voeg. Dit alles is 'n beduidende voordeel in vergelyking met die operateur van Crunchy Data.

Aangesien ons die oplossing van Zalando gekies het onder die 3 opsies wat oorweeg word, sal 'n verdere beskrywing van sy vermoëns hieronder aangebied word, onmiddellik saam met die praktyk van toepassing.

Oefen saam met Postgres Operator van Zalando

Operateursontplooiing is baie eenvoudig: laai net die huidige weergawe van GitHub af en pas die YAML-lêers vanaf die gids toe manifesteer. Alternatiewelik kan jy ook gebruik operateurhub.

Na die installasie moet u bekommerd wees oor die opstelling berging vir logs en rugsteun. Dit word gedoen via ConfigMap postgres-operator in die naamruimte waar jy die operateur geïnstalleer het. Sodra die bewaarplekke opgestel is, kan u u eerste PostgreSQL-kluster ontplooi.

Byvoorbeeld, ons standaard ontplooiing lyk soos volg:

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

Hierdie manifes ontplooi 'n groep van 3 gevalle met 'n syspan in die vorm postgres_uitvoerder, waaruit ons toepassingsstatistieke neem. Soos u kan sien, is alles baie eenvoudig, en as u wil, kan u 'n letterlik onbeperkte aantal trosse skep.

Dit is die moeite werd om aandag aan te gee webadministrasiepaneel - postgres-operateur-ui. Dit kom saam met die operateur en laat jou toe om groepe te skep en uit te vee, sowel as om te werk met rugsteun wat deur die operateur gemaak is.

Lys van PostgreSQL-klusters

Rugsteunbestuur

Nog 'n interessante kenmerk is die ondersteuning Spanne API. Hierdie meganisme skep outomaties rolle in PostgreSQL, gebaseer op die gevolglike lys gebruikersname. Die API laat jou dan toe om 'n lys van gebruikers terug te gee vir wie rolle outomaties geskep word.

Probleme en oplossings

Die gebruik van die operateur het egter gou verskeie beduidende tekortkominge aan die lig gebring:

gebrek aan nodeSelector ondersteuning;
onvermoë om rugsteun te deaktiveer;
wanneer die databasisskeppingsfunksie gebruik word, verskyn verstekvoorregte nie;
Soms ontbreek dokumentasie of is dit verouderd.

Gelukkig kan baie van hulle opgelos word. Kom ons begin van die einde - probleme met dokumentasie.

Waarskynlik sal jy die feit teëkom dat dit nie altyd duidelik is hoe om 'n rugsteun te registreer en hoe om die rugsteunemmer aan die operateur-UI te koppel nie. Die dokumentasie praat in die verbygaan hieroor, maar die werklike beskrywing is in PR:

moet 'n geheim maak;
gee dit aan die operateur as 'n parameter pod_environment_secret_name in die CRD met operateurinstellings of in ConfigMap (afhangende van hoe jy besluit om die operateur te installeer).

Soos dit blyk, is dit egter tans onmoontlik. Dis hoekom ons ingesamel het jou weergawe van die operateur met 'n paar bykomende derdeparty-ontwikkelings. Vir meer inligting daaroor, sien hieronder.

As jy die parameters vir rugsteun aan die operateur deurgee, naamlik - wal_s3_bucket en toegangsleutels in AWS S3, dan is dit sal alles rugsteun: nie net basisse in produksie nie, maar ook opvoering. Dit het ons nie gepas nie.

In die beskrywing van die parameters vir Spilo, wat die basiese Docker-omhulsel vir PgSQL is wanneer die operateur gebruik word, het dit geblyk: jy kan 'n parameter deurgee WAL_S3_BUCKET leeg, en daardeur deaktiveer rugsteun. Boonop het ek tot groot vreugde gevind gereed PR, wat ons dadelik in ons vurk aanvaar het. Nou moet jy net byvoeg enableWALArchiving: false na 'n PostgreSQL-klusterhulpbron.

Ja, daar was 'n geleentheid om dit anders te doen deur 2 operateurs te bestuur: een vir opvoering (sonder rugsteun), en die tweede vir produksie. Maar ons kon met een klaarkom.

Ok, ons het geleer hoe om toegang tot die databasisse vir S3 oor te dra en rugsteun het begin stoor. Hoe om rugsteunbladsye in Operator UI te laat werk?

Jy sal 3 veranderlikes by die operateur-UI moet voeg:

SPILO_S3_BACKUP_BUCKET
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

Hierna sal die bestuur van rugsteun beskikbaar word, wat in ons geval die werk met opvoering sal vereenvoudig, wat ons in staat sal stel om skywe van produksie daar af te lewer sonder bykomende skrifte.

Nog 'n voordeel was die werk met die Teams API en genoeg geleenthede om databasisse en rolle te skep deur gebruik te maak van operateurnutsgoed. Die geskepte rolle het by verstek geen regte gehad nie. Gevolglik kon 'n gebruiker met leesregte nie nuwe tabelle lees nie.

Hoekom is dit? Ten spyte van die feit dat in die kode daar is nodig GRANT, word hulle nie altyd gebruik nie. Daar is 2 metodes: syncPreparedDatabases и syncDatabases. In syncPreparedDatabases - ten spyte van die feit dat in die afdeling preparedDatabases daar is daar is 'n voorwaarde defaultRoles и defaultUsers om rolle te skep, word verstekregte nie toegepas nie. Ons is besig om 'n pleister voor te berei sodat hierdie regte outomaties toegepas word.

En die laaste punt in die verbeterings wat vir ons relevant is - kol, wat Node Affinity by die geskepte StatefulSet voeg. Ons kliënte verkies dikwels om koste te verminder deur spotgevalle te gebruik, en dit is duidelik nie die moeite werd om databasisdienste aan te bied nie. Hierdie probleem kan opgelos word deur tolerasies, maar die teenwoordigheid van Node Affinity gee groter vertroue.

Wat het gebeur?

Gebaseer op die resultate van die oplossing van bogenoemde probleme, het ons Postgres Operator van Zalando ingevurk jou bewaarplek, waar dit met sulke nuttige kolle versamel word. En vir groter gerief het ons ook ingesamel Docker-beeld.

Lys van PR's wat in die vurk aanvaar word:

Dit sal wonderlik wees as die gemeenskap hierdie PR's ondersteun sodat hulle stroomop kom met die volgende weergawe van die operateur (1.6).

Bonus! Produksie-migrasie suksesverhaal

As jy Patroni gebruik, kan lewendige produksie na die operateur gemigreer word met minimale stilstand.

Spilo laat jou toe om bystandgroepe te skep via S3-berging met Wal-E, wanneer die PgSQL-binêre logboek eers in S3 gestoor word en dan deur die replika uitgepomp word. Maar wat om te doen as jy het geen deur Wal-E op ou infrastruktuur gebruik? Die oplossing vir hierdie probleem is reeds dit is voorgestel op die hub.

PostgreSQL logiese replikasie kom tot die redding. Ons gaan egter nie in detail in oor hoe om publikasies en intekeninge te skep nie, want ... ons plan was 'n fiasko.

Die feit is dat die databasis verskeie gelaaide tabelle gehad het met miljoene rye, wat boonop voortdurend aangevul en uitgevee is. Eenvoudige intekening с copy_data, wanneer die nuwe replika al die inhoud van die meester kopieer, kan dit eenvoudig nie tred hou met die meester nie. Die kopiëring van inhoud het vir 'n week gewerk, maar het nooit die meester ingehaal nie. Op die ou end het dit my gehelp om die probleem op te los статья kollegas van Avito: jy kan data oordra met behulp van pg_dump. Ek sal ons (effens gewysigde) weergawe van hierdie algoritme beskryf.

Die idee is dat jy 'n gedeaktiveerde intekening kan maak wat gekoppel is aan 'n spesifieke replikasiegleuf, en dan die transaksienommer regstel. Daar was replikas beskikbaar vir produksiewerk. Dit is belangrik omdat die replika sal help om 'n konsekwente storting te skep en aanhou om veranderinge van die meester te ontvang.

Daaropvolgende opdragte wat die migrasieproses beskryf, sal die volgende gasheernotasies gebruik:

meester - bronbediener;
replika 1 — stroom replika op die ou produksie;
replika 2 - nuwe logiese replika.

Migrasieplan

1. Skep 'n intekening op die meester vir alle tabelle in die skema public basis dbname:

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

2. Skep 'n replikasiegleuf op die meester:

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

3. Stop replikasie op die ou replika:

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

4. Kry die transaksienommer van die meester:

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

5. Verwyder die storting van die ou replika. Ons sal dit in verskeie drade doen, wat sal help om die proses te bespoedig:

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

6. Laai die storting op na die nuwe bediener:

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

7. Nadat u die storting afgelaai het, kan u replikasie op die stroomreplika begin:

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

7. Kom ons skep 'n intekening op 'n nuwe logiese replika:

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. Kom ons kry oid intekeninge:

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

9. Kom ons sê dit is ontvang oid=1000. Kom ons pas die transaksienommer op die intekening toe:

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

10. Kom ons begin replikasie:

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

11. Gaan die intekeningstatus na, replikasie behoort te werk:

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. Nadat replikasie begin is en die databasisse gesinchroniseer is, kan jy oorskakel.

13. Nadat u replikasie gedeaktiveer het, moet u die rye regstel. Dit is goed beskryf in die artikel op wiki.postgresql.org.

Danksy hierdie plan het die oorskakeling met minimale vertragings plaasgevind.

Gevolgtrekking

Kubernetes-operateurs laat jou toe om verskeie aksies te vereenvoudig deur dit te verminder tot die skepping van K8s-hulpbronne. Nadat u egter merkwaardige outomatisering met hul hulp bereik het, is dit die moeite werd om te onthou dat dit ook 'n aantal onverwagte nuanses kan bring, so kies u operateurs verstandig.

Nadat ons die drie gewildste Kubernetes-operateurs vir PostgreSQL oorweeg het, het ons die projek van Zalando gekies. En ons moes sekere probleme daarmee oorkom, maar die resultaat was regtig aangenaam, so ons beplan om hierdie ervaring uit te brei na 'n paar ander PgSQL-installasies. As u ondervinding het met die gebruik van soortgelyke oplossings, sal ons bly wees om die besonderhede in die kommentaar te sien!

'n Kort oorsig van PostgreSQL-stellings vir Kubernetes, ons keuses en ervaring