Cathetan. nerjemahake.: materi iki saka proyek pendidikan minangka jawaban kanggo pitakonan populer nalika ngrancang infrastruktur basis Kubernetes. Muga-muga deskripsi sing cukup rinci babagan pro lan kontra saben pilihan bakal mbantu sampeyan nggawe pilihan sing paling apik kanggo proyek sampeyan.
TL; DR: pesawat padha saka workloads bisa mbukak ing sawetara klompok gedhe (saben kluster bakal duwe nomer akeh workloads) utawa ing akeh cilik (karo nomer cilik saka kathah ing saben kluster).
Ing ngisor iki ana tabel sing ngevaluasi pro lan kontra saben pendekatan:
Nalika nggunakake Kubernetes minangka platform kanggo mbukak aplikasi, sawetara pitakonan dhasar asring muncul babagan kerumitan nyetel kluster:
- Carane akeh kluster aku kudu nggunakake?
- Carane gedhe aku kudu nggawe wong?
- Apa sing kudu kalebu saben kluster?
Ing artikel iki, aku bakal nyoba mangsuli kabeh pitakonan kasebut kanthi nganalisa pro lan kontra saben pendekatan.
Pratelan pitakon
Minangka pangembang piranti lunak, sampeyan bisa uga ngembangake lan ngoperasikake akeh aplikasi ing wektu sing padha.
Kajaba iku, akeh kasus aplikasi kasebut sing bisa digunakake ing lingkungan sing beda - contone, iki bisa uga dev, test и produk.
Asil kasebut minangka matriks kabeh aplikasi lan lingkungan:
Aplikasi lan Lingkungan
Conto ing ndhuwur nggantosi 3 aplikasi lan 3 lingkungan, asil ing total 9 opsi bisa.
Saben conto aplikasi minangka unit panyebaran mandiri sing bisa digarap kanthi mandiri saka wong liya.
elinga yen contone aplikasi bisa dumadi saka akeh komponen, kayata frontend, backend, database, lsp. Ing kasus aplikasi microservices, contone bakal kalebu kabeh microservices.
Akibaté, pangguna Kubernetes duwe sawetara pitakonan:
- Apa kabeh conto aplikasi kudu diselehake ing siji kluster?
- Apa worth duwe kluster kapisah kanggo saben conto aplikasi?
- Utawa mbok menawa kombinasi saka pendekatan ing ndhuwur kudu digunakake?
Kabeh opsi iki cukup sregep, amarga Kubernetes minangka sistem fleksibel sing ora mbatesi kemampuan pangguna.
Ing ngisor iki sawetara cara sing bisa ditindakake:
- siji kluster umum gedhe;
- akeh klompok cilik sing khusus banget;
- siji kluster saben aplikasi;
- siji kluster saben lingkungan.
Kaya sing dituduhake ing ngisor iki, rong pendekatan pisanan ana ing ujung-ujung skala pilihan:
Saka sawetara klompok gedhe (kiwa) nganti akeh cilik (tengen)
Umumé, siji kluster dianggep "luwih gedhe" tinimbang liyane yen nduweni jumlah simpul lan polong sing luwih gedhe. Contone, kluster kanthi 10 simpul lan 100 polong luwih gedhe tinimbang kluster kanthi 1 simpul lan 10 polong.
Inggih, ayo padha miwiti!
1. Siji cluster umum gedhe
Opsi pisanan yaiku nyelehake kabeh beban kerja ing siji kluster:
Siji kluster gedhe
Ing pendekatan iki, kluster digunakake minangka universal platform infrastruktur - sampeyan mung masang kabeh sing perlu ing kluster Kubernetes ana.
Kubernetes ngidini bagean saka kluster bisa dipisahake kanthi logis saka saben liyane, supaya saben conto aplikasi bisa duwe ruang jeneng dhewe.
Ayo goleki pro lan kontra saka pendekatan iki.
+ Panggunaan sumber daya sing efisien
Kanthi kluster siji, sampeyan mung butuh siji salinan kabeh sumber daya sing dibutuhake kanggo mbukak lan ngatur kluster Kubernetes.
Contone, iki bener kanggo simpul master. Biasane, saben kluster Kubernetes duwe 3 simpul master, mula kanggo siji kluster nomere tetep kaya ngono (kanggo mbandhingake, 10 kluster mbutuhake 30 simpul master).
Subtlety ing ndhuwur uga ditrapake kanggo layanan liyane sing beroperasi ing kabeh kluster, kayata penyeimbang beban, pengontrol Ingress, otentikasi, logging lan sistem pemantauan.
Ing kluster siji, kabeh layanan kasebut bisa digunakake bebarengan kanggo kabeh beban kerja (ora perlu nggawe salinan, kaya sing ana ing pirang-pirang klompok).
+ Murah
Minangka akibat saka ndhuwur, kluster luwih sithik biasane luwih murah amarga ora ana biaya overhead.
Iki utamané bener kanggo kelenjar master, kang bisa biaya jumlah pinunjul saka dhuwit preduli saka carane padha tuan rumah (ing-premis utawa ing méga).
Sawetara layanan Kubernetes sing dikelola, kayata utawa , nyedhiyakake lapisan kontrol kanthi gratis. Ing kasus iki, masalah biaya kurang akut.
Ana uga layanan sing ngatur sing ngisi ragad tetep kanggo operasi saben kluster Kubernetes (contone, ).
+ Administrasi sing efisien
Ngatur siji kluster luwih gampang tinimbang ngatur sawetara.
Administrasi bisa kalebu tugas ing ngisor iki:
- Nganyari versi Kubernetes;
- nyetel pipa CI/CD;
- nginstal plugin CNI;
- nyetel sistem otentikasi pangguna;
- instalasi saka kontrol akses;
lan akeh liyane…
Ing kasus siji kluster, sampeyan kudu nindakake kabeh iki mung sapisan.
Kanggo akeh klompok, operasi kudu diulang kaping pirang-pirang, sing mbutuhake sawetara proses lan alat otomatisasi kanggo njamin konsistensi lan konsistensi ing proses kasebut.
Lan saiki sawetara tembung babagan kontra.
− Titik kegagalan tunggal
Ing kasus penolakan mung siji kluster bakal mandheg bisa langsung kabeh beban kerja!
Ana akeh cara sing bisa salah:
- nganyari Kubernetes nyebabake efek samping sing ora dikarepke;
- Komponen cluster-wide (contone, plugin CNI) wiwit ora bisa digunakake kaya samesthine;
- salah siji komponen kluster ora dikonfigurasi kanthi bener;
- kegagalan ing infrastruktur dhasar.
Salah sawijining kedadeyan kasebut bisa nyebabake karusakan serius ing kabeh beban kerja sing di-host ing kluster sing dienggo bareng.
- Ora isolasi kaku
Mlaku ing kluster sing dienggo bareng tegese aplikasi nuduhake hardware, kapabilitas jaringan, lan sistem operasi ing simpul kluster.
Ing pangertèn, loro kontaner kanthi rong aplikasi beda sing mlaku ing simpul sing padha kaya rong proses sing mlaku ing mesin sing padha nganggo kernel OS sing padha.
Kontainer Linux nyedhiyakake sawetara bentuk isolasi, nanging ora meh kuat kaya sing diwenehake dening, umpamane, mesin virtual. Intine, proses ing wadhah yaiku proses sing padha ing sistem operasi inang.
Iki bisa dadi masalah keamanan: pangaturan iki kanthi teoritis ngidini aplikasi sing ora ana hubungane bisa komunikasi karo siji liyane (sing sengaja utawa ora sengaja).
Kajaba iku, kabeh beban kerja ing kluster Kubernetes nuduhake sawetara layanan kluster kayata - iki ngidini aplikasi golek Layanan saka aplikasi liyane ing kluster.
Kabeh titik ing ndhuwur bisa uga duwe makna sing beda-beda gumantung saka syarat keamanan aplikasi.
Kubernetes nyedhiyakake macem-macem alat kanggo nyegah masalah keamanan kayata и . Nanging, nyetel kanthi bener mbutuhake sawetara pengalaman; Kajaba iku, dheweke ora bisa nutup kabeh bolongan keamanan.
Penting kanggo elinga yen Kubernetes asline dirancang kanggo andum, ora kanggo isolasi lan safety.
- Kekurangan multi-tenancy sing ketat
Amarga akeh sumber daya sing dienggo bareng ing kluster Kubernetes, ana pirang-pirang cara supaya aplikasi sing beda-beda bisa mlaku.
Contone, aplikasi bisa monopoli sumber daya sing dienggo bareng (kayata CPU utawa memori) lan nolak aplikasi liyane sing mlaku ing akses simpul sing padha.
Kubernetes nyedhiyakake macem-macem mekanisme kanggo ngontrol prilaku iki, kayata (deleng uga artikel ""- kb. transl.), и . Nanging, kaya ing kasus keamanan, konfigurasi kasebut cukup ora pati penting lan ora bisa nyegah kabeh efek samping sing ora dikarepake.
- Akeh pangguna
Ing kasus klompok siji, sampeyan kudu mbukak akses menyang akeh wong. Lan luwih akeh jumlahe, luwih dhuwur risiko sing bakal "break" soko.
Ing kluster sampeyan bisa ngontrol sing bisa nindakake apa nggunakake (ndeleng artikel ""- kb. transl.). Nanging, ora bakal nyegah pangguna "nglanggar" apa wae ing wates wilayah tanggung jawabe.
− Kluster ora bisa tuwuh tanpa wates
Kluster sing digunakake kanggo kabeh beban kerja bakal cukup gedhe (ing babagan jumlah simpul lan pod).
Nanging ing kene ana masalah liyane: kluster ing Kubernetes ora bisa tuwuh tanpa wates.
Ana watesan teoritis babagan ukuran kluster. Ing Kubernetes iku kira-kira .
Nanging, ing urip nyata, masalah bisa diwiwiti luwih awal - contone, mung karo .
Kasunyatane yaiku klompok gedhe nyedhiyakake beban sing dhuwur ing lapisan kontrol Kubernetes. Ing tembung liyane, supaya kluster munggah lan mlaku kanthi efisien mbutuhake tuning sing ati-ati.
Jeksa Agung bisa ngetokake iki ditliti ing artikel sing gegandhengan ing blog asli sing diarani "".
Nanging ayo nimbang pendekatan sing ngelawan: akeh klompok cilik.
2. Akeh cilik, kluster khusus
Kanthi pendekatan iki, sampeyan nggunakake kluster sing kapisah kanggo saben unsur sing sampeyan pasang:
Akeh kluster cilik
Kanggo tujuan artikel iki, ing unsur deployable nuduhake conto aplikasi - contone, versi dev saka aplikasi sing kapisah.
Strategi iki nggunakake Kubernetes minangka khusus runtime kanggo kasus aplikasi individu.
Ayo goleki pro lan kontra saka pendekatan iki.
+ "radius jeblugan" winates
Nalika kluster gagal, akibat negatif mung diwatesi kanggo beban kerja sing dipasang ing kluster kasebut. Kabeh beban kerja liyane tetep ora kena.
+ Isolasi
Beban kerja sing di-host ing klompok individu ora nuduhake sumber daya kayata prosesor, memori, sistem operasi, jaringan, utawa layanan liyane.
Asilé yaiku pamisahan sing ketat ing antarane aplikasi sing ora ana hubungane, sing bisa migunani kanggo keamanan.
+ Jumlah pangguna sing sithik
Amarga saben kluster mung ngemot beban kerja sing winates, jumlah pangguna sing duwe akses menyang klompok kasebut suda.
Sing luwih sithik wong sing duwe akses menyang kluster, luwih murah yen ana sing bakal "rusak".
Ayo kang katon ing cons.
- Panggunaan sumber daya sing ora efisien
Kaya sing wis kasebut sadurunge, saben kluster Kubernetes mbutuhake sumber daya manajemen tartamtu: node master, komponen lapisan kontrol, ngawasi lan solusi logging.
Ing kasus klompok cilik sing akeh, sumber daya sing luwih gedhe kudu dialokasikan kanggo manajemen.
− Larang
Panggunaan sumber daya sing ora efisien kanthi otomatis mbutuhake biaya sing dhuwur.
Contone, njaga 30 kelenjar master tinimbang telung karo daya komputasi padha kudu mengaruhi biaya.
- Kesulitan administrasi
Ngatur sawetara kluster Kubernetes luwih angel tinimbang ngatur mung siji.
Contone, sampeyan kudu ngatur otentikasi lan wewenang kanggo saben kluster. Versi Kubernetes uga kudu dianyari kaping pirang-pirang.
Sampeyan bisa uga kudu nggunakake otomatisasi supaya kabeh tugas kasebut luwih efisien.
Saiki ayo ndelok skenario sing kurang ekstrem.
3. Siji kluster saben aplikasi
Ing pendekatan iki, sampeyan nggawe kluster kapisah kanggo kabeh kasus aplikasi tartamtu:
Kluster saben aplikasi
Path iki bisa dianggep minangka generalisasi saka prinsip "kluster kapisah saben tim”, amarga biasane tim insinyur ngembangake siji utawa luwih aplikasi.
Ayo goleki pro lan kontra saka pendekatan iki.
+ Kluster bisa disetel kanggo aplikasi
Yen aplikasi duwe kabutuhan khusus, bisa dileksanakake ing klompok tanpa mengaruhi klompok liyane.
Kabutuhan kasebut bisa uga kalebu buruh GPU, plugin CNI tartamtu, bolong layanan, utawa sawetara layanan liyane.
Saben kluster bisa dicocogake karo aplikasi sing mlaku ing kono supaya mung ngemot apa sing dibutuhake.
- Lingkungan beda ing siji kluster
Kerugian saka pendekatan iki yaiku conto aplikasi saka lingkungan sing beda urip bebarengan ing kluster sing padha.
Contone, versi prod saka aplikasi mlaku ing kluster sing padha karo versi dev. Iki uga tegese pangembang beroperasi ing klompok sing padha ing ngendi versi produksi aplikasi kasebut dioperasikake.
Yen, amarga tumindak pangembang utawa glitches ing versi dev, ana kegagalan ing kluster, mula versi prod bisa uga nandhang sangsara - kelemahane pendekatan iki.
Lan pungkasane, skenario pungkasan ing dhaptar kita.
4. Siji kluster saben lingkungan
Skenario iki kalebu ngalokasi kluster sing kapisah kanggo saben lingkungan:
Siji cluster saben lingkungan
Contone, sampeyan bisa uga duwe klompok dev, test и produk, ing ngendi sampeyan bakal mbukak kabeh kasus aplikasi khusus kanggo lingkungan tartamtu.
Mangkene pro lan kontra saka pendekatan iki.
+ Isolasi lingkungan prod
Ing pendekatan iki, kabeh lingkungan diisolasi saka saben liyane. Nanging, ing laku, iki penting banget ing lingkungan prod.
Versi produksi aplikasi saiki bebas saka apa sing kedadeyan ing klompok lan lingkungan liyane.
Kanthi cara iki, yen ana masalah tiba-tiba muncul ing kluster dev, versi prod saka aplikasi bakal terus mlaku kaya-kaya ora ana kedadeyan.
+ Kluster bisa diatur karo lingkungan
Saben kluster bisa diatur karo lingkungane. Contone, sampeyan bisa:
- nginstal alat kanggo pangembangan lan debugging ing kluster dev;
- nginstal frameworks test lan alat ing kluster test;
- nggunakake hardware lan jaringan saluran luwih kuat ing kluster produk.
Iki ngidini sampeyan nambah efisiensi pangembangan lan operasi aplikasi.
+ Watesan akses menyang kluster produksi
Kebutuhan kanggo bisa langsung karo kluster prod arang muncul, supaya sampeyan bisa mbatesi kanthi signifikan bunder wong sing duwe akses menyang.
Sampeyan bisa luwih maju lan mbantah akses wong menyang kluster iki kabeh, lan nindakake kabeh penyebaran nggunakake alat CI / CD otomatis. Pendekatan kasebut bakal nyilikake risiko kesalahan manungsa persis ing endi sing paling relevan.
Lan saiki sawetara tembung babagan kontra.
− Ora ana isolasi ing antarane aplikasi
Kerugian utama pendekatan kasebut yaiku kekurangan hardware lan isolasi sumber daya ing antarane aplikasi.
Aplikasi sing ora ana hubungane nuduhake sumber daya kluster: inti sistem, prosesor, memori, lan sawetara layanan liyane.
Kaya sing wis kasebut, iki bisa mbebayani.
− Ora bisa lokalisasi dependensi aplikasi
Yen aplikasi duwe syarat khusus, mula kudu kepenak ing kabeh klompok.
Contone, yen aplikasi mbutuhake GPU, saben kluster kudu ngemot paling ora siji buruh karo GPU (sanajan mung digunakake dening aplikasi kasebut).
Akibaté, kita risiko biaya sing luwih dhuwur lan panggunaan sumber daya sing ora efisien.
kesimpulan
Yen sampeyan duwe pesawat tartamtu saka aplikasi, padha bisa diselehake ing sawetara klompok gedhe utawa akeh cilik.
Artikel kasebut mbahas pro lan kontra saka macem-macem pendekatan, wiwit saka siji klompok global nganti sawetara sing cilik lan khusus banget:
- siji kluster umum gedhe;
- akeh klompok cilik sing khusus banget;
- siji kluster saben aplikasi;
- siji kluster saben lingkungan.
Dadi pendekatan sing kudu ditindakake?
Minangka tansah, jawaban gumantung ing kasus panggunaan: sampeyan kudu nimbang pro lan kontra saka macem-macem pendekatan lan milih pilihan sing paling optimal.
Nanging, pilihan ora diwatesi karo conto ing ndhuwur - sampeyan bisa nggunakake kombinasi apa wae!
Contone, sampeyan bisa ngatur sawetara klompok kanggo saben tim: klompok pangembangan (ing bakal ana lingkungan dev и test) lan kluster kanggo produksi (ing ngendi lingkungan produksi bakal dumunung).
Adhedhasar informasi ing artikel iki, sampeyan bisa ngoptimalake pro lan kontra kanggo skenario tartamtu. Sugeng enjang!
PS
Waca uga ing blog kita:
- «";
- «";
- «";
- «".
Source: www.habr.com