Trumpa „Kubernetes“ skirtų „PostgreSQL“ teiginių, mūsų pasirinkimų ir patirties apžvalga

Vis dažniau klientai sulaukia tokių užklausų: „Norime kaip Amazon RDS, bet pigiau“; „Mes norime to kaip RDS, bet visur, bet kokioje infrastruktūroje. Norėdami įdiegti tokį valdomą sprendimą „Kubernetes“, peržiūrėjome dabartinę populiariausių „PostgreSQL“ operatorių („Stolon“, „Crunchy Data“ ir „Zalando“ operatorių) būklę ir padarėme pasirinkimą.

Šis straipsnis – tai patirtis, kurią įgijome tiek iš teorinės pusės (sprendimų apžvalga), tiek iš praktinės pusės (kas buvo pasirinkta ir kas iš to išėjo). Tačiau pirmiausia išsiaiškinkime, kokie yra bendrieji reikalavimai galimam RDS pakeitimui...

Kas yra RDS

Kai žmonės kalba apie RDS, mūsų patirtis rodo, kad jie turi galvoje valdomą DBVS paslaugą, kuri:

1. lengva konfigūruoti;
2. turi galimybę dirbti su momentinėmis nuotraukomis ir atsigauti po jų (geriausia su palaikymu PITR);
3. leidžia kurti pagrindines ir pavaldines topologijas;
4. turi gausų plėtinių sąrašą;
5. teikia auditą ir vartotojų/prieigos valdymą.

Paprastai tariant, požiūriai į užduoties įgyvendinimą gali būti labai skirtingi, tačiau kelias su sąlyginiu Ansible mums nėra artimas. (Kolegos iš 2GIS padarė panašią išvadą jo bandymas sukurti „įrankį, leidžiantį greitai įdiegti „Postgres“ pagrindu veikiančią klasterį.)

Operatoriai yra įprastas būdas išspręsti panašias Kubernetes ekosistemos problemas. Plačiau apie jas „Flantos“ techninis direktorius kalbėjo apie Kubernetes viduje paleistas duomenų bazes. distolĮ vienas iš jo pranešimų.

NB: Norėdami greitai sukurti paprastus operatorius, rekomenduojame atkreipti dėmesį į mūsų atvirojo kodo įrankį apvalkalo operatorius. Naudodami jį galite tai padaryti be žinios apie Go, bet sistemos administratoriams labiau pažįstamais būdais: Bash, Python ir kt.

Yra keletas populiarių „PostgreSQL“ K8s operatorių:

• Stolonas;
• Crunchy Data PostgreSQL operatorius;
• Zalando Postgres operatorius.

Pažvelkime į juos atidžiau.

Operatoriaus pasirinkimas

Be jau minėtų svarbių savybių, mes, kaip Kubernetes infrastruktūros operacijų inžinieriai, iš operatorių tikėjomės ir šių dalykų:

• diegimas iš Git ir su Individualūs ištekliai;
• ankšties anti-afiniteto palaikymas;
• mazgo giminingumo arba mazgo parinkiklio diegimas;
• leistinų nuokrypių įrengimas;
• derinimo galimybių prieinamumas;
• suprantamos technologijos ir net komandos.

Nesigilindamas į kiekvieną iš punktų (klauskite komentaruose, ar perskaičius visą straipsnį vis dar turite klausimų apie juos), pažymėsiu, kad šie parametrai reikalingi norint tiksliau apibūdinti klasterio mazgų specializaciją, kad užsisakyti juos konkrečioms programoms. Taip galime pasiekti optimalų našumo ir sąnaudų balansą.

Dabar pereikime prie pačių PostgreSQL operatorių.

1. Stolonas

Stolonas iš Italijos įmonės Sorint.lab in jau minėta ataskaita buvo laikomas savotišku DBVS operatorių standartu. Tai gana senas projektas: pirmasis jo viešas leidimas įvyko dar 2015 m. lapkritį (!), o „GitHub“ saugykla gali pasigirti beveik 3000 žvaigždžių ir daugiau nei 40 bendradarbių.

Iš tiesų, Stolonas yra puikus apgalvotos architektūros pavyzdys:

Šio operatoriaus įrenginį išsamiai galite rasti ataskaitoje arba projekto dokumentacija. Apskritai, pakanka pasakyti, kad jis gali atlikti viską, kas aprašyta: perjungimas, tarpiniai serveriai skaidriai prieigai prie kliento, atsarginės kopijos... Be to, tarpiniai serveriai suteikia prieigą per vieną galinio taško paslaugą – skirtingai nei kiti du toliau aptariami sprendimai (kiekvienas iš jų turi dvi paslaugas, skirtas patekti į bazę).

Tačiau Stolonas nėra tinkintų išteklių, todėl jo negalima įdiegti taip, kad būtų lengva ir greita – „kaip karštas pyragas“ – sukurti DBVS egzempliorius „Kubernetes“. Valdymas vykdomas per komunalinę paslaugą stolonctl, diegimas atliekamas naudojant vairo diagramą, o pasirinktiniai yra apibrėžti ir nurodyti ConfigMap.

Viena vertus, paaiškėja, kad operatorius tikrai nėra operatorius (juk nenaudoja CRD). Tačiau, kita vertus, tai lanksti sistema, leidžianti konfigūruoti K8s išteklius taip, kaip jums atrodo tinkama.

Apibendrinant, mums asmeniškai neatrodė optimalu kiekvienai duomenų bazei sukurti atskirą diagramą. Todėl pradėjome ieškoti alternatyvų.

2. Traškūs duomenys PostgreSQL operatorius

Operatorius iš Crunchy Data, jaunas Amerikos startuolis, atrodė kaip logiška alternatyva. Jo viešoji istorija prasideda nuo pirmojo išleidimo 2017 m. kovo mėn., nuo tada „GitHub“ saugykla sulaukė mažiau nei 1300 50 žvaigždučių ir daugiau nei 1.15 bendradarbių. Naujausias rugsėjo leidimas buvo išbandytas dirbti su Kubernetes 1.18–3.11, OpenShift 4.4+ ir 1.3+, GKE ir VMware Enterprise PKS XNUMX+.

„Crunchy Data PostgreSQL Operator“ architektūra taip pat atitinka nurodytus reikalavimus:

Valdymas vyksta per komunalines paslaugas pgo, tačiau jis savo ruožtu generuoja tinkintus „Kubernetes“ išteklius. Todėl operatorius mus, kaip potencialius vartotojus, nudžiugino:

• yra valdymas per CRD;
• patogus vartotojų valdymas (taip pat ir per CRD);
• integracija su kitais komponentais Crunchy Data Container Suite — specializuotas „PostgreSQL“ konteinerio vaizdų rinkinys ir darbui su juo skirtos paslaugos (įskaitant „pgBackRest“, „pgAudit“, „contrib“ plėtinius ir kt.).

Tačiau bandymai pradėti naudoti operatorių iš „Crunchy Data“ atskleidė keletą problemų:

• Tolerancijos galimybės nebuvo – numatytas tik nodeSelector.
• Sukurti blokai buvo diegimo dalis, nepaisant to, kad įdiegėme būseną atitinkančią programą. Skirtingai nuo „StatefulSets“, „Deployments“ negali sukurti diskų.

Paskutinis trūkumas sukelia juokingų akimirkų: bandomojoje aplinkoje mums pavyko paleisti 3 kopijas su vienu disku vietinė parduotuvė, todėl operatorius pranešė, kad veikia 3 kopijos (nors jos ir ne).

Kitas šio operatoriaus bruožas yra jo paruoštas integravimas su įvairiomis pagalbinėmis sistemomis. Pavyzdžiui, lengva įdiegti pgAdmin ir pgBounce ir in dokumentacija svarstomi iš anksto sukonfigūruoti Grafana ir Prometėjas. Neseniai 4.5.0-beta1 leidimas Atskirai pažymima patobulinta integracija su projektu pgMonitor, kurio dėka operatorius siūlo aiškią PgSQL metrikos vizualizaciją.

Tačiau keistas Kubernetes generuojamų išteklių pasirinkimas paskatino mus rasti kitokį sprendimą.

3. Zalando Postgres operatorius

Zalando gaminius žinome jau seniai: turime patirties naudojant Zalenium ir, žinoma, išbandėme Patroni yra jų populiarus HA sprendimas, skirtas PostgreSQL. Apie įmonės požiūrį į kūrybą Postgres operatorius eteryje sakė vienas iš jos autorių Aleksejus Kliukinas Postgres-antradienis Nr. 5, ir mums patiko.

