Ringkesan Singkat Pernyataan PostgreSQL kanggo Kubernetes, Pilihan lan Pengalaman Kita

Tambah akeh, panjaluk kasebut ditampa saka pelanggan: "Kita pengin kaya Amazon RDS, nanging luwih murah"; "Kita pengin kaya RDS, nanging ing endi wae, ing infrastruktur apa wae." Kanggo ngleksanakake solusi sing dikelola ing Kubernetes, kita ndeleng kahanan saiki operator paling populer kanggo PostgreSQL (Stolon, operator saka Crunchy Data lan Zalando) lan nggawe pilihan kita.

Artikel iki minangka pengalaman kita saka sudut pandang teoretis (review solusi) lan saka sudut pandang praktis (apa sing dipilih lan apa sing kedadeyan). Nanging pisanan, ayo nemtokake apa syarat umum kanggo panggantos potensial kanggo RDS ...

Apa iku RDS

Nalika wong ngomong babagan RDS, ing pengalaman kita, tegese layanan DBMS sing dikelola:

1. gampang diatur;
2. nduweni kemampuan kanggo nggarap jepretan lan waras saka wong-wong mau (luwih apik karo dhukungan kanggo PITR);
3. ngidini sampeyan nggawe topologi master-slave;
4. nduweni dhaptar ekstensi sing sugih;
5. nyedhiyakake audit lan manajemen pangguna / akses.

Umumé, pendekatan kanggo implementasine tugas bisa beda banget, nanging dalan karo Ansible kondisional ora cedhak karo kita. (Kolega saka 2GIS teka ing kesimpulan sing padha minangka asil saka usahane nggawe "Alat Penyebaran Rapid Kluster Failover berbasis Postgres".)

Operator minangka pendekatan sing ditampa umum kanggo ngrampungake masalah kasebut ing ekosistem Kubernetes. Kanthi luwih rinci babagan database sing ana ing Kubernetes, direktur teknis Flant wis ngandhani, distoling salah sawijining laporane.

NB: Kanggo nggawe operator prasaja kanthi cepet, disaranake sampeyan menehi perhatian marang sarana Open Source cangkang-operator. Nggunakake, sampeyan bisa nindakake iki tanpa kawruh babagan Go, nanging kanthi cara sing luwih akrab kanggo pangurus sistem: ing Bash, Python, lsp.

Ana sawetara operator K8s populer kanggo PostgreSQL:

• Stolon;
• Operator PostgreSQL Data Crunchy;
• Zalando PostgreSQL Operator.

Ayo padha ndeleng luwih cedhak.

Pilihan operator

Saliyane fitur penting sing wis kasebut ing ndhuwur, kita - minangka insinyur infrastruktur ing Kubernetes - uga ngarepake operator ing ngisor iki:

• nyebarake saka Git lan karo Sumber Daya Kustom;
• dhukungan anti-afinitas pod;
• nginstal afinitas simpul utawa pamilih simpul;
• nyetel toleransi;
• kasedhiyan opsi tuning;
• teknologi dingerteni lan malah printah.

Tanpa nerangake rincian saben poin (takon ing komentar yen sampeyan isih duwe pitakonan babagan sawise maca kabeh artikel), aku bakal nyathet kanthi umum yen paramèter kasebut dibutuhake kanggo katrangan sing luwih subtle babagan spesialisasi kelenjar kluster ing supaya pesen kanggo aplikasi tartamtu. Kanthi cara iki kita bisa entuk imbangan optimal antarane kinerja lan biaya.

Saiki - menyang operator PostgreSQL dhewe.

1. Stolon

Stolon saka perusahaan Italia Sorint.lab ing wis kasebut laporan Iki dianggep minangka standar ing antarane operator kanggo DBMS. Iki minangka proyek sing rada lawas: rilis umum pisanan ditindakake ing November 2015 (!), Lan repositori GitHub nduweni meh 3000 bintang lan 40+ kontributor.

Pancen, Stolon minangka conto arsitektur sing apik:

Piranti operator iki bisa ditemokaké ing rinci ing laporan utawa dokumentasi proyek. Umumé, cukup kanggo ngomong sing bisa nindakake kabeh sing diterangake: failover, proxy kanggo akses klien transparan, serep ... Kajaba iku, proxy nyedhiyakake akses liwat siji layanan endpoint - ora kaya rong solusi liyane sing dibahas ing ngisor iki (padha duwe rong layanan kanggo ngakses dhasar).

Nanging, Stolon ora Sumber Daya Custom, Pramila ora bisa disebarake kanthi cara sing gampang lan cepet - "kaya kue panas" - kanggo nggawe instans DBMS ing Kubernetes. Manajemen ditindakake liwat sarana stolonctl, penyebaran - liwat Helm-chart, lan adat sing ditetepake ing ConfigMap.

Ing tangan siji, ternyata operator kasebut dudu operator (amarga ora nggunakake CRD). Nanging ing tangan liyane, iku sistem fleksibel sing ngijini sampeyan kanggo ngatur sumber daya ing K8s cara pengin.

Summing munggah, kanggo kita pribadi, iku ora katon minangka cara paling apik kanggo miwiti grafik kapisah kanggo saben database. Dadi kita wiwit nggoleki alternatif.

2. Operator PostgreSQL Data Crunchy

Operator saka Crunchy Data, wiwitan Amerika enom, katon kaya alternatif logis. Sejarah umume diwiwiti kanthi rilis pisanan ing Maret 2017, wiwit iku repositori GitHub nampa kurang saka 1300 bintang lan 50+ kontributor. Rilis paling anyar saka September diuji kanggo nggarap Kubernetes 1.15-1.18, OpenShift 3.11+ lan 4.4+, GKE lan VMware Enterprise PKS 1.3+.

Arsitèktur Operator PostgreSQL Data Crunchy uga nyukupi syarat sing kasebut:

Manajemen liwat sarana pgo, Nanging, iku uga ngasilake Custom Resources kanggo Kubernetes. Mulane, operator seneng kita minangka pangguna potensial:

• ana kontrol liwat CRD;
• manajemen pangguna sing trep (uga liwat CRD);
• integrasi karo komponen liyane Suite Wadhah Data Crunchy - koleksi khusus gambar wadhah kanggo PostgreSQL lan keperluan kanggo nggarap (kalebu pgBackRest, pgAudit, ekstensi saka contrib, etc.).

Nanging, nyoba miwiti nggunakake operator saka Crunchy Data nuduhake sawetara masalah:

• Ora ana kemungkinan toleransi - mung nodeSelector sing diwenehake.
• Pod sing digawe minangka bagean saka Deployment, sanajan kasunyatane kita nggunakake aplikasi stateful. Ora kaya StatefulSets, Deployments ora bisa nggawe disk.

Cacat pungkasan nyebabake momen lucu: ing lingkungan tes, kita bisa mbukak 3 replika kanthi siji disk panyimpenan lokal, minangka asil saka operator kacarita sing 3 replika digunakake (sanajan iki ora cilik).

Fitur liyane saka operator iki yaiku integrasi sing wis siap karo macem-macem sistem tambahan. Contone, gampang nginstal pgAdmin lan pgBounce, lan ing dokumentasi prakonfigurasi Grafana lan Prometheus dianggep. Ing anyar release 4.5.0-beta1 kapisah nyathet integrasi apik karo project pgMonitor, amarga operator nawakake visualisasi visual metrik PgSQL metu saka kothak.

Nanging, pilihan aneh saka sumber daya Kubernetes nyebabake kita nemokake solusi sing beda.

3. Zalando Postgres Operator

Produk Zalando wis dikenal kanggo kita kanggo dangu: kita duwe pengalaman nggunakake Zalenium lan, mesthi, kita wis nyoba Patroni minangka solusi HA sing populer kanggo PostgreSQL. Babagan pendekatan perusahaan kanggo nggawe Operator PostgreSQL marang salah sawijining penulis - Alexei Klyukin - ing udhara Postgres-Selasa #5lan kita disenengi iku.

