Ing pungkasan taun kepungkur, siaran langsung liyane saka komunitas PostgreSQL Rusia ditindakake , sajrone co-founder Nikolai Samokhvalov ngomong karo direktur teknis Flant Dmitry Stolyarov babagan DBMS iki ing konteks Kubernetes.
Kita nerbitake transkrip saka bagean utama diskusi iki, lan ing Video lengkap dikirim:
Database lan Kubernetes
NS: Kita ora bakal ngomong babagan VACUUM lan CHECKPOINT dina iki. Kita pengin ngomong babagan Kubernetes. Aku ngerti sampeyan duwe pengalaman pirang-pirang taun. Aku nonton video sampeyan lan malah nonton maneh sawetara ... Ayo langsung menyang titik: kenapa Postgres utawa MySQL ing K8s?
DS: Ora ana lan ora bisa dadi jawaban sing pasti kanggo pitakonan iki. Nanging ing umum, iki gamblang lan penak ... potensial. Saben uwong pengin layanan sing dikelola.
NS: Kepriye , mung neng omah?
DS: Ya: kaya RDS, ing ngendi wae.
NS: "Anywhere" iku titik apik. Ing perusahaan gedhe, kabeh dumunung ing macem-macem panggonan. Yagene, yen perusahaan gedhe, ora njupuk solusi sing wis siap? Contone, Nutanix duwe pangembangan dhewe, perusahaan liyane (VMware ...) duwe "RDS, mung ing omah."
DS: Nanging kita ngomong bab implementasine kapisah sing mung bisa ing kahanan tartamtu. Lan yen kita ngomong babagan Kubernetes, mula ana macem-macem infrastruktur (sing bisa ana ing K8). Intine iki minangka standar kanggo API menyang awan ...
NS: Iki uga gratis!
DS: Ora penting banget. Kebebasan penting kanggo dudu bagean pasar sing gedhe banget. Liyane sing penting ... Sampeyan mbokmenawa kelingan laporan kasebut ""?
NS: Nggih.
DS: Aku ngerti sing ditampa banget ambigu. Sawetara wong mikir yen aku ngomong: "Guys, ayo njaluk kabeh database menyang Kubernetes!", Dene liyane mutusake yen iki kabeh pit elek. Nanging aku pengin ngomong sing beda banget: "Deleng apa sing kedadeyan, masalah apa lan kepiye carane bisa dirampungake. Apa kita kudu nggunakake database Kubernetes saiki? Produksi? Inggih, mung yen sampeyan seneng ... nindakake perkara tartamtu. Nanging kanggo dev, aku bisa ngomong yen aku nyaranake. Kanggo dev, dinamisme nggawe / mbusak lingkungan penting banget.
NS: Miturut dev, maksud sampeyan kabeh lingkungan sing ora prod? Pementasan, QA…
DS: Yen kita ngomong bab stands perf, banjur mbokmenawa ora, amarga syarat ana tartamtu. Yen kita ngomong babagan kasus khusus sing mbutuhake basis data sing gedhe banget kanggo pementasan, mesthine ora ... Yen iki minangka lingkungan statis lan tahan lama, apa gunane duwe basis data sing ana ing K8s?
NS: Ora ana. Nanging ing ngendi kita ndeleng lingkungan statis? Lingkungan statis bakal dadi lungse sesuk.
DS: Pementasan bisa statis. Kita duwe klien ...
NS: Iya, aku uga duwe. Masalah gedhe yen sampeyan duwe database 10 TB lan pementasan 200 GB ...
DS: Aku duwe kasus sing apik banget! Ing pementasan ana database produk sing owah-owahan digawe. Lan ana tombol: "muter metu kanggo produksi". Owah-owahan iki - delta - ditambahake (kayane mung disinkronake liwat API) ing produksi. Iki minangka pilihan sing endah banget.
NS: Aku wis ndeleng wiwitan ing Lembah sing lungguh ing RDS utawa malah ing Heroku - iki crita saka 2-3 taun kepungkur - lan padha ndownload dump menyang laptop. Amarga database isih mung 80 GB, lan ana papan ing laptop. Banjur padha tuku disk tambahan kanggo saben wong supaya padha duwe 3 database kanggo nindakake pembangunan beda. Iki uga kedadeyan. Aku uga weruh yen dheweke ora wedi nyalin prod menyang pementasan - gumantung banget marang perusahaan. Nanging aku uga weruh sing padha wedi banget, lan asring ora duwe cukup wektu lan tangan. Nanging sadurunge nerusake menyang topik iki, aku pengin krungu babagan Kubernetes. Apa aku ngerti kanthi bener yen durung ana sing ana ing prod?
DS: Kita duwe database cilik ing prod. Kita ngomong babagan volume puluhan gigabyte lan layanan non-kritis sing kita kesed nggawe replika (lan ora perlu). Lan kasedhiya yen ana panyimpenan normal ing Kubernetes. Database iki makarya ing mesin virtual - kondisional ing VMware, ing ndhuwur sistem panyimpenan. We diselehake ing lan saiki kita bisa nransfer saka mesin kanggo mesin.
NS: Database ukuran iki, nganti 100 GB, bisa mbalek metu ing sawetara menit ing disk apik lan jaringan apik, tengen? Kacepetan 1 GB per detik ora endah maneh.
DS: Ya, kanggo operasi linear iki ora masalah.
NS: Oke, kita mung kudu mikir babagan prod. Lan yen kita nimbang Kubernetes kanggo lingkungan non-produk, apa sing kudu ditindakake? Aku weruh ing Zalando , ing Crunchy , ana sawetara opsi liyane. Lan ana - iki kanca apik kita Alvaro saka Spanyol: apa padha nindakake iku ateges ora mung , lan distribusi kabeh (), sing, saliyane Postgres dhewe, dheweke uga mutusake nggawe serep, proxy Utusan ...
DS: Utusan napa? Ngimbangi lalu lintas Postgres khusus?
NS: Nggih. Yaiku, dheweke ndeleng: yen sampeyan njupuk distribusi lan kernel Linux, banjur PostgreSQL biasa minangka kernel, lan dheweke pengin nggawe distribusi sing ramah awan lan mbukak ing Kubernetes. Padha sijine bebarengan komponen (serep, etc.) lan debug supaya padha bisa uga.
DS: Keren banget! Intine iki piranti lunak kanggo nggawe Postgres sing dikelola dhewe.
NS: Distribusi Linux duwe masalah langgeng: carane nggawe driver supaya kabeh hardware didhukung. Lan padha duwe idea sing bakal bisa ing Kubernetes. Aku ngerti yen ing operator Zalando kita bubar ndeleng sambungan menyang AWS lan iki ora apik banget. Mesthine ora ana hubungane karo infrastruktur tartamtu - apa gunane?
DS: Aku ora ngerti persis apa kahanan Zalando tak menyang, nanging ing panyimpenan Kubernetes saiki digawe ing kuwi cara sing mokal kanggo njupuk serep disk nggunakake cara umum. Bubar ing standar - ing versi paling anyar - kita nggawe jepretan bisa, nanging ngendi iku dipun ginakaken? Jujur, kabeh isih mentahan ... Kita nyoba CSI ing ndhuwur AWS, GCE, Azure, vSphere, nanging sanalika sampeyan miwiti nggunakake, sampeyan bisa ndeleng sing durung siap.
NS: Pramila kadang kita kedah ngandelaken prasarana. Aku mikir iki isih tahap awal - rasa lara. Pitakonan: Saran apa sing bakal diwenehake kanggo wong anyar sing pengin nyoba PgSQL ing K8s? Operator apa mungkin?
DS: Masalah iku Postgres 3% kanggo kita. Kita uga duwe dhaptar piranti lunak sing beda banget ing Kubernetes, aku ora bakal dhaptar kabeh. Contone, Elasticsearch. Ana akeh operator: sawetara aktif berkembang, liyane ora. Kita wis nggawe syarat kanggo awake dhewe, apa sing kudu ana ing operator supaya bisa ditindakake kanthi serius. Ing operator khusus kanggo Kubernetes - ora ing "operator kanggo nindakake soko ing kahanan Amazon"... Nyatane, kita cukup akeh (= meh kabeh klien) nggunakake operator siji - (kita bakal nerbitake artikel babagan dheweke enggal).
NS: Lan ora kanggo MySQL uga? Aku ngerti yen Percona ... amarga saiki lagi nggarap MySQL, MongoDB, lan Postgres, dheweke kudu nggawe sawetara solusi universal: kanggo kabeh database, kanggo kabeh panyedhiya awan.
DS: Kita ora duwe wektu kanggo ndeleng operator kanggo MySQL. Iki dudu fokus utama kita saiki. MySQL bisa digunakake kanthi mandiri. Apa nggunakake operator yen sampeyan mung bisa miwiti database ... Sampeyan bisa miwiti wadhah Docker karo Postrges, utawa sampeyan bisa miwiti ing cara prasaja.
NS: Ana uga pitakonan babagan iki. Ora ana operator?
DS: Ya, 100% saka kita duwe PostgreSQL mlaku tanpa operator. Nganti saiki. Kita aktif nggunakake operator kanggo Prometheus lan Redis. Kita duwe rencana golek operator kanggo Elasticsearch - iki sing paling "kobong", amarga kita pengin nginstal ing Kubernetes ing 100% kasus. Kaya sing kita pengin mesthekake yen MongoDB uga tansah diinstal ing Kubernetes. Ing kene ana kepinginan tartamtu - ana perasaan yen ing kasus kasebut ana sing bisa ditindakake. Lan kita malah ora katon ing Postgres. Mesthi, kita ngerti manawa ana macem-macem pilihan, nanging nyatane kita duwe mandiri.
DB kanggo testing ing Kubernetes
NS: Ayo pindhah menyang topik testing. Cara ngowahi owah-owahan menyang database - saka perspektif DevOps. Ana microservices, akeh database, soko wis ganti nang endi wae kabeh wektu. Carane kanggo mesthekake CI / CD normal supaya kabeh ing urutan saka perspektif DBMS. Apa pendekatan sampeyan?
DS: Ora ana jawaban siji. Ana sawetara opsi. Sing pertama yaiku ukuran dasar sing pengin digulung. Sampeyan dhewe nyebutake manawa perusahaan duwe sikap sing beda kanggo nduwe salinan database prod ing dev lan panggung.
NS: Lan miturut kahanan GDPR, aku rumangsa luwih ati-ati ... Aku bisa ngomong yen ing Eropa wis mulai ngetrapake denda.
DS: Nanging asring sampeyan bisa nulis piranti lunak sing njupuk mbucal saka produksi lan obfuscates iku. Data prod dipikolehi (snapshot, dump, salinan binar ...), nanging dianonim. Nanging, bisa uga ana skrip generasi: iki bisa dadi perlengkapan utawa mung skrip sing ngasilake database gedhe. Masalahe yaiku: suwene wektu kanggo nggawe gambar dhasar? Lan suwene wektu kanggo nyebarake ing lingkungan sing dikarepake?
Kita teka menyang skema: yen klien duwe set data tetep (versi minimal saka database), banjur digunakake minangka standar. Yen kita ngomong babagan lingkungan review, nalika nggawe cabang, kita nyebarake conto aplikasi kasebut - kita nggawe database cilik ing kana. Nanging ternyata apik , nalika kita njupuk dump saka produksi sapisan dina (ing wengi) lan mbangun wadhah Docker karo PostgreSQL lan MySQL karo data dimuat iki adhedhasar. Yen sampeyan kudu nggedhekake database 50 kaping saka gambar iki, iki rampung cukup prasaja lan cepet.
NS: Kanthi nyalin prasaja?
DS: Data disimpen langsung ing gambar Docker. Sing. Kita duwe gambar sing wis siap, sanajan 100 GB. Thanks kanggo lapisan ing Docker, kita bisa kanthi cepet nyebarake gambar iki kaping pirang-pirang sing dibutuhake. Cara kasebut bodho, nanging kerjane apik.
NS: Banjur, nalika sampeyan nyoba, owah-owahan ing Docker, ta? Copy-on-write nang Docker - uncalan lan bali maneh, kabeh apik. Kelas! Lan sampeyan wis nggunakake kanthi lengkap?
DS: Sampun dangu.
NS: Kita nindakake perkara sing padha. Mung kita ora nggunakake copy-on-write Docker, nanging sawetara liyane.
DS: Ora umum. Lan Docker kerja ing endi wae.
NS: Ing teori, ya. Nanging kita uga duwe modul ana, sampeyan bisa nggawe modul beda lan bisa karo sistem file beda. Apa wayahe kene. Saka sisih Postgres, kita ndeleng kabeh iki kanthi beda. Saiki aku ndeleng saka sisih Docker lan ndeleng manawa kabeh bisa digunakake kanggo sampeyan. Nanging yen database ageng, contone, 1 TB, banjur kabeh iki njupuk wektu dawa: operasi ing wayah wengi, lan stuffing kabeh menyang Docker ... Lan yen 5 TB diiseni menyang Docker ... Utawa kabeh nggoleki?
DS: Apa bedane: iki blobs, mung bit lan bita.
NS: Bentenipun punika: apa sampeyan nindakake liwat dump lan mulihake?
DS: Ora perlu babar pisan. Cara kanggo ngasilake gambar iki bisa beda-beda.
NS: Kanggo sawetara klien, kita wis digawe iku supaya tinimbang ajeg ngasilaken gambar dhasar, kita terus-terusan tetep gaul. Iku ateges replika, nanging nampa data ora saka master langsung, nanging liwat arsip. Arsip binar ing ngendi WAL diundhuh saben dina, ing ngendi serep dijupuk ... WAL iki banjur tekan gambar dhasar kanthi wektu tundha sethithik (secara harfiah 1-2 detik). We clone saka iku ing sembarang cara - saiki kita duwe ZFS minangka standar.
DS: Nanging karo ZFS sampeyan diwatesi siji simpul.
NS: Nggih. Nanging ZFS uga duwe gaib : karo sampeyan bisa ngirim gambar asli seko lan malah (Aku durung nyoba tenan iki, nanging ...) sampeyan bisa ngirim delta antarane loro PGDATA. Nyatane, kita duwe alat liyane sing durung dipikirake kanggo tugas kasebut. PostgreSQL wis , sing dianggo kaya rsync "pinter", skipping akeh sing ora kudu nonton, amarga ora ana owah-owahan ana. Kita bisa nindakake sinkronisasi cepet ing antarane loro server lan mundur kanthi cara sing padha.
Dadi, saka iki, liyane DBA sisih, kita nyoba kanggo nggawe alat sing ngijini kita kanggo nindakake bab sing padha ngandika: kita duwe siji database, nanging kita pengin nyoba soko 50 kaping, meh bebarengan.
DS: 50 kaping tegese sampeyan kudu supaya 50 kedadean Spot.
NS: Ora, kita nindakake kabeh ing siji mesin.
DS: Nanging carane sampeyan bakal nggedhekake 50 kaping yen database siji iki, ngomong, terabyte. Paling kamungkinan dheweke perlu saratipun 256 GB RAM?
NS: Ya, kadhangkala sampeyan kudu akeh memori - iku normal. Nanging iki minangka conto saka urip. Mesin produksi duwe 96 intine lan 600 GB. Ing wektu sing padha, 32 intine (malah 16 intine saiki kadhangkala) lan 100-120 GB memori digunakake kanggo database.
DS: Lan 50 eksemplar pas ing kono?
NS: Dadi mung ana siji salinan, banjur copy-on-write (ZFS) dianggo ... Aku bakal pitutur marang kowe luwih rinci.
Contone, kita duwe database 10 TB. Padha digawe disk kanggo iku, ZFS uga teken ukuran 30-40 persen. Amarga kita ora nindakake tes beban, wektu nanggepi sing tepat ora penting kanggo kita: ayo nganti 2 kaping luwih alon - ora apa-apa.
We menehi kesempatan kanggo programer, QA, DBA, etc. nindakake testing ing 1-2 Utas. Contone, padha bisa nindakake sawetara jinis migrasi. Ora mbutuhake 10 intine bebarengan - butuh 1 Postgres backend, 1 inti. Migrasi bakal diwiwiti - bisa uga isih bakal miwiti, banjur inti kapindho bakal digunakake. We have 16-32 intine diparengake, supaya 10 wong bisa ing wektu sing padha, ora masalah.
Amarga fisik PGDATA padha, iku dadi metu sing kita bener ngapusi Postgres. Trik iki: contone, 10 Postgres diluncurake bebarengan. Apa masalah biasane? Padha sijine , ayo ngomong 25%. Dadi, iki 200 GB. Sampeyan ora bakal bisa miwiti luwih saka telu iki, amarga memori bakal entek.
Nanging ing sawetara titik kita nyadari yen iki ora perlu: kita nyetel shared_buffers dadi 2 GB. PostgreSQL wis , lan ing kasunyatan iku mung siji sing mengaruhi . Kita nyetel dadi 0,5 TB. Lan ora preduli yen dheweke ora ana: dheweke nggawe rencana kaya-kaya ana.
Mulane, nalika kita nyoba sawetara jinis migrasi, kita bisa ngumpulake kabeh rencana - kita bakal weruh carane iku bakal kelakon ing produksi. Detik bakal beda-beda (luwih alon), nanging data sing bener-bener diwaca, lan rencana dhewe (apa sing digabungake, lan liya-liyane) padha karo produksi. Lan sampeyan bisa mbukak akeh mriksa kuwi ing podo karo ing siji mesin.
DS: Apa sampeyan ora mikir ana sawetara masalah ing kene? Sing pertama yaiku solusi sing mung bisa digunakake ing PostgreSQL. Pendekatan iki banget pribadi, ora umum. Kapindho yaiku Kubernetes (lan kabeh teknologi maya saiki) melu akeh simpul, lan simpul kasebut ora pati jelas. Lan ing kasus sampeyan iku stateful, simpul terus-terusan. Bab-bab iki nggawe aku konflik.
NS: Kawitan, aku setuju, iki crita murni Postgres. Aku yen kita duwe sawetara jenis langsung IO lan blumbang buffer kanggo meh kabeh memori, pendekatan iki ora bisa - rencana bakal beda. Nanging saiki kita mung nggarap Postgres, kita ora mikir babagan wong liya.
Babagan Kubernetes. Sampeyan dhewe ngandhani ing endi wae yen kita duwe database sing terus-terusan. Yen conto gagal, sing utama yaiku nyimpen disk. Ing kene kita uga duwe kabeh platform ing Kubernetes, lan komponen karo Postgres kapisah (sanajan bakal ana ing sawijining dina). Mulane, kabeh kaya iki: contone ambruk, nanging kita nyimpen PV lan mung nyambungake menyang conto liyane (anyar), kaya-kaya ora ana apa-apa.
DS: Saka sudut pandangku, kita nggawe pod ing Kubernetes. K8s - elastis: knot diurutake yen perlu. Tugas iku mung nggawe polong lan ngandika yen perlu X jumlah sumber daya, banjur K8s bakal tokoh metu ing dhewe. Nanging dhukungan panyimpenan ing Kubernetes isih ora stabil: ing (rilis iki dirilis недели ago) fitur iki dadi mung beta.
Nem sasi nganti setahun bakal liwati - bakal dadi luwih utawa kurang stabil, utawa paling ora bakal diumumake. Banjur kemungkinan jepretan lan ngowahi ukuran ngrampungake masalah sampeyan kanthi lengkap. Amarga sampeyan duwe dhasar. Ya, bisa uga ora cepet banget, nanging kacepetan gumantung saka apa sing "ing hood", amarga sawetara implementasine bisa nyalin lan nyalin-tulis ing tingkat subsistem disk.
NS: Sampeyan uga perlu kanggo kabeh mesin (Amazon, Google ...) kanggo miwiti ndhukung versi iki - iki uga njupuk sawetara wektu.
DS: Kita durung nggunakake. Kita nggunakake kita.
Pangembangan lokal kanggo Kubernetes
NS: Apa sampeyan wis teka tengen kepinginan kuwi nalika sampeyan kudu nginstal kabeh pods ing siji mesin lan nindakake test cilik. Kanggo entuk bukti konsep kanthi cepet, deleng manawa aplikasi kasebut mlaku ing Kubernetes, tanpa nyediakake akeh mesin. Ana Minikube, kan?
DS: Iku misale jek kula sing kasus iki - tugasaken ing siji simpul - iku istimewa babagan pembangunan lokal. Utawa sawetara manifestasi saka pola kasebut. mangan , ana , . Kita pindhah menyang nggunakake Kubernetes IN Docker. Saiki kita miwiti nggarap kanggo tes.
NS: Aku digunakake kanggo mikir sing iki nyoba kanggo Lebokake kabeh pods ing siji gambar Docker. Nanging ternyata iki babagan sing beda banget. Oalah, ana wadhah sing kapisah, pod sing kapisah - mung ing Docker.
DS: Nggih. Lan ana imitasi sing rada lucu, nanging tegese iki ... Kita duwe sarana kanggo penyebaran - . Kita pengin nggawe mode kondisional werf up: "Entukake aku Kubernetes lokal." Lan banjur mbukak kondisional ana werf follow. Banjur pangembang bakal bisa ngowahi IDE, lan proses bakal dibukak ing sistem sing ndeleng owah-owahan lan mbangun maneh gambar, redeploying menyang K8s lokal. Iki carane kita arep nyoba kanggo ngatasi masalah pembangunan lokal.
Snapshots lan kloning database ing K8s kasunyatan
NS: Yen kita bali menyang copy-on-write. Aku ngeweruhi sing mega uga duwe jepretan. Padha bisa beda. Contone, ing GCP: sampeyan duwe conto multi-terabyte ing pesisir wétan Amerika Serikat. Sampeyan njupuk gambar kanthi periodik. Sampeyan njupuk salinan disk ing pesisir kulon saka gambar asli - ing sawetara menit kabeh wis siap, kerjane cepet banget, mung cache kudu diisi ing memori. Nanging klon kasebut (snapshots) kanggo 'nyediakake' volume anyar. Iki kelangan nalika sampeyan kudu nggawe akeh kedadean.
Nanging kanggo tes, misale jek kula sing jepretan, sing ngomong bab Docker utawa aku ngomong bab ZFS, btrfs malah LVM ... - padha ngijini sampeyan ora nggawe data tenan anyar ing siji mesin. Ing méga, sampeyan isih bakal mbayar saben wektu lan ngenteni ora sawetara detik, nanging menit (lan ing kasus , bisa uga jam tangan).
Nanging, sampeyan bisa njaluk data iki ing detik utawa loro, mbukak test lan uncalan adoh. Jepretan iki ngrampungake macem-macem masalah. Ing kasus sing sepisanan - kanggo nggedhekake lan entuk replika anyar, lan ing kaloro - kanggo tes.
DS: Aku ora setuju. Nggawe kloning volume kanthi bener minangka tugas awan. Aku wis ora katon ing implementasine, nanging aku ngerti carane kita nindakaken ing hardware. Kita duwe Ceph, ngidini volume fisik apa wae () ngomong Klone lan entuk volume kapindho kanthi karakteristik sing padha ing puluhan milidetik, 'ami, lsp. Sampeyan kudu ngerti yen ana copy-on-write sing angel ing njero. Kenging punapa awan kedahipun boten sami? Aku yakin dheweke nyoba nindakake iki kanthi cara siji utawa liyane.
NS: Nanging isih bakal njupuk sawetara detik, puluhan detik kanggo mundhakaken Kayata, nggawa Docker ana, etc.
DS: Kenapa kudu ngunggahake kabeh conto? We duwe Kayata karo 32 intine, 16 ... lan bisa pas menyang - contone, papat. Nalika kita pesen sing kaping lima, contone bakal diunggahake, banjur bakal dibusak.
NS: Ya, menarik, Kubernetes dadi crita sing beda. Database kita ora ana ing K8s, lan kita duwe siji conto. Nanging kloning database multi-terabyte njupuk ora luwih saka rong detik.
DS: Iki apik. Nanging titik awalku yaiku iki dudu solusi umum. Ya, iku kelangan, nanging mung cocok kanggo Postgres lan mung siji simpul.
NS: Iku cocok ora mung kanggo Postgres: plans iki, kaya aku diterangake, mung bakal bisa ing. Nanging yen kita ora keganggu babagan rencana, lan kita mung butuh kabeh data kanggo uji fungsional, mula iki cocog kanggo DBMS apa wae.
DS: Akeh taun kepungkur, kita nindakake sing padha ing jepretan LVM. Iki klasik. Pendekatan iki digunakake kanthi aktif. Node stateful mung nyeri. Amarga sampeyan ora kudu ngeculake, sampeyan kudu tansah eling ...
NS: Apa sampeyan ndeleng kemungkinan hibrida ing kene? Ayo dadi ngomong stateful sawetara jenis pod, iku bisa kanggo sawetara wong (akeh tester). Kita duwe volume siji, nanging amarga sistem file, klon kasebut lokal. Yen polong tiba, nanging disk tetep, polong bakal munggah, ngetung informasi babagan kabeh klon, pilih kabeh maneh lan ucapake: "Iki klon sampeyan mlaku ing port kasebut, terus nggarap."
DS: Secara teknis iki tegese ing Kubernetes iku siji pod ing ngendi kita mbukak akeh Postgres.
NS: Nggih. Dheweke duwe watesan: ayo ngomong ora luwih saka 10 wong sing kerja bareng karo dheweke ing wektu sing padha. Yen sampeyan butuh 20, kita bakal mbukak pod liya. Kita bakal clone kanthi lengkap, sawise nampa volume lengkap kaloro, bakal duwe 10 klon "tipis" sing padha. Apa sampeyan ora weruh kesempatan iki?
DS: Kita kudu nambah masalah keamanan ing kene. Organisasi jinis iki nuduhake yen pod iki nduweni hak istimewa (kapabilitas) sing dhuwur, amarga bisa nindakake operasi non-standar ing sistem file... Nanging aku mbaleni: Aku percaya yen ing jangka menengah bakal ndandani panyimpenan ing Kubernetes, lan ing awan bakal ndandani kabeh crita kanthi volume - kabeh bakal "mung bisa". Ana bakal ngowahi ukuran, kloning ... Ana volume - kita ngomong: "Gawe sing anyar adhedhasar iku," lan sawise detik lan setengah kita njaluk apa kita kudu.
NS: Aku ora pracaya siji lan setengah detik kanggo akeh terabyte. Ing Ceph sampeyan nindakake dhewe, nanging sampeyan ngomong babagan awan. Pindhah menyang méga, gawe tiron saka volume EBS multi-terabyte ing EC2 lan ndeleng apa kinerja bakal. Ora butuh sawetara detik. Aku kasengsem banget nalika dheweke bakal tekan level iki. Aku ngerti apa sing diomongake, nanging aku njaluk beda.
DS: Ok, nanging aku ngandika ing jangka menengah, ora short term. Kanggo sawetara taun.
Babagan operator kanggo PostgreSQL saka Zalando
Ing tengah rapat iki, Alexey Klyukin, mantan pangembang saka Zalando, uga melu lan ngomong babagan sejarah operator PostgreSQL:
Apik banget yen topik iki ditrapake ing umum: Postgres lan Kubernetes. Nalika kita miwiti nindakake ing Zalando ing 2017, iki minangka topik sing dikarepake kabeh wong, nanging ora ana sing nindakake. Saben uwong wis Kubernetes, nanging nalika padha takon apa apa karo database, malah wong seneng , sing martakaké K8s, ngandika kaya iki:
"Go menyang layanan sing dikelola lan gunakake, aja mbukak database ing Kubernetes. Yen ora, K8 sampeyan bakal mutusake, contone, kanggo nganyarke, mateni kabeh simpul, lan data sampeyan bakal mabur adoh, adoh banget.
Kita mutusake kanggo nggawe operator sing, bertentangan karo saran iki, bakal miwiti database Postgres ing Kubernetes. Lan kita duwe alesan sing apik - . Iki minangka failover otomatis kanggo PostgreSQL, rampung kanthi bener, yaiku. nggunakake etcd, konsul utawa ZooKeeper minangka panyimpenan saka informasi bab kluster. Repositori kasebut bakal menehi saben wong sing takon, umpamane, apa pimpinan saiki, informasi sing padha - sanajan kasunyatane kabeh wis disebarake - supaya ora ana pamisah otak. Plus kita wis kanggo dheweke.
Umumé, kabutuhan perusahaan kanggo failover otomatis muncul sawise migrasi saka pusat data hardware internal menyang méga. Awan kasebut adhedhasar solusi PaaS (Platform-as-a-Service) kepemilikan. Iku Open Source, nanging njupuk akèh karya kanggo njaluk iku munggah lan mlaku. Iku diarani .
Wiwitane, ora ana Kubernetes. Luwih tepate, nalika solusi kita dhewe wis disebarake, K8 wis ana, nanging mentahan ora cocok kanggo produksi. Iku, miturut pendapatku, 2015 utawa 2016. Ing taun 2017, Kubernetes wis dadi luwih utawa kurang diwasa-ana perlu kanggo pindhah menyang kono.
Lan kita wis duwe wadhah Docker. Ana PaaS sing nggunakake Docker. Apa ora nyoba K8s? Napa ora nulis operator sampeyan dhewe? Murat Kabilov, sing teka saka Avito, miwiti proyek kasebut kanthi inisiatif dhewe - "kanggo muter" - lan proyek kasebut "mati".
Nanging ing umum, aku pengin ngomong babagan AWS. Napa ana kode sejarah sing gegandhengan karo AWS...
Nalika sampeyan mbukak soko ing Kubernetes, sampeyan kudu ngerti sing K8s kuwi karya ing proses. Iku terus berkembang, nambah lan malah rusak saka wektu kanggo wektu. Sampeyan kudu ngati-ati kabeh owah-owahan ing Kubernetes, sampeyan kudu siyap kanggo nyilem yen ana kedadeyan lan sinau cara kerjane kanthi rinci - bisa uga luwih saka sing dikarepake. Iki, ing prinsip, ditrapake kanggo platform apa wae sing sampeyan mbukak database ...
Dadi, nalika kita nindakake statement kasebut, kita duwe Postgres mlaku ing volume eksternal (EBS ing kasus iki, amarga kita nggarap AWS). Basis data saya tambah akeh, ing sawetara titik kudu ngowahi ukurane: contone, ukuran awal EBS yaiku 100 TB, basis data saya tambah akeh, saiki kita pengin nggawe EBS 200 TB. kepriye? Ayo dadi ngomong sampeyan bisa nindakake mbucal / mulihake ing Kayata anyar, nanging iki bakal njupuk wektu dawa lan melu downtime.
Mulane, aku pengin ngowahi ukuran sing bakal nggedhekake partisi EBS banjur ngandhani sistem file supaya nggunakake spasi anyar. Lan kita nindakake, nanging ing wektu iku Kubernetes ora duwe API kanggo operasi ngowahi ukuran. Awit kita nggarap AWS, kita nulis kode kanggo API.
Ora ana sing ngalangi sampeyan nindakake perkara sing padha kanggo platform liyane. Ora ana tandha ing statement sing mung bisa mbukak ing AWS, lan ora bakal bisa digunakake ing kabeh liya. Umumé, iki minangka proyek Open Source: yen ana sing pengin nyepetake panggunaan API anyar, sampeyan olèh. mangan , narik panjalukan - tim Zalando nyoba nanggapi kanthi cepet lan ningkatake operator kasebut. Sa adoh aku ngerti, proyek ing Google Summer of Code lan sawetara inisiatif sing padha. Zalando nggarap kanthi aktif.
Bonus PS!
Yen sampeyan kasengsem ing topik PostgreSQL lan Kubernetes, mula uga elinga yen Postgres Selasa sabanjure kedadeyan minggu kepungkur, ing ngendi aku ngomong karo Nikolai Alexander Kukushkin saka Zalando. Video saka iku kasedhiya .
PPS
Waca uga ing blog kita:
- «";
- «";
- «";
- «".
Source: www.habr.com