🥇Kubernetes uchun PostgreSQL operatorlari haqida qisqacha ma'lumot, bizning tanlovimiz va tajribamiz

Borgan sari mijozlar quyidagi so'rovlarni olishmoqda: "Biz buni Amazon RDS kabi xohlaymiz, lekin arzonroq"; "Biz buni RDS kabi xohlaymiz, lekin hamma joyda, har qanday infratuzilmada." Kubernetes-da bunday boshqariladigan yechimni amalga oshirish uchun biz PostgreSQL uchun eng mashhur operatorlarning (Stolon, Crunchy Data va Zalando operatorlari) hozirgi holatini ko'rib chiqdik va o'z tanlovimizni qildik.

Ushbu maqola biz nazariy nuqtai nazardan (yechimlarni ko'rib chiqish) va amaliy tomondan (nima tanlangan va undan kelib chiqqan) to'plagan tajribamizdir. Ammo, avvalo, RDSni potentsial almashtirish uchun umumiy talablar nima ekanligini aniqlaylik ...

RDS nima

Odamlar RDS haqida gapirganda, bizning tajribamizga ko'ra, ular boshqariladigan DBMS xizmatini nazarda tutadi:

sozlash oson;
oniy suratlar bilan ishlash va ulardan tiklanish qobiliyatiga ega (yaxshisi yordam bilan PITR);
master-slave topologiyalarini yaratish imkonini beradi;
kengaytmalarning boy ro'yxatiga ega;
audit va foydalanuvchi/kirish boshqaruvini ta'minlaydi.

Umuman olganda, vazifani bajarishga yondashuvlar juda boshqacha bo'lishi mumkin, ammo shartli Ansible bilan yo'l bizga yaqin emas. (Natijada 2GIS hamkasblari xuddi shunday xulosaga kelishdi uning urinishi "Postgres-ga asoslangan o'chirish klasterini tezda joylashtirish uchun vosita" yarating.)

Operatorlar Kubernetes ekotizimidagi shunga o'xshash muammolarni hal qilishda keng tarqalgan yondashuvdir. "Flanta" ning texnik direktori allaqachon Kubernetes ichida ishga tushirilgan ma'lumotlar bazalari haqida ular haqida batafsil gapirib berdi. distol, in uning hisobotlaridan biri.

NB: Tezda oddiy operatorlarni yaratish uchun Ochiq manba yordam dasturimizga e'tibor berishni tavsiya qilamiz qobiq operatori. Undan foydalanib, siz buni Go-ni bilmasdan qilishingiz mumkin, lekin tizim ma'murlariga ko'proq tanish bo'lgan usullarda: Bash, Python va boshqalarda.

PostgreSQL uchun bir nechta mashhur K8s operatorlari mavjud:

Stolon;
Crunchy Data PostgreSQL operatori;
Zalando Postgres operatori.

Keling, ularni batafsil ko'rib chiqaylik.

Operator tanlash

Yuqorida aytib o'tilgan muhim xususiyatlarga qo'shimcha ravishda, biz Kubernetes infratuzilma operatsiyalari bo'yicha muhandislari sifatida operatorlardan quyidagilarni ham kutgan edik:

Git va undan foydalanish Maxsus manbalar;
pod anti-affinity qo'llab-quvvatlash;
tugunga yaqinlik yoki tugun selektorini o'rnatish;
tolerantliklarni o'rnatish;
sozlash imkoniyatlari mavjudligi;
tushunarli texnologiyalar va hatto buyruqlar.

Har bir nuqta haqida batafsil ma'lumot bermasdan (to'liq maqolani o'qib chiqqach, ular haqida hali ham savollaringiz bo'lsa, sharhlarda so'rang), men umuman ta'kidlaymanki, ushbu parametrlar klaster tugunlarining ixtisoslashuvini aniqroq tavsiflash uchun zarurdir. ularni maxsus ilovalar uchun buyurtma qiling. Shunday qilib, biz ishlash va narx bo'yicha optimal muvozanatga erisha olamiz.

Endi PostgreSQL operatorlarining o'ziga o'tamiz.

1. Stolon

Stolon Italiyaning Sorint.lab kompaniyasidan allaqachon aytib o'tilgan hisobot DBMS uchun operatorlar orasida o'ziga xos standart sifatida ko'rib chiqildi. Bu juda eski loyiha: uning birinchi ommaviy nashri 2015-yil noyabr oyida bo‘lib o‘tgan (!) va GitHub omborida deyarli 3000 yulduz va 40+ ishtirokchi bor.

Darhaqiqat, Stolon o'ylangan arxitekturaning ajoyib namunasidir:

Ushbu operatorning qurilmasini hisobotda yoki batafsilroq topish mumkin loyiha hujjatlari. Umuman olganda, u ta'riflangan hamma narsani amalga oshirishi mumkinligini aytish kifoya: uzilish, mijozning shaffof kirishi uchun proksi-serverlar, zaxira nusxalari ... Bundan tashqari, proksi-serverlar bitta so'nggi nuqta xizmati orqali kirishni ta'minlaydi - quyida muhokama qilingan boshqa ikkita echimdan farqli o'laroq (ularning har birida ikkita xizmat mavjud). bazaga kirish).

