ProHoster > Blogs > Administrācija > ÄŖss pārskats par PostgreSQL paziņojumiem uzņēmumam Kubernetes, mÅ«su izvēle un pieredze

ÄŖss pārskats par PostgreSQL paziņojumiem uzņēmumam Kubernetes, mÅ«su izvēle un pieredze

ÄŖss pārskats par PostgreSQL paziņojumiem uzņēmumam Kubernetes, mÅ«su izvēle un pieredze

Arvien biežāk klienti saņem Ŕādus pieprasÄ«jumus: ā€œGribam kā Amazon RDS, bet lētākā€; "Mēs vēlamies to kā RDS, bet visur, jebkurā infrastruktÅ«rā." Lai ieviestu Ŕādu pārvaldÄ«tu risinājumu vietnē Kubernetes, mēs apskatÄ«jām paÅ”reizējo populārāko PostgreSQL operatoru stāvokli (Stolon, operatori no Crunchy Data un Zalando) un izdarÄ«jām savu izvēli.

Šis raksts ir mūsu gūtā pieredze gan no teorētiskā viedokļa (risinājumu apskats), gan no praktiskās puses (kas tika izvēlēts un kas no tā izrietēja). Bet vispirms noskaidrosim, kādas ir vispārīgās prasības iespējamai RDS nomaiņai...

Kas ir RDS

Kad cilvēki runā par RDS, pēc mūsu pieredzes viņi domā pārvaldītu DBVS pakalpojumu, kas:

  1. viegli konfigurējams;
  2. ir iespēja strādāt ar momentuzņēmumiem un atjaunot no tiem (vēlams ar atbalstu PITR);
  3. ļauj izveidot galvenās un pakārtotās topoloģijas;
  4. ir bagātīgs paplaŔinājumu saraksts;
  5. nodroŔina auditu un lietotāju/piekļuves pārvaldību.

VispārÄ«gi runājot, pieejas uzdevuma Ä«stenoÅ”anai var bÅ«t ļoti dažādas, taču ceļŔ ar nosacÄ«to Ansible mums nav tuvs. (Rezultātā kolēģi no 2GIS nonāca pie lÄ«dzÄ«ga secinājuma viņa mēģinājums izveidot "rÄ«ku ātrai uz Postgres balstÄ«tas kļūmjpārlēces klastera izvietoÅ”anai.")

Operatori ir izplatÄ«ta pieeja lÄ«dzÄ«gu problēmu risināŔanai Kubernetes ekosistēmā. PlaŔāk par tiem ā€œFlantaā€ tehniskais direktors jau runājis saistÄ«bā ar Kubernetes iekÅ”ienē palaistajām datubāzēm. distolUz viens no viņa ziņojumiem.

NB: Lai ātri izveidotu vienkārÅ”us operatorus, iesakām pievērst uzmanÄ«bu mÅ«su atvērtā koda utilÄ«tai čaulas operators. Izmantojot to, varat to izdarÄ«t bez zināŔanām par Go, bet tādos veidos, kas ir pazÄ«stamāki sistēmas administratoriem: Bash, Python utt.

PostgreSQL ir vairāki populāri K8s operatori:

  • Stolons;
  • Crunchy Data PostgreSQL operators;
  • Zalando Postgres operators.

Apskatīsim tos tuvāk.

Operatora izvēle

Papildus jau iepriekÅ” minētajām svarÄ«gajām funkcijām mēs kā Kubernetes infrastruktÅ«ras operāciju inženieri no operatoriem gaidÄ«jām arÄ« sekojoÅ”o:

  • izvietoÅ”ana no Git un ar Pielāgoti resursi;
  • pod anti-afinitātes atbalsts;
  • mezgla afinitātes vai mezgla atlasÄ«tāja instalÄ“Å”ana;
  • pielaides uzstādÄ«Å”ana;
  • skaņoÅ”anas iespēju pieejamÄ«ba;
  • saprotamas tehnoloÄ£ijas un pat komandas.

