Saat membuat cluster Kubernetes, pertanyaan mungkin muncul: berapa banyak node pekerja yang harus dikonfigurasi dan jenis apa? Apa yang lebih baik untuk klaster lokal: membeli beberapa server yang kuat atau menggunakan selusin mesin lama di pusat data Anda? Apakah lebih baik mengambil delapan instance single-core atau dua quad-core di cloud?
Jawaban atas pertanyaan-pertanyaan ini ada di artikel. dalam terjemahan perintah .
Kapasitas klaster
Secara umum, cluster Kubernetes dapat dianggap sebagai βsupernodeβ yang besar. Total daya komputasinya adalah jumlah kekuatan semua node penyusunnya.
Ada beberapa cara untuk mencapai target kapasitas cluster yang Anda inginkan. Misalnya kita membutuhkan cluster dengan total kapasitas 8 core prosesor dan RAM 32 GB karena sekumpulan aplikasi membutuhkan resource yang sangat besar. Kemudian Anda dapat menginstal dua node dengan memori 16 GB atau empat node dengan memori 8 GB, dua prosesor quad-core, atau empat prosesor dual-core.
Berikut ini dua kemungkinan cara untuk membuat cluster:
Kedua opsi menghasilkan cluster dengan kapasitas yang sama, namun konfigurasi bawah memiliki empat node yang lebih kecil dan konfigurasi atas memiliki dua node yang lebih besar.
Opsi mana yang lebih baik?
Untuk menjawab pertanyaan ini, mari kita lihat kelebihan kedua opsi tersebut. Kami telah merangkumnya dalam sebuah tabel.
Beberapa node besar
Banyak node kecil
Manajemen klaster yang lebih mudah (jika dilakukan di lokasi)
Penskalaan otomatis yang lancar
Lebih murah (jika di lokasi)
Harganya sedikit berbeda (di cloud)
Dapat menjalankan aplikasi yang intensif sumber daya
Replikasi penuh
Sumber daya digunakan lebih efisien (lebih sedikit overhead pada daemon sistem
Toleransi kesalahan cluster yang lebih tinggi
Harap dicatat bahwa kita hanya berbicara tentang node pekerja. Memilih jumlah dan ukuran node utama adalah topik yang sangat berbeda.
Jadi, mari kita bahas setiap poin dari tabel secara lebih rinci.
Opsi pertama: beberapa node besar
Pilihan paling ekstrim adalah satu node pekerja untuk seluruh kapasitas cluster. Pada contoh di atas, ini adalah node pekerja tunggal dengan 16 inti CPU dan RAM 16 GB.
Kelebihan:
Plus No. 1. Pengelolaan lebih mudah
Lebih mudah mengelola beberapa alat berat dibandingkan mengelola seluruh armada. Peluncuran pembaruan dan perbaikan lebih cepat, dan lebih mudah untuk melakukan sinkronisasi. Jumlah kegagalan dalam jumlah absolut juga lebih sedikit.
Harap dicatat bahwa semua hal di atas berlaku untuk perangkat keras Anda, server Anda, dan bukan untuk instance cloud.
Situasinya berbeda di cloud. Di sana, pengelolaannya ditangani oleh penyedia layanan cloud. Oleh karena itu, mengelola sepuluh node di cloud tidak jauh berbeda dengan mengelola satu node.
Perutean lalu lintas dan distribusi beban antar pod di cloud : lalu lintas yang berasal dari Internet dikirim ke penyeimbang beban utama, yang meneruskan lalu lintas ke port salah satu node (layanan NodePort menetapkan port dalam kisaran 30000-32767 di setiap node cluster). Aturan yang ditetapkan oleh kube-proxy mengalihkan lalu lintas dari node ke pod. Berikut tampilan sepuluh pod pada dua node:
Kelebihan #2: Biaya per node lebih murah
Mobil bertenaga lebih mahal, namun kenaikan harganya belum tentu linier. Dengan kata lain, satu server sepuluh inti dengan memori 10 GB biasanya lebih murah daripada sepuluh server inti tunggal dengan jumlah memori yang sama.
Namun perlu diingat bahwa aturan ini biasanya tidak berfungsi di layanan cloud. Dalam skema penetapan harga saat ini di semua penyedia cloud besar, harga meningkat secara linear seiring dengan peningkatan kapasitas.
Jadi, di cloud Anda biasanya tidak bisa menyimpan di server yang lebih kuat.
Pro #3: Anda dapat menjalankan aplikasi yang membutuhkan banyak sumber daya
Beberapa aplikasi memerlukan server yang kuat dalam sebuah cluster. Misalnya, jika sistem pembelajaran mesin memerlukan memori 8 GB, Anda tidak akan dapat menjalankannya pada node 1 GB, namun hanya dengan setidaknya satu node pekerja besar.
Kontra
Kerugian No. 1. Banyak pod per node
Jika tugas yang sama dilakukan pada node yang lebih sedikit, maka masing-masing node secara alami akan memiliki lebih banyak pod.
Ini bisa menjadi masalah.
Alasannya adalah setiap modul menimbulkan beberapa overhead pada runtime container (misalnya Docker), serta kubelet dan cAdvisor.
Sebagai contoh, sebuah kubelet secara teratur menyelidiki semua container pada sebuah node untuk mengetahui kemampuan bertahannyaβsemakin banyak container, semakin banyak pekerjaan yang harus dilakukan oleh kubelet.
CAdvisor mengumpulkan statistik penggunaan sumber daya untuk semua container di sebuah node, dan kubelet secara rutin menanyakan informasi ini dan menyediakannya melalui API. Sekali lagi, lebih banyak container berarti lebih banyak pekerjaan untuk cAdvisor dan kubelet.
Jika jumlah modul bertambah, hal ini dapat memperlambat sistem dan bahkan menurunkan keandalannya.
Di repositori Kubernetes ada beberapa bahwa node berpindah antara status Ready/NotReady karena pemeriksaan rutin kubelet terhadap semua container pada sebuah node memakan waktu terlalu lama.
Untuk alasan ini Kubernetes . Bergantung pada performa node, Anda dapat menjalankan lebih banyak pod per node, namun sulit untuk memprediksi apakah akan ada masalah atau semuanya akan berfungsi dengan baik. Sebaiknya uji pekerjaan terlebih dahulu.
Kerugian No. 2. Keterbatasan replikasi
Terlalu sedikit node membatasi tingkat efektif replikasi aplikasi. Misalnya, jika Anda memiliki aplikasi ketersediaan tinggi dengan lima replika namun hanya dua node, maka tingkat replikasi efektif aplikasi tersebut dikurangi menjadi dua.
Lima replika hanya dapat didistribusikan ke dua node, dan jika salah satunya gagal, beberapa replika akan dihapus sekaligus.
Jika Anda memiliki lima node atau lebih, setiap replika akan berjalan pada node terpisah, dan kegagalan satu node akan menghapus paling banyak satu replika.
Oleh karena itu, persyaratan ketersediaan tinggi mungkin memerlukan jumlah minimum node tertentu dalam cluster.
Kerugian No. 3. Konsekuensi kegagalan yang lebih buruk
Dengan jumlah node yang sedikit, setiap kegagalan memiliki konsekuensi yang lebih serius. Misalnya, jika Anda hanya memiliki dua node dan salah satunya gagal, setengah dari modul Anda akan segera hilang.
Tentu saja, Kubernetes akan memigrasikan beban kerja dari node yang gagal ke node lain. Namun jika jumlahnya sedikit, maka kapasitas kosongnya mungkin tidak cukup. Akibatnya, beberapa aplikasi Anda tidak akan tersedia sampai Anda memunculkan node yang gagal.
Jadi, semakin banyak node, semakin kecil dampak kegagalan perangkat keras.
Kerugian #4: Lebih banyak langkah penskalaan otomatis
Kubernetes memiliki sistem penskalaan otomatis cluster untuk infrastruktur cloud, yang memungkinkan Anda menambahkan atau menghapus node secara otomatis tergantung pada kebutuhan Anda saat ini. Dengan node yang lebih besar, penskalaan otomatis menjadi lebih mendadak dan kikuk. Misalnya, pada dua node, penambahan node tambahan akan segera meningkatkan kapasitas cluster sebesar 50%. Dan Anda harus membayar untuk sumber daya tersebut, meskipun Anda tidak membutuhkannya.
Jadi, jika Anda berencana menggunakan penskalaan klaster otomatis, semakin kecil nodenya, semakin fleksibel dan hemat biaya penskalaan yang Anda dapatkan.
Sekarang mari kita lihat kelebihan dan kekurangan dari sejumlah besar node kecil.
Opsi kedua: banyak node kecil
Keuntungan pendekatan ini pada dasarnya berasal dari kelemahan opsi sebaliknya dengan beberapa node besar.
Kelebihan:
Pro #1: Lebih sedikit dampak kegagalan
Semakin banyak node, semakin sedikit pod pada setiap node. Misalnya, jika Anda memiliki seratus modul per sepuluh node, maka setiap node akan memiliki rata-rata sepuluh modul.
Dengan cara ini, jika salah satu node gagal, Anda hanya kehilangan 10% beban kerja. Kemungkinannya hanya sejumlah kecil replika yang akan terpengaruh dan keseluruhan aplikasi akan tetap beroperasi.
Selain itu, node yang tersisa kemungkinan akan memiliki sumber daya gratis yang cukup untuk menangani beban kerja dari node yang gagal, sehingga Kubernetes dapat dengan bebas menjadwal ulang pod dan aplikasi Anda akan kembali ke status fungsional dengan relatif cepat.
Pro #2: Replikasi yang bagus
Jika terdapat cukup node, penjadwal Kubernetes dapat menetapkan node yang berbeda ke semua replika. Dengan cara ini, jika sebuah node gagal, hanya satu replika yang akan terpengaruh dan aplikasi akan tetap tersedia.
Kontra
Kekurangan No. 1. Sulit dikendalikan
Node dalam jumlah besar lebih sulit dikelola. Misalnya, setiap node Kubernetes harus berkomunikasi satu sama lain, sehingga jumlah koneksi bertambah secara kuadrat, dan semua koneksi ini perlu dilacak.
Pengontrol node di Kubernetes Controller Manager secara teratur menelusuri semua node di cluster untuk memeriksa kesehatannya - semakin banyak node, semakin banyak beban pada pengontrol.
Beban pada database etcd juga bertambah - setiap panggilan kubelet dan kube-proxy untuk etcd (melalui API), ke mana etcd harus menyiarkan pembaruan objek.
Secara umum, setiap node pekerja memberikan beban tambahan pada komponen sistem node master.
Kubernetes secara resmi mendukung cluster dengan . Namun pada praktiknya sudah ada 500 node .
Untuk mengelola node pekerja dalam jumlah besar, Anda harus memilih node master yang lebih kuat. Misalnya, kube-up ukuran VM yang benar untuk node master bergantung pada jumlah node pekerja. Artinya, semakin banyak node pekerja, maka semakin produktif pula node masternya.
Untuk mengatasi masalah khusus ini ada pengembangan khusus, seperti . Sistem ini memungkinkan Anda untuk melewati batasan dan membangun cluster dengan sejumlah besar node pekerja.
Kerugian #2: Lebih banyak biaya overhead.
Pada setiap node pekerja, Kubernetes menjalankan serangkaian daemon sistem - ini termasuk runtime container (seperti Docker), kube-proxy dan kubelet, termasuk cAdvisor. Bersama-sama mereka mengkonsumsi sejumlah sumber daya tertentu.
Jika Anda memiliki banyak node kecil, proporsi overhead ini pada setiap node akan lebih besar. Misalnya, bayangkan semua daemon sistem pada satu node menggunakan 0,1 inti CPU dan memori 0,1 GB. Jika Anda memiliki satu node sepuluh inti dengan memori 10 GB, maka daemon akan menggunakan 1% kapasitas cluster. Di sisi lain, pada sepuluh node inti tunggal dengan memori 1 GB, daemon akan mengambil 10% dari kapasitas cluster.
Jadi, semakin sedikit node, semakin efisien penggunaan infrastruktur.
Kerugian No. 3. Penggunaan sumber daya yang tidak efisien
Pada node kecil, mungkin potongan sumber daya yang tersisa terlalu kecil untuk menetapkan beban kerja apa pun, sehingga tetap tidak digunakan.
Misalnya, setiap pod memerlukan memori 0,75 GB. Jika Anda memiliki sepuluh node, masing-masing dengan memori 1 GB, Anda dapat menjalankan sepuluh pod, menyisakan setiap node dengan 0,25 GB memori yang tidak terpakai.
Ini berarti 25% dari seluruh memori cluster terbuang sia-sia.
Pada node besar dengan memori 10 GB, Anda dapat menjalankan 13 modul ini - dan hanya akan ada satu fragmen 0,25 GB yang tidak terpakai.
Dalam hal ini, hanya 2,5% memori yang terbuang.
Dengan demikian, sumber daya digunakan lebih optimal pada node yang lebih besar.
Beberapa node besar atau banyak node kecil?
Jadi, mana yang lebih baik: beberapa node besar dalam satu cluster atau banyak node kecil? Seperti biasa, tidak ada jawaban yang jelas. Banyak hal bergantung pada jenis aplikasinya.
Misalnya, jika suatu aplikasi memerlukan memori 10 GB, node yang lebih besar adalah pilihan yang tepat. Dan jika aplikasi memerlukan replikasi sepuluh kali lipat untuk ketersediaan tinggi, risiko menempatkan replika hanya pada dua node saja tidak sepadan - minimal harus ada sepuluh node dalam cluster.
Dalam situasi peralihan, buatlah pilihan berdasarkan kelebihan dan kekurangan masing-masing pilihan. Mungkin beberapa argumen lebih relevan dengan situasi Anda dibandingkan argumen lainnya.
Dan sama sekali tidak perlu membuat semua node berukuran sama. Tidak ada yang menghalangi Anda untuk bereksperimen terlebih dahulu dengan node dengan ukuran yang sama, kemudian menambahkan node dengan ukuran berbeda ke dalamnya, menggabungkannya dalam sebuah cluster. Node pekerja di cluster Kubernetes bisa sangat heterogen. Jadi Anda bisa mencoba menggabungkan keunggulan kedua pendekatan tersebut.
Tidak ada resep tunggal, dan setiap situasi memiliki nuansa tersendiri, dan hanya produksi yang akan menunjukkan kebenarannya.
Terjemahan disiapkan oleh tim platform cloud .
Lebih lanjut tentang Kubernet: .
Sumber: www.habr.com