🥇Ikhtisar Singkat Pernyataan PostgreSQL untuk Kubernetes, Pilihan dan Pengalaman Kami

Permintaan seperti itu semakin banyak diterima dari pelanggan: “Kami menginginkannya seperti Amazon RDS, tetapi lebih murah”; “Kami menginginkannya seperti RDS, tetapi di mana saja, di infrastruktur apa pun.” Untuk mengimplementasikan solusi terkelola di Kubernetes, kami melihat kondisi terkini dari operator terpopuler untuk PostgreSQL (Stolon, operator dari Crunchy Data dan Zalando) dan menentukan pilihan.

Artikel ini adalah pengalaman kami baik dari sudut pandang teoretis (tinjauan solusi) dan dari sudut pandang praktis (apa yang dipilih dan apa hasilnya). Tapi pertama-tama, mari kita definisikan apa saja persyaratan umum untuk calon pengganti RDS...

Apa itu RDS

Ketika orang berbicara tentang RDS, menurut pengalaman kami, yang mereka maksud adalah layanan DBMS terkelola yang:

mudah diatur;
memiliki kemampuan untuk bekerja dengan snapshot dan memulihkannya (sebaiknya dengan dukungan untuk PITR);
memungkinkan Anda membuat topologi master-slave;
memiliki daftar ekstensi yang kaya;
menyediakan audit dan manajemen pengguna/akses.

Secara umum, pendekatan terhadap pelaksanaan tugas bisa sangat berbeda, namun jalur dengan Ansible bersyarat tidak dekat dengan kita. (Rekan-rekan dari 2GIS sampai pada kesimpulan serupa sebagai hasil dari usahanya buat "Alat Penerapan Cepat Kluster Failover berbasis Postgres".)

Operator adalah pendekatan umum untuk memecahkan masalah serupa di ekosistem Kubernetes. Direktur teknis “Flanta” telah membicarakannya secara lebih rinci sehubungan dengan database yang diluncurkan di dalam Kubernetes. distolDi salah satu laporannya.

NB: Untuk membuat operator sederhana dengan cepat, kami menyarankan Anda memperhatikan utilitas Sumber Terbuka kami operator shell. Dengan menggunakannya, Anda dapat melakukan ini tanpa sepengetahuan Go, tetapi dengan cara yang lebih familiar bagi administrator sistem: dengan Bash, Python, dll.

Ada beberapa operator K8 populer untuk PostgreSQL:

Stolon;
Operator PostgreSQL Data Renyah;
Operator Pos Zalando.

Mari kita lihat lebih dekat.

Pemilihan operator

Selain fitur-fitur penting yang telah disebutkan di atas, kami - sebagai insinyur infrastruktur di Kubernetes - juga mengharapkan hal-hal berikut dari operator:

disebarkan dari Git dan dengan Sumber Daya Kustom;
dukungan anti-afinitas pod;
memasang afinitas simpul atau pemilih simpul;
menetapkan toleransi;
ketersediaan opsi penyetelan;
teknologi yang dapat dimengerti dan bahkan perintah.

Tanpa merinci masing-masing poin (tanyakan di komentar jika Anda masih memiliki pertanyaan tentangnya setelah membaca keseluruhan artikel), saya akan mencatat secara umum bahwa parameter ini diperlukan untuk deskripsi yang lebih halus tentang spesialisasi node cluster di untuk memesannya untuk aplikasi tertentu. Dengan cara ini kita dapat mencapai keseimbangan optimal antara kinerja dan biaya.

Sekarang - ke operator PostgreSQL itu sendiri.

1. Stolon

Stolon dari perusahaan Italia Sorint.lab di laporan yang sudah disebutkan dianggap sebagai semacam standar di antara operator untuk DBMS. Ini adalah proyek yang agak lama: rilis publik pertamanya dilakukan pada bulan November 2015 (!), dan repositori GitHub memiliki hampir 3000 bintang dan 40+ kontributor.