Tai yra jauniausias straipsnyje aptartas sprendimas: pirmasis leidimas įvyko 2018 m. rugpjūčio mėn. Tačiau net nepaisant nedidelio oficialių leidimų skaičiaus, projektas nuėjo ilgą kelią, populiarumu jau pralenkdamas „Crunchy Data“ sprendimą su 1300+ žvaigždučių GitHub tinkle ir didžiausiu bendraautorių skaičiumi (70+).

„Po gaubtu“ šis operatorius naudoja laiko patikrintus sprendimus:

• Patroni ir Spilo Už vairavimą,
• WAL-E - atsarginėms kopijoms,
• PgBouncer - kaip jungties baseinas.

Štai kaip pristatoma Zalando operatoriaus architektūra:

Operatorius yra visiškai valdomas per tinkintus išteklius, automatiškai sukuria „StatefulSet“ iš konteinerių, kuriuos vėliau galima pritaikyti pridedant įvairias šonines priekabas. Visa tai yra didelis pranašumas, palyginti su operatoriumi iš Crunchy Data.

Kadangi Zalando sprendimą pasirinkome iš 3 svarstomų variantų, toliau bus pateiktas tolesnis jo galimybių aprašymas kartu su taikymo praktika.

Praktikuokite su Postgres operatoriumi iš Zalando

Operatoriaus diegimas yra labai paprastas: tiesiog atsisiųskite dabartinę versiją iš GitHub ir pritaikykite YAML failus iš katalogo manifestai. Arba taip pat galite naudoti „OperatorHub“.

Įdiegę turėtumėte nerimauti dėl nustatymo žurnalų ir atsarginių kopijų saugykla. Tai atliekama naudojant ConfigMap postgres-operator vardų srityje, kurioje įdiegėte operatorių. Kai saugyklos bus sukonfigūruotos, galite įdiegti savo pirmąjį PostgreSQL klasterį.

Pavyzdžiui, mūsų standartinis diegimas atrodo taip:

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

Šiame apraše pateikiama 3 egzempliorių grupė su šonine priekaba formoje postgres_exporter, iš kurios paimame taikymo metriką. Kaip matote, viskas yra labai paprasta ir, jei norite, galite sukurti tiesiog neribotą skaičių grupių.

Verta atkreipti dėmesį žiniatinklio administravimo skydelis - postgres-operator-ui. Jis pateikiamas kartu su operatoriumi ir leidžia kurti bei ištrinti grupes, taip pat dirbti su operatoriaus sukurtomis atsarginėmis kopijomis.

PostgreSQL klasterių sąrašas

Atsarginių kopijų valdymas

Kita įdomi funkcija yra palaikymas Teams API. Šis mechanizmas automatiškai sukuria vaidmenys PostgreSQL, remiantis gautu naudotojų vardų sąrašu. Tada API leidžia grąžinti vartotojų, kuriems automatiškai sukuriami vaidmenys, sąrašą.

Problemos ir sprendimai

Tačiau operatoriaus naudojimas netrukus atskleidė keletą reikšmingų trūkumų:

1. nodeSelector palaikymo trūkumas;
2. nesugebėjimas išjungti atsarginių kopijų;
3. naudojant duomenų bazės kūrimo funkciją, numatytosios privilegijos neatsiranda;
4. Periodiškai trūksta dokumentų arba jie pasenę.

Laimei, daugelį jų galima išspręsti. Pradėkime nuo pabaigos – problemos su dokumentacija.

Greičiausiai susidursite su tuo, kad ne visada aišku, kaip užregistruoti atsarginę kopiją ir kaip prijungti atsarginę kopiją prie operatoriaus vartotojo sąsajos. Dokumentuose apie tai kalbama prabėgomis, tačiau tikras aprašymas yra PR:

1. reikia padaryti paslaptį;
2. perduoti jį operatoriui kaip parametrą pod_environment_secret_name CRD su operatoriaus nustatymais arba ConfigMap (priklausomai nuo to, kaip nuspręsite įdiegti operatorių).

