Lühike ülevaade PostgreSQL operaatoritest Kuberneteses, meie valik ja kogemus

Kliendid küsivad üha enam: „Soovime nagu Amazon RDS, aga odavamalt“; „Soovime nagu RDS, aga igas infrastruktuuris“. Sellise hallatud lahenduse rakendamiseks Kuberneteses vaatasime üle kõige populaarsemate PostgreSQL operaatorite (Stolon, Crunchy Data ja Zalando operaatorid) hetkeolukorra ja tegime oma valiku.

See artikkel on meie saadud kogemus nii teoreetilisest küljest (lahenduste ülevaade) kui ka praktilisest küljest (mida valiti ja kuidas see välja kukkus). Kuid kõigepealt leiame välja, millised nõuded esitatakse võimaliku RDS asendaja suhtes...

Mis on RDS?

Kui inimesed räägivad RDS-ist, siis meie kogemuse järgi mõistetakse hallatavat (managed) andmebaasi teenust, mis:

1. on lihtsalt seadistatav;
2. ilma snapshot'ide toeta, mille abil taastuda (soovitatavalt — toetades PITR);
3. võib luua master-slave topoloogiaid;
4. on rikkalik laiendite loetelu;
5. pakub kasutusõiguste ja halduste auditit.

Kui rääkida üldiselt, siis lähenemisviisid seatud ülesande täitmiseks võivad olla üsna erinevad, kuid Ansible'i tee ei ole meile lähenev. (Sarnasele järeldusele jõudsid ka meie kolleegid 2GIS-ist pärast oma katset luua „vahend kiireks tornaadoresistentse Postgresi klastrisse paigaldamiseks“.)

Just operaatorid on levinud lähenemine sarnaste probleemide lahendamiseks Kubernetes ökosüsteemis. Rääkisime nende rakendamisest andmebaaside kontekstis, mida käivitatakse Kuberneteses, tehnilise direktor „Flantast“ distol, in oma ettekandes.

NB: Kiireks ja lihtsate operaatorite loomiseks soovitame tähelepanu pöörata meie Open Source utiliidile shell-operator. Selle abil on võimalik seda teha ilma Go teadmisteta ja süsteemi administraatoritele tuttavamate meetoditega: Bash, Python jne.

PostgreSQL-i jaoks on mõned populaarsed K8s operaatorid:

• Stolon;
• Crunchy Data PostgreSQL Operator;
• Zalando Postgres Operator.

Vaadakem neid lähemalt.

Operaatori valik

Peale nende oluliste võimaluste, millest juba varem räägiti, ootasime me — Kubernetes infrastruktuurihalduriteks — operaatoritelt ka järgmist:

• deploeerimist Gitist ja Custom Resources;
• pod anti-affinity toetust;
• node affinity või node selector seadistamist;
• tolerations seadistamist;
• häälestamisvõimaluste olemasolu;
• selged tehnoloogiad ja isegi käsud.

Süviti detaile igast punktist (küsige kommentaarides, kui teil jääb pärast artikli lugemist veel küsimusi), märgin üldiselt, et need parameetrid on vajalikud klastrite sõlmede spetsialiseerimise täpsemaks kirjeldamiseks, et neid tellida konkreetselt rakenduste jaoks. Nii saame saavutada optimaalset tasakaalu jõudluse ja hinna osas.

Nüüd — PostgreSQL operaatorite juurde.

1. Stolon

Stolon Itaalia ettevõttelt Sorint.lab eelnevalt mainitud ettekandes peeti mingisuguseks standardiks andmebaasi operaatorite seas. See on üsna vana projekt: esimene avalik väljaanne toimus juba novembris 2015(!), ja GitHubi hoidla võib uhkeldada peaaegu 3000 tähe ja 40+ kaasautorega.

Ja tõepoolest, Stolon on suurepärane näide läbimõeldud arhitektuurist:

Selle operaatori seadistamisega saab tutvuda ettekandes või projekti dokumentatsioonis. Üldiselt võib öelda, et ta suudab teha kõike, mis on kirjas: failover, läbipaistva kliendi juurdepääsu proksid, varukoopiad... Lisaks pakuvad proksid ühte teeninduspunkti — erinevalt kahest teisest lahendusest, mida arutatakse edasi (nendel on kaks teenust andmebaasi juurde pääsemiseks).

Kuid Stolonil pole Custom Resources, mis tähendab, et seda ei saa deploy'ida nii, et lihtsasti ja kiiresti — „nagu kuumad pirukad“ — luua andmebaasi eksemplare Kuberneteses. Halduse teostab utiliit stolonctl, deploy on läbi Helm chart'i ja kasutaja määratud ressursid määratakse ConfigMap'is.

Ühelt poolt näib, et operaator ei olegi tõeline operaator (kuna ta ei kasuta CRD-d). Teiselt poolt on tegemist paindliku süsteemiga, mis võimaldab ressursse K8s-s seadistada nii, nagu teile sobib.

Kokkuvõttes ei tundunud meile optimaalne luua eraldi chart iga andmebaasi jaoks. Seetõttu hakkasime otsima alternatiive.

2. Crunchy Data PostgreSQL Operator

Crunchy Data operaator, noore Ameerika idufirma, näis loogilise alternatiivina. Selle avalik ajalugu algas esimese väljaandega märtsis 2017 ja sellest ajast on GitHubi hoidla saanud vähem kui 1300 tähte ja 50+ kaasautorit. Viimane väljaanne septembrist on testitud koostöös Kubernetes 1.15—1.18, OpenShift 3.11+ ja 4.4+, GKE ja VMware Enterprise PKS 1.3+.

Crunchy Data PostgreSQL Operaatori arhitektuur vastab samuti nõuetele:

Halduse teostamine toimub utiliidi kaudu pgo, kuid see genereerib omakorda Custom Resources Kubernetes'e jaoks. Seetõttu rõõmustas meid kui potentsiaalseid kasutajaid operaator:

• on haldamine läbi CRD;
• mugav kasutajate haldamine (samuti läbi CRD);
• integreerimine teiste komponentidega Crunchy Data Container Suite — spetsiaalne konteinerite piltide kogum PostgreSQL jaoks ja tööriistad selle kasutamiseks (sealhulgas pgBackRest, pgAudit, laiendused contrib-ist jne).

Siiski tõid jõupingutused Crunchy Data operaatori kasutusele võtmisega esile mitmeid probleeme:

• Toleratsioonide võimalust ei olnud — ette nähtud oli vaid nodeSelector.
• Loodud pod'id olid osa Deployment'ist, kuigi me juurutame stateful rakendust. Erinevalt StatefulSet'ist ei oska Deployment'id luua kettaid.

Viimane puudus toob välja lõbusaid momente: testkeskkonnas õnnestus käivitada 3 koopiat ühe ketta abil kohalikku salvestust, mistõttu operaator teatas, et 3 koopiat töötab (kuigi see polnud tõsi).

Veel üheks selle operaatori eripäraks on valmis integratsioon erinevate abisüsteemidega. Näiteks on lihtne paigaldada pgAdmin ja pgBounce, ning dokumentatsioon kaalutakse eelnevalt seadistatud Grafana ja Prometheust. Hiljuti välja antud versioonis 4.5.0-beta1 toodud välja täiustatud integratsioon projekti pgMonitor, tänu millele operaator pakub visuaalset statistikat PgSQL üle vaate „karbist välja“.

Sellegipoolest viis kummaline valik genereeritud Kubernetes'e ressurssidest meid vajadusele leida teine lahendus.

3. Zalando Postgres Operaator

Zalando tooted on meile juba pikka aega tuttavad: meil on kogemus Zalenium'i kasutamisest ja muidugi proovisin me ka Patronit — nende populaarne HA-lahendus PostgreSQL jaoks. Ettevõtte lähenemisest Postgres Operaatori rääkis üks selle autoritest — Alexey Klyukin — saates Postgres-teisipäev №5, ja see meeldis meile.

See on artiklis käsitletud noorim lahendus: esimene väljaanne toimus 2018. aasta augustis. Siiski, hoolimata väikesest ametlikest väljaannetest, on projekt teinud suuri edusamme, edestades juba Crunchy Data lahendust, millel on üle 1300 tähe GitHub'is ja maksimaalne panustajate arv (üle 70).

Selle operaatori „kapoti all“ on ajaliselt tõestatud lahendused:

• Patroni ja Spilo halduseks,
• WAL-E varukoopiate jaoks,
• PgBouncer ühenduste basena.

Siit on esitatud Zalando operaatori arhitektuur:

Operaatorit hallatakse täielikult Custom Resources kaudu, mis loob automaatselt StatefulSet'ist konteineridest, mida saab seejärel kohandada, lisades pod'i erinevaid sidecar'e. See on suur eelis võrreldes Crunchy Data operaatoriga.

Kuna just Zalando lahendus valiti kolmest kaalutud variandist, on allpool esitatud rohkem teavet selle võimaluste kohta koos rakenduse praktikaga.

Zalando Postgres Operaatori praktika

Operaatori juurutamine toimub väga lihtsalt: piisab, kui laadida alla uusim versioon GitHub'ist ja rakendada YAML-failid katalogist. manifests. Teise võimalusena saab kasutada ka OperatorHub.

Pärast paigaldamist tuleks hoolitseda logide ja varukoopiate salvestusruumide seadistamise eest. See toimub ConfigMap kaudu postgres-operator nimetamiseks, kuhu operaator paigaldati. Kui salvestusruumid on seadistatud, saab juurutada esimese PostgreSQL klastri.

Näiteks näeb meie standardne juurutamine välja järgmine:

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

See manifest juurutab 3 eksemplari klastrit koos sidecar'iga postgres_exporter, mille kaudu kogume rakenduse mõõtmeid. Nagu näete, on kõik väga lihtne ja soovi korral saab luua peaaegu piiramatu arvu klastreid.

Tasub tähelepanu pöörata ka administratiivsele veebipaneelile — postgres-operator-ui. See tuleb koos operaatoriga ja võimaldab luua ja eemaldada klastreid ning töötada varukoopiate kallal, mida operaator loob.

PostgreSQL klastrite nimekiri

Varude haldamine

Teine huvitav omadus on Teams API. See mehhanism loob automaatselt rollid PostgreSQL-is, lähtudes saadud kasutajate nimede loendist. Pärast seda võimaldab API esitada kasutajate loendi, kellele luuakse automaatselt rollid.

Probleemid ja nende lahendamine

Kuid operaatori kasutamine tõi peagi esile mitmeid olulisi puudusi:

1. nodeSelectori toe puudumine;
2. varukoopiate keelamise võimatuse;
3. andmebaaside loomise funktsiooni kasutamisel ei anta vaikimisi õigusi;
4. vahel puudub dokumentatsioon või on see aegunud.

Õnneks on paljud neist lahendatavad. Alustame lõpust - probleemidega Microsofti dokumentatsioonile. Ainus tähelepanek — Ubuntu distributsiooni oleme juba alla laadinud ja installime selle järgmises etapis. Peaaegu kogu seadistamine seisneb Windowsi Linuxi alamsüsteemi ja Virtuaalmasinate platvormi täiendavate komponentide lubamises ning seejärel arvuti seadete muutuste rakendamiseks taaskäivitamises:.

Tõenäoliselt kohtub te sellega, et pole alati selge, kuidas määrata varukoopi ja kuidas ühendada varukoopia mahuti Operator UI-ga. Dokumentatsioon käsitleb seda pinnapealselt, reaalsed kirjeldused on PR:

1. saladus tuleb teha;
2. edastada see operaatorile parameetri kaudu pod_environment_secret_name CRD-s operaatori seadistustega või ConfigMapis (olenevalt sellest, kuidas otsustasite operaatorit installida).

Kuid, nagu osutus, on see praegusel hetkel võimatu. Seetõttu oleme kokku pannud oma versiooni operaatorist mõnede lisanduvate väliste rakendustega. Rohkem teavet selle kohta - vt allpool.

Kui edastada operaatorile varukoopia parameetreid, nimelt - wal_s3_bucket ja AWS S3 ligipääsuvõtmed, siis hakkab see varundama kõike: mitte ainult produktsioonis olevaid andmebaase, vaid ka stagingut. See ei sobinud meie jaoks.

Spilo parameetrite kirjeldamisel, mis on baasne Docker-i ümbrus PgSQL kasutamisel operaatori kaudu, selgus, et saab edastada parameetri WAL_S3_BUCKET tühjaks, seega saab varukoopiad välja lülitada. Veelgi enam, suureks rõõmuks leidsime ka valmis PR-i, mille me kohe oma forki lisasime. Nüüd on piisav lihtsalt lisada enableWALArchiving: false PostgreSQL klastri ressursile.

Jah, oli võimalus teha teisiti, käivitades 2 operaatorit: üks stagingu jaoks (ilma varukoopiateta) ja teine - produktsiooni jaoks. Kuid nii suudame hakkama saada ühega.

Olgu, me õppisime andmebaasidesse S3 ligipääsu edastama ja varukoopiad hakkasid salvestama. Kuidas saada töötama varukoopia lehed Operator UI-s?

Operator UI-s tuleb lisada 3 muutujat:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Pärast seda muutuvad varukoopiate haldamine võimalikuks, mis meie puhul lihtsustab tööd staginguga, võimaldades edastada sealt tootmiselt lõike ilma täiendavate skriptideta.

Veel ühe plussina nimetati Teams API-d ja laias ulatuses võimalusi andmebaaside ja rollide loomisel operaatori kaudu. Kuid loodud rollidel ei olnud vaikimisi õigusi. Vastavalt sellele ei saanud lugemisõigustega kasutaja uusi tabeleid lugeda.

Miks nii? Kuigi koodis on on vajalikud GRANT, neid ei rakendata alati. On kaks meetodit: syncPreparedDatabases ja syncDatabases. Failis syncPreparedDatabases — kuigi jaotises preparedDatabases on on tingimus defaultRoles ja defaultUsers rollide loomiseks, — vaikimisi õigusi ei rakendata. Meie töötame praegu plaastri kallal, et need õigused automaatselt rakenduks.

Ja viimane punkt meie jaoks olulistes täiustustes — patš, mis lisab Node Affinity loodavasse StatefulSet'i. Meie kliendid eelistavad sageli kulusid vähendada, kasutades spot-instanse, ja neid ei tohiks kindlasti kasutada andmebaasiteenuste jaoks. Selle küsimuse saaks lahendada ka toleratsioonide abil, kuid Node Affinity olemasolu annab suurema kindluse.

Mis saime?

Nende probleemide lahendamise tulemusena harisime Zalando Postgres Operator'i oma enda hoidlate, kus see kogutakse nende kasulike plaastritega. Ja mugavuse huvides kogusime ka Docker-ima.

PR nimekiri, mis on forkis vastu võetud:

• turvalise kergema pildi koostamine operaatori jaoks;
• varukoopiate deaktiveerimine;
• ressursside versioonide värskendamine aktiveeritud k8s versioonide jaoks;
• Node Affinity rakendamine.

Oleks suurepärane, kui kogukond toetaks neid PR-e, et need jõuaksid järgmise operaatori versiooniga (1.6) upstream'i.

Boonus! Edukuse lugu produktsiooni migratsioonist

Kui kasutate Patronit, saate operaatorile migreerida elava produktsiooni minimaalsete seiskumistega.

Spilo võimaldab luua standby-kliustreid S3-hoidlate kaudu Wal-E, kui binaarne logi PgSQL salvestatakse esmalt S3-s, seejärel kopeeritakse replikaga. Aga mis teha, kui te ei kasutate Wal-E vanas infrastruktuuris? Selle probleemi lahendus on juba ettepanekud Habr's.

