💭 👨‍🚀 🦄 Merancang Cluster Kubernetes: Berapa Banyak Seharusnya Ada? 🌭 🚦 🏊

Catatan perev. : Materi dari proyek pendidikan learnk8s ini adalah jawaban untuk pertanyaan populer saat merancang infrastruktur berdasarkan Kubernetes. Kami berharap deskripsi yang cukup rinci tentang pro dan kontra dari setiap opsi akan membantu untuk membuat pilihan terbaik untuk proyek Anda.

TL; DR : set beban kerja yang sama dapat dijalankan pada beberapa cluster besar (setiap cluster akan memiliki sejumlah besar beban kerja) atau pada banyak beban kecil (dengan sejumlah kecil beban di setiap cluster).

Tabel di bawah ini merangkum pro dan kontra dari setiap pendekatan:

Saat menggunakan Kubernetes sebagai platform untuk mengoperasikan aplikasi, beberapa pertanyaan mendasar tentang seluk-beluk konfigurasi cluster sering muncul:

Berapa banyak cluster yang digunakan?
Seberapa besar mereka?
Apa yang harus dimasukkan oleh setiap klaster?

Dalam artikel ini, saya akan mencoba menjawab semua pertanyaan ini dengan menganalisis pro dan kontra dari setiap pendekatan.

Pernyataan sebuah pertanyaan

Sebagai pembuat perangkat lunak, Anda cenderung mengembangkan dan mengoperasikan banyak aplikasi secara paralel.

Selain itu, banyak contoh aplikasi ini cenderung berjalan di berbagai lingkungan - misalnya, dapat berupa dev , test dan prod .

Hasilnya adalah seluruh matriks aplikasi dan lingkungan:

Aplikasi dan lingkungan

Dalam contoh di atas, 3 aplikasi dan 3 lingkungan disajikan, yang pada akhirnya memberikan 9 opsi yang memungkinkan.

Setiap instance aplikasi adalah unit penyebaran mandiri yang dapat dioperasikan secara independen dari yang lain.

Perhatikan bahwa instance aplikasi dapat terdiri dari banyak komponen.seperti frontend, backend, database, dll. Dalam hal aplikasi layanan mikro, instance akan mencakup semua layanan microser.

Akibatnya, pengguna Kubernetes memiliki beberapa pertanyaan:

Haruskah saya menempatkan semua instance aplikasi dalam satu cluster?
Haruskah saya membuat cluster terpisah untuk setiap instance aplikasi?
Atau mungkin Anda harus menggunakan kombinasi pendekatan di atas?

Semua opsi ini cukup layak, karena Kubernetes adalah sistem fleksibel yang tidak membatasi kemungkinan pengguna.

Berikut adalah beberapa cara yang mungkin:

satu cluster umum besar;
banyak kelompok kecil yang sangat terspesialisasi;
satu cluster untuk setiap aplikasi;
satu cluster untuk setiap lingkungan.

Seperti ditunjukkan di bawah ini, dua pendekatan pertama berada di ujung yang berlawanan dari skala opsi:

Dari beberapa kelompok besar (di sebelah kiri) ke banyak kelompok kecil (di sebelah kanan)

Secara umum, satu kelompok dianggap “lebih besar” daripada yang lain jika memiliki jumlah simpul dan polong yang lebih besar. Sebagai contoh, sebuah cluster dengan 10 node dan 100 pod lebih besar dari sebuah cluster dengan 1 node dan 10 pod.

Baiklah, mari kita mulai!

1. Satu cluster umum besar

Opsi pertama adalah menempatkan semua beban kerja dalam satu klaster:

Satu klaster besar

Sebagai bagian dari pendekatan ini, klaster ini digunakan sebagai platform infrastruktur universal - Anda hanya menggunakan semua yang Anda butuhkan di kluster Kubernet yang ada.

Namespace'y Kubernetes memungkinkan secara logis memisahkan bagian dari satu sama lain, sehingga ruang namanya dapat digunakan untuk setiap instance aplikasi.

