Apabila membuat kluster Kubernetes, soalan mungkin timbul: berapa banyak nod pekerja untuk dikonfigurasikan dan jenis apa? Apakah yang lebih baik untuk kluster di premis: beli beberapa pelayan berkuasa atau gunakan sedozen mesin lama di pusat data anda? Adakah lebih baik untuk mengambil lapan contoh teras tunggal atau dua teras empat dalam awan?
Jawapan kepada soalan-soalan ini ada dalam artikel. dalam terjemahan arahan .
Kapasiti kluster
Secara umum, gugusan Kubernetes boleh dianggap sebagai "supernod" yang besar. Jumlah kuasa pengkomputerannya ialah jumlah kuasa semua nod konstituennya.
Terdapat beberapa cara untuk mencapai sasaran kapasiti kelompok yang anda inginkan. Sebagai contoh, kami memerlukan kluster dengan jumlah kapasiti 8 teras pemproses dan 32 GB RAM kerana satu set aplikasi memerlukan banyak sumber. Kemudian anda boleh memasang dua nod dengan memori 16 GB atau empat nod dengan memori 8 GB, dua pemproses empat teras atau empat teras dwi.
Berikut ialah dua cara yang mungkin untuk membuat kluster:
Kedua-dua pilihan menghasilkan kluster dengan kapasiti yang sama, tetapi konfigurasi bawah mempunyai empat nod yang lebih kecil dan konfigurasi atas mempunyai dua nod yang lebih besar.
Pilihan mana yang lebih baik?
Untuk menjawab soalan ini, mari kita lihat kelebihan kedua-dua pilihan. Kami telah meringkaskannya dalam jadual.
Beberapa nod besar
Banyak nod kecil
Pengurusan kluster yang lebih mudah (jika ada di premis)
Autoscaling yang lancar
Lebih murah (jika di premis)
Harga sedikit berbeza (dalam awan)
Boleh menjalankan aplikasi intensif sumber
Replikasi penuh
Sumber digunakan dengan lebih cekap (kurang overhed pada daemon sistem
Toleransi kesalahan kelompok yang lebih tinggi
Sila ambil perhatian bahawa kita hanya bercakap tentang nod pekerja. Memilih bilangan dan saiz nod utama adalah topik yang sama sekali berbeza.
Jadi, mari kita bincangkan setiap perkara daripada jadual dengan lebih terperinci.
Pilihan pertama: beberapa nod besar
Pilihan yang paling melampau ialah satu nod pekerja untuk keseluruhan kapasiti kluster. Dalam contoh di atas, ini akan menjadi satu nod pekerja dengan 16 teras CPU dan 16 GB RAM.
Kelebihan
Ditambah No 1. Pengurusan yang lebih mudah
Lebih mudah untuk menguruskan beberapa mesin daripada keseluruhan armada. Ia lebih pantas untuk melancarkan kemas kini dan pembetulan serta lebih mudah untuk disegerakkan. Bilangan kegagalan dalam nombor mutlak juga kurang.
Sila ambil perhatian bahawa semua perkara di atas digunakan pada perkakasan anda, pelayan anda dan bukan pada kejadian awan.
Keadaan berbeza di awan. Di sana, pengurusan dikendalikan oleh penyedia perkhidmatan awan. Oleh itu, menguruskan sepuluh nod dalam awan tidak jauh berbeza dengan menguruskan satu nod.
Penghalaan trafik dan pengagihan beban antara pod dalam awan : trafik yang datang dari Internet dihantar ke pengimbang beban utama, yang memajukan trafik ke port salah satu nod (perkhidmatan NodePort menetapkan port dalam julat 30000-32767 dalam setiap nod kelompok). Peraturan yang ditetapkan oleh kube-proxy ubah hala trafik dari nod ke pod. Berikut ialah rupa sepuluh pod pada dua nod:
Pro #2: Kurang kos setiap nod
Kereta berkuasa lebih mahal, tetapi kenaikan harga tidak semestinya linear. Dalam erti kata lain, satu pelayan sepuluh teras dengan memori 10 GB biasanya lebih murah daripada sepuluh pelayan teras tunggal dengan jumlah memori yang sama.
Tetapi ambil perhatian bahawa peraturan ini biasanya tidak berfungsi dalam perkhidmatan awan. Dalam skim harga semasa semua penyedia awan utama, harga meningkat secara linear dengan kapasiti.
Oleh itu, dalam awan anda biasanya tidak boleh menyimpan pada pelayan yang lebih berkuasa.
Pro #3: Anda boleh menjalankan aplikasi intensif sumber
Sesetengah aplikasi memerlukan pelayan berkuasa dalam kelompok. Contohnya, jika sistem pembelajaran mesin memerlukan memori 8 GB, anda tidak akan dapat menjalankannya pada nod 1 GB, tetapi hanya dengan sekurang-kurangnya satu nod pekerja yang besar.
Kekurangan
Kelemahan No. 1. Banyak pod setiap nod
Jika tugas yang sama dilakukan pada lebih sedikit nod, maka setiap nod secara semula jadi akan mempunyai lebih banyak pod.
Ini boleh menjadi masalah.
Sebabnya ialah setiap modul memperkenalkan beberapa overhed kepada masa jalan kontena (cth. Docker), serta kubelet dan cAdvisor.
Contohnya, kubelet kerap menyiasat semua bekas pada nod untuk kemandirianβlebih banyak bekas, lebih banyak kerja yang perlu dilakukan oleh kubelet.
CAdvisor mengumpul statistik penggunaan sumber untuk semua bekas pada nod, dan kubelet kerap menanyakan maklumat ini dan memberikannya melalui API. Sekali lagi, lebih banyak bekas bermakna lebih banyak kerja untuk cAdvisor dan kubelet.
Jika bilangan modul bertambah, ia boleh memperlahankan sistem dan malah menjejaskan kebolehpercayaannya.
Dalam repositori Kubernetes beberapa bahawa nod melompat antara status Sedia/Tidak Sedia kerana semakan kubelet biasa bagi semua bekas pada nod mengambil masa terlalu lama.
Atas sebab ini Kubernetes . Bergantung pada prestasi nod, anda boleh menjalankan lebih banyak pod setiap nod, tetapi sukar untuk meramalkan sama ada akan ada masalah atau semuanya akan berfungsi dengan baik. Ia bernilai menguji kerja terlebih dahulu.
Kelemahan No. 2. Had ke atas replikasi
Terlalu sedikit nod mengehadkan tahap berkesan replikasi aplikasi. Sebagai contoh, jika anda mempunyai aplikasi ketersediaan tinggi dengan lima replika tetapi hanya dua nod, maka tahap replikasi berkesan aplikasi dikurangkan kepada dua.
Lima replika hanya boleh diedarkan pada dua nod, dan jika salah satu daripadanya gagal, ia akan mengalih keluar berbilang replika sekaligus.
Jika anda mempunyai lima nod atau lebih, setiap replika akan dijalankan pada nod yang berasingan, dan kegagalan satu nod akan mengalih keluar paling banyak satu replika.
Oleh itu, keperluan ketersediaan yang tinggi mungkin memerlukan bilangan nod minimum tertentu dalam kelompok.
Kelemahan No. 3. Akibat kegagalan yang lebih teruk
Dengan bilangan nod yang kecil, setiap kegagalan mempunyai akibat yang lebih serius. Contohnya, jika anda hanya mempunyai dua nod dan satu daripadanya gagal, separuh daripada modul anda hilang serta-merta.
Sudah tentu, Kubernetes akan memindahkan beban kerja daripada nod yang gagal kepada orang lain. Tetapi jika terdapat sedikit daripada mereka, maka mungkin tidak ada kapasiti percuma yang mencukupi. Akibatnya, beberapa aplikasi anda tidak akan tersedia sehingga anda memaparkan nod yang gagal.
Oleh itu, lebih banyak nod, semakin kurang kesan kegagalan perkakasan.
Kelemahan #4: Lebih banyak langkah penskalaan automatik
Kubernetes mempunyai sistem penskalaan automatik kelompok untuk infrastruktur awan, yang membolehkan anda menambah atau mengalih keluar nod secara automatik bergantung pada keperluan semasa anda. Dengan nod yang lebih besar, autoscaling menjadi lebih mendadak dan kikuk. Sebagai contoh, pada dua nod, menambah nod tambahan akan serta-merta meningkatkan kapasiti kluster sebanyak 50%. Dan anda perlu membayar untuk sumber tersebut, walaupun anda tidak memerlukannya.
Oleh itu, jika anda bercadang untuk menggunakan penskalaan kluster automatik, semakin kecil nod, penskalaan yang lebih fleksibel dan kos efektif yang anda akan perolehi.
Sekarang mari kita lihat kelebihan dan kekurangan sebilangan besar nod kecil.
Pilihan kedua: banyak nod kecil
Kelebihan pendekatan ini pada asasnya berpunca daripada kelemahan pilihan bertentangan dengan beberapa nod besar.
Kelebihan
Pro #1: Kurang kesan kegagalan
Semakin banyak nod, semakin sedikit pod pada setiap nod. Sebagai contoh, jika anda mempunyai seratus modul setiap sepuluh nod, maka setiap nod akan mempunyai purata sepuluh modul.
Dengan cara ini, jika salah satu nod gagal, anda hanya kehilangan 10% daripada beban kerja. Kemungkinannya ialah hanya sebilangan kecil replika akan terjejas dan aplikasi keseluruhan akan kekal beroperasi.
Selain itu, nod yang selebihnya berkemungkinan mempunyai sumber percuma yang mencukupi untuk mengendalikan beban kerja nod yang gagal, jadi Kubernetes boleh bebas menjadualkan semula pod dan aplikasi anda akan kembali ke keadaan berfungsi dengan agak cepat.
Pro #2: Replikasi yang baik
Jika terdapat nod yang mencukupi, penjadual Kubernetes boleh menetapkan nod yang berbeza kepada semua replika. Dengan cara ini, jika nod gagal, hanya satu replika akan terjejas dan aplikasi akan kekal tersedia.
Kekurangan
Kelemahan No 1. Sukar dikawal
Sebilangan besar nod lebih sukar untuk diurus. Sebagai contoh, setiap nod Kubernetes mesti berkomunikasi dengan semua yang lain, iaitu, bilangan sambungan berkembang secara kuadratik, dan semua sambungan ini perlu dijejaki.
Pengawal nod dalam Pengurus Pengawal Kubernetes kerap berjalan melalui semua nod dalam kelompok untuk memeriksa kesihatan - lebih banyak nod, lebih banyak beban pada pengawal.
Beban pada pangkalan data etcd juga semakin meningkat - setiap panggilan kubelet dan kube-proxy untuk etcd (melalui API), yang etcd harus menyiarkan kemas kini objek.
Secara umum, setiap nod pekerja mengenakan beban tambahan pada komponen sistem nod induk.
Kubernetes secara rasmi menyokong kluster dengan . Walau bagaimanapun, dalam praktiknya sudah ada 500 nod .
Untuk mengurus sejumlah besar nod pekerja, anda harus memilih nod induk yang lebih berkuasa. Contohnya, kube-up saiz VM yang betul untuk nod induk bergantung pada bilangan nod pekerja. Iaitu, lebih banyak nod pekerja, lebih produktif nod induk sepatutnya.
Untuk menyelesaikan masalah khusus ini terdapat perkembangan khas, seperti . Sistem ini membolehkan anda memintas sekatan dan membina kelompok dengan sejumlah besar nod pekerja.
Kelemahan #2: Lebih banyak kos overhed.
Pada setiap nod pekerja, Kubernetes menjalankan satu set daemon sistem - ini termasuk masa jalan kontena (seperti Docker), kube-proxy dan kubelet, termasuk cAdvisor. Bersama-sama mereka menggunakan sejumlah sumber tetap tertentu.
Jika anda mempunyai banyak nod kecil, perkadaran overhed ini pada setiap nod adalah lebih besar. Sebagai contoh, bayangkan bahawa semua daemon sistem pada satu nod bersama-sama menggunakan 0,1 teras CPU dan 0,1 GB memori. Jika anda mempunyai satu nod sepuluh teras dengan memori 10 GB, maka daemon menggunakan 1% daripada kapasiti kluster. Sebaliknya, pada sepuluh nod teras tunggal dengan memori 1 GB, daemon akan mengambil 10% daripada kapasiti kluster.
Oleh itu, lebih sedikit nod, lebih cekap infrastruktur digunakan.
Kelemahan No. 3. Penggunaan sumber yang tidak cekap
Pada nod kecil, mungkin bahagian sumber yang tinggal terlalu kecil untuk memberikan sebarang beban kerja, jadi ia kekal tidak digunakan.
Sebagai contoh, setiap pod memerlukan memori 0,75 GB. Jika anda mempunyai sepuluh nod, setiap satu dengan 1GB memori, anda boleh menjalankan sepuluh pod, meninggalkan setiap nod dengan 0,25GB memori yang tidak digunakan.
Ini bermakna 25% daripada keseluruhan memori kluster terbuang.
Pada nod besar dengan memori 10 GB, anda boleh menjalankan 13 modul ini - dan hanya akan ada satu serpihan yang tidak digunakan sebanyak 0,25 GB.
Dalam kes ini, hanya 2,5% daripada memori yang terbuang.
Oleh itu, sumber digunakan dengan lebih optimum pada nod yang lebih besar.
Beberapa nod besar atau banyak nod kecil?
Jadi, yang mana lebih baik: beberapa nod besar dalam kelompok atau banyak nod kecil? Seperti biasa, tiada jawapan yang jelas. Banyak bergantung pada jenis aplikasi.
Sebagai contoh, jika aplikasi memerlukan 10 GB memori, nod yang lebih besar adalah pilihan yang jelas. Dan jika aplikasi memerlukan replikasi sepuluh kali ganda untuk ketersediaan tinggi, risiko meletakkan replika pada hanya dua nod sahaja tidak berbaloi - mesti ada sekurang-kurangnya sepuluh nod dalam kelompok.
Dalam situasi pertengahan, buat pilihan berdasarkan kelebihan dan kekurangan setiap pilihan. Mungkin beberapa hujah lebih relevan dengan situasi anda daripada yang lain.
Dan tidak perlu sama sekali untuk membuat semua nod saiz yang sama. Tiada apa-apa yang menghalang anda daripada bereksperimen terlebih dahulu dengan nod yang sama saiz, kemudian menambah nod dengan saiz yang berbeza pada mereka, menggabungkannya dalam kelompok. Nod pekerja dalam kelompok Kubernetes boleh menjadi heterogen sepenuhnya. Oleh itu, anda boleh cuba menggabungkan kelebihan kedua-dua pendekatan.
Tidak ada resipi tunggal, dan setiap situasi mempunyai nuansa sendiri, dan hanya pengeluaran akan menunjukkan kebenaran.
Terjemahan disediakan oleh pasukan platform awan .
Lebih lanjut mengenai Kubernetes: .
Sumber: www.habr.com