Abiks on PostgreSQL-i loogiline replikatsioon. Kuid ärme lasku detailidesse, kuidas luua publikatsioone ja tellimusi, sest… meie plaan ebaõnnestus.

Asjaolu on see, et andmebaasis oli mitu koormatud tabelit miljonite ridadega, mis pidevalt täiendati ja kustutati. Lihtne tellimine jot copy_data, kui uus replik kopeerib kogu sisu meistrilt, ei jõudnud lihtsalt meistrist mööda. Sisu kopeerimine töötas nädal aega, kuid ei jõudnud meistrile järgi. Lõppkokkuvõttes aitas probleemi lahendada artikkel kolleeg Avitost: andmeid saab üle kanda, kasutades pg_dump. Kirjeldan meie (veidi täiustatud) varianti sellest algoritmist.

Idee on, et saab luua välja lülitatud tellimuse, mis on seotud konkreetse replikeerimise slotiga ja seejärel parandada tehingu numbri. Kasutusel olid replikad tootmise jaoks. See on oluline, kuna replikad aitavad luua ühtse dump'i ja jätkata muudatuste saamist peastersest.

Edasistes märkustes, mis kirjeldavad migreerimise protsessi, kasutatakse järgmisi tähistusi hostide jaoks:

1. master — algserver;
2. replica1 — voogereplikatsioon vanal tootmisserveril;
3. replica2 — uus loogiline replikatsioon.

Migreerimise plaan

1. Loome peasterses tellimuse kõigi tabelite jaoks skeemis public andmebaasi dbname:

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

2. Loome replikeerimise slot peasterses:

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

3. Peatame replikatsiooni vanal replikal:

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

4. Saame tehingu numbri peastersest:

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

5. Teeme dump'i vanalt replikalt. Teeme seda mitmes voos, mis aitab protsessi kiirendada:

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

6. Laeme dump'i uuele serverile:

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

7. Pärast dump'i laadimist on võimalik alustada replikatsiooni voogereplika peal:

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

7. Loome tellimuse uuel loogilisel replikal:

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. Saame oid tellimuse:

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

9. Oletame, et saime oid=1000. Rakendame tehingu numbri tellimusele:

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

10. Alustame replikatsiooni:

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

11. Kontrollime tellimuse staatust, replikatsioon peab töötama:

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. Pärast seda, kui replikatsioon on käivitatud ja andmebaasid on sünkroonitud, on võimalik täita lülitust.

13. Pärast replikatsiooni peatamist tuleb parandada järjestusi. Seda on hästi kirjeldatud artiklis wiki.postgresql.org.

Selle plaani tõttu õnnestus lülitus viia läbi minimaalsete viivitustega.

Kokkuvõte

Kubernetesi operaatorid võimaldavad erinevaid toiminguid lihtsustada, vähendades need K8s-resursside loomisele. Kuid hoolimata suurepärasest automatiseerimisest, mida nende abil saavutatakse, tuleb meeles pidada, et see võib tuua kaasa ka mitmeid ootamatuid nüansse, seega valige operaatorid mõistlikult.

Uurides kolme populaarseimat Kubernetesi operaatorit PostgreSQL jaoks, valisime Zalando projekti. Selle kasutamine tõi kaasa teatud raskusi, kuid tulemus oli tõeliselt rahuldustpakkuv, nii et plaanime laiendada seda kogemust ka mõnele muule PgSQL installatsioonile. Kui teil on sarnaste lahenduste kasutamise kogemusi, ootame teid kommentaarides neid detailselt jagama!

P.S.

Lugege ka meie blogist:

• «Andmebaasid ja Kubernetes (ülevaade ja video ettekandest)»;
• «Postgres-teisipäev №5: PostgreSQL ja Kubernetes. CI/CD. Testimise automatiseerimine»;
• «Üks lugu Redis'i operaatorist K8s-is ja miniülevaade selle andmebaasi analüüsi tööriistadest».

Allikas: habr.com