Iki minangka solusi paling enom sing dibahas ing artikel kasebut: rilis pisanan ditindakake ing Agustus 2018. Nanging, sanajan jumlah rilis resmi sing sithik, proyek kasebut wis adoh banget, wis ngluwihi popularitas solusi saka Crunchy Data kanthi lintang 1300+ ing GitHub lan jumlah kontributor maksimal (70+).

"Ing hood" operator iki, solusi sing diuji wektu digunakake:

• Patroni lan Spilo Kanggo nyopir,
• WAL-E - kanggo serep
• PgBouncer - minangka blumbang sambungan.

Mangkene carane arsitektur operator saka Zalando ditampilake:

Operator dikelola kanthi lengkap liwat Custom Resources, kanthi otomatis nggawe StatefulSet saka kontaner, sing banjur bisa disesuaikan kanthi nambah macem-macem sidecars menyang pod. Kabeh iki minangka plus sing signifikan dibandhingake karo operator saka Crunchy Data.

Amarga kita milih solusi saka Zalando ing antarane 3 opsi sing dianggep, katrangan luwih lengkap babagan kemampuane bakal diwenehi ing ngisor iki, bebarengan karo praktik aplikasi.

Praktek karo Operator Postgres dening Zalando

Penyebaran operator gampang banget: mung download rilis paling anyar saka GitHub lan aplikasi file YAML saka direktori mujudake. Utawa, sampeyan uga bisa nggunakake operatorhub.

Sawise instalasi, sampeyan kudu ngurus setelan kasebut panyimpenan kanggo log lan serep. Iki ditindakake liwat ConfigMap postgres-operator ing papan jeneng ing ngendi sampeyan nyetel operator. Kanthi repositori sing dikonfigurasi, sampeyan bisa masang kluster PostgreSQL pisanan.

Contone, panyebaran standar kita katon kaya iki:

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

Manifest iki nyebarake klompok 3 conto kanthi sidecar saka formulir kasebut postgres_exporter, saka ngendi kita ngumpulake metrik aplikasi. Nalika sampeyan bisa ndeleng, kabeh iku banget prasaja, lan yen sampeyan pengin, sampeyan bisa nggawe jumlah harfiah Unlimited saka klompok.

Iku worth mbayar manungsa waé kanggo panel web kanggo administrasi - postgres-operator-ui. Nerangake karo operator lan ngidini sampeyan nggawe lan mbusak klompok, uga nggarap serep sing digawe operator.

Dhaptar kluster PostgreSQL

Manajemen serep

Fitur menarik liyane yaiku dhukungan Teams API. Mekanisme iki kanthi otomatis nggawe peran ing PostgreSQL, adhedhasar asil dhaftar jeneng panganggo. Sawise iku, API ngidini sampeyan ngasilake dhaptar pangguna sing peran digawe kanthi otomatis.

Masalah lan solusi

Nanging, panggunaan operator kasebut kanthi cepet nuduhake sawetara kekurangan sing signifikan:

1. lack of support nodeSelector;
2. ora bisa mateni serep;
3. nalika nggunakake fungsi nggawe basis, hak istimewa gawan ora katon;
4. sacara periodik ora ana dokumentasi sing cukup utawa kedaluwarsa.

Untunge, akeh sing bisa ditanggulangi. Ayo dadi miwiti saka mburi - masalah karo dokumentasi.

Paling kamungkinan, sampeyan bakal nemokake kasunyatan sing ora tansah cetha carane ndhaftar serep lan carane nyambungake ember serep menyang UI Operator. Iki kasebut ing dokumentasi ing liwat, nanging gambaran nyata ing PR:

1. sampeyan kudu nggawe rahasia;
2. pass menyang operator minangka parameter pod_environment_secret_name ing CRD karo setelan operator utawa ing ConfigMap (gumantung carane sampeyan milih kanggo nginstal operator).

