Lühiülevaade Kubernetese PostgreSQL-i avaldustest, meie valikutest ja kogemustest

Üha enam saavad kliendid järgmisi taotlusi: „Tahame seda nagu Amazon RDS-i, kuid odavamalt“; "Me tahame seda nagu RDS-i, kuid kõikjal, mis tahes infrastruktuuris." Sellise hallatava lahenduse juurutamiseks Kuberneteses vaatasime üle PostgreSQL-i populaarseimate operaatorite hetkeseisu (Stolon, operaatorid ettevõtetest Crunchy Data ja Zalando) ja tegime oma valiku.

See artikkel on kogemus, mille oleme saanud nii teoreetilisest (lahenduste ülevaade) kui ka praktilisest küljest (mis valiti ja mis sellest välja tuli). Kuid kõigepealt teeme kindlaks, millised on üldised nõuded RDS-i võimalikule asendamisele...

Mis on RDS

Kui inimesed räägivad RDS-ist, siis meie kogemuse kohaselt peavad nad silmas hallatavat DBMS-i teenust, mis:

1. lihtne konfigureerida;
2. on võimeline hetktõmmistega töötama ja neist taastuma (eelistatavalt toega PITR);
3. võimaldab luua ülem-alluv topoloogiaid;
4. omab rikkalikku laienduste loendit;
5. pakub auditeerimist ja kasutajate/juurdepääsu haldust.

Üldiselt võib käsiloleva ülesande elluviimise lähenemisviisid olla väga erinevad, kuid tingimusliku Ansible'i tee pole meile lähedal. (Selle tulemusel jõudsid kolleegid 2GIS-ist sarnasele järeldusele tema katse luua "tööriist Postgresi-põhise tõrkesiirdeklastri kiireks juurutamiseks.")

Operaatorid on Kubernetese ökosüsteemis sarnaste probleemide lahendamiseks levinud lähenemisviis. “Flanta” tehniline direktor on neist juba lähemalt rääkinud seoses Kubernetese sees käivitatud andmebaasidega. distoolSisse üks tema aruannetest.

NB: Lihtsate operaatorite kiireks loomiseks soovitame pöörata tähelepanu meie avatud lähtekoodiga utiliidile kesta operaator. Seda kasutades saate seda teha ilma Go-st teadmata, kuid süsteemiadministraatoritele tuttavamal viisil: Bashis, Pythonis jne.

PostgreSQL-i jaoks on mitu populaarset K8s-i operaatorit:

• Stolon;
• Crunchy Data PostgreSQL-i operaator;
• Zalando Postgresi operaator.

Vaatame neid lähemalt.

Operaatori valik

Lisaks ülalmainitud olulistele funktsioonidele ootasime meie kui Kubernetese infrastruktuuri käitamise insenerid operaatoritelt ka järgmist:

• juurutamine Gitist ja koos Kohandatud ressursid;
• pod afiinsusvastane tugi;
• sõlme afiinsuse või sõlme valija installimine;
• tolerantside paigaldamine;
• häälestusvõimaluste olemasolu;
• arusaadavad tehnoloogiad ja isegi käsud.

Ilma iga punkti üksikasjadesse laskumata (küsige kommentaarides, kas teil on pärast kogu artikli lugemist nende kohta veel küsimusi), märgin üldiselt, et need parameetrid on vajalikud klastri sõlmede spetsialiseerumise täpsemaks kirjeldamiseks, et tellige need konkreetsete rakenduste jaoks. Nii saavutame jõudluse ja kulude osas optimaalse tasakaalu.

Liigume nüüd edasi PostgreSQL-i operaatorite endi juurde.

1. Stolon

Stolon Itaalia firmalt Sorint.lab in juba mainitud aruanne peeti DBMS-i operaatorite seas omamoodi standardiks. See on üsna vana projekt: selle esimene avalik väljalase toimus 2015. aasta novembris (!) ning GitHubi hoidlal on peaaegu 3000 tärni ja 40+ kaastöötajat.

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

