Tinjauan Singkat Pernyataan PostgreSQL pikeun Kubernetes, Pilihan sareng Pangalaman Kami

Beuki, klien anu narima requests handap: "Urang rék kawas Amazon RDS, tapi langkung mirah"; "Kami hoyong sapertos RDS, tapi di mana waé, dina infrastruktur naon waé." Pikeun nerapkeun solusi anu diurus dina Kubernetes, kami ningali kaayaan operator anu paling populér pikeun PostgreSQL (Stolon, operator ti Crunchy Data sareng Zalando) sareng ngadamel pilihan urang.

Tulisan ieu mangrupikeun pangalaman anu kami kéngingkeun tina sudut pandang téoritis (tinjauan solusi) sareng tina sisi praktis (naon anu dipilih sareng naon anu asalna). Tapi ke heula, hayu urang nangtukeun naon syarat umum pikeun ngagantian poténsial pikeun RDS ...

Naon RDS

Nalika jalma ngobrol ngeunaan RDS, dina pangalaman urang, aranjeunna hartosna jasa DBMS anu diurus anu:

1. gampang pikeun ngonpigurasikeun;
2. mibanda kamampuhan pikeun digawekeun ku snapshots tur malikkeun ti aranjeunna (preferably kalawan rojongan PITR);
3. ngidinan Anjeun pikeun nyieun topologies master-budak;
4. boga daptar euyeub ekstensi;
5. nyadiakeun auditing sarta pamaké / manajemén aksés.

Sacara umum, pendekatan pikeun ngalaksanakeun tugas di leungeun tiasa pisan béda, tapi jalur kalawan Ansible kondisional teu deukeut jeung urang. (Kolega ti 2GIS dugi ka kacindekan anu sami salaku hasilna usahana jieun "alat pikeun gancang nyebarkeun klaster failover basis Postgres.")

Operator mangrupikeun pendekatan umum pikeun ngarengsekeun masalah anu sami dina ékosistem Kubernetes. Diréktur téknis "Flanta" parantos nyarios langkung rinci ngeunaan éta ngeunaan pangkalan data anu diluncurkeun di jero Kubernetes. distoldi salah sahiji laporanna.

NB: Pikeun gancang nyieun operator basajan, kami nyarankeun nengetan utiliti Open Source kami cangkang-operator. Ngagunakeun éta, anjeun tiasa ngalakukeun ieu tanpa pangaweruh ngeunaan Go, tapi ku cara anu langkung akrab pikeun pangurus sistem: dina Bash, Python, jsb.

Aya sababaraha operator K8s populér pikeun PostgreSQL:

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

Hayu urang tingali aranjeunna langkung caket.

Pilihan operator

Salian fitur penting anu parantos disebatkeun di luhur, kami - salaku insinyur operasi infrastruktur Kubernetes - ogé ngarepkeun hal-hal ieu ti operator:

• deployment ti Git jeung kalawan Sumberdaya Adat;
• pod rojongan anti pangirut;
• masang pangirut titik atanapi pamilih titik;
• pamasangan tolerances;
• kasadiaan kamampuhan tuning;
• téknologi kaharti komo paréntah.

Tanpa badé rinci ngeunaan unggal titik (naroskeun dina koméntar upami anjeun masih gaduh patarosan ngeunaan éta saatos maca sadayana tulisan), kuring bakal perhatikeun sacara umum yén parameter ieu dipikabutuh pikeun langkung akurat ngajelaskeun spésialisasi titik kluster supados mesen aranjeunna pikeun aplikasi husus. Ku cara ieu urang tiasa ngahontal kasaimbangan optimal dina hal kinerja sareng biaya.

Ayeuna hayu urang ngalih ka operator PostgreSQL sorangan.

1. Stolon

Stolon ti parusahaan Italia Sorint.lab di geus disebutkeun laporan dianggap salaku jenis standar diantara operator pikeun DBMS. Ieu mangrupikeun proyék anu cukup lami: sékrési umum kahijina lumangsung dina bulan Nopémber 2015 (!), Sareng gudang GitHub gaduh ampir 3000 béntang sareng 40+ kontributor.

Mémang, Stolon mangrupikeun conto arsitéktur anu saé:

Alat operator ieu tiasa dipendakan sacara rinci dina laporan atanapi dokuméntasi proyék. Sacara umum, cukup disebutkeun yen eta bisa ngalakukeun sagalana ditétélakeun: failover, proxy pikeun aksés klien transparan, cadangan ... Leuwih ti éta, proxy nyadiakeun aksés ngaliwatan hiji layanan tungtung - kawas dua solusi séjén dibahas di handap (maranéhanana masing-masing boga dua layanan pikeun aksés base).

Sanajan kitu, Stolon euweuh Sumberdaya Adat, naha éta henteu tiasa disebarkeun ku cara anu gampang sareng gancang - "sapertos kueh panas" - nyiptakeun instansi DBMS di Kubernetes. Manajemén dilaksanakeun ngaliwatan utiliti stolonctl, deployment dipigawé ngaliwatan bagan Helm, sarta leuwih custom diartikeun sarta dieusian dina ConfigMap.

Di hiji sisi, tétéla yén operator teu bener hiji operator (sanggeus kabeh, teu make CRD). Tapi di sisi séjén, éta sistem fléksibel nu ngidinan Anjeun pikeun ngonpigurasikeun sumberdaya di K8s sakumaha nu katingali pas.

Pikeun nyimpulkeun, pikeun urang pribadi sigana henteu optimal pikeun nyiptakeun bagan anu misah pikeun unggal pangkalan data. Ku alatan éta, urang mimitian néangan alternatif.

2. Operator PostgreSQL Data Crunchy

Operator ti Crunchy Data, a ngamimitian ngora Amérika, seemed kawas alternatif logis. Sajarah umumna dimimitian ku sékrési munggaran dina Maret 2017, ti saprak éta gudang GitHub parantos nampi sahandapeun 1300 béntang sareng 50+ kontributor. Pelepasan panganyarna ti Séptémber diuji pikeun dianggo sareng Kubernetes 1.15-1.18, OpenShift 3.11+ sareng 4.4+, GKE sareng VMware Enterprise PKS 1.3+.

Arsitéktur Crunchy Data PostgreSQL Operator ogé nyumponan sarat anu dinyatakeun:

Manajemén lumangsung ngaliwatan utiliti pgo, kumaha oge, eta dina gilirannana ngahasilkeun Sumberdaya Adat pikeun Kubernetes. Ku alatan éta, operator pleased kami salaku pamaké poténsial:

• aya kontrol via CRD;
• manajemén pamaké merenah (ogé via CRD);
• integrasi jeung komponén séjén Crunchy Data Wadahna Suite - kumpulan husus gambar wadahna pikeun PostgreSQL jeung utilitas pikeun gawé bareng eta (kaasup pgBackRest, pgAudit, ekstensi ti contrib, jsb).

Nanging, usaha pikeun ngamimitian nganggo operator tina Crunchy Data ngungkabkeun sababaraha masalah:

• Teu aya kamungkinan toleransi - ngan nodeSelector anu disayogikeun.
• Polong anu diciptakeun mangrupikeun bagian tina Deployment, sanaos kanyataan yén kami nyebarkeun aplikasi stateful. Teu kawas StatefulSets, Deployments teu bisa nyieun disk.

Kelemahan anu terakhir nyababkeun momen lucu: dina lingkungan uji kami tiasa ngajalankeun 3 réplika sareng hiji disk gudang lokal, ngabalukarkeun operator ngalaporkeun yén 3 réplika berpungsi (sanajan henteu).

Fitur séjén tina operator ieu nyaéta integrasi siap-dijieunna sareng sababaraha sistem bantu. Contona, gampang masang pgAdmin sareng pgBounce, sareng di dokuméntasi pra-konpigurasi Grafana na Prometheus dianggap. Dina panganyarna ngabebaskeun 4.5.0-beta1 Ningkatkeun integrasi sareng proyék dipisahkeun pgMonitor, Hatur nuhun nu operator nawarkeun hiji visualisasi jelas PgSQL metrics out of the box.

Sanajan kitu, pilihan aneh sumberdaya Kubernetes-dihasilkeun kami ka kabutuhan pikeun manggihan solusi béda.

3. Zalando Postgres Operator

Kami parantos lami terang produk Zalando: kami gaduh pangalaman nganggo Zalenium sareng, tangtosna, kami nyobian Patroni nyaeta solusi HA populér maranéhanana pikeun PostgreSQL. Ngeunaan pendekatan perusahaan pikeun nyiptakeun Operator Postgres salah sahiji pangarang na, Alexey Klyukin, ceuk dina hawa Postgres-Salasa #5, sarta kami resep eta.

Ieu mangrupikeun solusi bungsu anu dibahas dina tulisan: sékrési munggaran lumangsung dina Agustus 2018. Sanajan kitu, sanajan sajumlah leutik Kaluaran formal, proyék geus datangna jauh, geus surpassing popularitasnya solusi tina Crunchy Data kalawan 1300+ béntang dina GitHub jeung jumlah maksimum kontributor (70+).

"Dina tiung" operator ieu nganggo solusi anu diuji waktos:

• Patroni jeung Spilo Pikeun nyetir,
• WAL-E - pikeun cadangan,
• PgBouncer - salaku kolam renang sambungan.

Ieu kumaha arsitéktur operator ti Zalando dibere:

Operator dikokolakeun sapinuhna ngaliwatan Custom Resources, otomatis nyiptakeun StatefulSet tina wadahna, anu teras tiasa disaluyukeun ku nambihan rupa-rupa sidecars kana pod. Sadaya ieu mangrupikeun kaunggulan anu signifikan dibandingkeun sareng operator tina Crunchy Data.

Kusabab kami milih solusi ti Zalando diantara pilihan 3 anu ditimbangkeun, pedaran salajengna ngeunaan kamampuanna bakal dibere di handap, langsung sareng prakték aplikasi.

Latihan sareng Operator Postgres ti Zalando

Panyebaran operator saderhana pisan: unduh pelepasan ayeuna tina GitHub sareng nerapkeun file YAML tina diréktori. manifests. Alternatipna, anjeun ogé tiasa nganggo operatorhub.

Saatos instalasi, anjeun kedah hariwang ngeunaan nyetél gudang pikeun log jeung cadangan. Hal ieu dilakukeun via ConfigMap postgres-operator dina spasi ngaran dimana anjeun masang operator. Sakali repositories dikonpigurasi, anjeun tiasa nyebarkeun klaster PostgreSQL munggaran anjeun.

Salaku conto, panyebaran standar kami sapertos kieu:

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

Manifes ieu nyebarkeun klaster 3 instansi sareng sidecar dina bentuk postgres_exporter, ti mana urang nyandak metrics aplikasi. Sakumaha anjeun tiasa tingali, sagalana basajan pisan, sarta lamun hayang, anjeun bisa nyieun jumlah sacara harfiah taya klaster.

Éta patut nengetan panel administrasi wéb - postgres-operator-ui. Éta hadir sareng operator sareng ngamungkinkeun anjeun nyiptakeun sareng ngahapus klaster, ogé damel sareng cadangan anu dilakukeun ku operator.

Daptar klaster PostgreSQL

Manajemén cadangan

fitur metot séjén nyaéta rojongan API Tim. Mékanisme ieu otomatis nyiptakeun peran dina PostgreSQL, dumasar kana hasil daptar ngaran pamaké. API lajeng ngidinan Anjeun pikeun balik daptar pamaké pikeun saha kalungguhan otomatis dijieun.

Masalah sareng solusi

Nanging, pamakean operator enggal ngungkabkeun sababaraha kalemahan anu signifikan:

1. kurangna rojongan nodeSelector;
2. henteu mampuh nganonaktipkeun cadangan;
3. nalika nganggo fungsi nyiptakeun pangkalan data, hak istimewa standar henteu muncul;
4. Kadang-kadang dokuméntasi leungit atanapi katinggaleun jaman.

Untungna, loba di antarana bisa direngsekeun. Hayu urang mimitian ti tungtungna - masalah jeung dokuméntasi.

Paling dipikaresep, anjeun bakal sapatemon kanyataan yén teu salawasna jelas kumaha carana ngadaptar cadangan tur kumaha nyambungkeun ember cadangan ka UI Operator. Dokuméntasi nyarioskeun perkawis ieu, tapi katerangan nyata aya PR:

1. kudu nyieun rusiah;
2. paskeun ka operator salaku parameter pod_environment_secret_name dina CRD sareng setélan operator atanapi di ConfigMap (gumantung kana kumaha anjeun mutuskeun masang operator).

Sanajan kitu, sakumaha tétéla, ieu ayeuna teu mungkin. Éta sababna urang kumpulkeun Vérsi operator Anjeun kalawan sababaraha kamajuan pihak katilu tambahan. Kanggo inpo nu langkung lengkep ihwal éta, tingali di handap.

Upami anjeun ngalihkeun parameter pikeun cadangan ka operator, nyaéta - wal_s3_bucket jeung kenop aksés dina AWS S3, lajeng eta bakal cadangan sagalana: teu ngan basa dina produksi, tapi ogé pementasan. Ieu teu cocog kami.

Dina katerangan parameter pikeun Spilo, anu mangrupikeun bungkus Docker dasar pikeun PgSQL nalika nganggo operator, tétéla: anjeun tiasa lulus parameter. WAL_S3_BUCKET kosong, sahingga nganonaktipkeun cadangan. Leuwih ti éta, pikeun kabagjaan hébat, abdi kapanggih siap PR, anu langsung kami tarima kana garpuh kami. Ayeuna anjeun ngan ukur kedah nambihan enableWALArchiving: false ka sumber daya klaster PostgreSQL.

Leres, aya kasempetan pikeun ngalakukeunana béda ku ngajalankeun 2 operator: hiji pikeun pementasan (tanpa cadangan), sareng anu kadua pikeun produksi. Tapi urang tiasa ngalakukeun sareng hiji.

Ok, urang diajar kumaha carana nransper aksés ka basis data pikeun S3 jeung cadangan mimiti asup kana gudang. Kumaha cara ngajantenkeun halaman cadangan dina UI Operator?

Anjeun kedah nambihan 3 variabel kana UI Operator:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Saatos ieu, manajemén cadangan bakal sayogi, anu dina kasus urang bakal nyederhanakeun padamelan sareng pementasan, ngamungkinkeun urang nganteurkeun irisan tina produksi di dinya tanpa naskah tambahan.

Kauntungan sejenna nyaéta gawé bareng Teams API sareng kasempetan anu cukup pikeun nyiptakeun database sareng peran nganggo alat operator. Sanajan kitu, nu dijieun peran teu boga hak sacara standar. Sasuai, pamaké kalawan hak baca teu bisa maca tabel anyar.

Kunaon éta? Najan kanyataan yén dina kode nyaeta anu diperyogikeun GRANT, aranjeunna henteu salawasna dipaké. Aya 2 métode: syncPreparedDatabases и syncDatabases. The syncPreparedDatabases - sanajan kanyataan yén dina bagian preparedDatabases nyaeta aya saratna defaultRoles и defaultUsers pikeun nyieun peran, hak standar teu dilarapkeun. Kami dina prosés nyiapkeun patch supados hak-hak ieu otomatis diterapkeun.

Sareng titik terakhir dina perbaikan anu relevan pikeun kami - tambalan, anu nambihan Node Affinity kana StatefulSet anu diciptakeun. Klién kami sering resep ngirangan biaya ku cara ngagunakeun instansi spot, sareng aranjeunna jelas henteu pantes jasa database hosting. Masalah ieu tiasa direngsekeun ku toleransi, tapi ayana Node Affinity masihan kapercayaan anu langkung ageung.

Aya naon?

Dumasar kana hasil ngarengsekeun masalah di luhur, kami forked Postgres Operator ti Zalando kana gudang Anjeun, dimana eta dikumpulkeun kalawan patch mangpaat sapertos. Sarta pikeun genah gede, urang ogé dikumpulkeun Gambar Docker.

Daptar PR anu ditarima kana garpu:

• ngawangun gambar lightweight aman pikeun operator di Docker;
• nganonaktipkeun cadangan;
• ngamutahirkeun versi sumberdaya pikeun versi kiwari k8s;
• palaksanaan Node Affinity.

Ieu bakal hébat lamun masarakat ngarojong PRs ieu ambéh maranéhanana meunang hulu jeung versi saterusna operator (1.6).

Bonus! Carita kasuksésan migrasi produksi

Lamun make Patroni, produksi hirup bisa migrasi ka operator kalawan downtime minimal.

Spilo ngidinan Anjeun pikeun nyieun klaster sayaga via gudang S3 kalawan Wal-E, nalika log binér PgSQL munggaran disimpen dina S3 teras dipompa kaluar ku réplika. Tapi naon anu kudu dipigawé lamun boga teu dipaké ku Wal-E on infrastruktur heubeul? Solusi pikeun masalah ieu geus eta disarankeun dina hub.

Réplikasi logis PostgreSQL datang pikeun nyalametkeun. Najan kitu, urang moal balik kana detil ngeunaan kumaha carana nyieun publikasi sarta langganan, sabab ... rencana urang éta fiasco a.

Kanyataan yén pangkalan data ngagaduhan sababaraha tabel anu sarat sareng jutaan barisan, anu, salian ti éta, terus dieusi sareng dipupus. Langganan basajan с copy_data, Nalika réplika anyar nyalin sadaya eusi tina master, éta ngan saukur teu tiasa ngiringan master. Niron eusi digawé pikeun saminggu, tapi pernah bray up kalawan master. Tungtungna, éta mantuan kuring ngajawab masalah artikel kolega ti Avito: Anjeun tiasa nransper data ngagunakeun pg_dump. Kuring bakal ngajelaskeun versi kami (rada dirobah) tina algoritma ieu.

Ide nya nu bisa nyieun langganan ditumpurkeun dihijikeun ka slot réplikasi husus, lajeng ngabenerkeun jumlah urus. Aya réplika sadia pikeun digawé produksi. Ieu penting sabab replica bakal mantuan nyieun dump konsisten tur terus narima parobahan ti master.

Paréntah salajengna anu ngajelaskeun prosés migrasi bakal nganggo notasi host ieu:

1. ngawasaan - server sumber;
2. réplika1 - streaming replika dina produksi heubeul;
3. réplika2 - réplika logis anyar.

Rencana migrasi

1. Jieun langganan dina master pikeun sakabéh tabel di schema nu public dasar dbname:

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

2. Jieun slot réplikasi dina master:

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

3. Eureun réplikasi dina réplika heubeul:

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

4. Meunangkeun nomer transaksi ti master:

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

5. Leupaskeun dump ti replica heubeul. Urang bakal ngalakukeun ieu dina sababaraha threads, anu bakal ngabantu nyepetkeun prosés:

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

6. Unggah dump ka server anyar:

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

7. Saatos ngundeur dump, Anjeun bisa ngamimitian réplikasi dina réplika streaming:

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

7. Hayu urang nyieun langganan dina réplika 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. Hayu urang meunang oid langganan:

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

9. Nyanggakeun katampi oid=1000. Hayu urang nerapkeun nomer transaksi ka langganan:

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

10. Hayu urang ngamimitian réplikasi:

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

11. Pariksa status langganan, réplikasi kedah dianggo:

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. Saatos réplikasi dimimitian jeung database anu nyingkronkeun, Anjeun bisa pindah leuwih.

13. Saatos nganonaktipkeun réplikasi, anjeun kedah ngabenerkeun sekuen. Ieu ogé digambarkeun dina artikel dina wiki.postgresql.org.

Hatur nuhun kana rencana ieu, switchover lumangsung kalawan reureuh minimal.

kacindekan

Operator Kubernetes ngamungkinkeun anjeun nyederhanakeun rupa-rupa tindakan ku cara ngirangan kana nyiptakeun sumber daya K8s. Nanging, saatos ngahontal otomatisasi anu luar biasa kalayan bantosanana, émut yén éta ogé tiasa nyababkeun sababaraha nuansa anu teu kaduga, janten milih operator anjeun kalayan bijaksana.

Saatos nganggap tilu operator Kubernetes anu pang populerna pikeun PostgreSQL, kami milih proyék ti Zalando. Sarta kami kudu nungkulan kasusah tangtu kalawan eta, tapi hasilna éta bener pleasing, sangkan rencanana rék dilegakeun pangalaman ieu sababaraha instalasi PgSQL lianna. Upami anjeun gaduh pangalaman nganggo solusi anu sami, kami bakal bungah ningali detil dina koméntar!

PS

Baca ogé dina blog urang:

• «Basis data sareng Kubernetes (review sareng laporan video)";
• «Postgres Salasa # 5: PostgreSQL sareng Kubernetes. CI/CD. Tés automation";
• «Hiji carita sareng operator Redis di K8s sareng ulasan mini ngeunaan utilitas pikeun nganalisis data tina pangkalan data ieu".

sumber: www.habr.com