Nanging, minangka ternyata, ing wayahe iki ora bisa. Mulane kita wis ngumpulake versi operator sampeyan karo sawetara pangembangan pihak katelu tambahan. Luwih lengkap babagan iki - deleng ing ngisor iki.

Yen sampeyan ngirim parameter menyang operator kanggo serep, yaiku - wal_s3_bucket lan tombol akses ing AWS S3, banjur iku bakal serep kabeh: ora mung basis ing produksi, nanging uga pementasan. Iku ora cocog karo kita.

Ing katrangan paramèter menyang Spilo, yaiku bungkus Docker dhasar kanggo PgSQL nalika nggunakake operator, ternyata sampeyan bisa ngliwati parameter. WAL_S3_BUCKET kosong, saéngga mateni serep. Kajaba iku, kanthi bungah banget, aku nemokake siap PR, sing langsung ditampa ing garpu kita. Saiki cukup gampang kanggo nambah enableWALArchiving: false menyang sumber kluster PostgreSQL.

Ya, sampeyan bisa nindakake kanthi beda kanthi mbukak 2 operator: siji kanggo pementasan (tanpa serep), lan sing kapindho kanggo produksi. Nanging kita bisa njaluk karo siji.

Ok, kita wis sinau carane nransfer akses kanggo S3 kanggo database lan serep wiwit njaluk menyang panyimpenan. Kepiye cara nggawe kaca serep ing UI Operator?

Ing UI Operator, sampeyan kudu nambah 3 variabel:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Sawise iku, manajemen serep bakal kasedhiya, sing ing kasus kita bakal nyederhanakake karya kanthi pementasan, ngidini sampeyan ngirim irisan saka produksi ing kana tanpa skrip tambahan.

Minangka plus liyane, bisa karo Teams API lan kesempatan amba kanggo nggawe database lan peran nggunakake alat operator disebut. Nanging, muncul peran ora duwe ijin minangka standar. Dadi, pangguna sing duwe hak maca ora bisa maca tabel anyar.

Kok ngono? Sanajan ing kode ana sing perlu GRANTpadha ora tansah Applied. Ana 2 cara: syncPreparedDatabases и syncDatabases. ing syncPreparedDatabases - senadyan kasunyatan sing ing bagean preparedDatabases ana ana syarate defaultRoles и defaultUsers kanggo nggawe peran, hak gawan ora ditrapake. Kita lagi nyiapake tembelan supaya hak kasebut ditrapake kanthi otomatis.

Lan wayahe pungkasan ing perbaikan sing cocog karo kita - tambalanA sing nambahake Afinitas Node menyang StatefulSet sing digawe. Klien kita asring luwih seneng ngethok biaya kanthi nggunakake conto titik, sing jelas ora cocog karo layanan database hosting. Masalah iki bisa dirampungake kanthi toleransi, nanging anane Node Affinity menehi kapercayan luwih akeh.

Apa sing kedadeyan?

Minangka asil saka mecahaken masalah ndhuwur, kita forked Postgres Operator saka Zalando menyang gudang sampeyanngendi iku arep karo patch migunani. Lan kanggo penak luwih, kita uga diklumpukake Gambar Docker.

Dhaptar PR sing ditampa ing garpu:

• mbangun gambar Docker entheng aman kanggo operator;
• mateni serep;
• nganyari versi sumber daya kanggo versi saiki k8s;
• ngleksanakake Node Affinity.

Bakal apik banget yen komunitas ndhukung PR kasebut supaya bisa munggah karo versi operator sabanjure (1.6).

Bonus! Kisah sukses migrasi produksi

Yen sampeyan nggunakake Patroni, produksi langsung bisa dipindhah menyang operator kanthi downtime minimal.

Spilo ngijini sampeyan kanggo nggawe kluster siyaga liwat panyimpenan S3 karo wal-enalika log binar PgSQL pisanan disimpen ing S3 banjur dipompa metu dening replika. Nanging apa yen sampeyan duwe ora digunakake dening Wal-E ing infrastruktur lawas? Solusi kanggo masalah iki wis iku disaranake ing hub.