Neiedziļinoties detaļās par katru punktu (jautājiet komentāros, vai pēc visa raksta izlasÄ«Å”anas jums joprojām ir jautājumi par tiem), kopumā atzÄ«mÄ“Å”u, ka Å”ie parametri ir nepiecieÅ”ami, lai precÄ«zāk aprakstÄ«tu klasteru mezglu specializāciju. pasÅ«tiet tos Ä«paÅ”iem lietojumiem. Tādā veidā mēs varam sasniegt optimālu lÄ«dzsvaru veiktspējas un izmaksu ziņā.

Tagad pāriesim pie paŔiem PostgreSQL operatoriem.

1. Stolons

Stolons no Itālijas uzņēmuma Sorint.lab in jau minētais ziņojums tika uzskatÄ«ts par sava veida standartu starp operatoriem DBVS. Å is ir diezgan vecs projekts: tā pirmā publiskā izlaiÅ”ana notika 2015. gada novembrÄ« (!), un GitHub krātuvē ir gandrÄ«z 3000 zvaigžņu un vairāk nekā 40 lÄ«dzstrādnieku.

PatieŔām, Stolon ir lielisks pārdomātas arhitektÅ«ras piemērs:

ÄŖss pārskats par PostgreSQL paziņojumiem uzņēmumam Kubernetes, mÅ«su izvēle un pieredze
SÄ«kāk ar Ŕī operatora ierÄ«ci var iepazÄ«ties pārskatā vai projekta dokumentācija. Kopumā pietiek pateikt, ka tas var paveikt visu, kas aprakstÄ«ts: kļūmjpārlēce, starpniekserveri caurspÄ«dÄ«gai klienta piekļuvei, dublējumkopijas... Turklāt starpniekserveri nodroÅ”ina piekļuvi, izmantojot vienu galapunkta pakalpojumu - atŔķirÄ«bā no pārējiem diviem tālāk apskatÄ«tajiem risinājumiem (katram ir divi pakalpojumi piekļuve bāzei).

Tomēr Stolons nav pielāgotu resursu, tāpēc to nevar izvietot tā, lai bÅ«tu viegli un ātri ā€“ ā€œkā karstmaizesā€ ā€“ izveidot DBVS gadÄ«jumus Kubernetes. PārvaldÄ«bu veic, izmantojot utilÄ«tu stolonctl, izvietoÅ”ana tiek veikta, izmantojot Helm diagrammu, un pielāgotie ir definēti un norādÄ«ti ConfigMap.

No vienas puses, izrādās, ka operators īsti nav operators (galu galā tas neizmanto CRD). Bet, no otras puses, tā ir elastīga sistēma, kas ļauj konfigurēt resursus K8s pēc saviem ieskatiem.

Rezumējot, mums personÄ«gi neŔķita optimāli katrai datubāzei izveidot atseviŔķu diagrammu. Tāpēc mēs sākām meklēt alternatÄ«vas.

2. Crunchy Data PostgreSQL operators

Operators no Crunchy Data, jauns amerikāņu startup, Ŕķita loÄ£iska alternatÄ«va. Tās publiskā vēsture sākas ar pirmo izlaiÅ”anu 2017. gada martā, kopÅ” tā laika GitHub repozitorijs ir saņēmis nedaudz mazāk par 1300 zvaigznÄ«tēm un vairāk nekā 50 lÄ«dzstrādnieku. Jaunākais septembra laidiens tika pārbaudÄ«ts darbam ar Kubernetes 1.15-1.18, OpenShift 3.11+ un 4.4+, GKE un VMware Enterprise PKS 1.3+.

Crunchy Data PostgreSQL Operator arhitektūra atbilst arī norādītajām prasībām:

ÄŖss pārskats par PostgreSQL paziņojumiem uzņēmumam Kubernetes, mÅ«su izvēle un pieredze