Selle operaatori seadme leiate üksikasjalikult aruandest või projekti dokumentatsioon. Üldiselt piisab, kui öelda, et see suudab teha kõike, mida kirjeldatakse: tõrkevahetus, puhverserverid läbipaistvaks kliendijuurdepääsuks, varukoopiad... Lisaks pakuvad puhverserverid juurdepääsu ühe lõpp-punkti teenuse kaudu – erinevalt kahest teisest allpool käsitletavast lahendusest (mõlemal on kaks teenust juurdepääsu baasile).

Küll aga Stolon pole kohandatud ressursse, mistõttu ei saa seda juurutada nii, et Kubernetesis DBMS-i eksemplare oleks lihtne ja kiire – “nagu kuumad saiad”. Juhtimine toimub utiliidi kaudu stolonctl, juurutamine toimub Helm diagrammi kaudu ning kohandatud on määratletud ja täpsustatud ConfigMapis.

Ühest küljest selgub, et operaator polegi tegelikult operaator (ei kasuta ju CRD-d). Kuid teisest küljest on see paindlik süsteem, mis võimaldab konfigureerida K8s ressursse oma äranägemise järgi.

Kokkuvõtteks võib öelda, et meile isiklikult ei tundunud iga andmebaasi jaoks eraldi diagrammi koostamine optimaalne. Seetõttu hakkasime otsima alternatiive.

2. Crunchy Data PostgreSQL-i operaator

Operaator firmast Crunchy Data, noor Ameerika idufirma, tundus loogiline alternatiiv. Selle avalik ajalugu algab esimese väljalaskega 2017. aasta märtsis, sellest ajast alates on GitHubi hoidla saanud veidi alla 1300 tärni ja 50+ kaastöötajat. Septembri viimast väljalaset testiti, et see toimiks versioonidega Kubernetes 1.15–1.18, OpenShift 3.11+ ja 4.4+, GKE ja VMware Enterprise PKS 1.3+.

Crunchy Data PostgreSQL Operatori arhitektuur vastab ka järgmistele nõuetele:

Juhtimine toimub utiliidi kaudu pgo, aga see omakorda genereerib Kubernetese jaoks kohandatud ressursse. Seetõttu rõõmustas operaator meid kui potentsiaalseid kasutajaid:

• on kontroll CRD kaudu;
• mugav kasutajahaldus (ka CRD kaudu);
• integreerimine teiste komponentidega Crunchy Data Container Suite — PostgreSQL-i konteinerpiltide ja sellega töötamiseks mõeldud utiliitide spetsiaalne kogu (sh pgBackRest, pgAudit, kaastöö laiendused jne).

Katsed Crunchy Data operaatorit kasutama hakata paljastasid aga mitmeid probleeme:

• Tolerantide võimalust ei olnud - pakutakse ainult nodeSelector.
• Loodud kaustad olid juurutamise osa, hoolimata asjaolust, et juurutasime olekupõhise rakenduse. Erinevalt StatefulSetsist ei saa juurutused kettaid luua.

Viimane puudus toob kaasa naljakaid hetki: testkeskkonnas õnnestus ühe kettaga käivitada 3 koopiat kohalik ladustamine, mille tõttu operaator teatas, et 3 koopiat töötasid (kuigi mitte).

Selle operaatori teine ​​omadus on selle valmis integreerimine erinevate tugisüsteemidega. Näiteks on lihtne installida pgAdmin ja pgBounce ning sisse dokumentatsioon eelkonfigureeritud Grafana ja Prometheus. Viimastel väljalase 4.5.0-beeta1 Eraldi märgitakse ära parem integratsioon projektiga pgMonitor, tänu millele pakub operaator PgSQL-i mõõdikute selget visualiseerimist.

Kubernetese loodud ressursside kummaline valik viis meid aga vajaduseni leida teistsugune lahendus.

3. Zalando Postgresi operaator