Tačiau, kaip paaiškėjo, šiuo metu tai neįmanoma. Todėl ir rinkome jūsų operatoriaus versija su kai kuriais papildomais trečiųjų šalių patobulinimais. Daugiau informacijos apie tai rasite žemiau.

Jei operatoriui perduodate atsarginės kopijos parametrus, būtent - wal_s3_bucket ir prieigos raktus AWS S3, tada jį padarys viską atsarginę kopiją: ne tik bazės gamyboje, bet ir pastatymas. Tai mums netiko.

„Spilo“, kuris yra pagrindinis „Docker“ įvyniotuvas, skirtas PgSQL, kai naudojamas operatorius, parametrų aprašyme paaiškėjo: galite perduoti parametrą WAL_S3_BUCKET tuščias, taip išjungiant atsargines kopijas. Be to, dideliam džiaugsmui radau paruoštas PR, kurį iškart priėmėme į savo šakutę. Dabar tereikia pridėti enableWALArchiving: false į PostgreSQL klasterio išteklius.

Taip, atsirado galimybė tai padaryti kitaip, paleidžiant 2 operatorius: vieną – inscenizacijai (be atsarginių kopijų), o antrą – gamybai. Bet su vienu galėjome išsiversti.

Gerai, išmokome perkelti prieigą prie S3 duomenų bazių ir atsarginės kopijos pradėjo patekti į saugyklą. Kaip padaryti, kad atsarginės kopijos veiktų operatoriaus vartotojo sąsajoje?

Prie operatoriaus vartotojo sąsajos turėsite pridėti 3 kintamuosius:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Po to atsiras atsarginių kopijų valdymas, o tai mūsų atveju supaprastins darbą su inscenizacija, leisdami ten pristatyti produkcijos dalis be papildomų scenarijų.

Kitas privalumas buvo darbas su Teams API ir didelės galimybės kurti duomenų bazes ir vaidmenis naudojant operatoriaus įrankius. Tačiau sukurta pagal nutylėjimą vaidmenys neturėjo jokių teisių. Atitinkamai vartotojas, turintis skaitymo teises, negalėjo skaityti naujų lentelių.

Kodėl taip? Nepaisant to, kad kode yra būtina GRANT, jie ne visada naudojami. Yra 2 būdai: syncPreparedDatabases и syncDatabases. Į syncPreparedDatabases - nepaisant to, kad skyriuje preparedDatabases yra yra sąlyga defaultRoles и defaultUsers norint sukurti vaidmenis, numatytosios teisės netaikomos. Šiuo metu ruošiame pataisą, kad šios teisės būtų taikomos automatiškai.

Ir paskutinis taškas mums aktualiuose patobulinimuose - pleistras, kuris prideda Mazgo giminingumą prie sukurto StatefulSet. Mūsų klientai dažnai renkasi mažinti sąnaudas naudodamiesi taškiniais egzemplioriais ir jiems akivaizdžiai neverta talpinti duomenų bazių paslaugų. Šią problemą galima išspręsti taikant tolerancijas, tačiau „Node Affinity“ buvimas suteikia daugiau pasitikėjimo.

Kas atsitiko?

Remdamiesi aukščiau pateiktų problemų sprendimo rezultatais, „Postgres Operator“ iš Zalando įjungėme į jūsų saugykla, kur surenkama tokiais naudingais lopais. O kad būtų patogiau, taip pat surinkome Docker vaizdas.

Priimtų PR sąrašas:

• sukurti saugų lengvą vaizdą Docker operatoriui;
• atsarginių kopijų išjungimas;
• išteklių versijų atnaujinimas dabartinėms k8s versijoms;
• Node Affinity įgyvendinimas.

Būtų puiku, jei bendruomenė palaikytų šiuos PR, kad jie būtų pasiekiami naudojant kitą operatoriaus versiją (1.6).

Premija! Gamybos migracijos sėkmės istorija

Jei naudojate Patroni, tiesioginė gamyba gali būti perkelta į operatorių su minimaliomis prastovomis.

„Spilo“ leidžia sukurti parengties režimo grupes per S3 saugyklą su Wal-E, kai PgSQL dvejetainis žurnalas pirmiausia išsaugomas S3, o po to išpumpuojamas replikos. Bet ką daryti, jei turite ne naudoja Wal-E senoje infrastruktūroje? Šios problemos sprendimas jau yra buvo pasiūlyta ant stebulės.

PostgreSQL loginė replikacija ateina į pagalbą. Tačiau mes nesigilinsime į tai, kaip kurti leidinius ir prenumeratas, nes... mūsų planas buvo fiasko.

Faktas yra tas, kad duomenų bazėje buvo kelios įkeltos lentelės su milijonais eilučių, kurios, be to, buvo nuolat pildomos ir ištrinamos. Paprasta prenumerata с copy_data, kai naujoji kopija nukopijuoja visą turinį iš pagrindinio kompiuterio, ji tiesiog negali neatsilikti nuo pagrindinio. Turinio kopijavimas veikė savaitę, bet niekada nepasivijo meistro. Galų gale tai padėjo man išspręsti problemą straipsnis kolegos iš Avito: galite perkelti duomenis naudodami pg_dump. Aprašysiu mūsų (šiek tiek pakeistą) šio algoritmo versiją.

Idėja yra ta, kad galite sudaryti išjungtą prenumeratą, susietą su konkrečia replikacijos vieta, ir ištaisyti operacijos numerį. Gamybos darbams buvo prieinamos kopijos. Tai svarbu, nes kopija padės sukurti nuoseklų iškeltą ir toliau gauti pakeitimus iš pagrindinio kompiuterio.

Vėlesnėse komandose, apibūdinančiose perkėlimo procesą, bus naudojami šie pagrindinio kompiuterio žymėjimai:

1. meistras — šaltinio serveris;
2. replika1 — senos produkcijos kopijos transliacija;
3. replika2 - nauja loginė kopija.

Migracijos planas

1. Sukurkite visų schemos lentelių prenumeratą pagrindiniame kompiuteryje public bazė dbname:

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

2. Sukurkite replikacijos lizdą pagrindiniame kompiuteryje:

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

3. Sustabdykite replikaciją senoje kopijoje:

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

4. Gaukite operacijos numerį iš meistro:

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

5. Pašalinkite išmetimą iš senos kopijos. Tai padarysime keliose gijose, kurios padės pagreitinti procesą:

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

6. Įkelkite išklotinę į naują serverį:

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

7. Atsisiuntę išklotinę galite pradėti replikaciją srautinio perdavimo kopijoje:

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

7. Sukurkime naujos loginės kopijos prenumeratą:

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. Paimkime oid prenumeratos:

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

9. Tarkime, buvo gauta oid=1000. Prenumeratai pritaikykime operacijos numerį:

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

10. Pradėkime replikaciją:

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

11. Patikrinkite prenumeratos būseną, replikacija turėtų veikti:

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. Pradėjus replikaciją ir sinchronizavus duomenų bazes, galite persijungti.

13. Išjungę replikaciją, turite pataisyti sekas. Tai gerai aprašyta straipsnyje wiki.postgresql.org.

Dėl šio plano perėjimas įvyko su minimaliais vėlavimais.

išvada

Kubernetes operatoriai leidžia supaprastinti įvairius veiksmus, sumažinant juos iki K8s išteklių kūrimo. Tačiau jų pagalba pasiekus nepaprastą automatizavimą, verta atminti, kad tai gali atnešti ir nemažai netikėtų niuansų, todėl operatorius rinkitės išmintingai.

Apsvarstę tris populiariausius „Kubernetes“ operatorius, skirtus „PostgreSQL“, pasirinkome Zalando projektą. Ir su juo turėjome įveikti tam tikrus sunkumus, tačiau rezultatas tikrai džiugino, todėl planuojame šią patirtį išplėsti ir kai kuriose kitose PgSQL instaliacijose. Jei turite panašių sprendimų naudojimo patirties, mielai pamatysime išsamią informaciją komentaruose!

PS

Taip pat skaitykite mūsų tinklaraštyje:

• «Duomenų bazės ir „Kubernetes“ (apžvalga ir vaizdo įrašų ataskaita)»;
• «„Postgres“ antradienis Nr. 5: „PostgreSQL“ ir „Kubernetes“. CI/CD. Testavimo automatika»;
• «Viena istorija su „Redis“ operatoriumi K8s ir nedidelė paslaugų, skirtų duomenims iš šios duomenų bazės analizuoti, apžvalga".

Šaltinis: www.habr.com