Kubernetes için PostgreSQL Beyanlarına, Seçimlerimize ve Deneyimimize Kısa Bir Bakış

Müşteriler giderek artan bir şekilde şu talepleri alıyor: “Amazon RDS gibi ama daha ucuzunu istiyoruz”; "Bunu RDS gibi istiyoruz ama her yerde, her altyapıda." Kubernetes'te böylesine yönetilen bir çözümü uygulamak için PostgreSQL için en popüler operatörlerin (Stolon, Crunchy Data ve Zalando operatörleri) mevcut durumuna baktık ve seçimimizi yaptık.

Bu makale hem teorik açıdan (çözümlerin gözden geçirilmesi) hem de pratik açıdan (neyin seçildiği ve bunun sonucunda ne olduğu) edindiğimiz deneyimdir. Ama önce, RDS'nin potansiyel bir alternatifi için genel gereksinimlerin neler olduğunu belirleyelim...

RDS nedir

Deneyimlerimize göre, insanlar RDS hakkında konuştuğunda, yönetilen bir DBMS hizmetini kastediyorlar:

1. yapılandırması kolay;
2. anlık görüntülerle çalışma ve onlardan kurtarma becerisine sahiptir (tercihen destek ile) PİTR);
3. master-slave topolojileri oluşturmanıza olanak tanır;
4. zengin bir uzantı listesine sahiptir;
5. denetim ve kullanıcı/erişim yönetimi sağlar.

Genel olarak konuşursak, eldeki görevi gerçekleştirmeye yönelik yaklaşımlar çok farklı olabilir, ancak koşullu Ansible'ın yolu bize yakın değil. (2GIS'teki meslektaşlarımız da sonuç olarak benzer bir sonuca vardılar) onun girişimi "Postgres tabanlı bir yük devretme kümesini hızlı bir şekilde dağıtmaya yönelik bir araç." oluşturun.)

Operatörler, Kubernetes ekosistemindeki benzer sorunların çözümü için yaygın bir yaklaşımdır. "Flanta"nın teknik direktörü Kubernetes'te başlatılan veritabanlarıyla ilgili olarak onlar hakkında daha ayrıntılı olarak konuştu. damıtmakIçinde raporlarından biri.

NB: Hızlı bir şekilde basit operatörler oluşturmak için Açık Kaynak yardımcı programımıza dikkat etmenizi öneririz. kabuk operatörü. Bunu kullanarak bunu Go bilgisi olmadan, ancak sistem yöneticilerinin daha aşina olduğu yöntemlerle yapabilirsiniz: Bash, Python, vb.

PostgreSQL için birkaç popüler K8s operatörü vardır:

• Stolon;
• Crunchy Data PostgreSQL Operatörü;
• Zalando Postgres Operatörü.

Onlara daha yakından bakalım.

Operatör Seçimi

Yukarıda bahsettiğimiz önemli özelliklere ek olarak Kubernetes altyapı operasyon mühendisleri olarak biz de operatörlerden şunları bekliyorduk:

• Git'ten dağıtım ve Özel Kaynaklar;
• pod anti-afinite desteği;
• düğüm benzeşimi veya düğüm seçicinin kurulması;
• toleransların kurulumu;
• ayarlama yeteneklerinin kullanılabilirliği;
• anlaşılır teknolojiler ve hatta komutlar.

Her bir noktanın ayrıntılarına girmeden (makalenin tamamını okuduktan sonra hala sorularınız varsa yorumlarda sorun), genel olarak bu parametrelerin küme düğümlerinin uzmanlığını daha doğru bir şekilde tanımlamak için gerekli olduğunu not edeceğim. bunları belirli uygulamalar için sipariş edin. Bu şekilde performans ve maliyet açısından en uygun dengeyi yakalayabiliriz.

Şimdi PostgreSQL operatörlerinin kendilerine geçelim.

1. Stolon

stolon İtalyan şirketi Sorint.lab'dan daha önce bahsedilen rapor DBMS için operatörler arasında bir tür standart olarak kabul edildi. Bu oldukça eski bir proje: ilk halka açık sürümü Kasım 2015(!)'de gerçekleşti ve GitHub deposu neredeyse 3000 yıldız ve 40'tan fazla katkıda bulunanla övünüyor.

Gerçekten de Stolon, düşünceli mimarinin mükemmel bir örneğidir:

Bu operatörün cihazı raporda ayrıntılı olarak bulunabilir veya Proje belgeleri. Genel olarak, açıklanan her şeyi yapabildiğini söylemek yeterlidir: yük devretme, şeffaf istemci erişimi için proxy'ler, yedeklemeler... Ayrıca proxy'ler, aşağıda tartışılan diğer iki çözümden farklı olarak tek bir uç nokta hizmeti aracılığıyla erişim sağlar (her birinin iki hizmeti vardır). üsse erişiliyor).

Ancak Stolon'un Özel Kaynak yokBu nedenle Kubernetes'te DBMS örnekleri oluşturmanın "sıcak kek gibi" kolay ve hızlı olmasını sağlayacak şekilde konuşlandırılamaz. Yönetim yardımcı program aracılığıyla gerçekleştirilir stolonctl, dağıtım Helm grafiği aracılığıyla yapılır ve özel olanlar ConfigMap'te tanımlanır ve ayarlanır.

Bir yandan operatörün gerçekte bir operatör olmadığı ortaya çıkıyor (sonuçta CRD kullanmıyor). Ancak diğer yandan K8'lerdeki kaynakları uygun gördüğünüz şekilde yapılandırmanıza olanak tanıyan esnek bir sistemdir.

Özetlemek gerekirse, her veritabanı için ayrı bir grafik oluşturmak kişisel olarak bize pek uygun gelmedi. Bu nedenle alternatif aramaya başladık.

2. Sorunsuz Veri PostgreSQL Operatörü

Crunchy Data'dan OperatörGenç bir Amerikalı girişim olan , mantıklı bir alternatif gibi görünüyordu. Kamuya açık tarihi Mart 2017'deki ilk sürümle başlıyor ve o zamandan bu yana GitHub deposu 1300'ün biraz altında yıldız ve 50'den fazla katkıda bulunan kişi aldı. Eylül ayının en son sürümü Kubernetes 1.15-1.18, OpenShift 3.11+ ve 4.4+, GKE ve VMware Enterprise PKS 1.3+ ile çalışacak şekilde test edildi.

Crunchy Data PostgreSQL Operatörünün mimarisi de belirtilen gereksinimleri karşılamaktadır:

Yönetim yardımcı program aracılığıyla gerçekleşir pgoancak o da Kubernetes için Özel Kaynaklar oluşturur. Bu nedenle operatör potansiyel kullanıcılar olarak bizi memnun etti:

• CRD aracılığıyla kontrol var;
• uygun kullanıcı yönetimi (CRD yoluyla da);
• diğer bileşenlerle entegrasyon Crunchy Veri Konteyner Paketi — PostgreSQL için özel bir konteyner görüntüleri koleksiyonu ve onunla çalışmaya yönelik yardımcı programlar (pgBackRest, pgAudit, katkıda bulunan uzantılar vb. dahil).

Ancak Crunchy Data'dan operatörü kullanmaya başlama girişimleri birkaç sorunu ortaya çıkardı:

• Tolerans olasılığı yoktu - yalnızca nodeSelector sağlanmıştır.
• Durum bilgisi olan bir uygulamayı dağıtmış olmamıza rağmen, oluşturulan bölmeler Dağıtımın bir parçasıydı. StatefulSet'lerden farklı olarak Dağıtımlar disk oluşturamaz.

Son dezavantaj komik anlara yol açıyor: test ortamında tek diskle 3 replika çalıştırmayı başardık yerel depolama, operatörün 3 kopyanın çalıştığını (çalışmasalar bile) bildirmesine neden olur.

Bu operatörün bir diğer özelliği de çeşitli yardımcı sistemlerle hazır entegrasyonudur. Örneğin, pgAdmin ve pgBounce'u yüklemek kolaydır ve belgeleme önceden yapılandırılmış Grafana ve Prometheus dikkate alınır. Son olarak 4.5.0-beta1 sürümünü yayınlayın Projeyle geliştirilmiş entegrasyon ayrı olarak not edilmiştir pgMonitör, bu sayede operatör, PgSQL metriklerinin kutudan çıktığı haliyle net bir şekilde görselleştirilmesini sağlar.

Ancak Kubernetes tarafından üretilen kaynakların garip seçimi bizi farklı bir çözüm bulma ihtiyacına yöneltti.

3. Zalando Postgres Operatörü

Zalando ürünlerini uzun zamandır tanıyoruz: Zalenium kullanma deneyimimiz var ve elbette denedik patroni PostgreSQL için popüler HA çözümleridir. Şirketin yaratma yaklaşımı hakkında Postgres Operatörü yazarlarından biri olan Alexey Klyukin yayında şunları söyledi: Postgres-Salı #5ve hoşumuza gitti.

Bu makalede tartışılan en genç çözüm: ilk sürüm Ağustos 2018'de gerçekleşti. Bununla birlikte, az sayıda resmi sürüme rağmen proje uzun bir yol kat etti ve GitHub'da 1300'den fazla yıldız ve maksimum katkıda bulunan kişi sayısı (70+) ile Crunchy Data'nın çözümünün popülaritesini şimdiden aştı.

"Kaportanın altında" bu operatör zaman içinde test edilmiş çözümleri kullanıyor:

• Patroni ve oyun Sürüş için,
• WAL-E - yedeklemeler için,
• PgBouncer - bağlantı havuzu olarak.

Zalando'nun operatör mimarisi şu şekilde sunuluyor:

Operatör tamamen Özel Kaynaklar aracılığıyla yönetilir, kaplardan otomatik olarak bir StatefulSet oluşturur ve bu daha sonra bölmeye çeşitli sepetler eklenerek özelleştirilebilir. Bütün bunlar Crunchy Data'nın operatörüne kıyasla önemli bir avantajdır.

Göz önünde bulundurulan 3 seçenek arasından Zalando'nun çözümünü seçtiğimiz için, uygulama pratiğiyle birlikte aşağıda yeteneklerine ilişkin daha ayrıntılı bir açıklama sunulacaktır.

Zalando'dan Postgres Operatörü ile Pratik Yapın

Operatör dağıtımı çok basittir: Geçerli sürümü GitHub'dan indirin ve YAML dosyalarını dizinden uygulayın manifestolar. Alternatif olarak şunu da kullanabilirsiniz: operatör merkezi.

Kurulumdan sonra kurulum konusunda endişelenmelisiniz günlükler ve yedeklemeler için depolama. Bu ConfigMap aracılığıyla yapılır postgres-operator operatörü yüklediğiniz ad alanına. Depolar yapılandırıldıktan sonra ilk PostgreSQL kümenizi dağıtabilirsiniz.

Örneğin, standart konuşlandırmamız şuna benzer:

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 bildirim, formda bir sepet içeren 3 örnekten oluşan bir kümeyi dağıtır postgres_exporter, buradan uygulama ölçümlerini alıyoruz. Gördüğünüz gibi her şey çok basit ve dilerseniz tam anlamıyla sınırsız sayıda küme oluşturabilirsiniz.

dikkat etmeye değer web yönetim paneli - postgres-operatör-ui. Operatörle birlikte gelir ve kümeler oluşturmanıza ve silmenize, ayrıca operatör tarafından yapılan yedeklemelerle çalışmanıza olanak tanır.

PostgreSQL kümelerinin listesi

Yedekleme yönetimi

Bir başka ilginç özellik ise destek Ekipler API'sı. Bu mekanizma otomatik olarak oluşturur PostgreSQL'deki roller, ortaya çıkan kullanıcı adları listesine göre. API daha sonra rollerin otomatik olarak oluşturulduğu kullanıcıların bir listesini döndürmenize olanak tanır.

Sorunlar ve çözümler

Bununla birlikte, operatörün kullanımı çok geçmeden bazı önemli eksiklikleri ortaya çıkardı:

1. nodeSelector desteğinin eksikliği;
2. yedeklemelerin devre dışı bırakılamaması;
3. veritabanı oluşturma işlevini kullanırken varsayılan ayrıcalıklar görünmez;
4. Bazen belgeler eksik veya güncel değil.

Neyse ki birçoğu çözülebilir. Sondan başlayalım - sorunlar belgeler.

Büyük olasılıkla, bir yedeğin nasıl kaydedileceğinin ve yedekleme paketinin Operatör Arayüzüne nasıl bağlanacağının her zaman net olmadığı gerçeğiyle karşılaşacaksınız. Belgeler geçerken bundan bahsediyor, ancak gerçek açıklama PR:

1. bir sır saklamam gerekiyor;
2. bunu operatöre parametre olarak iletin pod_environment_secret_name operatör ayarlarının bulunduğu CRD'de veya ConfigMap'te (operatörü nasıl kurmaya karar verdiğinize bağlı olarak).

Ancak bunun şu anda mümkün olmadığı ortaya çıktı. Bu yüzden topladık operatör sürümünüz bazı ek üçüncü taraf geliştirmeleriyle birlikte. Bu konuda daha fazla bilgi için aşağıya bakın.

Yedekleme parametrelerini operatöre iletirseniz, yani - wal_s3_bucket ve AWS S3'teki anahtarlara erişin, ardından her şeyi yedekleyecek: sadece üretimde değil, aynı zamanda sahnelemede de temeller. Bu bize yakışmadı.

Operatörü kullanırken PgSQL için temel Docker sarmalayıcısı olan Spilo'nun parametrelerinin açıklamasında şu ortaya çıktı: bir parametre iletebilirsiniz WAL_S3_BUCKET boş olduğundan yedeklemeler devre dışı bırakılır. Üstelik büyük bir sevinçle buldum hazır halkla ilişkiler, bunu hemen çatalımıza kabul ettik. Şimdi eklemeniz yeterli enableWALArchiving: false PostgreSQL küme kaynağına.

Evet, 2 operatörü çalıştırarak bunu farklı şekilde yapma fırsatı vardı: biri hazırlama için (yedekleme olmadan), ikincisi üretim için. Ama bir tanesiyle yetinebildik.

Tamam, S3 için veritabanlarına erişimin nasıl aktarılacağını öğrendik ve yedekler depoya alınmaya başlandı. Yedekleme sayfalarının Operatör Arayüzü'nde çalışması nasıl sağlanır?

Operatör Arayüzüne 3 değişken eklemeniz gerekecektir:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Bundan sonra, yedeklemelerin yönetimi mümkün olacak ve bu bizim durumumuzda aşamalandırma ile çalışmayı basitleştirecek ve üretimden dilimleri ek komut dosyaları olmadan oraya teslim etmemize olanak tanıyacak.

Diğer bir avantaj ise Teams API ile çalışma ve operatör araçlarını kullanarak veritabanları ve roller oluşturmaya yönelik geniş fırsatlardı. Ancak yaratılan rollerin varsayılan olarak hiçbir hakkı yoktu. Buna göre okuma hakkına sahip bir kullanıcı yeni tabloları okuyamıyordu.

Nedenmiş? Kodda olmasına rağmen var gerekli GRANT, her zaman kullanılmazlar. 2 yöntem vardır: syncPreparedDatabases и syncDatabases. syncPreparedDatabases - bölümde olmasına rağmen preparedDatabases var bir şart var defaultRoles и defaultUsers roller oluşturmak için varsayılan haklar uygulanmaz. Bu hakların otomatik olarak uygulanabilmesi için bir yama hazırlama aşamasındayız.

Ve bizi ilgilendiren iyileştirmelerdeki son nokta - yamaoluşturulan StatefulSet'e Node Affinity ekleyen. Müşterilerimiz genellikle spot bulut sunucularını kullanarak maliyetleri düşürmeyi tercih ediyor ve bunların veritabanı hizmetlerini barındırmaya kesinlikle değmeyeceği açık. Bu sorun toleranslarla çözülebilir ancak Node Affinity'nin varlığı daha fazla güven verir.

Ne oldu

Yukarıdaki sorunları çözmenin sonuçlarına dayanarak Postgres Operatörünü Zalando'dan çatalladık. deponuz, bu kadar faydalı yamalarla toplandığı yer. Daha fazla kolaylık sağlamak için ayrıca şunları da topladık: Docker görüntüsü.

Çatala kabul edilen PR'lerin listesi:

• Docker'da operatör için güvenli, hafif bir görüntü oluşturma;
• yedeklemeleri devre dışı bırakma;
• k8s'in güncel sürümleri için kaynak sürümlerini güncelleme;
• Node Affinity'nin uygulanması.

Topluluğun bu PR'leri desteklemesi ve böylece operatörün bir sonraki sürümüyle (1.6) yukarı yönde hareket etmeleri harika olacaktır.

Bonus! Üretim geçişi başarı öyküsü

Patroni kullanıyorsanız canlı prodüksiyon, minimum kesinti süresiyle operatöre taşınabilir.

Spilo, S3 depolama aracılığıyla yedek kümeler oluşturmanıza olanak tanır. Wal-E, PgSQL ikili günlüğü ilk olarak S3'te depolandığında ve ardından kopya tarafından dışarı pompalandığında. Ama varsa ne yapmalısınız? hayır Wal-E tarafından eski altyapıda mı kullanılıyor? Bu sorunun çözümü zaten önerildi merkez üzerinde.

PostgreSQL mantıksal çoğaltması imdadımıza yetişiyor. Ancak yayınların ve aboneliklerin nasıl oluşturulacağı konusunda ayrıntılara girmeyeceğiz çünkü... planımız fiyaskoydu.

Gerçek şu ki, veritabanında milyonlarca satır içeren birkaç yüklü tablo vardı ve bunlar sürekli olarak yenileniyor ve siliniyordu. Basit abonelik с copy_data, yeni kopya ana kopyanın tüm içeriğini kopyaladığında ana kopyaya ayak uyduramaz. İçeriği kopyalamak bir hafta boyunca işe yaradı ancak ustaya asla yetişemedi. Sonunda sorunu çözmeme yardımcı oldu makale Avito'dan meslektaşlarınız: kullanarak verileri aktarabilirsiniz pg_dump. Bu algoritmanın (biraz değiştirilmiş) versiyonunu anlatacağım.

Buradaki fikir, belirli bir çoğaltma yuvasına bağlanan devre dışı bırakılmış bir abonelik oluşturabilmeniz ve ardından işlem numarasını düzeltebilmenizdir. Üretim çalışmaları için kopyalar mevcuttu. Bu önemlidir çünkü kopya tutarlı bir döküm oluşturmaya ve ana sunucudan değişiklikleri almaya devam etmeye yardımcı olacaktır.

Geçiş sürecini açıklayan sonraki komutlar aşağıdaki ana bilgisayar gösterimlerini kullanacaktır:

1. usta — kaynak sunucu;
2. kopya1 — eski prodüksiyondaki yayın kopyası;
3. kopya2 - yeni mantıksal kopya.

Taşıma planı

1. Şemadaki tüm tablolar için ana sunucuda bir abonelik oluşturun public temel dbname:

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

2. Ana bilgisayarda bir çoğaltma yuvası oluşturun:

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

3. Eski kopyada çoğaltmayı durdurun:

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

4. Master'dan işlem numarasını alın:

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

5. Dökümü eski kopyadan çıkarın. Bunu, süreci hızlandırmaya yardımcı olacak birkaç başlıkta yapacağız:

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

6. Dökümü yeni sunucuya yükleyin:

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

7. Dökümü indirdikten sonra akış kopyasında çoğaltmayı başlatabilirsiniz:

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

7. Yeni bir mantıksal kopya üzerinde abonelik oluşturalım:

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. Haydi alalım oid abonelikler:

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

9. Diyelim ki alındı oid=1000. İşlem numarasını aboneliğe uygulayalım:

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

10. Çoğaltmaya başlayalım:

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

11. Abonelik durumunu kontrol edin, çoğaltma çalışmalıdır:

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. Çoğaltma başlatıldıktan ve veritabanları senkronize edildikten sonra geçiş yapabilirsiniz.

13. Çoğaltmayı devre dışı bıraktıktan sonra dizileri düzeltmeniz gerekir. Bu iyi tanımlanmış wiki.postgresql.org'daki makalede.

Bu plan sayesinde geçiş minimum gecikmeyle gerçekleşti.

Sonuç

Kubernetes operatörleri, çeşitli eylemleri K8 kaynaklarının oluşturulmasına indirgeyerek basitleştirmenize olanak tanır. Bununla birlikte, onların yardımıyla kayda değer bir otomasyon elde ettikten sonra, bunun aynı zamanda bir takım beklenmedik nüansları da beraberinde getirebileceğini hatırlamakta fayda var; bu nedenle operatörlerinizi akıllıca seçin.

PostgreSQL için en popüler üç Kubernetes operatörünü göz önünde bulundurarak projeyi Zalando'dan seçtik. Ve bununla bazı zorlukların üstesinden gelmek zorunda kaldık, ancak sonuç gerçekten memnuniyet vericiydi, bu yüzden bu deneyimi diğer bazı PgSQL kurulumlarına genişletmeyi planlıyoruz. Benzer çözümleri kullanma deneyiminiz varsa, yorumlarda ayrıntıları görmekten memnuniyet duyarız!

PS

Blogumuzda da okuyun:

• «Veritabanları ve Kubernetes (inceleme ve video raporu)";
• «Postgres Salı #5: PostgreSQL ve Kubernetes. CI/CD. Test otomasyonu";
• «K8'lerdeki Redis operatörünü içeren bir hikaye ve bu veritabanındaki verileri analiz etmeye yönelik yardımcı programların mini incelemesi'.

Kaynak: habr.com