Biroq, Stolon maxsus manbalar yo'q, shuning uchun uni Kubernetes-da DBMS nusxalarini yaratish oson va tez "issiq keklar kabi" bo'ladigan tarzda joylashtirish mumkin emas. Boshqaruv yordamchi dastur orqali amalga oshiriladi stolonctl, joylashtirish Helm diagrammasi orqali amalga oshiriladi va moslashtirilganlar ConfigMapda aniqlanadi va belgilanadi.

Bir tomondan, operator aslida operator emasligi ma'lum bo'ldi (oxir-oqibat u CRD dan foydalanmaydi). Ammo boshqa tomondan, bu K8-larda resurslarni o'zingiz xohlagan tarzda sozlash imkonini beruvchi moslashuvchan tizim.

Xulosa qilib aytadigan bo'lsak, shaxsan biz uchun har bir ma'lumotlar bazasi uchun alohida diagramma yaratish maqbul ko'rinmadi. Shuning uchun biz muqobil variantlarni izlay boshladik.

2. Crunchy Data PostgreSQL operatori

Crunchy Data operatori, yosh amerikalik startap mantiqiy muqobildek tuyuldi. Uning ommaviy tarixi 2017 yil mart oyida birinchi relizdan boshlanadi, shundan beri GitHub ombori 1300 dan kam yulduz va 50 dan ortiq ishtirokchi oldi. Sentyabr oyidagi so'nggi versiya Kubernetes 1.15-1.18, OpenShift 3.11+ va 4.4+, GKE va VMware Enterprise PKS 1.3+ bilan ishlash uchun sinovdan o'tkazildi.

Crunchy Data PostgreSQL Operator arxitekturasi ham belgilangan talablarga javob beradi:

Boshqaruv yordamchi dastur orqali amalga oshiriladi pgo, ammo u o'z navbatida Kubernetes uchun maxsus resurslarni yaratadi. Shuning uchun operator bizni potentsial foydalanuvchilar sifatida xursand qildi:

CRD orqali nazorat mavjud;
qulay foydalanuvchi boshqaruvi (CRD orqali ham);
boshqa komponentlar bilan integratsiya Crunchy Data Container Suite — PostgreSQL uchun konteyner tasvirlarining ixtisoslashtirilgan to'plami va u bilan ishlash uchun yordamchi dasturlar (jumladan, pgBackRest, pgAudit, hissa qo'shgan kengaytmalar va boshqalar).

Biroq, Crunchy Data operatoridan foydalanishni boshlashga urinishlar bir nechta muammolarni aniqladi:

Chidamlilik imkoniyati yo'q edi - faqat nodeSelector taqdim etiladi.
Biz statistik ilovani joylashtirganimizga qaramay, yaratilgan podslar Deploymentning bir qismi edi. StatefulSets-dan farqli o'laroq, Deployments disklarni yarata olmaydi.

Oxirgi kamchilik kulgili daqiqalarga olib keladi: sinov muhitida biz bitta disk bilan 3 ta nusxani ishga tushirishga muvaffaq bo'ldik. mahalliy saqlash, operatorning 3 ta replika ishlayotgani haqida xabar berishiga sabab bo'ladi (garchi ular bo'lmasa ham).

Ushbu operatorning yana bir xususiyati uning turli yordamchi tizimlar bilan tayyor integratsiyalashuvidir. Masalan, pgAdmin va pgBounce va ichiga o'rnatish oson hujjatlar oldindan tuzilgan Grafana va Prometey ko'rib chiqiladi. Yaqinda 4.5.0-beta1 versiyasi Loyiha bilan yaxshilangan integratsiya alohida qayd etilgan pgMonitor, buning yordamida operator qutidan tashqarida PgSQL ko'rsatkichlarining aniq vizualizatsiyasini taklif qiladi.

Biroq, Kubernetes tomonidan yaratilgan resurslarning g'alati tanlovi bizni boshqa yechim topish zarurligiga olib keldi.

3. Zalando Postgres operatori

Biz Zalando mahsulotlarini uzoq vaqtdan beri bilamiz: biz Zaleniumdan foydalanish tajribamiz bor va, albatta, sinab ko'rdik Patroni bu ularning PostgreSQL uchun mashhur HA yechimidir. Kompaniyaning yaratishga yondashuvi haqida Postgres operatori uning mualliflaridan biri Aleksey Klyukin efirda aytdi Postgres-seshanba №5va bizga yoqdi.

Bu maqolada muhokama qilingan eng yosh yechim: birinchi nashr 2018 yil avgust oyida bo'lib o'tdi. Biroq, rasmiy nashrlarning kam sonli bo'lishiga qaramay, loyiha GitHub-da 1300+ yulduz va maksimal hissa qo'shuvchilar soni (70+) bo'lgan Crunchy Data yechimidan mashhurligi bo'yicha uzoq yo'lni bosib o'tdi.

"Kaput ostida" ushbu operator vaqt sinovidan o'tgan echimlardan foydalanadi:

Patroni va O'yin Haydash uchun,
WAL-E - zaxira nusxalari uchun,
PgBouncer - ulanish hovuzi sifatida.

Zalando operator arxitekturasi quyidagicha taqdim etiladi:

Operator to'liq Maxsus resurslar orqali boshqariladi, konteynerlardan avtomatik ravishda StatefulSet-ni yaratadi, keyin uni podkastga turli xil yonboshchalar qo'shish orqali sozlash mumkin. Bularning barchasi Crunchy Data operatori bilan solishtirganda muhim afzallik hisoblanadi.

Biz ko'rib chiqilayotgan 3 ta variant orasidan Zalandodan yechim tanlaganimiz sababli, uning imkoniyatlarining batafsil tavsifi darhol qo'llash amaliyoti bilan birga quyida taqdim etiladi.

Zalandodan Postgres operatori bilan mashq qiling

Operatorni joylashtirish juda oddiy: shunchaki GitHub-dan joriy versiyani yuklab oling va katalogdan YAML fayllarini qo'llang. namoyon qiladi. Shu bilan bir qatorda, siz ham foydalanishingiz mumkin operatorhub.

O'rnatishdan so'ng, sozlash haqida tashvishlanishingiz kerak jurnallar va zaxiralar uchun saqlash. Bu ConfigMap orqali amalga oshiriladi postgres-operator operatorni o'rnatgan nom maydonida. Repozitariylar sozlangandan so'ng siz birinchi PostgreSQL klasteringizni o'rnatishingiz mumkin.

Misol uchun, bizning standart joylashtirishimiz quyidagicha ko'rinadi:

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

Bu manifest 3 ta misoldan iborat klasterni shaklda yonboshi bilan joylashtiradi postgres_exporter, undan biz dastur ko'rsatkichlarini olamiz. Ko'rib turganingizdek, hamma narsa juda oddiy va agar xohlasangiz, cheksiz miqdordagi klasterlarni yaratishingiz mumkin.

Bunga e'tibor qaratishga arziydi veb-boshqaruv paneli - postgres-operator-ui. U operator bilan birga keladi va klasterlarni yaratish va o'chirish, shuningdek, operator tomonidan yaratilgan zahiralar bilan ishlash imkonini beradi.

PostgreSQL klasterlari ro'yxati

Zaxira boshqaruvi

Yana bir qiziqarli xususiyat - qo'llab-quvvatlash Teams API. Ushbu mexanizm avtomatik ravishda yaratiladi PostgreSQL-dagi rollar, natijada foydalanuvchi nomlari ro'yxati asosida. Keyin API sizga rollar avtomatik ravishda yaratilgan foydalanuvchilar ro'yxatini qaytarishga imkon beradi.

Muammolar va yechimlar

Biroq, operatordan foydalanish tez orada bir nechta muhim kamchiliklarni aniqladi:

nodeSelector yordamining etishmasligi;
zaxira nusxalarini o'chirib qo'yish mumkin emas;
ma'lumotlar bazasini yaratish funktsiyasidan foydalanganda standart imtiyozlar paydo bo'lmaydi;
Ba'zida hujjatlar yo'qoladi yoki eskirgan.

Yaxshiyamki, ularning ko'pchiligini hal qilish mumkin. Oxiridan boshlaylik - muammolar hujjatlar.

Ehtimol, siz zaxira nusxasini qanday ro'yxatdan o'tkazish va zaxira paqirni Operator UI-ga qanday ulash har doim ham aniq emasligi bilan duch kelasiz. Hujjatlar bu haqda o'tib ketadi, ammo haqiqiy tavsifi mavjud PR:

sir ochish kerak;
parametr sifatida operatorga o'tkazing pod_environment_secret_name operator sozlamalari bilan CRDda yoki ConfigMap-da (operatorni qanday o'rnatishga qaror qilganingizga qarab).

Biroq, ma'lum bo'lishicha, hozirda bu mumkin emas. Shuning uchun biz yig'dik operatoringiz versiyasi ba'zi qo'shimcha uchinchi tomon ishlanmalari bilan. Bu haqda ko'proq ma'lumot olish uchun quyida ko'ring.

Agar siz zaxiralash uchun parametrlarni operatorga o'tkazsangiz, xususan - wal_s3_bucket va AWS S3 da kirish kalitlari, keyin esa hamma narsani zaxira qiladi: nafaqat ishlab chiqarishdagi bazalar, balki sahnalashtirish. Bu bizga mos kelmadi.

Operatordan foydalanganda PgSQL uchun asosiy Docker o'rami bo'lgan Spilo parametrlari tavsifida shunday bo'ldi: siz parametrni o'tkazishingiz mumkin. WAL_S3_BUCKET bo'sh, shu bilan zaxira nusxalarini o'chirib qo'yadi. Bundan tashqari, men katta quvonchni topdim tayyor PR, biz darhol vilkalarimizga qabul qildik. Endi siz shunchaki qo'shishingiz kerak enableWALArchiving: false PostgreSQL klaster resursiga.

Ha, 2 ta operatorni ishga tushirish orqali buni boshqacha qilish imkoniyati bor edi: biri sahnalashtirish uchun (zaxirasiz), ikkinchisi esa ishlab chiqarish uchun. Ammo biz bittasi bilan bardosh bera oldik.

OK, biz S3 uchun ma'lumotlar bazalariga kirishni qanday o'tkazishni bilib oldik va zaxira nusxalari xotiraga tusha boshladi. Operator UI da zaxira sahifalarni qanday qilish mumkin?

Operator UI ga 3 ta o'zgaruvchini qo'shishingiz kerak bo'ladi:

SPILO_S3_BACKUP_BUCKET
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

Shundan so'ng, zaxira nusxalarini boshqarish imkoniyati paydo bo'ladi, bu bizning holatlarimizda qo'shimcha skriptlarsiz ishlab chiqarishdan bo'laklarni etkazib berishga imkon beradigan sahnalashtirish bilan ishlashni soddalashtiradi.

Yana bir afzallik Teams API bilan ishlash va operator vositalaridan foydalangan holda ma'lumotlar bazalari va rollarni yaratish uchun keng imkoniyatlar edi. Biroq, yaratilgan rollar sukut bo'yicha hech qanday huquqqa ega emas edi. Shunga ko'ra, o'qish huquqiga ega foydalanuvchi yangi jadvallarni o'qiy olmadi.

Nega bunday? Kodeksda bo'lishiga qaramay mavjud kerak GRANT, ular har doim ham ishlatilmaydi. 2 ta usul mavjud: syncPreparedDatabases и syncDatabases. The syncPreparedDatabases - bo'limda bo'lishiga qaramay preparedDatabases mavjud sharti bor defaultRoles и defaultUsers rollarni yaratish uchun standart huquqlar qo'llanilmaydi. Biz ushbu huquqlar avtomatik ravishda qo'llanilishi uchun yamoq tayyorlamoqdamiz.

Va biz uchun tegishli bo'lgan yaxshilanishlarning oxirgi nuqtasi - yamoq, bu yaratilgan StatefulSet-ga tugun yaqinligini qo'shadi. Bizning mijozlarimiz ko'pincha spot misollardan foydalangan holda xarajatlarni kamaytirishni afzal ko'radilar va ular ma'lumotlar bazasi xizmatlarini joylashtirishga arzimaydi. Bu muammoni sabr-toqat orqali hal qilish mumkin, ammo Node Affinity mavjudligi ko'proq ishonch beradi.

Nima bo'ldi?

Yuqoridagi muammolarni hal qilish natijalariga ko'ra, biz Postgres operatorini Zalando-dan ajratib oldik sizning omboringiz, bu kabi foydali yamoqlar bilan to'plangan joyda. Va kattaroq qulaylik uchun biz ham yig'dik Docker tasviri.

Forkga qabul qilingan PRlar ro'yxati:

Agar hamjamiyat ushbu PR-larni operatorning keyingi versiyasi (1.6) bilan yuqoriga ko'tarilishi uchun qo'llab-quvvatlasa, juda yaxshi bo'ladi.

Bonus! Ishlab chiqarish migratsiyasi muvaffaqiyat tarixi

Agar siz Patroni dan foydalansangiz, jonli ishlab chiqarish operatorga minimal uzilishlar bilan ko'chirilishi mumkin.

Spilo bilan S3 saqlash orqali kutish klasterlarini yaratish imkonini beradi Val-E, PgSQL ikkilik jurnali avval S3 da saqlangan va keyin replika tomonidan pompalansa. Ammo agar mavjud bo'lsa, nima qilish kerak yo'q Wal-E tomonidan eski infratuzilmada foydalaniladimi? Bu muammoning yechimi allaqachon mavjud taklif qilindi markazda.

PostgreSQL mantiqiy replikatsiyasi yordamga keladi. Biroq, biz nashrlar va obunalarni qanday yaratish haqida batafsil ma'lumot bermaymiz, chunki ... bizning rejamiz fiasko edi.