Mari kita lihat pro dan kontra dari pendekatan ini.

+ Penggunaan sumber daya secara efisien

Dalam kasus satu cluster, hanya satu salinan dari semua sumber daya yang diperlukan untuk memulai dan mengelola cluster Kubernetes diperlukan.

Sebagai contoh, ini berlaku untuk node master. Biasanya ada 3 node master untuk setiap cluster Kubernetes, jadi untuk satu cluster tunggal jumlahnya akan tetap begitu (untuk perbandingan, 10 cluster akan membutuhkan 30 node master).

Kehalusan di atas berlaku untuk layanan lain yang beroperasi pada basis cluster-luas, seperti penyeimbang beban, pengontrol masuknya, otentikasi, logging dan sistem pemantauan.

Dalam satu cluster, semua layanan ini dapat segera digunakan untuk semua beban kerja (Anda tidak perlu membuat salinannya, seperti dalam kasus beberapa cluster).

+ Murah

Sebagai konsekuensi dari hal tersebut di atas, sejumlah kecil cluster biasanya lebih murah karena tidak ada biaya untuk kelebihan sumber daya.

Hal ini terutama berlaku untuk node master, yang dapat menelan biaya uang yang signifikan terlepas dari metode penempatan (di tempat atau di cloud).

Beberapa layanan Kubernet yang dikelola, seperti Google Kubernetes Engine (GKE) atau Azure Kubernetes Service (AKS) , menyediakan lapisan kontrol secara gratis. Dalam hal ini, masalah biaya kurang akut.

Ada juga layanan terkelola yang mengenakan biaya tetap untuk setiap cluster Kubernetes (misalnya, Layanan Amazon Elastic Kubernetes, EKS ).

+ Administrasi yang efektif

Mengelola satu kluster lebih mudah daripada beberapa.

Administrasi dapat mencakup tugas-tugas berikut:

perbarui versi Kubernetes;
Konfigurasi pipa CI / CD
Instalasi plugin CNI;
mengatur sistem otentikasi pengguna;
pengaturan pengontrol akses;

dan banyak lainnya ...

Dalam kasus satu cluster, semua ini harus dilakukan hanya sekali.

Untuk banyak kluster, operasi harus diulang berkali-kali, yang mungkin akan memerlukan beberapa otomatisasi proses dan alat untuk memastikan proses yang sistematis dan seragam.

Dan sekarang beberapa kata tentang kontra.

- Titik kegagalan

Jika terjadi kegagalan klaster tunggal , semua beban kerja akan berhenti bekerja segera !

Ada banyak opsi saat ada yang salah:

memperbarui Kubernetes mengarah ke efek samping yang tidak terduga;
komponen cluster-wide (misalnya, plugin CNI) tidak berfungsi seperti yang diharapkan;
Salah satu komponen cluster tidak dikonfigurasi dengan benar.
kegagalan dalam infrastruktur yang mendasarinya.

Salah satu insiden tersebut dapat menyebabkan kerusakan serius pada semua beban kerja yang terletak di cluster umum.

- Kurangnya isolasi keras

Bekerja dalam cluster bersama berarti aplikasi berbagi perangkat keras, kemampuan jaringan, dan sistem operasi pada node cluster.

Dalam arti tertentu, dua wadah dengan dua aplikasi berbeda yang berjalan pada node yang sama mirip dengan dua proses yang berjalan pada mesin yang sama yang menjalankan kernel OS yang sama.

Wadah Linux menyediakan beberapa bentuk isolasi, tetapi jauh dari sekuat yang disediakan oleh, katakanlah, mesin virtual. Intinya, proses dalam sebuah wadah adalah proses yang sama yang berjalan pada sistem operasi host.

Ini bisa menjadi masalah keamanan: organisasi semacam itu secara teoritis memungkinkan aplikasi yang tidak terkait untuk berinteraksi satu sama lain (sengaja atau tidak sengaja).

