Sempre più, i clienti ricevenu e seguenti dumande: "Vulemu cum'è Amazon RDS, ma più prezzu"; "Vulemu cum'è RDS, ma in ogni locu, in ogni infrastruttura". Per implementà una tale soluzione amministrata in Kubernetes, avemu vistu u statu attuale di l'operatori più populari per PostgreSQL (Stolon, operatori di Crunchy Data è Zalando) è avemu fattu a nostra scelta.
Questu articulu hè a sperienza chì avemu acquistatu sia da un puntu di vista teoricu (revisione di suluzioni) sia da un latu praticu (ciò chì hè statu sceltu è ciò chì hè vinutu). Ma prima, determinemu quali sò i requisiti generali per un sustitutu potenziale per RDS ...
Cosa hè RDS
Quandu a ghjente parla di RDS, in a nostra sperienza, significanu un serviziu DBMS amministratu chì:
- faciule da cunfigurà;
- hà a capacità di travaglià cù snapshots è restaurà da elli (preferibile cù supportu );
- permette di creà topologies master-slave;
- hà una ricca lista di estensioni;
- furnisce auditu è gestione di l'utilizatori / accessu.
In generale, l'avvicinamenti à implementà u compitu in manu pò esse assai diffirenti, ma a strada cun Ansible cundizionale ùn hè micca vicinu à noi. (I culleghi di 2GIS sò ghjunti à una cunclusione simile cum'è u risultatu crea "un strumentu per implementà rapidamente un cluster di failover basatu in Postgres").
L'operatori sò un approcciu cumuni per risolve prublemi simili in l'ecosistema Kubernetes. U direttore tecnicu di "Flanta" hà digià parlatu in più dettagliu di elli in relazione à e basa di dati lanciate in Kubernetes. in .
NB: Per creà rapidamente operatori simplici, ricumandemu di attentu à a nostra utilità Open Source . Utilizendu, pudete fà questu senza cunniscenze di Go, ma in modi più familiari per l'amministratori di u sistema: in Bash, Python, etc.
Ci sò parechji operatori K8s populari per PostgreSQL:
- Stolon;
- Crunchy Data PostgreSQL Operatore;
- Operatore Zalando Postgres.
Fighjemu à elli più vicinu.
Selezzione di l'operatore
In più di l'impurtanti caratteristiche digià citate sopra, noi - cum'è ingegneri di l'operazioni di l'infrastruttura di Kubernetes - aspettavamu ancu i seguenti da l'operatori:
- implementazione da Git è cun ;
- pod supportu anti-affinità;
- installà affinità di nodi o selettore di nodi;
- stallazione di tolleranze;
- dispunibilità di capacità di tuning;
- tecnulugii capisci è ancu cumandamenti.
Senza entre in dettagli nantu à ognuna di i punti (dumandate in i cumenti s'ellu avete sempre dumande nantu à elli dopu avè lettu l'articulu sanu), aghju nutatu in generale chì sti paràmetri sò necessarii per descriverà più accuratamente a specializazione di i nodi di cluster per esse. ordinali per applicazioni specifiche. In questu modu pudemu ottene l'equilibriu ottimale in termini di rendiment è costu.
Avà andemu à l'operatori PostgreSQL stessi.
1. Stolonu
da a cumpagnia italiana Sorint.lab in era cunsideratu cum'è un tipu di standard trà l'operatori per DBMS. Questu hè un prughjettu abbastanza vechju: a so prima liberazione publica hè accaduta in nuvembre 2015 (!), è u repository GitHub vanta quasi 3000 stelle è 40+ contributori.
In verità, Stolon hè un excelente esempiu di architettura pensativa:
U dispusitivu di stu operatore pò esse trovu in detail in u rapportu o . In generale, basta à dì chì pò fà tuttu ciò chì hè descrittu: failover, proxy per l'accessu trasparente di u cliente, backups... Inoltre, i proxies furniscenu l'accessu per mezu di un serviziu endpoint - à u cuntrariu di l'altri dui suluzioni discututi quì sottu (ognunu hà dui servizii per accessu à a basa).
Tuttavia, Stolon , chì hè per quessa ùn pò micca esse implementatu in tale manera chì hè faciule è rapidu - "cum'è torte calde" - per creà istanze DBMS in Kubernetes. A gestione hè realizata attraversu l'utilità stolonctl, l'implementazione hè fatta à traversu u graficu Helm, è quelli persunalizati sò definiti è specificati in ConfigMap.
Da una banda, si trova chì l'operatore ùn hè micca veramente un operatore (dopu à tuttu, ùn usa micca CRD). Ma d'altra banda, hè un sistema flexible chì vi permette di cunfigurà risorse in K8s cum'è vede bè.
Per riassume, per noi personalmente ùn pareva ottimali per creà un graficu separatu per ogni basa di dati. Dunque, avemu cuminciatu à circà l'alternative.
2. Crunchy Data PostgreSQL Operator
, una ghjovana startup americana, pareva una alternativa logica. A so storia publica principia cù a prima liberazione in marzu 2017, da tandu u repository GitHub hà ricevutu pocu menu di 1300 stelle è 50+ cuntributori. L'ultima versione di settembre hè stata pruvata per travaglià cù Kubernetes 1.15-1.18, OpenShift 3.11+ è 4.4+, GKE è VMware Enterprise PKS 1.3+.
L'architettura di Crunchy Data PostgreSQL Operator risponde ancu à i requisiti dichjarati:
A gestione si faci per mezu di l'utilità pgo, in ogni modu, genera Risorse Personalizzate per Kubernetes. Dunque, l'operatore ci hà piacè cum'è utilizatori potenziali:
- ci hè cuntrollu via CRD;
- gestione cunvene di l'utilizatori (ancu via CRD);
- integrazione cù altri cumpunenti - una cullizzioni specializata d'imaghjini di cuntenituri per PostgreSQL è utilità per travaglià cun ellu (cumprese pgBackRest, pgAudit, estensioni da contrib, etc.).
Tuttavia, i tentativi di cumincià à aduprà l'operatore da Crunchy Data anu revelatu parechji prublemi:
- Ùn ci era micca pussibilità di tollerazioni - solu nodeSelector hè furnitu.
- I pods creati eranu parte di Deployment, malgradu u fattu chì avemu implementatu una applicazione stateful. A cuntrariu di StatefulSets, Deployments ùn ponu micca creà dischi.
L'ultimu inconveniente porta à mumenti divertenti: nantu à l'ambiente di prova, avemu riesciutu à eseguisce 3 repliche cù un discu magazzinu lucale, pruvucannu à l'operatore per rapportà chì 3 rèpliche travagliavanu (ancu s'ellu ùn eranu micca).
Una altra caratteristica di questu operatore hè a so integrazione pronta cù diversi sistemi ausiliari. Per esempiu, hè faciule d'installà pgAdmin è pgBounce, è in Grafana pre-configurati è Prometheus sò cunsiderate. In recenti L'integrazione mejorata cù u prugettu hè nutata separatamente , grazia à quale l'operatore offre una visualizazione chjara di e metriche PgSQL fora di a scatula.
Tuttavia, a strana scelta di risorse generate da Kubernetes ci hà purtatu à a necessità di truvà una suluzione sfarente.
3. Operatore Zalando Postgres
Avemu cunnisciutu i prudutti Zalando per un bellu pezzu: avemu l'experientia cù Zalenium è, sicuru, avemu pruvatu hè a so soluzione HA populari per PostgreSQL. Circa l'approcciu di a cumpagnia di creà unu di i so autori, Alexey Klyukin, hà dettu in l'aria , è ci hè piaciutu.
Questa hè a suluzione più ghjovana discussa in l'articulu: a prima liberazione hè stata in Aostu 2018. Tuttavia, anche malgradu u picculu numeru di versioni furmali, u prugettu hà fattu una longa strada, superendu digià in pupularità a suluzione da Crunchy Data cù 1300+ stelle in GitHub è u numeru massimu di cuntributori (70+).
"Sottu u cappucciu" stu operatore usa suluzioni testate in u tempu:
- Patroni è Per guidà,
- - per i backups,
- - cum'è una piscina di cunnessione.
Eccu cumu si prisenta l'architettura di l'operatore da Zalando:
L'operatore hè gestitu cumplettamente per mezu di Risorse Personalizzate, crea automaticamente un StatefulSet da cuntenituri, chì pò esse persunalizatu aghjunghjendu diversi sidecars à u pod. Tuttu chistu hè un vantaghju significativu in paragunà cù l'operatore da Crunchy Data.
Siccomu avemu sceltu a suluzione da Zalando trà l'opzioni 3 in cunsiderà, una descrizzione ulteriore di e so capacità serà presentata quì sottu, immediatamente cù a pratica di l'applicazione.
Pratica cù Postgres Operator da Zalando
A implementazione di l'operatore hè assai simplice: basta à scaricà a versione attuale da GitHub è applicà i fugliali YAML da u cartulare. . In alternativa, pudete puru aduprà .
Dopu à a stallazione, duvete preoccupari di a stallazione . Questu hè fattu via ConfigMap postgres-operator in u namespace induve installate l'operatore. Una volta chì i repositori sò cunfigurati, pudete implementà u vostru primu cluster PostgreSQL.
Per esempiu, a nostra implementazione standard hè cusì:
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
Stu manifestu implementa un cluster di 3 casi cù un sidecar in a forma , da quale avemu pigliatu metrica di l'applicazione. Comu pudete vede, tuttu hè assai simplice, è se vulete, pudete creà un numeru literalmente illimitatu di clusters.
Hè vale a pena attenti pannellu di amministrazione web - . Veni cù l'operatore è permette di creà è sguassate clusters, è ancu di travaglià cù backups fatti da l'operatore.
Lista di clusters PostgreSQL
Gestione di salvezza
Un'altra caratteristica interessante hè u supportu . Stu mecanismu crea automaticamente roles in PostgreSQL, basatu annantu à a lista resultanti di nomi d'utilizatori. L'API poi permette di vultà una lista di l'utilizatori per i quali i roli sò creati automaticamente.
Prublemi è suluzione
In ogni casu, l'usu di l'operatore hà revelatu prestu parechje difetti significativi:
- mancanza di supportu nodeSelector;
- incapacità di disattivà e copie di salvezza;
- quandu si usa a funzione di creazione di basa di dati, i privilegi predeterminati ùn si prisentanu micca;
- A volte a documentazione manca o hè obsoleta.
Fortunatamente, parechji di elli ponu esse risolti. Partemu da a fine - prublemi cù documentazione.
Hè assai prubabile, truverete u fattu chì ùn hè micca sempre chjaru cumu registrà una copia di salvezza è cumu cunnette u bucket di salvezza à l'Uperatore UI. A documentazione parla di questu in passaghju, ma a vera descrizzione hè in :
- bisognu di fà un sicretu;
- trasmette à l'operatore cum'è un paràmetru
pod_environment_secret_namein u CRD cù i paràmetri di l'operatore o in ConfigMap (secondu cumu decide di stallà l'operatore).
Tuttavia, cum'è risulta, questu hè attualmente impussibile. Hè per quessa chì avemu cullatu cù alcuni sviluppi supplementari di terzu. Per più infurmazione nantu à questu, vede quì sottu.
Se passa i paràmetri di salvezza à l'operatore, à dì - wal_s3_bucket e chiavi di accessu in AWS S3, allora ferà una copia di salvezza di tuttu: micca solu basi in a pruduzzione, ma ancu in scena. Questu ùn ci cunvene micca.
In a descrizzione di i paràmetri per Spilo, chì hè u wrapper di basa di Docker per PgSQL quandu si usa l'operatore, hè risultatu: pudete passà un paràmetru. WAL_S3_BUCKET viotu, disattivendu cusì e backup. Inoltre, per grande gioia, aghju trovu , chì avemu accettatu subitu in a nostra forchetta. Avà basta à aghjunghje enableWALArchiving: false à una risorsa di cluster PostgreSQL.
Iè, ci era l'uppurtunità di fà in modu diversu cù l'operatore 2: unu per staging (senza backups), è u sicondu per a produzzione. Ma avemu pussutu fà cun una.
Ok, avemu amparatu à trasfirià l'accessu à e basa di dati per S3 è i backups cuminciaru à entre in u almacenamiento. Cumu fà chì e pagine di salvezza travaglianu in Operator UI?
Avete bisognu di aghjunghje 3 variàbili à l'interfaccia di l'operatore:
-
SPILO_S3_BACKUP_BUCKET -
AWS_ACCESS_KEY_ID -
AWS_SECRET_ACCESS_KEY
Dopu questu, a gestione di e copie di salvezza diventerà dispunibule, chì in u nostru casu simplificà u travagliu cù staging, chì ci permette di furnisce fette da a pruduzzione quì senza scripts supplementari.
Un altru vantaghju era u travagliu cù l'API Teams è ampie opportunità per creà basa di dati è roli utilizendu strumenti di l'operatore. Tuttavia, u creatu roli ùn avianu micca diritti per difettu. In cunsiquenza, un utilizatore cù diritti di lettura ùn pudia micca leghje novi tavule.
Perchè hè questu? Malgradu u fattu chì in u codice necessariu GRANT, ùn sò micca sempre usati. Ci sò 2 metudi: syncPreparedDatabases и syncDatabases. L' syncPreparedDatabases - malgradu u fattu chì in a rùbbrica preparedDatabases ci hè una cundizione defaultRoles и defaultUsers per creà roles, i diritti predeterminati ùn sò micca applicati. Semu in u prucessu di preparà un patch per chì sti diritti sò automaticamente applicati.
È l'ultimu puntu in e migliure chì sò pertinenti per noi - , chì aghjunghje Node Affinity à u StatefulSet creatu. I nostri clienti spessu preferiscenu riduce i costi usendu istanze spot, è chjaramente ùn valenu micca a pena di hosting servizii di basa di dati. Stu prublema puderia esse risolta per via di e tollerazioni, ma a presenza di Node Affinity dà più fiducia.
Chi hè successu?
Basatu nantu à i risultati di risolve i prublemi sopra, avemu forked Postgres Operator da Zalando in , induve hè cullatu cù tali patch utili. È per più comodità, avemu ancu cullatu .
Lista di PR accettati in u fork:
- ;
- ;
- ;
- .
Serà grande se a cumunità sustene questi PR per ch'elli ghjunghjenu upstream cù a prossima versione di l'operatore (1.6).
Bonus! Storia di successu di a migrazione di produzzione
Sè vo aduprate Patroni, a produzzione live pò esse migratu à l'operatore cù un minimu downtime.
Spilo permette di creà clusters standby via S3 storage with , Quandu u logu binariu PgSQL hè prima guardatu in S3 è poi pompatu da a replica. Ma chì fà si avete ùn utilizatu da Wal-E nantu à a vechja infrastruttura? A suluzione à stu prublema hè digià nantu à u hub.
A replicazione logica di PostgreSQL vene in salvezza. In ogni casu, ùn entremu micca in dettagliu cumu per creà publicazioni è abbonamenti, perchè ... u nostru pianu era un fiasco.
U fattu hè chì a basa di dati avia parechje tavule caricate cù milioni di fila, chì, in più, sò stati constantemente rimpiazzati è sguassati. с copy_data, Quandu a nova replica copia tutti i cuntenuti da u maestru, ùn pò micca esse ghjustu cù u maestru. Copià u cuntenutu hà travagliatu per una settimana, ma ùn hà mai pigliatu u maestru. In fine, m'hà aiutatu à risolve u prublema culleghi da Avito: vi ponu trasfiriri dati cù pg_dump. Descriveraghju a nostra versione (ligeramente mudificata) di questu algoritmu.
L'idea hè chì pudete fà un abbunamentu disattivatu ligatu à un slot di replicazione specificu, è dopu corregge u numeru di transazzione. Ci era riplichi dispunibili per u travagliu di produzzione. Questu hè impurtante perchè a replica aiuterà à creà un dump consistente è cuntinueghja à riceve cambiamenti da u maestru.
I cumandamenti successivi chì descrizanu u prucessu di migrazione utilizanu e seguenti notazioni d'ospiti:
- Maestru - servore fonte;
- replica 1 - replica in streaming nantu à a vechja pruduzzione;
- replica 2 - nova replica logica.
Pianu di migrazione
1. Crea un abbunamentu nantu à u maestru per tutte e tavule in u schema public basa dbname:
psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"
2. Crea un slot di replicazione nantu à u maestru:
psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"
3. Arresta a replicazione nantu à a vechja replica:
psql -h replica1 -c "select pg_wal_replay_pause();"
4. Get u numeru di transazzione da u maestru:
psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"
5. Eliminate u dump da a vechja replica. Facemu questu in parechji fili, chì aiutanu à accelerà u prucessu:
pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname
6. Caricate u dump à u novu servitore:
pg_restore -h replica2 -F d -j 8 -d dbname dump/
7. Dopu avè scaricatu u dump, pudete inizià a replicazione nantu à a replica streaming:
psql -h replica1 -c "select pg_wal_replay_resume();"
7. Creemu un abbonamentu nantu à una nova replica logica:
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. Andemu oid abbonamenti:
psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"
9. Dicemu chì hè statu ricevutu oid=1000. Applichemu u numeru di transazzione à l'abbonamentu:
psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"
10. Cuminciamu a replicazione:
psql -h replica2 -d dbname -c "alter subscription oldprod enable;"
11. Verificate u statutu di abbunamentu, a replicazione deve travaglià:
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. Dopu chì a replicazione hè cuminciata è e basa di dati sò sincronizati, pudete cambià.
13. Dopu avè disattivatu a replicazione, avete bisognu di correggerà e sequenze. Questu hè ben descrittu .
Grazie à stu pianu, u cambiamentu hè fattu cù ritardi minimi.
cunchiusioni
L'operatori di Kubernetes vi permettenu di simplificà diverse azzioni, riducendu à a creazione di risorse K8s. In ogni casu, avè ottinutu l'automatizazione notevule cù u so aiutu, vale a pena ricurdà chì pò ancu purtà una quantità di sfumature inespettate, cusì sceglite i vostri operatori cun prudenza.
Dopu avè cunsideratu i trè operatori Kubernetes più populari per PostgreSQL, avemu sceltu u prugettu da Zalando. È avemu avutu a superà certe difficultà cun ella, ma u risultatu era veramente piacevule, cusì avemu pensatu à espansione sta sperienza à qualchi altre installazioni PgSQL. Sè avete sperienza cù suluzioni simili, saremu felici di vede i dettagli in i cumenti!
PS
Leghjite puru nant'à u nostru blog:
- «";
- «";
- «».
Source: www.habr.com