Pārvaldība notiek, izmantojot utilītu pgotomēr tas savukārt ģenerē Kubernetes pielāgotus resursus. Tāpēc operators mūs kā potenciālos lietotājus iepriecināja:

  • ir kontrole caur CRD;
  • ērta lietotāju pārvaldÄ«ba (arÄ« caur CRD);
  • integrācija ar citiem komponentiem Crunchy Data Container Suite ā€” specializēta PostgreSQL konteinera attēlu kolekcija un utilÄ«tas darbam ar to (tostarp pgBackRest, pgAudit, paplaÅ”inājumi no contrib utt.).

Tomēr mēģinājumi sākt izmantot operatoru no Crunchy Data atklāja vairākas problēmas:

  • Pielaides nebija iespējams - tiek nodroÅ”ināts tikai nodeSelector.
  • Izveidotie aplikumi bija daļa no izvietoÅ”anas, neskatoties uz to, ka mēs izvietojām statusu saturoÅ”u lietojumprogrammu. AtŔķirÄ«bā no StatefulSets, Deployments nevar izveidot diskus.

Pēdējais trūkums noved pie smieklīgiem brīžiem: testa vidē mums izdevās palaist 3 kopijas ar vienu disku vietējā krātuve, liekot operatoram ziņot, ka darbojas 3 kopijas (lai gan tās nedarbojās).

Vēl viena Ŕī operatora iezÄ«me ir tā gatavā integrācija ar dažādām palÄ«gsistēmām. Piemēram, ir viegli instalēt pgAdmin un pgBounce, un in dokumentācija tiek apsvērti iepriekÅ” konfigurēti Grafana un Prometheus. Nesen laidiens 4.5.0-beta1 AtseviŔķi tiek atzÄ«mēta uzlabota integrācija ar projektu pgMonitor, pateicoties kam operators piedāvā skaidru PgSQL metrikas vizualizāciju.

Tomēr dÄ«vainā Kubernetes radÄ«to resursu izvēle noveda mÅ«s pie nepiecieÅ”amÄ«bas meklēt citu risinājumu.

3. Zalando Postgres operators

Zalando produktus pazÄ«stam jau sen: mums ir pieredze Zalenium lietoÅ”anā un, protams, arÄ« izmēģinājām Patroni ir viņu populārais HA risinājums PostgreSQL. Par uzņēmuma pieeju radÄ«Å”anai Postgres operators ēterā sacÄ«ja viens no tās autoriem Aleksejs Kļukins Postgres-otrdiena #5, un mums tas patika.

Å is ir jaunākais rakstā apspriestais risinājums: pirmā izlaiÅ”ana notika 2018. gada augustā. Tomēr, pat neskatoties uz nelielo oficiālo izlaidumu skaitu, projekts ir nogājis garu ceļu, popularitātē jau pārspējot Crunchy Data risinājumu ar 1300+ zvaigznēm GitHub un maksimālo atbalstÄ«tāju skaitu (70+).

ā€œZem pārsegaā€ Å”is operators izmanto laika pārbaudÄ«tus risinājumus:

  • Patroni un Spilo BraukÅ”anai,
  • WAL-E - dublÄ“Å”anai,
  • PgBouncer - kā savienojuma baseins.

Šādi tiek prezentēta Zalando operatora arhitektūra:

ÄŖss pārskats par PostgreSQL paziņojumiem uzņēmumam Kubernetes, mÅ«su izvēle un pieredze

Operators tiek pilnÄ«bā pārvaldÄ«ts, izmantojot pielāgotos resursus, automātiski izveido StatefulSet no konteineriem, ko pēc tam var pielāgot, pievienojot podam dažādas blakusvāģus. Tas viss ir bÅ«tiska priekÅ”rocÄ«ba salÄ«dzinājumā ar operatoru no Crunchy Data.

Tā kā mēs izvēlējāmies risinājumu no Zalando no 3 izskatāmajām iespējām, tālāk tiks sniegts sÄ«kāks tā iespēju apraksts kopā ar pielietoÅ”anas praksi.

Prakse ar Postgres operatoru no Zalando

Operatora izvietoÅ”ana ir ļoti vienkārÅ”a: vienkārÅ”i lejupielādējiet paÅ”reizējo versiju no GitHub un lietojiet YAML failus no direktorija izpaužas. AlternatÄ«vi, jÅ«s varat arÄ« izmantot operatoru centrs.

