Nalika nggawe kluster Kubernetes, bisa uga ana pitakonan: pira simpul pekerja sing kudu dikonfigurasi lan jinis apa? Apa sing luwih apik kanggo kluster ing lokasi: tuku sawetara server sing kuat utawa gunakake puluhan mesin lawas ing pusat data sampeyan? Apa luwih apik kanggo njupuk wolung siji-inti utawa loro kedadean kotak-inti ing méga?
Jawaban kanggo pitakonan iki ana ing artikel. ing jarwaning parentah .
Kapasitas kluster
Umumé, kluster Kubernetes bisa dianggep minangka "supernode" sing gedhé. Total daya komputasi minangka gunggunge kekuwatan kabeh node konstituen.
Ana sawetara cara kanggo nggayuh target kapasitas kluster sing dikarepake. Contone, kita butuh kluster kanthi kapasitas total 8 inti prosesor lan 32 GB RAM amarga sakumpulan aplikasi mbutuhake sumber daya sing akeh. Banjur sampeyan bisa nginstal loro kelenjar karo 16 GB memori utawa papat kelenjar karo 8 GB memori, loro prosesor kotak-inti utawa papat dual-inti.
Ing ngisor iki mung rong cara kanggo nggawe kluster:
Kaloro opsi kasebut ngasilake kluster kanthi kapasitas sing padha, nanging konfigurasi ngisor duwe papat kelenjar cilik lan konfigurasi ndhuwur duwe rong kelenjar luwih gedhe.
Pilihan sing luwih apik?
Kanggo njawab pitakonan iki, ayo goleki keuntungan saka loro pilihan kasebut. Kita wis ngringkes mau ing tabel.
Saperangan simpul gedhe
Akeh simpul cilik
Manajemen kluster sing luwih gampang (yen ana ing lokasi)
Autoscaling lancar
Luwih murah (yen ing panggonan)
Rega rada beda (ing awan)
Bisa mbukak aplikasi sumber daya-intensif
Replikasi lengkap
Sumber daya digunakake kanthi luwih efisien (kurang overhead ing daemon sistem
Toleransi fault cluster sing luwih dhuwur
Wigati dimangerteni manawa kita mung ngomong babagan simpul pekerja. Milih nomer lan ukuran simpul utama minangka topik sing beda banget.
Dadi, ayo ngrembug saben poin saka tabel kanthi luwih rinci.
Pilihan pisanan: sawetara simpul gedhe
Pilihan sing paling ekstrim yaiku siji simpul pekerja kanggo kabeh kapasitas kluster. Ing conto ing ndhuwur, iki bakal dadi simpul buruh siji kanthi 16 inti CPU lan 16 GB RAM.
Плюсы
Plus No.. 1. Manajemen luwih gampang
Iku luwih gampang kanggo ngatur sawetara mesin saka kabèh armada. Iku luwih cepet kanggo muter metu nganyari lan mbenakake, lan iku luwih gampang kanggo nyinkronake. Jumlah gagal ing nomer absolut uga kurang.
Wigati dimangerteni manawa kabeh sing kasebut ing ndhuwur ditrapake kanggo hardware, server, lan dudu kanggo kedadeyan awan.
Kahanan beda ing awan. Ing kana, manajemen ditangani dening panyedhiya layanan awan. Dadi, ngatur sepuluh simpul ing awan ora beda karo ngatur siji simpul.
Nuntun lalu lintas lan distribusi muatan ing antarane polong ing méga : lalu lintas sing teka saka Internet dikirim menyang load balancer utama, sing nerusake lalu lintas menyang port salah sawijining kelenjar (layanan NodePort nyetel port ing sawetara 30000-32767 ing saben simpul kluster). Aturan sing disetel dening kube-proxy pangalihan lalu lintas saka simpul menyang pod. Mangkene apa sing katon kanggo sepuluh pod ing rong simpul:
Pro #2: Kurang biaya saben simpul
Mobil sing kuat luwih larang, nanging kenaikan rega ora mesthi linear. Ing tembung liyane, siji server sepuluh-inti karo 10 memori GB biasane luwih murah tinimbang sepuluh server siji-inti karo jumlah memori sing padha.
Nanging elinga yen aturan iki biasane ora bisa digunakake ing layanan awan. Ing skema rega saiki kabeh panyedhiya awan utama, rega mundhak kanthi linear kanthi kapasitas.
Mangkono, ing méga sampeyan biasane ora bisa nyimpen ing server sing luwih kuat.
Pro #3: Sampeyan bisa mbukak aplikasi intensif sumber daya
Sawetara aplikasi mbutuhake server kuat ing kluster. Contone, yen sistem learning machine mbutuhake 8 memori GB, sampeyan ora bakal bisa mbukak ing 1 simpul GB, nanging mung karo paling siji simpul buruh gedhe.
Минусы
Kerugian No.. 1. Akeh polong saben simpul
Yen tugas sing padha ditindakake ing simpul sing luwih sithik, mula saben-saben bakal duwe polong luwih akeh.
Iki bisa dadi masalah.
Alesane yaiku saben modul ngenalake sawetara overhead menyang runtime wadhah (contone Docker), uga kubelet lan cAdvisor.
Contone, kubelet ajeg mriksa kabeh wadhah ing simpul supaya bisa urip - luwih akeh wadhah, luwih akeh karya sing kudu ditindakake kubelet.
CAdvisor ngumpulake statistik panggunaan sumber kanggo kabeh kontaner ing simpul, lan kubelet ajeg takon informasi iki lan nyedhiyani liwat API. Maneh, luwih akeh kontaner tegese luwih akeh kerja kanggo cAdvisor lan kubelet.
Yen jumlah modul mundhak, bisa alon mudhun sistem lan malah ngrusak linuwih.
Ing repositori Kubernetes sawetara sing kelenjar mlumpat antarane Siap / status NotReady amarga mriksa kubelet biasa kabeh kontaner ing simpul njupuk dawa banget.
Mulane Kubernetes . Gumantung ing kinerja simpul kang, sampeyan bisa mbukak liyane pods saben simpul, nanging iku hard kanggo prédhiksi apa bakal ana masalah utawa kabeh bakal bisa uga. Iku worth nyoba karya ing advance.
Kerugian No.. 2. Watesan ing réplikasi
Kakehan simpul mbatesi ombone efektif replikasi aplikasi. Contone, yen sampeyan duwe aplikasi kasedhiyan dhuwur kanthi limang replika nanging mung rong simpul, mula tingkat efektif replikasi aplikasi dikurangi dadi loro.
Lima replika mung bisa disebarake ing rong kelenjar, lan yen salah siji gagal, bakal ngilangi pirang-pirang replika bebarengan.
Yen sampeyan duwe limang kelenjar utawa luwih, saben tiron bakal mbukak ing simpul kapisah, lan Gagal siji simpul bakal mbusak paling siji replika.
Mangkono, syarat kasedhiyan dhuwur bisa mbutuhake jumlah minimal simpul tartamtu ing kluster.
Kerugian No 3. Akibat sing luwih elek saka kegagalan
Kanthi jumlah node sing cilik, saben kegagalan duwe akibat sing luwih serius. Contone, yen sampeyan mung duwe rong simpul lan salah sijine gagal, setengah saka modul sampeyan langsung ilang.
Mesthine, Kubernetes bakal migrasi beban kerja saka simpul gagal menyang wong liya. Nanging yen ana sawetara, banjur ana uga ora cukup kapasitas free. Akibaté, sawetara aplikasi sampeyan ora kasedhiya nganti sampeyan mbukak simpul sing gagal.
Mangkono, luwih akeh simpul, luwih sithik pengaruh kegagalan hardware.
Kekurangan #4: Langkah-langkah autoscaling liyane
Kubernetes duwe sistem skala otomatis kluster kanggo infrastruktur awan, sing ngidini sampeyan nambah utawa mbusak simpul kanthi otomatis gumantung saka kabutuhan saiki. Kanthi simpul sing luwih gedhe, autoscaling dadi luwih cepet lan kikuk. Contone, ing rong simpul, nambahake simpul tambahan bakal nambah kapasitas kluster kanthi 50%. Lan sampeyan kudu mbayar sumber daya kasebut, sanajan sampeyan ora butuh.
Mangkono, yen sampeyan arep nggunakake skala kluster otomatis, sing luwih cilik simpul, sing luwih fleksibel lan biaya-efektif skala sampeyan bakal entuk.
Saiki ayo kang katon ing kaluwihan lan cacat saka nomer akeh simpul cilik.
Pilihan kapindho: akeh kelenjar cilik
Kaluwihan saka pendekatan iki ateges asale saka kerugian saka pilihan ngelawan karo sawetara kelenjar gedhe.
Плюсы
Pro #1: Kurang impact saka Gagal
Luwih akeh simpul, luwih sithik polong ing saben simpul. Contone, yen sampeyan duwe satus modul saben sepuluh simpul, saben simpul bakal duwe rata-rata sepuluh modul.
Kanthi cara iki, yen salah siji simpul gagal, sampeyan mung bakal kelangan 10% saka beban kerja. Kemungkinan mung sawetara replika sing bakal kena pengaruh lan aplikasi sakabèhé bakal tetep operasional.
Kajaba iku, simpul sing isih ana bakal duwe sumber daya gratis sing cukup kanggo nangani beban kerja simpul sing gagal, mula Kubernetes bisa kanthi bebas ngatur jadwal maneh pod lan aplikasi sampeyan bakal bali menyang kahanan fungsional kanthi cepet.
Pro # 2: Replikasi apik
Yen ana cukup simpul, panjadwal Kubernetes bisa nemtokake simpul beda kanggo kabeh replika. Kanthi cara iki, yen simpul gagal, mung siji replika sing bakal kena pengaruh lan aplikasi bakal kasedhiya.
Минусы
Kerugian No.. 1. Susah dikontrol
Nomer simpul sing akeh luwih angel diatur. Contone, saben simpul Kubernetes kudu komunikasi karo kabeh liyane, yaiku, jumlah sambungan mundhak quadratically, lan kabeh sambungan iki kudu dilacak.
Pengontrol simpul ing Kubernetes Controller Manager kanthi rutin ngliwati kabeh simpul ing kluster kanggo mriksa kesehatan - luwih akeh simpul, luwih akeh beban ing pengontrol.
Beban ing database etcd uga akeh - saben kubelet lan kube-proxy nelpon kanggo etcd (liwat API), sing etcd ngirim siaran nganyari obyek.
Umumé, saben simpul buruh ngetrapake beban tambahan ing komponen sistem simpul master.
Kubernetes resmi ndhukung kluster karo . Nanging, ing laku wis ana 500 simpul .
Kanggo ngatur akeh simpul buruh, sampeyan kudu milih simpul master sing luwih kuat. Contone, kube-up ukuran VM bener kanggo simpul master gumantung ing nomer kelenjar buruh. Tegese, luwih akeh simpul pekerja, luwih produktif simpul master.
Kanggo ngatasi masalah tartamtu iki ana pembangunan khusus, kayata . Sistem iki ngidini sampeyan ngliwati watesan lan mbangun kluster kanthi jumlah node pekerja sing akeh.
Kerugian # 2: Biaya overhead liyane.
Ing saben simpul buruh, Kubernetes mbukak sakumpulan daemon sistem - iki kalebu runtime wadah (kayata Docker), kube-proxy lan kubelet, kalebu cAdvisor. Bareng padha nggunakake jumlah tetep tartamtu saka sumber daya.
Yen sampeyan duwe akeh simpul cilik, proporsi nduwur sirah iki ing saben simpul luwih gedhe. Contone, mbayangno kabeh daemon sistem ing simpul siji bebarengan nggunakake 0,1 intine CPU lan 0,1 memori GB. Yen sampeyan duwe simpul sepuluh inti kanthi memori 10 GB, mula daemon nggunakake 1% saka kapasitas kluster. Ing sisih liya, ing sepuluh simpul inti siji kanthi memori 1 GB, daemon bakal njupuk 10% saka kapasitas kluster.
Mangkono, luwih sithik node, luwih efisien infrastruktur digunakake.
Kerugian No 3. Panggunaan sumber daya sing ora efisien
Ing simpul cilik, bisa uga potongan sumber daya sing isih cilik banget kanggo nemtokake beban kerja, mula tetep ora digunakake.
Contone, saben pod mbutuhake memori 0,75 GB. Yen sampeyan duwe sepuluh simpul, saben karo 1GB memori, sampeyan bisa mbukak sepuluh pods, ninggalake saben simpul karo 0,25GB memori sing ora digunakake.
Iki tegese 25% saka kabeh memori kluster boroske.
Ing simpul gedhe kanthi memori 10 GB, sampeyan bisa mbukak 13 modul kasebut - lan mung ana siji pecahan sing ora digunakake 0,25 GB.
Ing kasus iki, mung 2,5% saka memori boroske.
Mangkono, sumber daya digunakake kanthi luwih optimal ing node sing luwih gedhe.
Sawetara kelenjar gedhe utawa akeh cilik?
Dadi, sing luwih apik: sawetara kelenjar gedhe ing kluster utawa akeh cilik? Kaya biasane, ora ana jawaban sing jelas. Kathah gumantung ing jinis aplikasi.
Contone, yen aplikasi mbutuhake memori 10 GB, simpul sing luwih gedhe minangka pilihan sing jelas. Lan yen aplikasi mbutuhake tiron sepuluh tikel kanggo kasedhiyan dhuwur, iku meh ora worth risiko nempatno tiron ing mung loro kelenjar - kudu ana minimal sepuluh kelenjar ing kluster.
Ing kahanan penengah, nggawe pilihan adhedhasar kaluwihan lan cacat saben pilihan. Mbok menawa sawetara argumen luwih cocog karo kahanan sampeyan tinimbang liyane.
Lan ora perlu nggawe kabeh simpul ukuran sing padha. Ora ana sing ngalang-alangi sampeyan nyoba dhisik karo simpul kanthi ukuran sing padha, banjur nambahake simpul kanthi ukuran sing beda, gabungke ing kluster. Node pekerja ing kluster Kubernetes bisa dadi heterogen. Supaya sampeyan bisa nyoba kanggo gabungke kaluwihan saka loro pendekatan.
Ora ana resep siji, lan saben kahanan nduweni nuansa dhewe, lan mung produksi bakal nuduhake bebener.
Terjemahan disiapake dening tim platform awan .
Liyane babagan Kubernetes: .
Source: www.habr.com