Kratek pregled izjav PostgreSQL za Kubernetes, naše izbire in izkušnje

Stranke vse pogosteje prejemajo naslednje zahteve: »Želimo kot Amazon RDS, vendar cenejši«; "Želimo ga kot RDS, vendar povsod, v kateri koli infrastrukturi." Za implementacijo takšne upravljane rešitve na Kubernetes smo si ogledali trenutno stanje najbolj priljubljenih operaterjev za PostgreSQL (Stolon, operaterji Crunchy Data in Zalando) in se odločili.

Ta članek je izkušnja, ki smo jo pridobili tako s teoretičnega vidika (pregled rešitev) kot s praktičnega vidika (kaj je bilo izbrano in kaj je iz tega). Najprej pa ugotovimo, kakšne so splošne zahteve za morebitno zamenjavo za RDS ...

Kaj je RDS

Ko ljudje govorijo o RDS, po naših izkušnjah mislijo na upravljano storitev DBMS, ki:

1. enostavno konfigurirati;
2. ima sposobnost dela s posnetki in obnavljanja po njih (po možnosti s podporo PITR);
3. omogoča ustvarjanje topologij master-slave;
4. ima bogat seznam razširitev;
5. zagotavlja nadzor in upravljanje uporabnikov/dostopov.

Na splošno so lahko pristopi k izvedbi naloge zelo različni, vendar nam pot s pogojnim Ansibleom ni blizu. (Kolegi iz 2GIS so posledično prišli do podobne ugotovitve njegov poskus ustvarite "orodje za hitro uvajanje samodejne gruče, ki temelji na Postgresu.")

Operaterji so običajen pristop za reševanje podobnih težav v ekosistemu Kubernetes. Tehnični direktor "Flanta" je o njih že podrobneje govoril v zvezi z bazami podatkov, ki so se začele znotraj Kubernetesa. distolV eno od njegovih poročil.

NB: Za hitro ustvarjanje preprostih operaterjev priporočamo, da ste pozorni na naš odprtokodni pripomoček lupina-operater. Z njegovo uporabo lahko to storite brez poznavanja Go, vendar na načine, ki so sistemskim skrbnikom bolj znani: v Bashu, Pythonu itd.

Obstaja več priljubljenih operaterjev K8s za PostgreSQL:

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

Poglejmo si jih podrobneje.

Izbira operaterja

Poleg zgoraj omenjenih pomembnih funkcij smo kot inženirji za delovanje infrastrukture Kubernetes od operaterjev pričakovali tudi naslednje:

• uvajanje iz Gita in s Viri po meri;
• podpora proti afiniteti;
• namestitev afinitete vozlišča ali izbirnika vozlišča;
• namestitev toleranc;
• razpoložljivost možnosti uglaševanja;
• razumljive tehnologije in celo ukaze.

Ne da bi se spuščal v podrobnosti o vsaki od točk (vprašajte v komentarjih, če imate po branju celotnega članka še vedno vprašanja o njih), bom na splošno opozoril, da so ti parametri potrebni za natančnejši opis specializacije vozlišč gruče, da bi jih naročite za posebne aplikacije. Tako lahko dosežemo optimalno razmerje med zmogljivostjo in stroški.

Zdaj pa preidimo na same operaterje PostgreSQL.

1. Stolon

Stolon iz italijanskega podjetja Sorint.lab v že omenjeno poročilo veljal za neke vrste standard med operaterji za DBMS. To je precej star projekt: njegova prva javna izdaja je bila novembra 2015(!), repozitorij GitHub pa se ponaša s skoraj 3000 zvezdicami in 40+ sodelavci.

Stolon je namreč odličen primer premišljene arhitekture:

Napravo tega operaterja lahko podrobno najdete v poročilu oz projektna dokumentacija. Na splošno je dovolj, da rečemo, da zmore vse opisano: samodejni preklop, proxyje za pregleden dostop odjemalcev, varnostne kopije ... Poleg tega proxyji omogočajo dostop prek ene storitve končne točke - za razliko od drugih dveh rešitev, obravnavanih spodaj (vsak ima dve storitvi za dostop do baze).

Vendar Stolon brez virov po meri, zato ga ni mogoče razmestiti tako, da bi bilo preprosto in hitro – »kot na pecivo« – ustvariti primerke DBMS v Kubernetesu. Upravljanje se izvaja prek pripomočka stolonctl, uvedba poteka prek grafikona Helm, tiste po meri pa so definirane in navedene v ConfigMap.

Po eni strani se izkaže, da operater v resnici ni operater (navsezadnje ne uporablja CRD). Toda po drugi strani je to prilagodljiv sistem, ki vam omogoča, da konfigurirate vire v K8s, kot se vam zdi primerno.

Če povzamem, se nam osebno ni zdelo optimalno ustvariti ločen grafikon za vsako bazo podatkov. Zato smo začeli iskati alternative.

2. Operater Crunchy Data PostgreSQL

Operater iz Crunchy Data, mladi ameriški startup, se je zdel logična alternativa. Njegova javna zgodovina se začne s prvo izdajo marca 2017, od takrat pa je repozitorij GitHub prejel nekaj manj kot 1300 zvezdic in 50+ sodelavcev. Najnovejša izdaja iz septembra je bila testirana za delovanje s Kubernetes 1.15–1.18, OpenShift 3.11+ in 4.4+, GKE in VMware Enterprise PKS 1.3+.

Tudi arhitektura operaterja Crunchy Data PostgreSQL izpolnjuje navedene zahteve:

Upravljanje poteka prek pripomočka pgo, pa ustvari vire po meri za Kubernetes. Zato nas je operater razveselil kot potencialne uporabnike:

• obstaja nadzor preko CRD;
• priročno upravljanje uporabnikov (tudi preko CRD);
• integracija z drugimi komponentami Crunchy Data Container Suite — specializirana zbirka slik vsebnika za PostgreSQL in pripomočki za delo z njim (vključno s pgBackRest, pgAudit, razširitvami iz contrib itd.).

Vendar so poskusi začeti uporabljati operaterja iz Crunchy Data razkrili več težav:

• Ni bilo možnosti toleranc - na voljo je samo nodeSelector.
• Ustvarjeni sklopi so bili del uvajanja, kljub dejstvu, da smo uvedli aplikacijo s stanjem. Za razliko od StatefulSets, Deployments ne more ustvariti diskov.

Zadnja pomanjkljivost vodi do smešnih trenutkov: v testnem okolju nam je uspelo zagnati 3 replike z enim diskom lokalno shranjevanje, zaradi česar je operater sporočil, da 3 replike delujejo (čeprav niso).

Druga značilnost tega operaterja je že pripravljena integracija z različnimi pomožnimi sistemi. Na primer, enostavno je namestiti pgAdmin in pgBounce ter v dokumentacijo upoštevata se prednastavljena Grafana in Prometheus. Predkratkim izdaja 4.5.0-beta1 Posebej je omenjena izboljšana integracija s projektom pgMonitor, zahvaljujoč kateremu operater ponuja jasno vizualizacijo meritev PgSQL takoj po namestitvi.

Vendar nas je čudna izbira virov, ki jih je ustvaril Kubernetes, pripeljala do potrebe po drugačni rešitvi.

3. Operater Zalando Postgres

Izdelke Zalando poznamo že dolgo: imamo izkušnje z uporabo Zaleniuma in smo seveda poskusili Patroni je njihova priljubljena rešitev HA za PostgreSQL. O pristopu podjetja k ustvarjanju Operater Postgres je v oddaji dejal eden od njegovih avtorjev Aleksej Kljukin Postgres-torek #5, in nam je bilo všeč.

To je najmlajša rešitev, obravnavana v članku: prva izdaja je bila izvedena avgusta 2018. Toda kljub majhnemu številu formalnih izdaj je projekt prišel daleč in je po priljubljenosti že presegel rešitev Crunchy Data s 1300+ zvezdicami na GitHubu in največjim številom sodelujočih (70+).

"Pod pokrovom" ta operater uporablja časovno preizkušene rešitve:

• Patroni in Spilo Za vožnjo,
• WAL-E - za varnostne kopije,
• PgBouncer - kot povezovalni bazen.

Takole je predstavljena arhitektura operaterja iz Zalanda:

Operater je v celoti upravljan prek virov po meri, samodejno ustvari StatefulSet iz vsebnikov, ki jih je nato mogoče prilagoditi z dodajanjem različnih stranskih prikolic v sklop. Vse to je pomembna prednost v primerjavi z operaterjem Crunchy Data.

Ker smo med 3 obravnavanimi možnostmi izbrali rešitev podjetja Zalando, bo v nadaljevanju predstavljen nadaljnji opis njenih zmogljivosti, takoj skupaj s prakso uporabe.

Vadite z operaterjem Postgres iz Zalanda

Namestitev operaterja je zelo preprosta: preprosto prenesite trenutno izdajo iz GitHuba in uporabite datoteke YAML iz imenika manifestira. Lahko pa uporabite tudi operatorhub.

Po namestitvi bi morali skrbeti za nastavitev shranjevanje dnevnikov in varnostnih kopij. To se naredi prek ConfigMap postgres-operator v imenskem prostoru, kjer ste namestili operater. Ko so repozitoriji konfigurirani, lahko namestite svojo prvo gručo PostgreSQL.

Na primer, naša standardna uvedba izgleda takole:

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

Ta manifest razmesti gručo 3 primerkov s stransko prikolico v obrazcu postgres_exporter, iz katerega vzamemo metriko aplikacije. Kot lahko vidite, je vse zelo preprosto in če želite, lahko ustvarite dobesedno neomejeno število grozdov.

Vredno je pozornosti spletna skrbniška plošča - postgres-operator-ui. Prihaja z operaterjem in vam omogoča ustvarjanje in brisanje gruč ter delo z varnostnimi kopijami, ki jih naredi operater.

Seznam gruč PostgreSQL

Upravljanje varnostnih kopij

Druga zanimiva lastnost je podpora API za ekipe. Ta mehanizem samodejno ustvari vloge v PostgreSQL, na podlagi dobljenega seznama uporabniških imen. API vam nato omogoča, da vrnete seznam uporabnikov, za katere so vloge samodejno ustvarjene.

Problemi in rešitve

Vendar je uporaba operaterja kmalu razkrila več pomembnih pomanjkljivosti:

1. pomanjkanje podpore za nodeSelector;
2. nezmožnost onemogočanja varnostnih kopij;
3. pri uporabi funkcije ustvarjanja baze podatkov se privzete pravice ne prikažejo;
4. Včasih dokumentacija manjka ali je zastarela.

Na srečo jih je veliko mogoče rešiti. Začnimo od konca – težave z dokumentacijo.

Najverjetneje boste naleteli na dejstvo, da ni vedno jasno, kako registrirati varnostno kopijo in kako povezati varnostno vedro z uporabniškim vmesnikom operaterja. Dokumentacija o tem govori mimogrede, pravi opis pa je v PR:

1. treba narediti skrivnost;
2. posreduje operaterju kot parameter pod_environment_secret_name v CRD z nastavitvami operaterja ali v ConfigMap (odvisno kako se odločite za namestitev operaterja).

Vendar, kot kaže, je to trenutno nemogoče. Zato smo zbrali vaša različica operaterja z nekaterimi dodatnimi razvojnimi deli tretjih oseb. Za več informacij o tem glejte spodaj.

Če operaterju posredujete parametre za varnostno kopiranje, in sicer - wal_s3_bucket in ključe za dostop v AWS S3, nato ga bo varnostno kopiral vse: ne samo podlage v produkciji, ampak tudi uprizoritev. To nam ni ustrezalo.

V opisu parametrov za Spilo, ki je osnovni ovoj Dockerja za PgSQL pri uporabi operatorja, se je izkazalo: lahko posredujete parameter WAL_S3_BUCKET prazno, s čimer onemogočite varnostno kopiranje. Poleg tega sem na veliko veselje našel pripravljen PR, ki smo ga takoj sprejeli v svoje vilice. Zdaj morate samo dodati enableWALArchiving: false v vir gruče PostgreSQL.

Da, obstajala je možnost, da to storimo drugače z vodenjem dveh operaterjev: enega za pripravo (brez varnostnih kopij) in drugega za proizvodnjo. Toda z enim smo se lahko zadovoljili.

Ok, naučili smo se, kako prenesti dostop do baz podatkov za S3 in varnostne kopije so začele prihajati v shrambo. Kako omogočiti delovanje rezervnih strani v uporabniškem vmesniku operaterja?

V uporabniški vmesnik operaterja boste morali dodati 3 spremenljivke:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Po tem bo na voljo upravljanje varnostnih kopij, kar bo v našem primeru poenostavilo delo z uprizoritvijo, kar nam bo omogočilo, da brez dodatnih skriptov dostavimo rezine iz proizvodnje.

Dodatna prednost je bilo delo z API-jem Teams in veliko možnosti za ustvarjanje baz podatkov in vlog z uporabo operaterskih orodij. Vendar ustvarjeno vloge privzeto niso imele pravic. Skladno s tem uporabnik s pravicami branja ni mogel brati novih tabel.

Zakaj? Kljub temu, da je v kodi obstaja potrebno GRANT, se ne uporabljajo vedno. Obstajata 2 načina: syncPreparedDatabases и syncDatabases. V syncPreparedDatabases – kljub temu, da v razdelku preparedDatabases obstaja obstaja pogoj defaultRoles и defaultUsers za ustvarjanje vlog se privzete pravice ne uporabljajo. Trenutno pripravljamo popravek, da se te pravice samodejno uporabijo.

In zadnja točka v izboljšavah, ki so pomembne za nas - obliž, ki ustvarjenemu StatefulSet doda afiniteto vozlišča. Naše stranke pogosto raje zmanjšajo stroške z uporabo promptnih primerkov in očitno niso vredni gostovanja storitev baze podatkov. To težavo je mogoče rešiti s tolerancami, vendar prisotnost afinitete vozlišča daje večje zaupanje.

Kaj se je zgodilo?

Na podlagi rezultatov reševanja zgornjih težav smo razcepili Postgres Operator iz Zalanda v vaše skladišče, kjer je zbrano s tako uporabnimi našitki. In za večje udobje smo tudi zbrali Dockerjeva slika.

Seznam PR-jev, sprejetih v fork:

• ustvarjanje varne lahke slike za operaterja v Dockerju;
• onemogočanje varnostnih kopij;
• posodabljanje različic virov za trenutne različice k8s;
• implementacijo Node Affinity.

Super bi bilo, če bi skupnost podprla te PR-je, tako da bodo prišli navzgor z naslednjo različico operaterja (1.6).

Bonus! Zgodba o uspehu selitve proizvodnje

Če uporabljate Patroni, lahko produkcijo v živo prenesete k operaterju z minimalnimi izpadi.

Spilo vam omogoča ustvarjanje pripravljenih gruč prek pomnilnika S3 z Wal-E, ko je binarni dnevnik PgSQL najprej shranjen v S3 in ga nato izčrpa replika. Toda kaj storiti, če imate ne uporablja Wal-E na stari infrastrukturi? Rešitev te težave je že bilo je predlagano na pestu.

Na pomoč priskoči logična replikacija PostgreSQL. Vendar se ne bomo spuščali v podrobnosti o tem, kako ustvariti publikacije in naročnine, ker ... naš načrt je bil fiasko.

Dejstvo je, da je imela zbirka podatkov več naloženih tabel z milijoni vrstic, ki so se poleg tega nenehno dopolnjevale in brisale. Enostavna naročnina с copy_data, ko nova replika kopira vso vsebino z masterja, preprosto ne more slediti masterju. Kopiranje vsebine je delovalo en teden, vendar nikoli ni dohitelo mojstra. Na koncu mi je pomagal rešiti težavo članek kolegi iz Avita: podatke lahko prenašate z uporabo pg_dump. Opisal bom našo (nekoliko spremenjeno) različico tega algoritma.

Ideja je, da lahko onemogočeno naročnino povežete z določeno režo za podvajanje in nato popravite številko transakcije. Na voljo so bile replike za proizvodno delo. To je pomembno, ker bo replika pomagala ustvariti dosleden izpis in še naprej prejemati spremembe od glavnega dela.

Naslednji ukazi, ki opisujejo postopek selitve, bodo uporabljali naslednje zapise gostitelja:

1. mojster — izvorni strežnik;
2. replika1 — pretočna replika na staro produkcijo;
3. replika2 - nova logična replika.

Načrt selitve

1. Ustvarite naročnino na master za vse tabele v shemi public osnova dbname:

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

2. Ustvarite režo za podvajanje na glavnem:

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

3. Ustavite podvajanje na stari repliki:

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

4. Pridobite številko transakcije od poveljnika:

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

5. Odstranite smetišče iz stare replike. To bomo storili v več nitih, kar bo pomagalo pospešiti postopek:

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

6. Naložite izpis na nov strežnik:

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

7. Po prenosu izpisa lahko začnete replikacijo na pretočni repliki:

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

7. Ustvarimo naročnino na novo logično repliko:

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. Gremo oid naročnine:

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

9. Recimo, da je bilo prejeto oid=1000. Uporabimo transakcijsko številko za naročnino:

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

10. Začnimo replikacijo:

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

11. Preverite status naročnine, replikacija bi morala delovati:

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. Ko se replikacija zažene in so baze podatkov sinhronizirane, lahko preklopite.

13. Ko onemogočite replikacijo, morate popraviti zaporedja. To je dobro opisano v članku na wiki.postgresql.org.

Zahvaljujoč temu načrtu je prehod potekal z minimalnimi zamudami.

Zaključek

Operaterji Kubernetes vam omogočajo poenostavitev različnih dejanj tako, da jih zmanjšate na ustvarjanje virov K8s. Ker pa smo z njihovo pomočjo dosegli izjemno avtomatizacijo, velja spomniti, da lahko prinese tudi številne nepričakovane nianse, zato pametno izbirajte svoje operaterje.

Ob upoštevanju treh najbolj priljubljenih operaterjev Kubernetes za PostgreSQL smo izbrali projekt podjetja Zalando. In z njim smo morali premagati določene težave, vendar je bil rezultat res zadovoljiv, zato nameravamo to izkušnjo razširiti na nekatere druge namestitve PgSQL. Če imate izkušnje z uporabo podobnih rešitev, bomo veseli podrobnosti v komentarjih!

PS

Preberite tudi na našem blogu:

• «Baze podatkov in Kubernetes (pregled in video poročilo)»;
• «Postgres torek #5: PostgreSQL in Kubernetes. CI/CD. Avtomatizacija testiranja»;
• «Ena zgodba z operaterjem Redis v K8s in mini pregled pripomočkov za analizo podatkov iz te zbirke podatkov".

Vir: www.habr.com