Pada akhir tahun lalu, siaran langsung lain komunitas Rusia PostgreSQL
#RuPostgres terjadi , di mana co-founder-nya Nikolai Samokhvalov berbicara dengan direktur teknis Flanta Dmitry Stolyarov tentang DBMS ini dalam konteks Kubernetes.
Kami menerbitkan transkrip dari badan utama diskusi ini, dan video lengkap telah diposting
di saluran YouTube komunitas :
Basis data dan Kubernet
NS : Kami tidak akan membicarakan VACUUM dan CHECKPOINTs hari ini. Kami ingin berbicara tentang Kubernetes. Saya tahu bahwa Anda memiliki pengalaman bertahun-tahun. Saya menonton video Anda dan bahkan meninjau beberapa bagian ... Mari kita mulai: mengapa Postgres atau MySQL di K8s?DS : Tidak ada jawaban tunggal untuk pertanyaan ini dan tidak mungkin. Tetapi secara umum, itu adalah kesederhanaan dan kenyamanan ... potensi. Lagi pula, semua orang menginginkan layanan yang dikelola.
NS : Suka RDS , hanya di rumah?DS : Ya: menyukai RDS, hanya di mana saja.
NS : "Di mana saja" adalah poin yang bagus. Di perusahaan besar, semuanya terletak di tempat yang berbeda. Dan mengapa, jika ini adalah perusahaan besar, jangan mengambil solusi yang sudah jadi? Misalnya, Nutanix memiliki perkembangannya sendiri, sementara perusahaan lain (VMware ...) memiliki "RDS, hanya di rumah" yang sama.DS : Tetapi kita berbicara tentang satu implementasi yang hanya akan bekerja dalam kondisi tertentu. Dan jika kita berbicara tentang Kubernetes, maka ada banyak sekali infrastruktur (yang bisa di K8). Ini pada dasarnya adalah standar untuk API ke cloud ...
NS : Gratis juga!DS : Ini tidak begitu penting. Gratis tidak penting untuk segmen pasar yang sangat besar. Hal lain yang penting ... Anda mungkin ingat laporan "
Database dan Kubernetes "?
NS : Ya.DS : Saya menyadari bahwa dia dianggap sangat ambigu. Beberapa orang berpikir bahwa saya berkata: "Teman-teman, kami pergi semua database ke Kubernet!", Sementara yang lain memutuskan bahwa mereka semua sepeda yang mengerikan. Dan saya ingin mengatakan sesuatu yang lain sama sekali: “Lihatlah apa yang terjadi, apa masalahnya dan bagaimana mereka dapat diselesaikan. Sekarang pergi pangkalan di Kubernetes? Produksi? Ya, hanya jika Anda suka ... melakukan hal-hal tertentu. Tetapi bagi dev, saya dapat mengatakan bahwa saya merekomendasikannya. Bagi dev, menciptakan / menghapus lingkungan secara dinamis sangat penting. ”
NS: By dev, maksud Anda semua lingkungan yang bukan prod? Pementasan, QA ...DS : Jika kita berbicara tentang perf stand, maka mungkin belum, karena persyaratannya spesifik di sana. Jika kita berbicara tentang kasus-kasus khusus di mana database yang sangat besar diperlukan untuk pementasan, maka mungkin tidak terlalu ... Jika ini adalah lingkungan statis, berumur panjang, lalu apa manfaatnya memiliki basis yang terletak di K8?
NS : Tidak ada. Tetapi di mana kita melihat lingkungan statis? Lingkungan statis sudah usang besok.DS : Pementasan bisa statis. Kami memiliki klien ...
NS : Ya, saya juga punya. Masalah besar adalah jika Anda memiliki basis 10 TB dan pementasan - 200 GB ...DS : Saya punya case yang sangat keren! Pada pementasan ada basis prod'ovy di mana perubahan dilakukan. Dan tombol disediakan: "mulai produksi". Perubahan ini - delta - ditambahkan (tampaknya, mereka hanya disinkronkan oleh API) dalam produksi. Ini adalah pilihan yang sangat eksotis.
NS : Saya melihat startup di Valley yang duduk di RDS, atau bahkan di Heroku - ini adalah kisah 2-3 tahun yang lalu - dan mereka mengunduh dump ke laptop mereka. Karena basisnya hanya 80 GB sejauh ini, dan ada tempat di laptop. Kemudian mereka membeli disk untuk semua orang, sehingga mereka memiliki 3 pangkalan, sehingga mereka dapat melakukan pengembangan yang berbeda. Ini juga terjadi. Saya juga melihat bahwa mereka tidak takut untuk menyalin prod ke dalam pementasan - itu sangat tergantung pada perusahaan. Tetapi dia melihat bahwa mereka sangat takut, dan seringkali mereka tidak punya cukup waktu dan tangan. Tetapi sebelum kita beralih ke topik ini, saya ingin mendengar tentang Kubernetes. Saya mengerti benar bahwa dalam prod'e sejauh ini tidak ada?DS : Kami memiliki basis kecil di prod. Kita berbicara tentang volume puluhan gigabyte dan layanan non-kritis, yang terlalu malas untuk membuat replika (dan tidak ada kebutuhan seperti itu). Dan asalkan di bawah Kubernetes ada penyimpanan normal. Basis data ini bekerja di mesin virtual - kondisional dalam VMware, di atas penyimpanan. Kami menempatkannya di
PV dan sekarang kami dapat mentransfernya dari mobil ke mobil.
NS : Pangkalan dengan ukuran ini, hingga 100 GB, pada disk yang bagus dan dengan jaringan yang bagus dapat diluncurkan dalam beberapa menit, bukan? Kecepatan 1 GB per detik tidak lagi eksotis.DS : Ya, untuk operasi linier ini bukan masalah.
NS : Oke, kita seharusnya memikirkan prod saja. Dan jika kita mempertimbangkan Kubernetes untuk lingkungan non-prod - bagaimana melakukannya? Saya melihat bahwa di Zalando mereka membuat operator , di Crunchy mereka menggergaji , ada beberapa opsi lain. Dan ada OnGres - ini adalah teman baik kami Alvaro dari Spanyol: pada kenyataannya, mereka bukan hanya operator , tetapi seluruh distribusi ( StackGres ), di mana, selain Postgres sendiri, mereka juga memutuskan untuk mendorong cadangan, utusan Utusan ...DS : Utusan untuk apa? Perimbangan lalu lintas postgres tepatnya?
NS : Ya. Yaitu, mereka melihatnya sebagai: jika Anda mengambil distribusi Linux dan kernel, maka PostgreSQL yang biasa adalah kernel, dan mereka ingin membuat distribusi yang ramah cloud dan berjalan di Kubernetes. Mereka merapat komponen (cadangan, dll.) Dan debug agar berfungsi dengan baik.DS : Sangat keren! Intinya, ini adalah perangkat lunak untuk membuat Postgres terkelola Anda.
NS : Distribusi Linux memiliki masalah abadi: cara membuat driver sehingga semua perangkat keras didukung. Dan mereka memiliki gagasan bahwa mereka akan bekerja di Kubernetes. Saya tahu bahwa di operator Zalando kami baru-baru ini melihat bola mata pada AWS dan ini tidak terlalu baik. Seharusnya tidak ada ikatan dengan infrastruktur tertentu - lalu apa gunanya?DS : Saya tidak tahu dalam situasi spesifik apa Zalando terlibat, tetapi dalam penyimpanan Kubernetes sekarang dibuat sedemikian rupa sehingga tidak mungkin untuk menghapus cadangan disk dengan cara yang umum. Baru-baru ini, standar - dalam versi terbaru dari
spesifikasi CSI - membuat kemungkinan snapshot, tetapi di mana itu diterapkan? Jujur, ini masih mentah ... Kami mencoba CSI di atas AWS, GCE, Azure, vSphere, tetapi kami mulai menggunakannya sedikit, karena Anda dapat melihat bahwa itu belum siap.
NS : Karena itu, terkadang Anda harus terikat dengan infrastruktur. Saya pikir ini masih tahap awal - masalah pertumbuhan. Pertanyaan: apa yang akan Anda rekomendasikan untuk pemula yang ingin mencoba PgSQL di K8s? Operator yang mana mungkin?DS : Masalahnya bagi kami Postgres adalah 3%. Kami masih memiliki daftar perangkat lunak yang sangat besar di Kubernetes, saya bahkan tidak akan menuliskan semuanya. Misalnya, Elasticsearch. Ada banyak operator: ada yang berkembang aktif, ada yang tidak. Bagi kami sendiri, kami membuat persyaratan yang harus ada di operator, sehingga kami menganggapnya serius. Operator ini khusus untuk Kubernetes - bukan “operator untuk melakukan sesuatu dalam kondisi Amazon ..." Faktanya, kami menggunakan satu operator yang cukup luas (= untuk hampir semua klien) -
untuk Redis (kami akan segera menerbitkan artikel tentang hal itu) .
NS : Tapi untuk MySQL juga? Saya tahu Percona ... karena mereka sekarang terlibat dalam MySQL, MongoDB, dan Postgres, mereka harus memiliki semacam universal gash: untuk semua database, untuk semua penyedia cloud.DS : Kami tidak punya waktu untuk melihat pernyataan untuk MySQL. Bagi kami, ini bukan fokus utama sekarang. MySQL berfungsi dengan baik di standalone. Mengapa operator, jika Anda baru saja memulai database ... Anda dapat memulai wadah Docker dengan Postrges, atau Anda dapat memulainya dengan cara yang sederhana.
NS : Ini juga pertanyaan. Tidak ada operator sama sekali?DS : Ya, 100% dari kita menjalankan PostgreSQL tanpa operator. Sejauh ini. Kami secara aktif menggunakan operator untuk Prometheus, untuk Redis. Kami memiliki rencana untuk menemukan operator untuk Elasticsearch - ini yang paling terbakar karena kami ingin menginstalnya dalam 100% kasus di Kubernetes. Sama seperti kami ingin memastikan bahwa MongoDB selalu diinstal di Kubernetes juga. Daftar Keinginan tertentu muncul di sini - ada perasaan bahwa dalam kasus ini sesuatu dapat dilakukan. Dan tentang Postgres kami bahkan tidak melihat. Tentu saja, kita tahu tentang adanya opsi yang berbeda, tetapi sebenarnya kita memiliki standalone.
Menguji Basis Data di Kubernetes
NS : Mari kita beralih ke topik pengujian. Cara meluncurkan perubahan dalam database - dari sudut pandang perspektif DevOps. Ada layanan microser, banyak database, sepanjang waktu sesuatu berubah. Cara memastikan CI / CD normal sehingga semuanya dalam urutan dari posisi DBMS. Apa pendekatanmu?DS : Tidak ada jawaban. Ada beberapa opsi. Yang pertama adalah ukuran dasar yang ingin kita roll out. Anda sendiri menyebutkan bahwa perusahaan memiliki sikap yang berbeda untuk memiliki salinan basis produk pada dev dan stage.
NS : Dan dalam hal GDPR, saya pikir mereka semakin rapi ... Saya dapat mengatakan bahwa di Eropa mereka sudah mulai baik-baik saja.DS : Tetapi Anda sering dapat menulis perangkat lunak yang membuang produksi dan mengaburkannya. Ternyata data prod'ovye (snapshot, dump, binary copy ...), tetapi mereka anonim. Sebagai gantinya, mungkin ada skrip generasi: bisa berupa skrip atau hanya skrip yang menghasilkan basis data besar. Masalahnya adalah apa: berapa lama gambar dasar diperlukan untuk dibuat? Dan berapa banyak waktu untuk menggunakannya di lingkungan yang tepat?
Kami sampai pada skema: jika klien memiliki dataset fixture (versi minimum dari database), maka secara default kami menggunakannya. Jika kita berbicara tentang lingkungan ulasan, ketika kita membuat cabang, kita telah menggunakan contoh aplikasi - kita meluncurkan basis data kecil di sana. Tapi
pilihannya ternyata baik, ketika kita membuang dump dari produksi sekali sehari (pada malam hari) dan mengumpulkan atas dasar wadah Docker dengan PostgreSQL dan MySQL dengan data yang dimuat ini. Jika Anda perlu menggunakan basis 50 kali dari gambar ini, ini dilakukan cukup sederhana dan cepat.
NS : Menyalin sederhana?DS : Data disimpan langsung di gambar Docker. Yaitu kami memiliki gambar yang sudah jadi, meskipun 100 GB. Berkat lapisan di Docker, kami dapat dengan cepat menyebarkan gambar ini sebanyak yang diperlukan. Metodenya bodoh, tetapi berhasil dengan cukup baik.
NS : Lebih lanjut, saat pengujian, itu berubah tepat di dalam Docker, kan? Copy-on-write di dalam Docker - membuangnya dan pergi lagi, semuanya baik-baik saja. Kelas! Dan Anda sudah menggunakannya dengan kekuatan dan main?DS : Untuk waktu yang lama.
NS : Kami melakukan hal yang sangat mirip. Hanya kami tidak menggunakan copy-on-write Docker, tetapi beberapa lagi.JS : Dia bukan generik. Dan Docker'ny bekerja di mana-mana.
NS : Secara teori, ya. Tetapi kami juga memiliki modul di sana, Anda dapat membuat berbagai modul dan bekerja dengan sistem file yang berbeda. Beberapa saat. Dari Postgres, kami melihat semua ini secara berbeda. Sekarang saya melihat dari sisi Docker dan melihat bahwa semuanya bekerja untuk Anda. Tetapi jika database sangat besar, misalnya, 1 TB, maka ini semua panjang: baik operasi di malam hari dan segala sesuatu di Docker ... Dan jika 5 TB diisi di Docker ... Atau apakah semuanya normal?DS : Apa bedanya: itu gumpalan, hanya bit dan byte.
NS : Perbedaannya adalah ini: apakah Anda melakukan ini melalui dump dan restore?DS : Sama sekali tidak perlu. Metode untuk menghasilkan gambar ini bisa berbeda.
NS : Untuk beberapa klien, kami membuatnya sehingga alih-alih secara teratur menghasilkan gambar dasar, kami terus memperbaruinya. Ini pada dasarnya adalah replika, tetapi data tidak diterima langsung dari master, tetapi melalui arsip. Arsip biner, tempat WAL digulirkan setiap hari, cadangan juga dihapus di sana ... WAL ini kemudian terbang - dengan sedikit penundaan (harfiah 1-2 detik) - ke gambar dasar. Kami mengkloningnya dengan cara apa pun - sekarang kami memiliki ZFS secara default.DS : Tetapi dengan ZFS Anda terbatas pada satu simpul.
NS : Ya. Tetapi ZFS juga memiliki pengiriman ajaib: Anda dapat mengirim snapshot dengannya dan bahkan (saya belum benar-benar mengujinya, tapi ...) Anda dapat mengirim delta antara dua PGDATA . Faktanya, kami memiliki alat lain yang tidak kami pertimbangkan secara khusus untuk tugas-tugas tersebut. PostgreSQL memiliki pg_rewind , yang berfungsi sebagai rsync "pintar", melewatkan banyak hal yang tidak perlu Anda tonton, karena tidak ada yang berubah di sana pasti. Kita dapat melakukan sinkronisasi cepat antara dua server dan mundur dengan cara yang persis sama.Jadi, kami mencoba ini, lebih banyak DBA'noy, pihak untuk membuat alat yang memungkinkan Anda untuk melakukan hal yang sama seperti yang Anda katakan: kami memiliki satu basis, tetapi kami ingin menguji sesuatu 50 kali, hampir pada saat yang sama.DS : 50 kali berarti Anda perlu memesan 50 instance Spot.
NS : Tidak, kami melakukan semuanya dengan satu mesin.DS : Tapi bagaimana Anda menggunakan 50 kali jika basis yang satu ini, katakanlah, satu terabyte. Kemungkinan besar dia membutuhkan 256 GB RAM bersyarat?
NS : Ya, kadang-kadang banyak memori diperlukan - ini normal. Tapi contoh seperti itu dari kehidupan. Mesin produksi memiliki 96 core dan 600 GB. Pada saat yang sama, 32 core digunakan untuk database (bahkan 16 core kadang-kadang sekarang digunakan) dan memori 100-120 GB.DS : Dan 50 salinan ada di sana?
NS : Jadi hanya ada satu salinan, lalu copy-on-write (ZFS'ny) berfungsi ... Saya akan memberi tahu Anda lebih banyak.Misalnya, kami memiliki basis 10 TB. Mereka membuat disk untuk itu, ZFS masih diperas ukurannya 30-40. Karena kami tidak melakukan pengujian beban, waktu respons yang tepat tidak penting bagi kami: biarkan hingga 2 kali lebih lambat - tidak apa-apa.Kami mengaktifkan programmer, QA, DBA, dll. Lakukan pengujian dalam 1-2 utas. Misalnya, mereka dapat memulai beberapa jenis migrasi. Tidak memerlukan 10 core sekaligus - perlu 1 postgres backend, 1 core. Migrasi akan dimulai - mungkin autovacuum masih akan mulai, kemudian inti kedua diaktifkan. Kami telah mengalokasikan 16-32 core, sehingga 10 orang dapat bekerja secara bersamaan, tidak ada masalah.Karena PGDATA fisik sama, ternyata kita sebenarnya membodohi Postgres. Kuncinya adalah ini: dimulai, misalnya, 10 Postgres pada saat yang sama. Masalah apa biasanya apa? Mereka menempatkan shared_buffers , katakanlah, 25%. Dengan demikian, ini adalah 200 GB. Anda tidak akan memulai lebih dari tiga, karena memori akan berakhir.Tetapi pada titik tertentu kami menyadari bahwa ini tidak perlu: kami menetapkan shared_buffers ke 2 GB. PostgreSQL memiliki efektif_cache_size, dan pada kenyataannya hanya memengaruhi rencana . Kami menempatkannya di 0,5 Tb. Dan itu tidak masalah bahwa mereka tidak benar-benar ada: dia membuat rencana seolah-olah mereka ada.Karena itu, ketika kami menguji beberapa jenis migrasi, kami dapat mengumpulkan semua rencana - kami akan melihat bagaimana itu akan terjadi dalam produksi. Detik akan ada yang berbeda (lebih lambat), tetapi data yang benar-benar kita baca, dan rencana itu sendiri (seperti BERGABUNG, dll.) Diperoleh persis sama seperti pada produksi. Dan secara paralel, Anda dapat menjalankan banyak pemeriksaan ini pada satu mesin.DS : Apakah menurut Anda ada beberapa masalah? Yang pertama adalah solusi yang hanya berfungsi pada PostgreSQL. Pendekatan ini sangat pribadi, tidak generik. Yang kedua - Kubernetes (dan di situlah cloud sekarang) melibatkan banyak node, dan node-node ini bersifat fana. Dan dalam kasus Anda itu adalah node persisten stateful. Hal-hal ini bertentangan dengan saya.
NS : Pertama - Saya setuju, ini murni cerita Postgres. Saya pikir jika kita memiliki IO langsung dan buffer pool untuk hampir semua memori, pendekatan ini tidak akan berhasil - akan ada rencana yang berbeda. Tetapi kami hanya bekerja dengan Postgres untuk saat ini, kami tidak memikirkan orang lain.Tentang Kubernetes. Anda sendiri selalu mengatakan bahwa kami memiliki basis yang gigih. Jika instance crash, hal utama adalah menyimpan disk. Di sini kita juga memiliki seluruh platform di Kubernetes, dan komponen dengan Postgres terpisah (walaupun suatu hari akan ada di sana). Karena itu, semuanya begitu: instance jatuh, tetapi kami menyimpannya PV dan hanya terhubung ke instance (baru) lainnya, seolah-olah tidak ada yang terjadi.DS : Dari sudut pandang saya, kami membuat pod di Kubernetes. K8s - elastic: komponen dipesan sendiri sesuai kebutuhan. Tugasnya adalah hanya membuat pod dan mengatakan bahwa ia membutuhkan sumber daya X, dan kemudian K8 akan mengetahuinya. Tetapi dukungan penyimpanan di Kubernetes masih tidak stabil: di
1.16 , di
1.17 (rilis ini dirilis
minggu lalu), fitur-fitur ini hanya menjadi beta.
Enam bulan atau satu tahun akan berlalu - itu akan menjadi lebih atau kurang stabil, atau setidaknya akan dinyatakan demikian. Maka kemungkinan snapshot dan ukurannya sudah menyelesaikan masalah Anda sepenuhnya. Karena Anda punya basis. Ya, ini mungkin tidak terlalu cepat, tetapi kecepatan tergantung pada apa yang "di bawah tenda," karena beberapa implementasi dapat menyalin dan menyalin pada tingkat subsistem disk.
NS : Juga penting bagi semua mesin (Amazon, Google ...) untuk mulai mendukung versi ini - itu juga membutuhkan waktu.DS : Meskipun kami tidak menggunakannya. Kami menggunakan milik kami.
Pengembangan lokal di bawah Kubernetes
NS : Pernahkah Anda menemukan Wishlist seperti itu ketika Anda perlu menaikkan semua pod pada satu mesin dan melakukan sedikit pengujian. Untuk mendapatkan bukti konsep dengan cepat, lihat bahwa aplikasi berfungsi di Kubernetes, tanpa mengalokasikan banyak mesin untuknya. Apakah ada Minikube, kan?DS : Bagi saya kasus ini - menyebar pada satu node - secara eksklusif tentang pengembangan lokal. Atau beberapa manifestasi dari pola semacam itu. Ada
Minikube , ada
k3 ,
JENIS . Kita akan menggunakan Kubernetes IN Docker. Sekarang mereka mulai bekerja dengannya untuk tes.
NS : Dulu saya berpikir bahwa ini adalah upaya untuk membungkus semua pod dalam satu gambar Docker. Tapi ternyata ini tentang hal lain. Pokoknya, ada wadah yang terpisah, pod yang terpisah - hanya di Docker.DS : Ya. Dan ada tiruan yang agak lucu dilakukan, tetapi intinya adalah ... Kami memiliki alat penyebaran -
werf . Kami ingin membuat mode di dalamnya - dengan syarat tidak
werf up : "Naikkan saya Kubernet lokal". Dan kemudian jalankan
werf follow bersyarat
werf follow . Kemudian pengembang akan dapat mengedit dalam IDE, dan sebuah proses diluncurkan dalam sistem yang melihat perubahan dan menyusun kembali gambar, mengubahnya menjadi K8 lokal. Jadi kami ingin mencoba menyelesaikan masalah pembangunan lokal.
Snapshots dan kloning basis data dalam realitas K8s
NS : Jika Anda kembali ke copy-on-write. Saya perhatikan bahwa awan juga memiliki foto. Mereka bekerja secara berbeda. Misalnya, di GCP: Anda memiliki instance multi-terabyte di pantai timur Amerika Serikat. Anda melakukan snapshot secara berkala. Anda mengambil salinan disk di pantai barat dari sebuah snapshot - dalam beberapa menit semuanya sudah siap, ia bekerja sangat cepat, hanya cache yang perlu diisi dalam memori. Tapi klon ini (snapshot) - untuk 'ketentuan' itu volume baru. Ini bagus ketika Anda perlu membuat banyak contoh.Tetapi untuk tes, menurut saya, snapshot yang Anda bicarakan di Docker atau yang saya bicarakan di ZFS, btrfs dan bahkan LVM ... - mereka memungkinkan Anda untuk tidak membuat data yang benar-benar baru pada mesin yang sama. Di awan, Anda masih harus membayar untuk mereka setiap waktu dan menunggu bukan menit, tetapi menit (dan dalam kasus beban malas , mungkin berjam-jam).Alih-alih, Anda bisa mendapatkan data ini dalam satu atau dua detik, uji coba dan buang. Snapshots ini memecahkan masalah yang berbeda. Dalam kasus pertama - untuk skala dan mendapatkan replika baru, dan yang kedua - untuk tes.DS : Saya tidak setuju. Volume kloning biasanya adalah tugas cloud. Saya tidak melihat implementasi mereka, tetapi saya tahu bagaimana kami melakukannya pada perangkat keras. Kami memiliki Ceph, di dalamnya Anda dapat memberi tahu volume fisik apa pun (
RBD ) untuk
dikloning dan mendapatkan volume kedua dengan karakteristik yang sama,
IOPS , dll., Dalam puluhan milidetik. Anda harus memahami bahwa ada copy-on-write yang rumit di dalamnya. Mengapa cloud tidak melakukan hal yang sama? Saya yakin mereka entah bagaimana mencoba melakukan ini.
NS : Tetapi mereka masih akan membutuhkan detik, puluhan detik untuk meningkatkan instance, membawa Docker ke sana, dll.DS : Mengapa perlu mengangkat seluruh instance? Tapi kami memiliki instance untuk 32 core, untuk 16 ... dan entah bagaimana cocok ke dalamnya - misalnya, empat. Saat kami memesan yang kelima, instance akan naik, dan kemudian akan dihapus.
NS : Ya, yang menarik, Kubernetes memiliki cerita yang berbeda. Database kami tidak dalam K8s, dan satu contoh. Tetapi mengkloning basis data multi-terabyte tidak lebih dari dua detik.DS : Itu keren. Tetapi pesan awal saya adalah ini bukan solusi umum. Ya, itu keren, tetapi hanya Postgres yang cocok dan hanya pada satu node.
NS : Sangat cocok tidak hanya untuk Postgres: rencana-rencana ini, seperti yang saya jelaskan, hanya akan berfungsi seperti itu. Tetapi jika Anda tidak repot dengan rencana, tetapi kami hanya membutuhkan semua data untuk pengujian fungsional, maka ini cocok untuk DBMS apa pun.DS : Bertahun-tahun lalu kami melakukan ini pada snapshot LVM. Ini klasik. Pendekatan ini telah sangat aktif digunakan. Hanya node stateful yang menyakitkan. Karena mereka tidak perlu dijatuhkan, selalu ingat tentang mereka ...
NS : Apakah Anda melihat kemungkinan hibrida di sini? Katakanlah stateful adalah semacam pod, ini berfungsi untuk beberapa orang (banyak penguji). Kami memiliki satu volume, tetapi berkat sistem file, klon adalah lokal. Jika pod jatuh, disk tetap - pod naik, ia mempertimbangkan informasi tentang semua klon, mengembalikan semuanya dan berkata: "Ini klon Anda di port ini, mulai bekerja dengan mereka lebih jauh."DS : Secara teknis, ini berarti bahwa di dalam Kubernetes, ini adalah satu pod, di dalamnya kita menjalankan banyak Postgres.
NS : Ya. Dia memiliki batas: misalkan, pada saat yang sama, tidak lebih dari 10 orang bekerja dengannya. Jika Anda membutuhkan 20 - jalankan pod seperti kedua. Kloning sepenuhnya realistis, setelah menerima volume penuh kedua, itu akan memiliki 10 klon "tipis" yang sama. Tidak melihat peluang seperti itu?DS : Kami harus menambahkan masalah keamanan di sini. Opsi organisasi semacam itu menyiratkan bahwa pod ini memiliki kemampuan tinggi karena dapat melakukan operasi non-standar pada sistem file ... Tapi saya ulangi: Saya percaya bahwa dalam jangka menengah, penyimpanan akan diperbaiki di Kubernetes, keseluruhan cerita dengan volume akan diperbaiki di awan. - semuanya akan "hanya berfungsi." Ini akan mengubah ukuran, mengkloning ... Ada volume - kita katakan: "Buat yang baru berdasarkan itu" - dan setelah satu setengah detik kita mendapatkan apa yang kita butuhkan.
NS : Saya tidak percaya dalam satu setengah detik untuk banyak terabyte. Di Ceph, Anda melakukannya sendiri, dan berbicara tentang awan. Pergi ke cloud, di EC2, buat klon volume EBS banyak terabyte dan lihat bagaimana kinerjanya. Tidak butuh beberapa detik. Saya sangat tertarik ketika mereka mencapai indikator seperti itu. Saya mengerti apa yang Anda bicarakan, tetapi biarkan saya tidak setuju.DS : Ok, tapi saya katakan dalam jangka menengah, bukan jangka pendek. Selama beberapa tahun.
Operator pro untuk PostgreSQL dari Zalando
Di tengah pertemuan ini, Alexey Klyukin, mantan pengembang dari Zalando, yang berbicara tentang sejarah operator PostgreSQL, juga bergabung dengannya:
Sangat menyenangkan bahwa secara umum topik ini disentuh: Postgres dan Kubernetes. Ketika kami mulai melakukannya di Zalando pada 2017, itu adalah topik yang ingin dilakukan semua orang, tetapi tidak ada yang melakukannya. Semua orang sudah memiliki Kubernetes, tetapi ketika ditanya apa yang harus dilakukan dengan database, bahkan orang-orang seperti Kelsey Hightower yang memberitakan K8 mengatakan sesuatu seperti ini:
"Pergi ke layanan yang dikelola dan menggunakannya, jangan memulai database di Kubernetes. Kalau tidak, K8 Anda akan memutuskan, misalnya, untuk memutakhirkan, mengeluarkan semua node, dan data Anda akan terbang jauh, jauh sekali. "
Kami memutuskan untuk membuat operator yang, berlawanan dengan saran ini, akan meluncurkan database Postgres di Kubernetes. Dan kami memiliki fondasi yang bagus - Patroni . Ini adalah failover otomatis untuk PostgreSQL, dilakukan dengan benar, mis. menggunakan etcd, consul atau ZooKeeper sebagai repositori untuk informasi cluster. Repositori yang akan diberikan kepada semua orang yang bertanya, misalnya, pemimpin seperti apa sekarang, informasi yang sama - terlepas dari kenyataan bahwa kita telah mendistribusikan semuanya - sehingga tidak ada otak yang terpisah. Plus, kami memiliki gambar Docker untuknya.
Secara umum, kebutuhan untuk failover otomatis di perusahaan muncul setelah migrasi dari pusat data besi internal ke cloud. Cloud didasarkan pada solusi kepemilikan PaaS (Platform-as-a-Service). Ini adalah Open Source, tetapi untuk meningkatkannya, Anda harus bekerja keras. Itu disebut STUPS .
Awalnya, tidak ada Kubernet. Lebih tepatnya, ketika solusi sendiri dikerahkan, K8 sudah, tetapi sangat kasar sehingga tidak cocok untuk produksi. Itu menurut saya, 2015 atau 2016. Pada 2017, Kubernet menjadi lebih atau kurang matang - ada kebutuhan untuk bermigrasi di sana.
Dan kami sudah memiliki wadah buruh pelabuhan. Ada PaaS yang menggunakan Docker. Mengapa tidak mencoba K8? Mengapa tidak menulis pernyataan Anda sendiri? Murat Kabilov, yang datang kepada kami dari Avito, memulai ini sebagai proyek atas inisiatifnya sendiri - "bermain" - dan proyek "lepas landas".
Tetapi secara umum, saya ingin berbicara tentang AWS. Mengapa ada kode terkait AWS secara historis ...
Ketika Anda menjalankan sesuatu di Kubernetes, Anda perlu memahami bahwa K8 adalah pekerjaan yang sedang berjalan. Itu terus berkembang, meningkat dan bahkan secara berkala pecah. Anda perlu memonitor semua perubahan di Kubernet dengan hati-hati, Anda harus siap untuk membenamkan diri di dalamnya, dan mencari tahu cara kerjanya secara detail - mungkin lebih dari yang Anda inginkan. Pada prinsipnya, ini adalah platform apa pun di mana Anda menjalankan basis data ...
Jadi, ketika kami melakukan pernyataan, kami memiliki Postgres, yang bekerja dengan volume eksternal (dalam hal ini, EBS, sejak kami bekerja di AWS). Basis data tumbuh, pada beberapa titik itu perlu untuk mengubah ukuran: misalnya, ukuran asli EBS adalah 100 TB, basis data telah berkembang, sekarang kami ingin membuat EBS dalam 200 TB. Bagaimana? Misalkan Anda dapat melakukan dump / restore ke instance baru, tetapi ini lama dan dengan downtime.
Oleh karena itu, saya ingin mengubah ukuran yang akan memperluas partisi EBS dan kemudian memberitahu sistem file untuk menggunakan ruang baru. Dan kami melakukannya, tetapi pada saat itu Kubernetes tidak memiliki API untuk operasi pengubahan ukuran. Karena kami bekerja pada AWS, kami menulis kode untuk API-nya.
Tidak ada yang mau melakukan hal yang sama untuk platform lain. Tidak ada komplikasi dalam pernyataan bahwa itu hanya dapat dijalankan pada AWS, dan itu tidak akan bekerja pada yang lainnya. Secara umum, ini adalah proyek Open Source: jika ada yang ingin mempercepat kemunculan penggunaan API baru, kami dipersilakan. Ada GitHub , tarik-permintaan - tim Zalando berusaha untuk dengan cepat merespons mereka dan mempromosikan operator. Sejauh yang saya tahu, proyek ini berpartisipasi dalam Google Summer of Code dan beberapa inisiatif serupa lainnya. Zalando sangat aktif di dalamnya.
Bonus PS!
Jika Anda tertarik dengan topik PostgreSQL dan Kubernetes, maka kami juga menarik perhatian pada fakta bahwa minggu lalu Postgres berikutnya terjadi, di mana
Alexander Kukushkin dari Zalando berbicara dengan Nikolai. Video darinya tersedia di
sini .
PPS
Baca juga di blog kami: