Nalika nyiptakeun klaster Kubernetes, patarosan tiasa timbul: sabaraha titik pagawé anu kedah dikonpigurasikeun sareng jinis naon? Naon anu langkung saé pikeun klaster di premis: mésér sababaraha server anu kuat atanapi nganggo belasan mesin lami di pusat data anjeun? Naha langkung saé nyandak dalapan inti tunggal atanapi dua instansi quad-core dina méga?
Jawaban kana patarosan ieu aya dina tulisan. dina tarjamah paréntah .
Kapasitas klaster
Sacara umum, klaster Kubernetes bisa dianggap salaku "supernode" badag. Daya komputasi totalna nyaéta jumlah kakuatan sadaya titik konstituénna.
Aya sababaraha cara pikeun ngahontal target kapasitas klaster anu dipikahoyong. Salaku conto, urang peryogi kluster kalayan kapasitas total 8 inti prosesor sareng 32 GB RAM kusabab sakumpulan aplikasi ngabutuhkeun seueur sumber. Teras anjeun tiasa pasang dua titik kalayan mémori 16 GB atanapi opat titik kalayan mémori 8 GB, dua prosésor quad-core atanapi opat dua-inti.
Ieu ngan ukur dua cara pikeun nyiptakeun klaster:
Kadua pilihan ngahasilkeun klaster kalayan kapasitas anu sami, tapi konfigurasi handap ngagaduhan opat titik anu langkung alit sareng konfigurasi luhur ngagaduhan dua titik anu langkung ageung.
Pilihan mana anu langkung saé?
Pikeun ngajawab patarosan ieu, hayu urang tingali kaunggulan duanana pilihan. Kami geus diringkeskeun aranjeunna dina tabel.
Sababaraha titik badag
Loba titik leutik
Manajemén klaster anu langkung gampang (upami aya di tempat)
Skala otomatis lemes
Langkung mirah (upami on-premise)
Hargana rada béda (dina awan)
Bisa ngajalankeun aplikasi sumberdaya-intensif
Réplikasi pinuh
Sumberdaya dianggo langkung éfisién (kurang overhead dina daemon sistem
kasabaran sesar klaster luhur
Punten dicatet yén urang ngan ukur nyarioskeun ngeunaan titik pagawé. Milih jumlah sareng ukuran titik utama mangrupikeun topik anu béda.
Janten, hayu urang bahas unggal poin tina tabél sacara langkung rinci.
Pilihan kahiji: sababaraha titik badag
Pilihan anu paling ekstrim nyaéta hiji titik worker pikeun sakabéh kapasitas klaster. Dina conto di luhur, ieu bakal janten titik worker tunggal sareng 16 inti CPU sareng 16 GB RAM.
Плюсы
Ditambah No.. 1. manajemén gampang
Leuwih gampang pikeun ngatur sababaraha mesin ti sakabeh armada. Langkung gancang ngaluncurkeun apdet sareng perbaikan, sareng langkung gampang pikeun nyingkronkeun. Jumlah gagal dina jumlah mutlak ogé kirang.
Punten dicatet yén sadaya di luhur manglaku ka hardware anjeun, server anjeun, sareng sanés pikeun instansi awan.
Kaayaan béda dina méga. Di dinya, manajemén diurus ku panyadia jasa awan. Ku kituna, ngatur sapuluh titik dina awan teu jauh béda ti ngatur hiji titik.
Rute lalu lintas sareng distribusi beban antara polong dina méga : lalulintas datang ti Internet dikirim ka balancer beban utama, nu diteruskeun lalulintas ka port salah sahiji titik (jasa NodePort susunan port dina rentang 30000-32767 dina unggal titik klaster). Aturan anu diatur ku kube-proxy alihan lalu lintas tina titik ka pod. Ieu kumaha rupana pikeun sapuluh pod dina dua titik:
Pro #2: Kirang biaya per node
Mobil anu kuat langkung mahal, tapi kanaékan hargana henteu merta linier. Dina basa sejen, hiji server sapuluh-core kalawan 10 GB memori biasana langkung mirah ti sapuluh server single-core kalawan jumlah memori anu sarua.
Tapi perhatikeun yén aturan ieu biasana henteu dianggo dina jasa awan. Dina skéma harga ayeuna sadaya panyadia awan utama, harga naek linier kalawan kapasitas.
Ku kituna, dina awan anjeun biasana teu bisa nyimpen dina server leuwih kuat.
Pro #3: Anjeun tiasa ngajalankeun aplikasi sumberdaya-intensif
Sababaraha aplikasi merlukeun server kuat dina klaster. Contona, upami sistem learning mesin merlukeun 8 memori GB, Anjeun moal bisa ngajalankeun eta dina 1 titik GB, tapi ngan mibanda sahanteuna hiji titik worker badag.
Минусы
disadvantage No.. 1. Loba pods per node
Upami tugas anu sami dilaksanakeun dina pangsaeutikna titik, maka masing-masing sacara alami bakal ngagaduhan langkung pods.
Ieu bisa jadi masalah.
Alesanna nyaéta unggal modul ngenalkeun sababaraha overhead kana runtime wadahna (contona Docker), ogé kubelet sareng cAdvisor.
Contona, hiji kubelet rutin usik sadaya wadah dina titik pikeun survivability-beuki peti, beuki loba karya kubelet kudu ngalakukeun.
CAdvisor ngumpulkeun statistik pamakéan sumberdaya pikeun sakabéh peti on node a, sarta kubelet rutin queries inpo ieu jeung nyadiakeun eta via API. Sakali deui, langkung seueur wadah hartosna langkung seueur padamelan pikeun cAdvisor sareng kubelet.
Upami jumlah modul naék, éta tiasa ngalambatkeun sistem sareng ngarusak réliabilitasna.
Dina Repository Kubernetes sababaraha yén titik luncat antara status Siap / NotReady sabab cék kubelet biasa sadaya wadah dina titik nyokot panjang teuing.
Ku sabab kitu Kubernetes . Gumantung kana kinerja node, anjeun tiasa ngajalankeun langkung pods per node, tapi hese diprediksi naha bakal aya masalah atawa sagalana bakal jalan. Eta sia nguji karya sateuacanna.
disadvantage No.. 2. Watesan dina réplikasi
Saeutik teuing titik ngawates tingkat efektif réplikasi aplikasi. Contona, upami anjeun gaduh aplikasi kasadiaan tinggi sareng lima réplika tapi ngan ukur dua titik, maka tingkat réplikasi efektif aplikasi diréduksi jadi dua.
Lima réplika ngan tiasa disebarkeun ka dua titik, sareng upami salah sahijina gagal, éta bakal nyandak sababaraha réplika sakaligus.
Upami anjeun gaduh lima titik atanapi langkung, unggal réplika bakal dijalankeun dina titik anu misah, sareng gagalna hiji titik bakal ngaleungitkeun paling seueur réplika.
Ku kituna, syarat kasadiaan tinggi bisa merlukeun jumlah minimum nu tangtu titik dina klaster.
Kakurangan No 3. Konsékuansi parah gagal
Kalayan sajumlah leutik titik, unggal kagagalan ngagaduhan akibat anu langkung serius. Salaku conto, upami anjeun ngan ukur gaduh dua titik sareng salah sahijina gagal, satengah modul anjeun langsung ngaleungit.
Tangtosna, Kubernetes bakal migrasi beban kerja tina titik anu gagal ka batur. Tapi lamun aya sababaraha di antarana, mangka bisa jadi teu cukup kapasitas bébas. Hasilna, sababaraha aplikasi anjeun moal sayogi dugi ka anjeun muka titik anu gagal.
Ku kituna, beuki titik, nu kirang dampak gagal hardware.
Kakurangan # 4: Langkung léngkah-léngkah autoscaling
Kubernetes gaduh sistem skala otomatis klaster pikeun infrastruktur awan, anu ngamungkinkeun anjeun sacara otomatis nambihan atanapi ngahapus titik gumantung kana kabutuhan anjeun ayeuna. Kalayan titik anu langkung ageung, autoscaling janten langkung ngadadak sareng kikuk. Contona, dina dua titik, nambahan hiji titik tambahan bakal geuwat ningkatkeun kapasitas klaster ku 50%. Sareng anjeun kedah mayar sumber-sumber éta, sanaos anjeun henteu peryogina.
Janten, upami anjeun ngarencanakeun ngagunakeun skala klaster otomatis, langkung alit titik-titikna, skala anu langkung fleksibel sareng biaya-éféktif anjeun bakal kéngingkeun.
Ayeuna hayu urang nempo kaunggulan jeung kalemahan sajumlah badag titik leutik.
Pilihan kadua: loba titik leutik
Kaunggulan tina pendekatan ieu dasarna batang tina kalemahan tina pilihan sabalikna kalawan sababaraha titik badag.
Плюсы
Pro #1: Kurang dampak gagalna
Beuki loba titik, beuki saeutik polong dina unggal titik. Contona, upami anjeun gaduh saratus modul per sapuluh titik, teras unggal titik bakal boga rata-rata sapuluh modul.
Ku cara ieu, upami salah sahiji titik gagal, anjeun ngan leungit 10% tina beban kerja. Kasempetan aya ngan sajumlah leutik réplika anu bakal kapangaruhan sareng aplikasi sakabéh bakal tetep operasional.
Salaku tambahan, titik-titik sésana sigana bakal gaduh sumber daya gratis anu cekap pikeun nanganan beban kerja titik anu gagal, ku kituna Kubernetes tiasa sacara bébas ngajadwalkeun ulang pods sareng aplikasi anjeun bakal balik deui ka kaayaan fungsional anu rélatif gancang.
Pro #2: réplikasi alus
Lamun aya cukup titik, scheduler Kubernetes bisa nangtukeun titik béda pikeun sakabéh réplika. Ku cara ieu, upami node gagal, ngan ukur hiji réplika anu bakal kapangaruhan sareng aplikasina tetep sayogi.
Минусы
Kakurangan No.. 1. Hésé dikadalikeun
Jumlah titik anu ageung langkung sesah diurus. Salaku conto, unggal titik Kubernetes kedah komunikasi sareng sadaya anu sanés, nyaéta, jumlah sambungan naék sacara kuadrat, sareng sadaya sambungan ieu kedah dilacak.
Controller titik di Kubernetes Controller Manager rutin ngaliwat sadaya titik dina kluster pikeun mariksa kaséhatan - langkung seueur titik, langkung seueur beban dina controller.
Beban dina database jsb ogé tumuwuh - unggal kubelet na kube-proxy nelepon pikeun etcd (via API), nu etcd kedah disiarkeun apdet obyék.
Sacara umum, unggal titik worker maksakeun beban tambahan dina komponén sistem tina titik master.
Kubernetes resmi ngarojong klaster kalawan . Sanajan kitu, dina prakna geus aya 500 titik .
Pikeun ngatur sajumlah ageung titik pagawé, anjeun kedah milih titik master anu langkung kuat. Contona, kube-up ukuran VM bener pikeun titik master gumantung kana jumlah titik worker. Hartina, beuki titik worker, kudu leuwih produktif titik master.
Pikeun ngajawab masalah husus ieu aya kamajuan husus, kayaning . Sistim ieu ngidinan Anjeun pikeun bypass larangan sarta ngawangun klaster kalawan jumlah badag titik worker.
disadvantage # 2: waragad overhead langkung.
Dina unggal titik worker, Kubernetes ngajalankeun sakumpulan daemons sistem - ieu kalebet runtime wadahna (sapertos Docker), kube-proxy sareng kubelet, kalebet cAdvisor. Kalawan babarengan aranjeunna meakeun jumlah tetep tangtu sumberdaya.
Upami anjeun gaduh seueur titik leutik, proporsi overhead ieu dina unggal titik langkung ageung. Contona, ngabayangkeun yén sakabéh daemons sistem dina titik tunggal babarengan ngagunakeun 0,1 cores CPU jeung 0,1 memori GB. Upami Anjeun gaduh hiji titik sapuluh-inti kalawan 10 GB memori, daemons meakeun 1% tina kapasitas klaster. Di sisi séjén, dina sapuluh titik single-core kalawan 1 GB memori, daemons bakal nyandak 10% tina kapasitas klaster.
Ku kituna, leuwih saeutik titik, leuwih efisien infrastruktur dipaké.
Kakurangan No 3. pamakéan sumberdaya teu efisien
Dina titik leutik, bisa jadi éta sakumpulan sumberdaya sésana leutik teuing pikeun napelkeun workload wae, ngarah tetep teu dipaké.
Contona, unggal pod merlukeun 0,75 GB memori. Upami Anjeun gaduh sapuluh titik, unggal kalawan 1GB memori, Anjeun tiasa ngajalankeun sapuluh pods, ninggalkeun unggal titik kalawan 0,25GB memori henteu kapake.
Ieu ngandung harti yén 25% tina sakabéh mémori kluster urang wasted.
Dina titik badag kalayan memori 10 GB, anjeun tiasa ngajalankeun 13 modul ieu - sarta bakal aya ngan hiji sempalan henteu kapake tina 0,25 GB.
Dina hal ieu, ngan 2,5% tina mémori wasted.
Ku kituna, sumberdaya dipaké leuwih optimal dina titik nu leuwih gede.
Sababaraha titik ageung atanapi seueur titik leutik?
Janten, mana anu langkung saé: sababaraha titik ageung dina klaster atanapi seueur anu alit? Sakumaha biasa, teu aya jawaban anu jelas. Loba gumantung kana jenis aplikasi.
Contona, upami hiji aplikasi merlukeun 10 GB memori, titik nu leuwih gede mangrupa pilihan atra. Tur upami aplikasi merlukeun réplikasi sapuluh kali lipat pikeun kasadiaan tinggi, éta boro patut resiko nempatkeun réplika dina ngan dua titik - kudu aya minimum sapuluh titik dina klaster.
Dina kaayaan panengah, jieun pilihan dumasar kana kaunggulan sareng kalemahan unggal pilihan. Panginten sababaraha alesan langkung relevan pikeun kaayaan anjeun tibatan anu sanés.
Sareng henteu kedah ngadamel sadaya titik dina ukuran anu sami. Henteu aya anu ngahalangan anjeun pikeun ékspérimén heula sareng titik-titik anu ukuranana sami, teras nambihan titik-titik ukuran anu béda-béda, ngagabungkeun aranjeunna dina klaster. Titik pagawe dina klaster Kubernetes tiasa lengkep hétérogén. Janten anjeun tiasa nyobian ngagabungkeun kauntungan tina duanana pendekatan.
Teu aya resep tunggal, sareng unggal kaayaan ngagaduhan nuansa sorangan, sareng ngan ukur produksi anu bakal nunjukkeun kaleresan.
Tarjamahan disiapkeun ku tim platform awan .
Langkung seueur ngeunaan Kubernetes: .
sumber: www.habr.com