Selain itu, semua beban kerja di cluster Kubernetes berbagi beberapa layanan cluster-lebar, seperti DNS - ini memungkinkan aplikasi untuk menemukan Layanan aplikasi lain dalam cluster.

Semua item di atas mungkin memiliki arti yang berbeda tergantung pada persyaratan untuk keamanan aplikasi.

Kubernetes menyediakan berbagai alat untuk mencegah masalah keamanan, seperti PodSecurityPolicies dan NetworkPolicies . Namun, untuk konfigurasi yang tepat memerlukan beberapa pengalaman tambahan, mereka tidak dapat menutup semua lubang keamanan.

Penting untuk selalu mengingat bahwa Kubernet awalnya dirancang untuk berbagi.dan bukan untuk isolasi dan keamanan .

- Kurangnya multi-tenancy yang ketat

Mengingat berlimpahnya sumber daya bersama di kluster Kubernetes, ada banyak cara di mana aplikasi yang berbeda dapat “saling menghantam”.

Misalnya, aplikasi dapat memonopoli sumber daya bersama (seperti prosesor atau memori) dan menghilangkan aplikasi lain yang berjalan pada simpul akses yang sama.

Kubernetes menyediakan berbagai mekanisme untuk mengendalikan perilaku seperti itu, seperti permintaan dan batas sumber daya (lihat juga artikel " Batas CPU dan pembatasan agresif di Kubernetes " - sekitar. Terjemahan.) , ResourceQuotas dan LimitRanges . Namun, seperti dalam hal keamanan, konfigurasinya cukup non-trivial dan mereka tidak dapat mencegah sepenuhnya semua efek samping yang tidak terduga.

- Sejumlah besar pengguna

Dalam kasus satu cluster, banyak orang harus membuka akses ke sana. Dan semakin besar jumlahnya, semakin tinggi pula risiko bahwa mereka akan “memecahkan sesuatu”.

Di dalam cluster, Anda dapat mengontrol siapa dan apa yang dapat dilakukan dengan menggunakan kontrol akses berbasis peran (RBAC) (lihat artikel " Pengguna dan Otorisasi RBAC di Kubernetes " - kira-kira Transfer ) . Namun, itu tidak akan mencegah pengguna dari "melanggar" sesuatu dalam batas-batas wilayah tanggung jawab mereka.

- Cluster tidak dapat tumbuh tanpa batas

Cluster yang digunakan untuk semua beban kerja mungkin akan cukup besar (dalam hal jumlah node dan pod).

Tapi di sini muncul masalah lain: cluster di Kubernetes tidak bisa tumbuh tanpa batas.

Ada batasan teoritis tentang ukuran cluster. Di Kubernetes, sekitar 5.000 node, 150 ribu pod dan 300 ribu kontainer .

Namun, dalam kehidupan nyata, masalah dapat dimulai jauh lebih awal - misalnya, hanya 500 node .

Faktanya adalah bahwa cluster besar mengerahkan beban tinggi pada lapisan kontrol Kubernetes. Dengan kata lain, untuk menjaga operasional cluster dan menggunakan sumber daya secara efisien, diperlukan penyetelan yang hati-hati.

Masalah ini dieksplorasi dalam artikel terkait di blog asli berjudul " Arsitektur cluster Kubernetes - memilih ukuran simpul pekerja ".

Tapi mari kita lihat pendekatan yang berlawanan: banyak kelompok kecil.

2. Banyak kelompok kecil dan khusus

Dengan pendekatan ini, Anda menggunakan kluster terpisah untuk setiap elemen yang dapat digunakan:

Banyak kelompok kecil

Untuk keperluan artikel ini, elemen yang dapat digunakan mengacu pada instance aplikasi - misalnya, versi dev dari aplikasi terpisah.

Strategi ini menggunakan Kubernetes sebagai runtime khusus untuk instance aplikasi individual.