Gap shundaki, ma'lumotlar bazasida millionlab qatorlardan iborat bir nechta yuklangan jadvallar mavjud edi, ular doimiy ravishda to'ldiriladi va o'chiriladi. Oddiy obuna с copy_data, yangi replika barcha tarkibni masterdan nusxa ko'chirganda, u oddiygina master bilan birga bo'lolmaydi. Tarkibni nusxalash bir hafta davomida ishladi, lekin hech qachon ustaga etib bormadi. Oxir-oqibat, bu menga muammoni hal qilishga yordam berdi maqola Avito hamkasblari: yordamida ma'lumotlarni uzatishingiz mumkin pg_dump. Men ushbu algoritmning (bir oz o'zgartirilgan) versiyasini tasvirlab beraman.

G'oya shundan iboratki, siz ma'lum bir replikatsiya uyasiga bog'langan o'chirilgan obunani amalga oshirishingiz va keyin tranzaksiya raqamini to'g'rilashingiz mumkin. Ishlab chiqarish ishlari uchun nusxalar mavjud edi. Bu juda muhim, chunki replika doimiy axlatni yaratishga yordam beradi va masterdan o'zgarishlarni qabul qilishni davom ettiradi.

Migratsiya jarayonini tavsiflovchi keyingi buyruqlar quyidagi xost belgilaridan foydalanadi:

usta — manba serveri;
replika 1 — eski ishlab chiqarishda striming replika;
replika 2 - yangi mantiqiy nusxa.

Migratsiya rejasi

1. Sxemadagi barcha jadvallar uchun masterda obuna yarating public bazalar dbname:

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

2. Masterda replikatsiya uyasi yarating:

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

3. Eski nusxada replikatsiyani to'xtating:

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

4. Magistrdan tranzaksiya raqamini oling:

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

5. Eski nusxadan axlatni olib tashlang. Biz buni bir nechta mavzularda qilamiz, bu jarayonni tezlashtirishga yordam beradi:

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

6. Dumpni yangi serverga yuklang:

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

7. Dumpni yuklab olgandan so'ng, siz oqimli replikada replikatsiyani boshlashingiz mumkin:

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

7. Yangi mantiqiy nusxada obuna yaratamiz:

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. Keling, olamiz oid obunalar:

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

9. Aytaylik, u qabul qilindi oid=1000. Obunaga tranzaksiya raqamini qo'llaymiz:

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

10. Replikatsiyani boshlaylik:

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

11. Obuna holatini tekshiring, replikatsiya ishlashi kerak:

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. Replikatsiya ishga tushirilgandan va ma'lumotlar bazalari sinxronlashtirilgandan so'ng, siz o'zgartirishingiz mumkin.

13. Replikatsiyani o'chirib qo'yganingizdan so'ng, ketma-ketliklarni tuzatishingiz kerak. Bu yaxshi tasvirlangan wiki.postgresql.org saytidagi maqolada.

Ushbu reja tufayli o'tish minimal kechikishlar bilan amalga oshirildi.

xulosa

Kubernetes operatorlari turli harakatlarni K8s resurslarini yaratishga qisqartirish orqali soddalashtirishga imkon beradi. Biroq, ularning yordami bilan ajoyib avtomatlashtirishga erishgandan so'ng, u bir qator kutilmagan nuanslarni ham keltirishi mumkinligini yodda tutish kerak, shuning uchun operatorlaringizni oqilona tanlang.

PostgreSQL uchun uchta eng mashhur Kubernetes operatorlarini ko'rib chiqib, biz Zalando-dan loyihani tanladik. Va biz u bilan ma'lum qiyinchiliklarni engishimiz kerak edi, lekin natija haqiqatan ham yoqimli edi, shuning uchun biz ushbu tajribani boshqa PgSQL o'rnatishlariga kengaytirishni rejalashtirmoqdamiz. Agar sizda shunga o'xshash echimlardan foydalanish tajribangiz bo'lsa, biz sharhlarda tafsilotlarni ko'rishdan xursand bo'lamiz!