Teame Zalando tooteid juba ammu: omame Zaleniumi kasutamise kogemust ja loomulikult proovisime Patroni on nende populaarne HA-lahendus PostgreSQL-i jaoks. Ettevõtte lähenemisest loomisele Postgresi operaator ütles üks selle autoreid Aleksei Kljukin eetris Postgres-Teispäev nr 5, ja meile meeldis.

See on artiklis käsitletud lahendus noorim: esimene väljalase toimus 2018. aasta augustis. Kuid isegi vaatamata ametlike väljaannete väikesele arvule on projekt jõudnud kaugele, ületades populaarsuselt juba Crunchy Data lahendust, millel on GitHubis 1300+ tärni ja maksimaalne kaastööliste arv (70+).

"Kaoti all" kasutab see operaator ajaproovitud lahendusi:

• Patroni ja Spilo Sõitmiseks,
• WAL-E - varukoopiate jaoks,
• PgBouncer - ühendusbasseinina.

Zalando operaatoriarhitektuuri esitletakse järgmiselt:

Operaatorit hallatakse täielikult kohandatud ressursside kaudu, ta loob konteineritest automaatselt StatefulSet'i, mida saab seejärel kohandada, lisades kasti erinevaid külgkorve. See kõik on märkimisväärne eelis võrreldes Crunchy Data operaatoriga.

Kuna valisime Zalando lahenduse kolme kaalutletava variandi hulgast, esitatakse allpool selle võimaluste täiendav kirjeldus koos rakenduse praktikaga.

Harjutage Zalando Postgresi operaatoriga

Operaatori juurutamine on väga lihtne: lihtsalt laadige GitHubist alla praegune versioon ja rakendage YAML-failid kataloogist manifestid. Teise võimalusena võite kasutada ka operaatorikeskus.

Pärast installimist peaksite muretsema seadistamise pärast logide ja varukoopiate salvestusruum. Seda tehakse ConfigMapi kaudu postgres-operator nimeruumis, kuhu operaatori installisite. Kui hoidlad on konfigureeritud, saate juurutada oma esimese PostgreSQL-i klastri.

Näiteks meie standardne juurutus näeb välja selline:

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 kolmest eksemplarist koosneva klastri, mille vormil on külgkorv postgres_exporter, millest võtame rakendusmõõdikud. Nagu näete, on kõik väga lihtne ja soovi korral saate luua sõna otseses mõttes piiramatu arvu klastreid.

Tasub tähelepanu pöörata veebihalduspaneel - postgres-operator-ui. See on operaatoriga kaasas ja võimaldab teil luua ja kustutada klastreid, samuti töötada operaatori tehtud varukoopiatega.

PostgreSQL-i klastrite loend

Varundushaldus

Veel üks huvitav funktsioon on tugi Teamsi API. See mehhanism loob automaatselt rollid PostgreSQL-is, mis põhineb saadud kasutajanimede loendil. Seejärel võimaldab API teil tagastada kasutajate loendi, kellele rollid luuakse automaatselt.

Probleemid ja lahendused

Operaatori kasutamisel ilmnes aga peagi mitmeid olulisi puudusi:

1. nodeSelectori toe puudumine;
2. võimetus varukoopiaid keelata;
3. andmebaasi loomise funktsiooni kasutamisel vaikeõigusi ei kuvata;
4. Mõnikord on dokumentatsioon puudu või aegunud.

Õnneks saab paljusid neist lahendada. Alustame lõpust – probleemid dokumentatsioon.

Tõenäoliselt puutute kokku tõsiasjaga, et alati pole selge, kuidas varukoopiat registreerida ja kuidas varukoopiat operaatori kasutajaliidesega ühendada. Dokumentatsioonis räägitakse sellest möödaminnes, kuid tegelik kirjeldus on sees PR:

1. vajadus teha saladust;
2. edastada see operaatorile parameetrina pod_environment_secret_name operaatori sätetega CRD-s või ConfigMapis (olenevalt sellest, kuidas otsustate operaatori installida).