Memang benar, Stolon adalah contoh bagus dari arsitektur yang bijaksana:

Perangkat operator ini dapat ditemukan secara rinci di laporan atau dokumentasi proyek. Secara umum, cukuplah untuk mengatakan bahwa ia dapat melakukan semua yang dijelaskan: failover, proxy untuk akses klien transparan, pencadangan ... Selain itu, proxy menyediakan akses melalui satu layanan titik akhir - tidak seperti dua solusi lain yang dibahas di bawah (mereka memiliki dua layanan untuk mengakses basis).

Namun, Stolon tidak ada Sumber Daya Kustom, itulah sebabnya ia tidak dapat diterapkan sedemikian rupa sehingga mudah dan cepat - "seperti kue panas" - untuk membuat instance DBMS di Kubernetes. Manajemen dilakukan melalui utilitas stolonctl, penerapan - melalui diagram Helm, dan diagram kustom ditentukan di ConfigMap.

Di satu sisi ternyata operatornya sebenarnya bukan operator (karena tidak menggunakan CRD). Namun di sisi lain, ini adalah sistem fleksibel yang memungkinkan Anda mengonfigurasi sumber daya di K8 sesuai keinginan Anda.

Kesimpulannya, bagi kami pribadi, ini sepertinya bukan cara terbaik untuk memulai bagan terpisah untuk setiap database. Jadi kami mulai mencari alternatif.

2. Operator PostgreSQL Data Renyah

Operator dari Crunchy Data, sebuah startup muda Amerika, tampak seperti alternatif yang logis. Sejarah publiknya dimulai dengan rilis pertama pada bulan Maret 2017, sejak itu repositori GitHub telah menerima kurang dari 1300 bintang dan 50+ kontributor. Rilis terbaru dari bulan September telah diuji untuk bekerja dengan Kubernetes 1.15-1.18, OpenShift 3.11+ dan 4.4+, GKE dan VMware Enterprise PKS 1.3+.

Arsitektur Operator Crunchy Data PostgreSQL juga memenuhi persyaratan yang disebutkan:

Pengelolaannya melalui utilitas pgo, namun pada gilirannya menghasilkan Sumber Daya Khusus untuk Kubernetes. Oleh karena itu, operator menyenangkan kami sebagai pengguna potensial:

ada kontrol melalui CRD;
manajemen pengguna yang nyaman (juga melalui CRD);
integrasi dengan komponen lain Suite Kontainer Data Renyah - kumpulan gambar container khusus untuk PostgreSQL dan utilitas untuk bekerja dengannya (termasuk pgBackRest, pgAudit, ekstensi dari contrib, dll.).

Namun, upaya untuk mulai menggunakan operator dari Crunchy Data menunjukkan beberapa masalah:

Tidak ada kemungkinan toleransi - hanya nodeSelector yang disediakan.
Pod yang dibuat adalah bagian dari Deployment, meskipun faktanya kami sedang men-deploy aplikasi stateful. Berbeda dengan StatefulSets, Deployment tidak dapat membuat disk.

Cacat terakhir menyebabkan momen lucu: di lingkungan pengujian, kami berhasil menjalankan 3 replika dengan satu disk penyimpanan lokal, akibatnya operator melaporkan bahwa 3 replika berfungsi (walaupun tidak demikian).

Fitur lain dari operator ini adalah integrasi siap pakai dengan berbagai sistem tambahan. Misalnya, mudah untuk menginstal pgAdmin dan pgBounce, dan masuk dokumentasi Grafana dan Prometheus yang telah dikonfigurasi sebelumnya dipertimbangkan. Baru-baru ini rilis 4.5.0-beta1 secara terpisah mencatat peningkatan integrasi dengan proyek pgMonitor, berkat operator yang menawarkan visualisasi visual metrik PgSQL secara langsung.

Namun, pilihan sumber daya yang dihasilkan Kubernetes yang aneh membuat kami menemukan solusi yang berbeda.

3. Operator Pos Zalando