Pēc instalÄ“Å”anas jums jāuztraucas par iestatÄ«Å”anu žurnālu un dublējumkopiju krātuve. Tas tiek darÄ«ts, izmantojot ConfigMap postgres-operator nosaukumvietā, kurā instalējāt operatoru. Kad krātuves ir konfigurētas, varat izvietot savu pirmo PostgreSQL klasteru.

Piemēram, mÅ«su standarta izvietoÅ”ana izskatās Ŕādi:

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

Å is manifests izvieto 3 gadÄ«jumu kopu ar blakusvāģi formā postgres_eksportētājs, no kuras mēs ņemam lietojumprogrammu rādÄ«tājus. Kā redzat, viss ir ļoti vienkārÅ”i, un, ja vēlaties, varat izveidot burtiski neierobežotu skaitu klasteru.

Ir vērts pievērst uzmanÄ«bu tÄ«mekļa administrÄ“Å”anas panelis Sākot no postgres-operator-ui. Tas nāk kopā ar operatoru un ļauj izveidot un dzēst klasterus, kā arÄ« strādāt ar operatora veiktajām dublējumkopijām.

ÄŖss pārskats par PostgreSQL paziņojumiem uzņēmumam Kubernetes, mÅ«su izvēle un pieredze
PostgreSQL klasteru saraksts

ÄŖss pārskats par PostgreSQL paziņojumiem uzņēmumam Kubernetes, mÅ«su izvēle un pieredze
Rezerves kopiju pārvaldība

Vēl viena interesanta iezīme ir atbalsts Teams API. Šis mehānisms automātiski izveido lomas PostgreSQL, pamatojoties uz iegūto lietotājvārdu sarakstu. Pēc tam API ļauj atgriezt to lietotāju sarakstu, kuriem tiek automātiski izveidotas lomas.

Problēmas un risinājumi

Tomēr operatora izmantoÅ”ana drÄ«z vien atklāja vairākus bÅ«tiskus trÅ«kumus:

  1. nodeSelector atbalsta trūkums;
  2. nespēja atspējot dublējumus;
  3. izmantojot datu bāzes izveides funkciju, noklusējuma privilēģijas neparādās;
  4. Dažkārt trūkst dokumentācijas vai tā ir novecojusi.

Par laimi, daudzus no tiem var atrisināt. Sāksim no gala ā€“ problēmas ar dokumentācija.

Visticamāk, jÅ«s saskarsities ar faktu, ka ne vienmēr ir skaidrs, kā reÄ£istrēt dublējumu un kā savienot rezerves kopiju ar operatora lietotāja interfeisu. Dokumentācijā par to ir runāts garāmejot, bet Ä«stais apraksts ir iekŔā PR:

  1. nepiecieÅ”ams izveidot noslēpumu;
  2. nodod to operatoram kā parametru pod_environment_secret_name CRD ar operatora iestatījumiem vai ConfigMap (atkarībā no tā, kā jūs nolemjat instalēt operatoru).

Tomēr, kā izrādās, Å”obrÄ«d tas nav iespējams. Tāpēc mēs savācām jÅ«su operatora versija ar dažiem papildu treÅ”o puÅ”u uzlabojumiem. PlaŔāku informāciju par to skatiet tālāk.

Ja nododat operatoram parametrus dublÄ“Å”anai, proti - wal_s3_bucket un piekļuves atslēgas AWS S3, tad tā dublēs visu: ne tikai bāzes ražoÅ”anā, bet arÄ« inscenÄ“Å”ana. Tas mums nederēja.

Spilo parametru aprakstā, kas ir pamata Docker iesaiņojums PgSQL, izmantojot operatoru, izrādÄ«jās: jÅ«s varat nodot parametru WAL_S3_BUCKET tukÅ”s, tādējādi atspējojot dublÄ“Å”anu. Turklāt par lielu prieku es atklāju gatavs PR, ko uzreiz pieņēmām savā dakÅ”iņā. Tagad jums vienkārÅ”i jāpievieno enableWALArchiving: false uz PostgreSQL klastera resursu.

