Catatan. terjemahan: materi ini dari proyek pendidikan adalah jawaban atas pertanyaan populer saat merancang infrastruktur berbasis Kubernetes. Kami berharap penjelasan yang cukup rinci tentang pro dan kontra dari setiap opsi akan membantu Anda membuat pilihan terbaik untuk proyek Anda.
TL; DR: kumpulan beban kerja yang sama dapat dijalankan pada beberapa cluster besar (setiap cluster akan memiliki jumlah beban kerja yang besar) atau pada banyak cluster kecil (dengan jumlah beban yang sedikit di setiap cluster).
Di bawah ini adalah tabel yang mengevaluasi pro dan kontra dari setiap pendekatan:
Saat menggunakan Kubernetes sebagai platform untuk menjalankan aplikasi, beberapa pertanyaan mendasar sering muncul mengenai seluk-beluk pengaturan cluster:
- Berapa banyak cluster yang harus saya gunakan?
- Seberapa besar saya harus membuatnya?
- Apa saja yang harus disertakan dalam setiap cluster?
Pada artikel ini, saya akan mencoba menjawab semua pertanyaan tersebut dengan menganalisis pro dan kontra dari setiap pendekatan.
Pernyataan sebuah pertanyaan
Sebagai pengembang perangkat lunak, Anda mungkin mengembangkan dan mengoperasikan banyak aplikasi secara bersamaan.
Selain itu, banyak contoh aplikasi ini yang cenderung berjalan di lingkungan yang berbeda - misalnya, lingkungan ini mungkin saja berjalan dev, uji ΠΈ melecut.
Hasilnya adalah keseluruhan matriks aplikasi dan lingkungan:
Aplikasi dan Lingkungan
Contoh di atas mewakili 3 aplikasi dan 3 lingkungan, sehingga menghasilkan total 9 opsi yang memungkinkan.
Setiap instance aplikasi adalah unit penerapan mandiri yang dapat digunakan secara independen terhadap yang lain.
Harap dicatat bahwa contoh aplikasi mungkin terdiri dari banyak komponen, seperti frontend, backend, database, dll. Dalam kasus aplikasi layanan mikro, instansnya akan mencakup semua layanan mikro.
Akibatnya, pengguna Kubernetes mempunyai beberapa pertanyaan:
- Haruskah semua contoh aplikasi ditempatkan dalam satu cluster?
- Apakah layak memiliki cluster terpisah untuk setiap contoh aplikasi?
- Atau mungkin kombinasi dari pendekatan di atas harus digunakan?
Semua opsi ini cukup layak, karena Kubernetes adalah sistem fleksibel yang tidak membatasi kemampuan pengguna.
Berikut beberapa cara yang mungkin:
- satu cluster umum yang besar;
- banyak kelompok kecil yang sangat terspesialisasi;
- satu cluster per aplikasi;
- satu cluster per lingkungan.
Seperti ditunjukkan di bawah, dua pendekatan pertama berada pada ujung yang berlawanan dalam skala pilihan:
Dari beberapa cluster besar (kiri) hingga banyak cluster kecil (kanan)
Secara umum, suatu cluster dianggap βlebih besarβ dibandingkan cluster lainnya jika cluster tersebut memiliki jumlah node dan pod yang lebih banyak. Misalnya, sebuah cluster dengan 10 node dan 100 pod lebih besar dari cluster dengan 1 node dan 10 pod.
Baiklah, mari kita mulai!
1. Satu cluster umum yang besar
Opsi pertama adalah menempatkan semua beban kerja dalam satu cluster:
Satu cluster besar
Dalam pendekatan ini, cluster digunakan sebagai universal platform infrastruktur β Anda cukup menerapkan semua yang Anda perlukan di cluster Kubernetes yang sudah ada.
Kubernetes memungkinkan bagian-bagian cluster dipisahkan secara logis satu sama lain, sehingga setiap instance aplikasi dapat memiliki namespace sendiri.
Mari kita lihat pro dan kontra dari pendekatan ini.
+ Penggunaan sumber daya yang efisien
Dengan satu cluster, Anda hanya memerlukan satu salinan dari semua sumber daya yang diperlukan untuk menjalankan dan mengelola cluster Kubernetes.
Misalnya, hal ini berlaku untuk node master. Biasanya, setiap cluster Kubernetes memiliki 3 node master, jadi untuk satu cluster, jumlahnya akan tetap sama (sebagai perbandingan, 10 cluster memerlukan 30 node master).
Kehalusan di atas juga berlaku untuk layanan lain yang beroperasi di seluruh cluster, seperti penyeimbang beban, pengontrol Ingress, sistem autentikasi, logging, dan pemantauan.
Dalam satu cluster, semua layanan ini dapat digunakan sekaligus untuk semua beban kerja (tidak perlu membuat salinannya, seperti halnya dengan beberapa cluster).
+ Murah
Sebagai konsekuensi dari hal di atas, jumlah cluster yang lebih sedikit biasanya lebih murah karena tidak ada biaya overhead.
Hal ini terutama berlaku untuk node master, yang dapat menghabiskan banyak uang terlepas dari bagaimana node tersebut dihosting (on-premise atau di cloud).
Beberapa layanan Kubernetes yang dikelola, seperti ΠΈΠ»ΠΈ , berikan lapisan kontrol secara gratis. Dalam hal ini, permasalahan biaya tidak terlalu akut.
Ada juga layanan terkelola yang membebankan biaya tetap untuk pengoperasian setiap cluster Kubernetes (misalnya, ).
+ Administrasi yang efisien
Mengelola satu cluster lebih mudah daripada mengelola beberapa cluster.
Administrasi dapat mencakup tugas-tugas berikut:
- Pembaruan versi Kubernetes;
- menyiapkan saluran CI/CD;
- menginstal plugin CNI;
- menyiapkan sistem otentikasi pengguna;
- pemasangan pengontrol akses;
dan banyak lagiβ¦
Dalam kasus satu cluster, Anda harus melakukan semua ini hanya sekali.
Bagi banyak cluster, operasi harus diulang berkali-kali, yang mungkin memerlukan beberapa otomatisasi proses dan alat untuk memastikan konsistensi dan konsistensi dalam proses.
Dan sekarang beberapa kata tentang kerugiannya.
β Satu titik kegagalan
Dalam kasus penolakan satu-satunya cluster akan segera berhenti bekerja semua beban kerja!
Ada banyak kemungkinan terjadinya kesalahan:
- memperbarui Kubernetes menyebabkan efek samping yang tidak terduga;
- Komponen seluruh klaster (misalnya, plugin CNI) mulai tidak berfungsi seperti yang diharapkan;
- salah satu komponen cluster tidak dikonfigurasi dengan benar;
- kegagalan pada infrastruktur yang mendasarinya.
Salah satu insiden tersebut dapat menyebabkan kerusakan serius pada semua beban kerja yang dihosting di klaster bersama.
β Tidak ada isolasi yang kaku
Berjalan di cluster bersama berarti aplikasi berbagi perangkat keras, kemampuan jaringan, dan sistem operasi pada node cluster.
Dalam arti tertentu, dua container dengan dua aplikasi berbeda yang berjalan pada node yang sama seperti dua proses yang berjalan pada mesin yang sama dan menjalankan kernel OS yang sama.
Kontainer Linux menyediakan beberapa bentuk isolasi, namun tidak sekuat yang disediakan oleh, misalnya, mesin virtual. Intinya, suatu proses dalam sebuah container adalah proses yang sama yang berjalan pada sistem operasi host.
Ini bisa menjadi masalah keamanan: pengaturan ini secara teoritis memungkinkan aplikasi yang tidak terkait untuk berkomunikasi satu sama lain (baik disengaja atau tidak sengaja).
Selain itu, semua beban kerja di klaster Kubernetes berbagi beberapa layanan di seluruh klaster seperti - ini memungkinkan aplikasi menemukan Layanan aplikasi lain di cluster.
Semua poin di atas mungkin memiliki arti berbeda tergantung pada persyaratan keamanan aplikasi.
Kubernetes menyediakan berbagai alat untuk mencegah masalah keamanan seperti ΠΈ . Namun, pengaturannya dengan benar memerlukan pengalaman; selain itu, mereka tidak mampu menutup semua lubang keamanan secara mutlak.
Penting untuk selalu diingat bahwa Kubernetes pada awalnya dirancang untuk itu membagikan, tidak untuk isolasi dan keamanan.
β Kurangnya multi-tenancy yang ketat
Mengingat banyaknya sumber daya bersama dalam klaster Kubernetes, ada banyak cara agar aplikasi yang berbeda dapat saling mengimbangi.
Misalnya, suatu aplikasi mungkin memonopoli sumber daya bersama (seperti CPU atau memori) dan menolak aplikasi lain yang berjalan pada node yang sama untuk mengaksesnya.
Kubernetes menyediakan berbagai mekanisme untuk mengendalikan perilaku ini, seperti (lihat juga artikel β" - kira-kira. terjemahan.), ΠΈ . Namun, seperti halnya keamanan, konfigurasinya tidak sepele dan tidak mampu mencegah semua efek samping yang tidak terduga.
β Jumlah pengguna yang banyak
Dalam kasus satu cluster, Anda harus membuka akses ke banyak orang. Dan semakin besar jumlahnya, semakin tinggi risiko mereka βmerusakβ sesuatu.
Di dalam cluster Anda dapat mengontrol siapa yang dapat melakukan apa dengan menggunakan (lihat artikel β" - kira-kira. terjemahan.). Namun, hal itu tidak akan mencegah pengguna untuk βmelanggarβ sesuatu dalam wilayah tanggung jawabnya.
β Cluster tidak dapat berkembang tanpa batas waktu
Cluster yang digunakan untuk semua beban kerja kemungkinan besar berukuran cukup besar (dalam hal jumlah node dan pod).
Namun di sini muncul masalah lain: cluster di Kubernetes tidak dapat berkembang tanpa batas.
Ada batasan teoretis mengenai ukuran cluster. Di Kubernetes kira-kira .
Namun, dalam kehidupan nyata, masalah bisa dimulai jauh lebih awal - misalnya, hanya dengan .
Faktanya adalah cluster yang besar memberikan beban yang tinggi pada lapisan kontrol Kubernetes. Dengan kata lain, menjaga agar cluster tetap aktif dan berjalan secara efisien memerlukan penyesuaian yang cermat.
Masalah ini dieksplorasi dalam artikel terkait di blog asli berjudul "'.
Namun mari kita pertimbangkan pendekatan sebaliknya: banyak kelompok kecil.
2. Banyak kelompok kecil yang terspesialisasi
Dengan pendekatan ini, Anda menggunakan cluster terpisah untuk setiap elemen yang Anda terapkan:
Banyak cluster kecil
Untuk keperluan artikel ini, di bawah elemen yang dapat diterapkan mengacu pada sebuah contoh aplikasi - misalnya, versi dev dari aplikasi terpisah.
Strategi ini menggunakan Kubernetes sebagai spesialisasinya waktu proses untuk contoh aplikasi individual.
Mari kita lihat pro dan kontra dari pendekatan ini.
+ βRadius ledakanβ terbatas
Ketika sebuah klaster gagal, konsekuensi negatifnya hanya terbatas pada beban kerja yang disebarkan di klaster tersebut. Semua beban kerja lainnya tetap tidak tersentuh.
+ Isolasi
Beban kerja yang dihosting di klaster individual tidak berbagi sumber daya seperti prosesor, memori, sistem operasi, jaringan, atau layanan lainnya.
Hasilnya adalah isolasi yang ketat antara aplikasi yang tidak terkait, yang dapat bermanfaat bagi keamanannya.
+ Sejumlah kecil pengguna
Mengingat bahwa setiap cluster hanya berisi serangkaian beban kerja terbatas, jumlah pengguna yang memiliki akses ke cluster tersebut berkurang.
Semakin sedikit orang yang memiliki akses ke cluster, semakin rendah risiko bahwa sesuatu akan βrusak.β
Mari kita lihat kekurangannya.
β Penggunaan sumber daya yang tidak efisien
Seperti disebutkan sebelumnya, setiap cluster Kubernetes memerlukan serangkaian sumber daya manajemen tertentu: node master, komponen lapisan kontrol, solusi pemantauan dan logging.
Dalam kasus klaster kecil dalam jumlah besar, porsi sumber daya yang lebih besar harus dialokasikan kepada manajemen.
β Mahal
Penggunaan sumber daya yang tidak efisien secara otomatis menimbulkan biaya yang tinggi.
Misalnya, mempertahankan 30 node master, bukan tiga node dengan daya komputasi yang sama, akan mempengaruhi biaya.
β Kesulitan dalam administrasi
Mengelola beberapa klaster Kubernetes jauh lebih sulit dibandingkan mengelola hanya satu klaster.
Misalnya, Anda harus mengonfigurasi otentikasi dan otorisasi untuk setiap cluster. Versi Kubernetes juga harus diperbarui beberapa kali.
Anda mungkin perlu menggunakan otomatisasi untuk membuat semua tugas ini lebih efisien.
Sekarang mari kita lihat skenario yang tidak terlalu ekstrem.
3. Satu cluster per aplikasi
Dalam pendekatan ini, Anda membuat cluster terpisah untuk semua instance aplikasi tertentu:
Cluster per aplikasi
Jalur ini dapat dianggap sebagai generalisasi dari prinsip βcluster terpisah per timβ, karena biasanya tim insinyur mengembangkan satu atau lebih aplikasi.
Mari kita lihat pro dan kontra dari pendekatan ini.
+ Clusternya bisa disesuaikan dengan aplikasi
Jika suatu aplikasi memiliki kebutuhan khusus, aplikasi tersebut dapat diimplementasikan dalam sebuah cluster tanpa mempengaruhi cluster lainnya.
Kebutuhan tersebut mungkin mencakup pekerja GPU, plugin CNI tertentu, mesh layanan, atau layanan lainnya.
Setiap cluster dapat disesuaikan dengan aplikasi yang berjalan di dalamnya sehingga hanya berisi apa yang dibutuhkan saja.
β Lingkungan berbeda dalam satu cluster
Kerugian dari pendekatan ini adalah bahwa contoh aplikasi dari lingkungan yang berbeda hidup berdampingan dalam cluster yang sama.
Misalnya, aplikasi versi prod berjalan di cluster yang sama dengan versi dev. Ini juga berarti bahwa pengembang beroperasi di cluster yang sama di mana versi produksi aplikasi dioperasikan.
Jika, karena tindakan pengembang atau gangguan pada versi dev, terjadi kegagalan pada cluster, maka versi prod berpotensi mengalami masalah juga - kelemahan besar dari pendekatan ini.
Dan terakhir, skenario terakhir dalam daftar kami.
4. Satu cluster per lingkungan
Skenario ini melibatkan pengalokasian cluster terpisah untuk setiap lingkungan:
Satu cluster per lingkungan
Misalnya, Anda mungkin memiliki cluster dev, uji ΠΈ melecut, di mana Anda akan menjalankan semua contoh aplikasi yang didedikasikan untuk lingkungan tertentu.
Berikut adalah pro dan kontra dari pendekatan ini.
+ Isolasi lingkungan produksi
Dalam pendekatan ini, semua lingkungan diisolasi satu sama lain. Namun, dalam praktiknya hal ini sangat penting dalam lingkungan produksi.
Versi produksi aplikasi sekarang tidak bergantung pada apa yang terjadi di klaster dan lingkungan lain.
Dengan cara ini, jika masalah tiba-tiba muncul di cluster dev, aplikasi versi prod akan terus bekerja seolah-olah tidak terjadi apa-apa.
+ Cluster dapat disesuaikan dengan lingkungan
Setiap cluster dapat disesuaikan dengan lingkungannya. Misalnya, Anda dapat:
- menginstal alat untuk pengembangan dan debugging di cluster dev;
- menginstal kerangka kerja dan alat pengujian di cluster uji;
- menggunakan perangkat keras dan saluran jaringan yang lebih kuat di cluster melecut.
Hal ini memungkinkan Anda meningkatkan efisiensi pengembangan dan pengoperasian aplikasi.
+ Membatasi akses ke cluster produksi
Kebutuhan untuk bekerja secara langsung dengan cluster prod jarang muncul, sehingga Anda dapat secara signifikan membatasi jumlah orang yang memiliki akses ke cluster tersebut.
Anda dapat melangkah lebih jauh dan menolak akses orang ke cluster ini sama sekali, dan melakukan semua penerapan menggunakan alat CI/CD otomatis. Pendekatan seperti ini akan meminimalkan risiko kesalahan manusia pada tempat yang paling relevan.
Dan sekarang beberapa kata tentang kerugiannya.
β Tidak ada isolasi antar aplikasi
Kerugian utama dari pendekatan ini adalah kurangnya isolasi perangkat keras dan sumber daya antar aplikasi.
Aplikasi yang tidak terkait berbagi sumber daya cluster: inti sistem, prosesor, memori, dan beberapa layanan lainnya.
Seperti yang telah disebutkan, hal ini berpotensi berbahaya.
- Ketidakmampuan untuk melokalisasi dependensi aplikasi
Jika suatu aplikasi memiliki persyaratan khusus, maka persyaratan tersebut harus dipenuhi di semua cluster.
Misalnya, jika suatu aplikasi memerlukan GPU, maka setiap cluster harus berisi setidaknya satu pekerja dengan GPU (meskipun hanya digunakan oleh aplikasi tersebut).
Akibatnya, kita menanggung risiko biaya yang lebih tinggi dan penggunaan sumber daya yang tidak efisien.
Kesimpulan
Jika Anda memiliki sekumpulan aplikasi tertentu, aplikasi tersebut dapat ditempatkan di beberapa cluster besar atau banyak cluster kecil.
Artikel ini membahas pro dan kontra dari berbagai pendekatan, mulai dari satu klaster global hingga beberapa klaster kecil dan sangat terspesialisasi:
- satu cluster umum yang besar;
- banyak kelompok kecil yang sangat terspesialisasi;
- satu cluster per aplikasi;
- satu cluster per lingkungan.
Jadi pendekatan mana yang harus Anda ambil?
Seperti biasa, jawabannya bergantung pada kasus penggunaan: Anda perlu mempertimbangkan pro dan kontra dari berbagai pendekatan dan memilih opsi yang paling optimal.
Namun, pilihannya tidak terbatas pada contoh di atas - Anda dapat menggunakan kombinasi keduanya!
Misalnya, Anda dapat mengatur beberapa klaster untuk setiap tim: klaster pengembangan (di dalamnya akan terdapat lingkungan dev ΠΈ uji) dan cluster untuk produksi (di mana lingkungan produksi akan berlokasi).
Berdasarkan informasi dalam artikel ini, Anda dapat mengoptimalkan pro dan kontra sesuai dengan skenario tertentu. Semoga beruntung!
PS
Baca juga di blog kami:
- «»;
- «»;
- «»;
- Β«'.
Sumber: www.habr.com