Produk Zalando sudah kami kenal sejak lama: kami berpengalaman menggunakan Zalenium dan tentunya sudah kami coba Patroni adalah solusi HA populer mereka untuk PostgreSQL. Tentang pendekatan perusahaan dalam menciptakan Operator PostgreSQL kata salah satu penulisnya - Alexei Klyukin - saat mengudara Postgres-Selasa #5dan kami menyukainya.

Ini adalah solusi termuda yang dibahas dalam artikel: rilis pertama dilakukan pada Agustus 2018. Namun, meskipun jumlah rilis formalnya sedikit, proyek ini telah berkembang pesat, telah melampaui popularitas solusi dari Crunchy Data dengan 1300+ bintang di GitHub dan jumlah kontributor maksimum (70+).

“Di bawah tenda” operator ini, solusi yang telah teruji digunakan:

Patroni dan spilo Untuk mengemudi,
WAL-E - untuk cadangan,
PgBouncer - sebagai kumpulan koneksi.

Berikut tampilan arsitektur operator dari Zalando:

Operator dikelola sepenuhnya melalui Sumber Daya Kustom, secara otomatis membuat StatefulSet dari kontainer, yang kemudian dapat dikustomisasi dengan menambahkan berbagai sidecar ke pod. Semua ini merupakan nilai tambah yang signifikan dibandingkan dengan operator dari Crunchy Data.

Karena kami memilih solusi dari Zalando di antara 3 opsi yang dipertimbangkan, penjelasan lebih lanjut tentang kemampuannya akan disajikan di bawah ini, beserta praktik penerapannya.

Berlatih dengan Operator Postgres oleh Zalando

Penerapan operator sangat sederhana: cukup unduh rilis terbaru dari GitHub dan terapkan file YAML dari direktori manifes. Alternatifnya, Anda juga bisa menggunakan hub operator.

Setelah instalasi, Anda harus mengurus pengaturannya penyimpanan untuk log dan cadangan. Itu dilakukan melalui ConfigMap postgres-operator di namespace tempat Anda mengatur operator. Dengan repositori yang dikonfigurasi, Anda dapat menyebarkan klaster PostgreSQL pertama Anda.

Misalnya, penerapan standar kami terlihat seperti ini:

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 ini menyebarkan cluster yang terdiri dari 3 instance dengan sidecar formulir postgres_exporter, tempat kami mengumpulkan metrik aplikasi. Seperti yang Anda lihat, semuanya sangat sederhana, dan jika diinginkan, Anda dapat membuat cluster dalam jumlah yang tidak terbatas.

Ini perlu diperhatikan panel web untuk administrasi - postgres-operator-ui. Muncul dengan operator dan memungkinkan Anda membuat dan menghapus cluster, serta bekerja dengan cadangan yang dibuat operator.

Daftar cluster PostgreSQL

Manajemen cadangan

Fitur menarik lainnya adalah dukungan API Tim. Mekanisme ini otomatis tercipta peran di PostgreSQL, berdasarkan daftar nama pengguna yang dihasilkan. API kemudian memungkinkan Anda mengembalikan daftar pengguna yang perannya dibuat secara otomatis.

Masalah dan solusinya

Namun, penggunaan operator segera menunjukkan beberapa kelemahan signifikan:

kurangnya dukungan nodeSelector;
ketidakmampuan untuk menonaktifkan cadangan;
saat menggunakan fungsi buat basis, hak istimewa default tidak muncul;
secara berkala dokumentasinya tidak cukup atau sudah kadaluwarsa.

Untungnya, banyak di antaranya yang bisa diselesaikan. Mari kita mulai dari akhir - masalah dengan dokumentasi.

Kemungkinan besar, Anda akan menemukan kenyataan bahwa tidak selalu jelas cara mendaftarkan cadangan dan cara menghubungkan keranjang cadangan ke UI Operator. Hal ini disebutkan dalam dokumentasi secara sepintas, tetapi deskripsi sebenarnya ada di PR:

anda perlu merahasiakannya;
meneruskannya ke operator sebagai parameter pod_environment_secret_name di CRD dengan pengaturan operator atau di ConfigMap (tergantung bagaimana Anda memilih untuk menginstal operator).

Namun, ternyata, saat ini hal tersebut tidak memungkinkan. Itu sebabnya kami mengumpulkannya versi operator Anda dengan beberapa pengembangan pihak ketiga tambahan. Lebih lanjut tentang itu - lihat di bawah.

Jika Anda meneruskan parameter ke operator untuk cadangan, yaitu - wal_s3_bucket dan kunci akses di AWS S3, lalu akan membuat cadangan semuanya: tidak hanya berbasis produksi, tetapi juga pementasan. Itu tidak cocok untuk kami.

Pada penjelasan parameter Spilo yang merupakan basic Docker wrapper untuk PgSQL saat menggunakan operator ternyata dapat melewatkan sebuah parameter WAL_S3_BUCKET kosong, sehingga menonaktifkan pencadangan. Terlebih lagi, saya sangat gembira karena saya menemukannya siap PR, yang segera kami terima di garpu kami. Sekarang cukup mudah untuk menambahkannya enableWALArchiving: false ke sumber daya klaster PostgreSQL.

Ya, hal ini dapat dilakukan secara berbeda dengan menjalankan 2 operator: satu untuk staging (tanpa cadangan), dan yang kedua untuk produksi. Tapi kami bisa bertahan dengan satu hal.

Oke, kita sudah belajar cara mentransfer akses S3 ke database dan backup mulai masuk ke penyimpanan. Bagaimana cara membuat halaman cadangan berfungsi di UI Operator?

Di UI Operator, Anda perlu menambahkan 3 variabel:

SPILO_S3_BACKUP_BUCKET
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

Setelah itu, manajemen pencadangan akan tersedia, yang dalam kasus kami akan menyederhanakan pekerjaan dengan pementasan, memungkinkan Anda mengirimkan potongan dari produksi ke sana tanpa skrip tambahan.

Kelebihan lainnya adalah bekerja dengan Teams API dan peluang luas untuk membuat database dan peran menggunakan alat operator. Namun, muncul peran tidak memiliki hak secara default. Oleh karena itu, pengguna dengan hak baca tidak dapat membaca tabel baru.

Mengapa demikian? Meskipun dalam kode ada perlu GRANTmereka tidak selalu diterapkan. Ada 2 metode: syncPreparedDatabases и syncDatabases. Di syncPreparedDatabases - terlepas dari kenyataan bahwa di bagian tersebut preparedDatabases ada ada syaratnya defaultRoles и defaultUsers untuk membuat peran, hak default tidak diterapkan. Kami sedang dalam proses menyiapkan tambalan agar hak ini diterapkan secara otomatis.

Dan momen terakhir dalam perbaikan yang relevan bagi kami - tambalan, yang menambahkan Node Affinity ke StatefulSet yang dibuat. Klien kami sering kali lebih memilih untuk mengurangi biaya dengan menggunakan instans spot, dan mereka jelas tidak layak untuk menghosting layanan database. Masalah ini bisa saja diselesaikan melalui toleransi, namun kehadiran Node Affinity memberikan kepercayaan diri yang lebih besar.

Apa yang terjadi?

Sebagai hasil dari penyelesaian masalah di atas, kami membagi Operator Postgres dari Zalando menjadi repositori Andakemana tujuannya dengan tambalan yang sangat berguna. Dan untuk kenyamanan lebih, kami juga mengumpulkannya gambar buruh pelabuhan.

Daftar PR yang diterima di fork:

Alangkah baiknya jika komunitas mendukung PR ini agar bisa upstream dengan operator versi berikutnya (1.6).

Bonusnya! Kisah sukses migrasi produksi

Jika Anda menggunakan Patroni, produksi langsung dapat dimigrasikan ke operator dengan waktu henti minimal.