Kuid nagu selgub, on see praegu võimatu. Sellepärast kogusimegi teie operaatori versioon mõne täiendava kolmanda osapoole arendusega. Selle kohta lisateabe saamiseks vaadake allpool.

Kui edastate operaatorile varundamise parameetrid, nimelt - wal_s3_bucket ja juurdepääsuvõtmed AWS S3-s, seejärel see varundab kõik: mitte ainult tootmise alused, vaid ka lavastus. See meile ei sobinud.

Spilo, mis on operaatori kasutamisel PgSQL-i jaoks põhiline Dockeri ümbris, parameetrite kirjelduses selgus: saate parameetri edastada WAL_S3_BUCKET tühjaks, keelates seeläbi varukoopiad. Pealegi leidsin suureks rõõmuks valmis PR, mille võtsime kohe oma kahvlisse vastu. Nüüd peate lihtsalt lisama enableWALArchiving: false PostgreSQL-i klastri ressursile.

Jah, oli võimalus seda teha teisiti, käivitades 2 operaatorit: üks lavastuseks (ilma varukoopiateta) ja teine ​​tootmiseks. Aga ühega saime hakkama.

Ok, õppisime, kuidas S3 jaoks juurdepääsu andmebaasidele üle anda ja varukoopiad hakkasid salvestusruumi saama. Kuidas panna varulehed operaatoriliideses tööle?

Peate operaatori kasutajaliidesele lisama 3 muutujat:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Pärast seda muutub kättesaadavaks varukoopiate haldamine, mis meie puhul lihtsustab tööd lavastusega, võimaldades meil ilma täiendavate skriptideta sinna tootmisest viilud kohale toimetada.

Teine eelis oli töö Teams API-ga ning rohked võimalused andmebaaside ja rollide loomiseks operaatoritööriistade abil. Siiski loodud rollidel ei olnud vaikimisi õigusi. Seetõttu ei saanud lugemisõigustega kasutaja uusi tabeleid lugeda.

Miks nii? Vaatamata sellele, et koodis on vajalik GRANT, neid ei kasutata alati. On 2 meetodit: syncPreparedDatabases и syncDatabases. Sisse syncPreparedDatabases - hoolimata sellest, et jaos preparedDatabases on on tingimus defaultRoles и defaultUsers rollide loomiseks vaikeõigusi ei rakendata. Valmistame ette plaastrit, et need õigused rakenduksid automaatselt.

Ja viimane punkt meie jaoks olulistes täiustustes - plaaster, mis lisab loodud StatefulSetile Node Affinity. Meie kliendid eelistavad sageli kulusid vähendada kohapealsete eksemplaride abil ja nad ei tasu ilmselt andmebaasiteenuseid majutada. Selle probleemi saab lahendada taluvuste abil, kuid Node Affinity olemasolu annab suurema kindlustunde.

Mis juhtus

Ülaltoodud probleemide lahendamise tulemuste põhjal ühendasime Zalandost Postgres Operatori teie hoidla, kus seda selliste kasulike plaastritega kogutakse. Ja suurema mugavuse huvides kogusime ka Dockeri pilt.

Kahvlisse vastu võetud PR-de loend:

• Dockeri operaatori jaoks turvalise kerge pildi loomine;
• varukoopiate keelamine;
• k8s praeguste versioonide ressursiversioonide värskendamine;
• Node Affinity rakendamine.

On suurepärane, kui kogukond toetab neid PR-sid, et need saaksid operaatori järgmise versiooniga (1.6) ülesvoolu.

Boonus! Tootmisrände edulugu

Kui kasutate Patroni, saab reaalajas tootmise minimaalse seisakuajaga üle viia operaatorile.

Spilo võimaldab teil luua ooterežiimi klastreid S3 salvestusruumi kaudu Wal-E, kui PgSQL-i kahendlogi salvestatakse esmalt S3-sse ja seejärel pumbatakse selle välja koopia abil. Aga mida teha, kui on ei kasutab Wal-E vanal infrastruktuuril? Selle probleemi lahendus on juba olemas seda soovitati rummu peal.