Jā, bija iespēja to izdarÄ«t savādāk, palaižot 2 operatorus: vienu inscenÄ“Å”anai (bez dublējumkopijām), bet otru ražoÅ”anai. Bet ar vienu varējām iztikt.

Labi, mēs uzzinājām, kā pārsÅ«tÄ«t piekļuvi S3 datu bāzēm, un dublējumkopijas sāka nokļūt krātuvē. Kā nodroÅ”ināt, lai rezerves lapas darbotos Operator UI?

ÄŖss pārskats par PostgreSQL paziņojumiem uzņēmumam Kubernetes, mÅ«su izvēle un pieredze

Operatora lietotāja saskarnei būs jāpievieno 3 mainīgie:

  • SPILO_S3_BACKUP_BUCKET
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

Pēc tam kļūs pieejama dublējumkopiju pārvaldÄ«ba, kas mÅ«su gadÄ«jumā vienkārÅ”os darbu ar iestudÄ“Å”anu, ļaujot tur nogādāt Ŕķēles no ražoÅ”anas bez papildu skriptiem.

Vēl viena priekÅ”rocÄ«ba bija darbs ar Teams API un plaÅ”as iespējas izveidot datu bāzes un lomas, izmantojot operatora rÄ«kus. Tomēr radÄ«tais lomām pēc noklusējuma nebija tiesÄ«bu. AttiecÄ«gi lietotājs ar lasÄ«Å”anas tiesÄ«bām nevarēja lasÄ«t jaunas tabulas.

Kāpēc ir tā, ka? Neskatoties uz to, ka kodā tur ir nepiecieÅ”ams GRANT, tos ne vienmēr izmanto. Ir 2 metodes: syncPreparedDatabases Šø syncDatabases. Uz syncPreparedDatabases - neskatoties uz to, ka sadaļā preparedDatabases tur ir ir nosacÄ«jums defaultRoles Šø defaultUsers lai izveidotu lomas, noklusējuma tiesÄ«bas netiek piemērotas. Mēs gatavojam ielāpu, lai Ŕīs tiesÄ«bas tiktu automātiski piemērotas.

Un pēdējais punkts mums aktuālajos uzlabojumos - plāksteris, kas izveidotajam StatefulSet pievieno Node Affinity. MÅ«su klienti bieži dod priekÅ”roku izmaksu samazināŔanai, izmantojot spot instances, un viņiem acÄ«mredzami nav vērts mitināt datu bāzes pakalpojumus. Å o problēmu var atrisināt, izmantojot pielaides, taču mezgla Affinity klātbÅ«tne nodroÅ”ina lielāku pārliecÄ«bu.

Kas notika?

Pamatojoties uz iepriekÅ” minēto problēmu risināŔanas rezultātiem, mēs izveidojām Postgres Operator no Zalando uz jÅ«su krātuve, kur tas tiek savākts ar tādiem noderÄ«giem ielāpiem. Un lielākai ērtÄ«bai mēs arÄ« savācām Docker attēls.

DakŔā pieņemto PR saraksts:

BÅ«tu lieliski, ja kopiena atbalstÄ«s Å”os PR, lai tie tiktu parādÄ«ti augÅ”pusē ar nākamo operatora versiju (1.6).

Bonuss! RažoŔanas migrācijas veiksmes stāsts

Ja izmantojat Patroni, tieÅ”o ražoÅ”anu var migrēt uz operatoru ar minimālu dÄ«kstāvi.

Spilo ļauj izveidot gaidstāves klasterus, izmantojot S3 krātuvi ar Wal-E, kad PgSQL binārais žurnāls vispirms tiek saglabāts S3 un pēc tam to izsūknē kopija. Bet ko darīt, ja jums ir nē izmanto Wal-E vecajā infrastruktūrā? Šīs problēmas risinājums jau ir tas tika ieteikts uz rumbas.