Mari kita lihat pro dan kontra dari pendekatan ini.

+ "Radius ledakan" terbatas

Ketika gugus mogok, konsekuensi negatif hanya terbatas pada beban kerja yang dikerahkan di gugus ini. Semua beban kerja lainnya tetap utuh.

+ Isolasi

Beban kerja yang dihosting pada kelompok individu tidak berbagi sumber daya seperti prosesor, memori, sistem operasi, jaringan, atau layanan lainnya.

Akibatnya, kami mendapatkan isolasi ketat antara aplikasi yang tidak terkait, yang mungkin mempengaruhi keamanannya.

+ Sejumlah kecil pengguna

Mengingat bahwa setiap cluster hanya berisi satu set beban kerja terbatas, jumlah pengguna dengan akses ke itu berkurang.

Semakin sedikit orang yang memiliki akses ke cluster, semakin rendah risiko bahwa sesuatu akan “pecah”.

Mari kita lihat kontra.

- Penggunaan sumber daya yang tidak efisien

Seperti yang disebutkan sebelumnya, setiap klaster Kubernetes memerlukan seperangkat sumber daya kontrol tertentu: master node, komponen dari lapisan kontrol, solusi untuk pemantauan dan penebangan.

Dalam kasus sejumlah besar kelompok kecil, perlu mengalokasikan sumber daya yang lebih besar untuk manajemen.

- Harga tinggi

Penggunaan sumber daya yang tidak efisien secara otomatis memerlukan biaya tinggi.

Misalnya, pemeliharaan 30 master node bukan tiga dengan daya komputasi yang sama akan mempengaruhi biaya.

- Kesulitan administrasi

Mengelola beberapa kluster Kubernet jauh lebih sulit daripada mengaturnya.

Misalnya, Anda harus mengonfigurasi otentikasi dan otorisasi untuk setiap cluster. Memperbarui versi Kubernetes juga harus dilakukan beberapa kali.

Kemungkinan besar, Anda harus menerapkan otomatisasi untuk meningkatkan efektivitas semua tugas ini.

Sekarang pertimbangkan skenario yang kurang ekstrim.

3. Satu cluster per aplikasi

Sebagai bagian dari pendekatan ini, Anda membuat cluster terpisah untuk semua contoh aplikasi tertentu:

Cluster per aplikasi

Dengan cara ini dapat dianggap sebagai generalisasi dari prinsip " cluster terpisah per tim ", karena biasanya tim insinyur terlibat dalam pengembangan satu atau lebih aplikasi.

Mari kita lihat pro dan kontra dari pendekatan ini.

+ Cluster dapat disesuaikan untuk aplikasi

Jika aplikasi memiliki kebutuhan khusus, mereka dapat diimplementasikan dalam sebuah cluster tanpa mempengaruhi cluster lainnya.

Kebutuhan tersebut dapat mencakup pekerja GPU, plugin CNI tertentu, service mesh, atau layanan lain.

Setiap cluster dapat disesuaikan dengan aplikasi yang berjalan di dalamnya sehingga hanya berisi apa yang dibutuhkan.

- Lingkungan berbeda dalam satu cluster

Kerugian dari pendekatan ini adalah bahwa instance aplikasi dari lingkungan yang berbeda hidup berdampingan dalam cluster yang sama.

Misalnya, versi prod dari aplikasi berjalan di cluster yang sama dengan versi dev. Ini juga berarti bahwa pengembang melakukan aktivitas mereka di kluster yang sama di mana versi produksi aplikasi dioperasikan.

Jika, karena tindakan pengembang atau gangguan dari versi dev di cluster, kegagalan terjadi, maka versi prod berpotensi dapat menderita - kelemahan besar dari pendekatan ini.

Dan akhirnya, skrip terakhir dalam daftar kami.

4. Satu cluster untuk setiap lingkungan

Skenario ini memberikan alokasi cluster terpisah untuk masing-masing lingkungan:

Satu cluster untuk lingkungan

Sebagai contoh, Anda dapat memiliki cluster dev , test dan prod di mana Anda akan menjalankan semua instance aplikasi yang dirancang untuk lingkungan tertentu.

Inilah pro dan kontra dari pendekatan ini.

+ Isolasi lingkungan prod

Dalam pendekatan ini, semua lingkungan terisolasi satu sama lain. Namun, dalam praktiknya, ini sangat penting untuk lingkungan prod.

Versi produksi aplikasi sekarang tidak tergantung pada apa yang terjadi di cluster dan lingkungan lain.

Dengan demikian, jika masalah tiba-tiba muncul di klaster dev, versi prod aplikasi akan terus bekerja seolah-olah tidak ada yang terjadi.

+ Cluster dapat disesuaikan dengan lingkungan

Setiap cluster dapat disesuaikan dengan lingkungannya. Misalnya, Anda dapat:

menginstal alat pengembangan dan debugging di cluster dev;
instal kerangka kerja pengujian dan alat-alat dalam kelompok uji ;
Gunakan peralatan dan saluran jaringan yang lebih kuat di kluster produk .

Ini memungkinkan Anda untuk meningkatkan efisiensi pengembangan dan pengoperasian aplikasi.

+ Batasi akses ke kluster produksi

Kebutuhan untuk bekerja dengan kluster prod langsung muncul jarang, sehingga Anda dapat secara signifikan membatasi lingkaran orang yang memiliki akses ke sana.

Anda dapat melangkah lebih jauh dan secara umum menghilangkan akses orang ke kluster ini, dan melakukan semua penyebaran menggunakan alat CI / CD otomatis. Pendekatan semacam itu akan meminimalkan risiko kesalahan manusia persis di tempat yang paling relevan.

Dan sekarang beberapa kata tentang kontra.

- Kurangnya isolasi antara aplikasi

Kelemahan utama dari pendekatan ini adalah kurangnya perangkat keras dan isolasi sumber daya antara aplikasi.

Aplikasi yang tidak terkait berbagi sumber daya klaster: inti sistem, prosesor, memori, dan beberapa layanan lainnya.

Seperti yang sudah disebutkan, ini bisa berpotensi berbahaya.

- Ketidakmampuan untuk melokalisasi ketergantungan aplikasi

Jika aplikasi memiliki persyaratan khusus, maka mereka harus dipenuhi di semua cluster.

Sebagai contoh, jika suatu aplikasi membutuhkan GPU, maka setiap cluster harus mengandung setidaknya satu pekerja dengan GPU (bahkan jika itu hanya digunakan oleh aplikasi itu).

Akibatnya, kami menghadapi risiko biaya yang lebih tinggi dan penggunaan sumber daya yang tidak efisien.

Kesimpulan

Jika Anda memiliki seperangkat aplikasi tertentu, Anda dapat menempatkannya di beberapa kluster besar atau di banyak kluster kecil.

Artikel ini membahas pro dan kontra dari berbagai pendekatan, mulai dari satu klaster global hingga beberapa yang kecil dan sangat terspesialisasi:

satu cluster umum besar;
banyak kelompok kecil yang sangat terspesialisasi;
satu cluster untuk setiap aplikasi;
satu cluster untuk setiap lingkungan.

Jadi, pendekatan mana yang harus dipilih?

Seperti biasa, jawabannya tergantung pada use case: 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 mereka!

Misalnya, Anda dapat mengatur sepasang cluster per tim: sebuah cluster untuk pengembangan (yang akan memiliki lingkungan pengembang dan pengujian ) dan sebuah cluster untuk produksi (di mana lingkungan produksi akan berada).

Berdasarkan informasi dalam artikel ini, Anda dapat mengoptimalkan pro dan kontra sesuai untuk skenario tertentu. Semoga berhasil

Merancang Cluster Kubernetes: Berapa Banyak Seharusnya Ada?