Appi tuleb PostgreSQL-i loogiline replikatsioon. Kuid me ei hakka üksikasjalikult kirjeldama, kuidas väljaandeid luua ja tellimusi luua, sest... meie plaan oli fiasko.

Fakt on see, et andmebaasis oli mitu miljonite ridadega laaditud tabelit, mida pealegi pidevalt täiendati ja kustutati. Lihtne tellimus с copy_data, kui uus koopia kopeerib kogu sisu põhiseadmest, ei suuda see lihtsalt masteriga sammu pidada. Sisu kopeerimine töötas nädala, kuid ei jõudnud meistrile järele. Lõpuks aitas see mul probleemi lahendada artikkel kolleegid Avitost: saate andmeid edastada kasutades pg_dump. Kirjeldan selle algoritmi meie (veidi muudetud) versiooni.

Idee seisneb selles, et saate teha puudega tellimuse, mis on seotud konkreetse replikatsioonipesaga, ja seejärel parandada tehingunumbrit. Tootmistöödeks olid saadaval koopiad. See on oluline, kuna koopia aitab luua järjepideva tõmmise ja saada edaspidi masterilt muudatusi.

Edasised migreerimisprotsessi kirjeldavad käsud kasutavad järgmisi hostimärke:

1. meister — lähteserver;
2. replika1 — vana toodangu koopia voogesitus;
3. replika2 - uus loogiline koopia.

Rändeplaan

1. Looge tellimus kõigi skeemi tabelite jaoks public alus dbname:

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

2. Looge juhtseadmele replikatsioonipesa.

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

3. Peatage replikatsioon vanal koopial:

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

4. Hankige tehingu number kaptenilt:

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

5. Eemaldage vanast koopiast prügimägi. Teeme seda mitmes lõimes, mis aitab protsessi kiirendada:

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

6. Laadige väljavõte uude serverisse üles:

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

7. Pärast tõmmise allalaadimist saate alustada voogesituse koopia replikatsiooni.

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

7. Loome uuele loogilisele koopiale tellimuse:

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. Lähme oid tellimused:

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

9. Oletame, et see sai kätte oid=1000. Rakendame tellimusele tehingunumbri:

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. Kontrollige tellimuse olekut, replikatsioon peaks 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 replikatsiooni käivitamist ja andmebaaside sünkroonimist saate ümber lülituda.

13. Pärast replikatsiooni keelamist peate jadasid parandama. Seda on hästi kirjeldatud artiklis saidil wiki.postgresql.org.

Tänu sellele plaanile toimus üleminek minimaalsete viivitustega.

Järeldus

Kubernetese operaatorid võimaldavad teil erinevaid toiminguid lihtsustada, taandades need K8s ressursside loomisele. Olles aga saavutanud nende abiga tähelepanuväärse automatiseerimise, tasub meeles pidada, et see võib kaasa tuua ka hulga ootamatuid nüansse, seega valige operaatorid targalt.

Arvestades kolme populaarseimat Kubernetese operaatorit PostgreSQL-i jaoks, valisime Zalando projekti. Ja me pidime sellega ületama teatud raskused, kuid tulemus oli tõesti meeldiv, seega kavatseme seda kogemust laiendada mõnele teisele PgSQL-i installile. Kui teil on kogemusi sarnaste lahenduste kasutamisel, näeme hea meelega üksikasju kommentaarides!

PS

Loe ka meie blogist:

• «Andmebaasid ja Kubernetes (ülevaade ja videoaruanne)";
• «Postgresi teisipäev nr 5: PostgreSQL ja Kubernetes. CI/CD. Testimise automatiseerimine";
• «Üks lugu Redise operaatoriga K8sis ja miniülevaade utiliitidest selle andmebaasi andmete analüüsimiseks'.

Allikas: www.habr.com