Spilo memungkinkan Anda membuat cluster siaga melalui penyimpanan S3 dengan wa-eketika log biner PgSQL pertama kali disimpan di S3 dan kemudian dipompa keluar oleh replika. Namun bagaimana jika Anda punya tidak digunakan oleh Wal-E di infrastruktur lama? Solusi untuk masalah ini sudah ada itu disarankan di hub.

Replikasi logis PostgreSQL hadir untuk menyelamatkan. Namun, kami tidak akan menjelaskan secara detail cara membuat publikasi dan langganan, karena ... rencana kami gagal.

Faktanya adalah bahwa database memiliki beberapa tabel yang dimuat dengan jutaan baris, yang, terlebih lagi, terus-menerus diisi ulang dan dihapus. Berlangganan Sederhana с copy_data, ketika replika baru menyalin semua konten dari master, replika tersebut tidak dapat mengikuti masternya. Penyalinan konten berhasil selama seminggu, tetapi tidak pernah berhasil mencapai masternya. Pada akhirnya, ini membantu menyelesaikan masalah tersebut artikel rekan dari Avito: Anda dapat mentransfer data menggunakan pg_dump. Saya akan menjelaskan versi algoritma ini (yang sedikit dimodifikasi).

Idenya adalah Anda dapat membuat langganan yang dinonaktifkan dikaitkan dengan slot replikasi tertentu dan kemudian memperbaiki nomor transaksi. Ada replika untuk pekerjaan produksi. Hal ini penting karena replika akan membantu membuat dump yang konsisten dan terus menerima perubahan dari master.

Perintah selanjutnya yang menjelaskan proses migrasi akan menggunakan notasi berikut untuk host:

menguasai — server sumber;
replika1 - streaming replika pada produksi lama;
replika2 - replika logis baru.

Rencana migrasi

1. Buat langganan ke semua tabel dalam skema di wizard public basis dbname:

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

2. Buat slot replikasi pada master:

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

3. Hentikan replikasi pada replika lama:

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

4. Dapatkan nomor transaksi dari master:

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

5. Buang dari replika lama. Kami akan melakukan ini di beberapa thread, yang akan membantu mempercepat proses:

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

6. Unggah dump ke server baru:

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

7. Setelah mengunduh dump, Anda dapat memulai replikasi pada replika streaming:

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

7. Buat langganan pada replika logis baru:

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

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

9. Katakanlah sudah diterima oid=1000. Mari terapkan nomor transaksi pada langganan:

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

10. Mari mulai replikasi:

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

11. Periksa status berlangganan, replikasi akan berfungsi:

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. Setelah replikasi dimulai dan database disinkronkan, Anda dapat beralih.

13. Setelah menonaktifkan replikasi, Anda perlu memperbaiki urutannya. Itu dijelaskan dengan baik dalam artikel di wiki.postgresql.org.

Berkat rencana ini, peralihan dapat dilakukan dengan sedikit penundaan.

Kesimpulan

Operator Kubernetes memungkinkan Anda menyederhanakan berbagai tindakan dengan menguranginya menjadi pembuatan sumber daya K8. Namun, setelah mencapai otomatisasi yang luar biasa dengan bantuan mereka, perlu diingat bahwa hal ini juga dapat membawa sejumlah nuansa yang tidak terduga, jadi pilihlah operator Anda dengan bijak.

Setelah meninjau tiga operator Kubernetes terpopuler untuk PostgreSQL, kami memilih proyek dari Zalando. Dan kami harus mengatasi beberapa kesulitan dengannya, namun hasilnya sungguh memuaskan, jadi kami berencana untuk memperluas pengalaman ini ke beberapa instalasi PgSQL lainnya. Jika Anda memiliki pengalaman menggunakan solusi serupa, kami akan senang melihat detailnya di komentar!

Tinjauan Singkat Pernyataan PostgreSQL untuk Kubernetes, Pilihan dan Pengalaman Kami