Replikasi logis PostgreSQL teka kanggo ngluwari. Nanging, kita ora bakal menehi katrangan babagan cara nggawe publikasi lan langganan, amarga ... rencana kita gagal.

Kasunyatan iku database wis sawetara tabel dimuat karo mayuta-yuta larik, kang, malih, padha saya replenished lan dibusak. Langganan prasaja с copy_data, nalika tiron anyar nyalin kabeh isi saka master, iku mung ora bisa tetep karo master. Nyalin konten makarya sajrone seminggu, nanging ora nate kejiret karo master. Ing pungkasan, mbantu ngatasi masalah kasebut artikel kolega saka Avito: sampeyan bisa nransfer data nggunakake pg_dump. Aku bakal njlèntrèhaké kita (rada diowahi) versi algoritma iki.

Ing idea iku sampeyan bisa nggawe langganan dipatèni disambungake menyang slot réplikasi tartamtu lan banjur ndandani nomer transaksi. Ana replika kanggo karya produksi. Iki penting amarga replika bakal mbantu nggawe mbucal konsisten lan terus nampa owah-owahan saka master.

Printah sakteruse sing njlentrehake proses migrasi bakal nggunakake notasi ing ngisor iki kanggo host:

1. Master - server sumber;
2. replika 1 - streaming replika ing produksi lawas;
3. replika 2 - replika logis anyar.

Rencana migrasi

1. Nggawe langganan kanggo kabeh tabel ing skema ing tuntunan public dhasar dbname:

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

2. Nggawe slot replikasi ing master:

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

3. Stop replikasi ing replika lawas:

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

4. Entuk nomer transaksi saka master:

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

5. Mbuwang saka replika lawas. Kita bakal nindakake iki ing sawetara utas, sing bakal mbantu nyepetake proses:

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

6. Unggah dump menyang server anyar:

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

7. Sawise ngundhuh dump, sampeyan bisa miwiti replikasi ing replika streaming:

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

7. Gawe langganan ing replika logis anyar:

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. Njaluk oid langganan:

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

9. Dipun tampa oid=1000. Ayo aplikasi nomer transaksi kanggo langganan:

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

10. Ayo miwiti replikasi:

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

11. Priksa status langganan, replikasi kudu bisa:

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. Sawise replikasi diwiwiti lan database disinkronake, sampeyan bisa ngalih.

13. Sawise mateni réplikasi, sampeyan kudu ndandani urutan. Iku uga diterangake ing artikel ing wiki.postgresql.org.

Thanks kanggo rencana iki, switchover liwati kanthi wektu tundha minimal.

kesimpulan

Operator Kubernetes ngidini sampeyan nyederhanakake macem-macem tumindak kanthi nyuda nggawe sumber daya K8s. Nanging, sawise entuk otomatisasi sing luar biasa kanthi bantuan, kudu dieling-eling manawa bisa uga nggawa sawetara nuansa sing ora dikarepake, mula pilih operator sampeyan kanthi wicaksana.

Sawise mriksa telung operator Kubernetes sing paling populer kanggo PostgreSQL, kita milih proyek kasebut saka Zalando. Lan kita kudu ngatasi sawetara kangelan karo, nanging asil tenan nyenengke, supaya kita rencana kanggo ngluwihi pengalaman iki kanggo sawetara instalasi liyane saka PgSQL. Yen sampeyan duwe pengalaman nggunakake solusi sing padha, kita bakal seneng ndeleng rincian ing komentar!

PS

Waca uga ing blog kita:

• «Database lan Kubernetes (ringkesan lan laporan video)";
• «Postgres Selasa # 5: PostgreSQL lan Kubernetes. CI/CD. Tes Otomatisasi";
• «Siji crita karo operator Redis ing K8s lan mini-review keperluan kanggo nganalisa data saka database iki".

Source: www.habr.com