PostgreSQL loģiskā replikācija nāk palīgā. Tomēr mēs nerunāsim par to, kā izveidot publikācijas un abonementus, jo... mūsu plāns bija fiasko.

Fakts ir tāds, ka datu bāzē bija vairākas ielādētas tabulas ar miljoniem rindu, kuras turklāt tika pastāvÄ«gi papildinātas un dzēstas. VienkārÅ”s abonements с copy_data, kad jaunā replika kopē visu saturu no galvenā, tā vienkārÅ”i nevar sekot meistaram. Satura kopÄ“Å”ana darbojās nedēļu, bet nekad nesasniedza meistaru. Galu galā tas man palÄ«dzēja atrisināt problēmu raksts kolēģi no Avito: varat pārsÅ«tÄ«t datus, izmantojot pg_dump. Es aprakstÄ«Å”u mÅ«su (nedaudz pārveidoto) Ŕī algoritma versiju.

Ideja ir tāda, ka varat izveidot atspējotu abonementu, kas saistÄ«ts ar konkrētu replikācijas slotu, un pēc tam labot darÄ«juma numuru. RažoÅ”anas darbam bija pieejamas kopijas. Tas ir svarÄ«gi, jo kopija palÄ«dzēs izveidot konsekventu izgāztuvi un turpinās saņemt izmaiņas no galvenā.

Turpmākajās komandās, kas apraksta migrācijas procesu, tiks izmantoti Ŕādi resursdatora apzÄ«mējumi:

  1. meistars ā€” avota serveris;
  2. replika1 ā€” vecās produkcijas kopijas straumÄ“Å”ana;
  3. replika2 - jauna loģiska kopija.

Migrācijas plāns

1. Visām shēmas tabulām izveidojiet abonementu galvenajā versijā public bāze dbname:

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

2. Masterā izveidojiet replikācijas slotu:

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

3. Apturiet replikāciju vecajā replikā:

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

4. Saņemiet darījuma numuru no galvenā:

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

5. Noņemiet izgāztuvi no vecās kopijas. Mēs to darÄ«sim vairākos pavedienos, kas palÄ«dzēs paātrināt procesu:

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

6. AugÅ”upielādējiet izdruku jaunajā serverÄ«:

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

7. Pēc izgāztuves lejupielādes varat sākt replikāciju straumÄ“Å”anas replikā:

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

7. Izveidosim abonementu jaunai loÄ£iskai kopijai:

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. Saņemsim oid abonementi:

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

9. Pieņemsim, ka tas tika saņemts oid=1000. Piemērosim abonementam darījuma numuru:

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

10. Sāksim replikāciju:

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

11. Pārbaudiet abonementa statusu, replikācijai vajadzētu darboties:

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. Kad ir sākta replikācija un datu bāzes ir sinhronizētas, varat pārslēgties.

13. Pēc replikācijas atspējoÅ”anas ir jālabo secÄ«bas. Tas ir labi aprakstÄ«ts rakstā vietnē wiki.postgresql.org.

Pateicoties Å”im plānam, pārslēgÅ”anās notika ar minimālu kavÄ“Å”anos.

Secinājums

Kubernetes operatori ļauj vienkārÅ”ot dažādas darbÄ«bas, reducējot tās lÄ«dz K8s resursu izveidei. Taču, panākot ievērojamu automatizāciju ar viņu palÄ«dzÄ«bu, der atcerēties, ka tā var nest arÄ« vairākas negaidÄ«tas nianses, tāpēc operatorus izvēlieties saprātÄ«gi.

Ņemot vērā trÄ«s populārākos PostgreSQL Kubernetes operatorus, mēs izvēlējāmies Zalando projektu. Un ar to mums bija jāpārvar zināmas grÅ«tÄ«bas, taču rezultāts bija patieŔām iepriecinoÅ”s, tāpēc plānojam Å”o pieredzi paplaÅ”ināt arÄ« uz dažām citām PgSQL instalācijām. Ja jums ir pieredze lÄ«dzÄ«gu risinājumu izmantoÅ”anā, mēs ar prieku redzēsim sÄ«kāku informāciju komentāros!

PS

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru