Meskipun umumnya merupakan praktik terbaik untuk menggunakan sesedikit mungkin cluster, organisasi memilih untuk men-deploy beberapa cluster guna mencapai tujuan teknis dan bisnis mereka karena berbagai alasan. Setidaknya, sebagian besar organisasi memisahkan non-produksi dari layanan produksi dengan menempatkannya di cluster yang berbeda. Dalam skenario yang lebih kompleks, organisasi mungkin memilih beberapa cluster untuk memisahkan layanan di seluruh tingkat, lokalitas, tim, atau penyedia infrastruktur.
Sebagian besar alasan untuk mengadopsi beberapa klaster masuk ke dalam tiga kategori persyaratan:
- Isolasi: memisahkan bidang kontrol dan bidang data layanan, terutama untuk meningkatkan keandalan atau memenuhi kebutuhan keamanan
- Lokasi: menempatkan layanan di lokasi tertentu untuk memenuhi kebutuhan ketersediaan, latensi, dan lokalitas
- Skala: terutama dalam konteks cluster Kubernetes, penskalaan layanan melampaui batas praktis yang diberlakukan oleh satu cluster
Kami akan membahasnya secara lebih mendetail di bagian berikut.
Dalam banyak kasus, organisasi perlu menyeimbangkan beberapa persyaratan ini secara bersamaan. Saat memikirkan organisasi Anda sendiri, ingat bahwa rekomendasi umum kami adalah menggunakan cluster sesedikit mungkin. Tentukan kebutuhan multi-cluster mana yang merupakan prioritas tertinggi bagi organisasi Anda dan yang tidak dapat dibobol, lalu buat kompromi yang sesuai untuk membuat arsitektur multi-cluster.
Jika Anda mendapati organisasi Anda mempertimbangkan mode cluster per model layanan atau cluster-per-team, Anda mungkin ingin mempertimbangkan beban pengelolaan yang diberlakukan pada operator sistem tersebut. Armada serta komponen dan fitur Google Cloud yang mendukungnya berupaya untuk membuat pengelolaan beberapa cluster semudah mungkin, tetapi selalu ada kompleksitas pengelolaan tambahan dengan lebih banyak cluster.
Isolasi
Dalam konteks ini, isolasi mengacu pada pemisahan bidang kontrol dan/atau bidang data, yang keduanya dapat dilakukan dengan menjalankan beberapa cluster. Namun, bergantung pada implementasinya, pemisahan ini kemungkinan juga meluas ke isolasi bidang data. Isolasi biasanya muncul ketika mempertimbangkan hal berikut:
Lingkungan
Organisasi sering kali menjalankan layanan pengembangan, staging/pengujian, dan produksi di berbagai cluster terpisah, yang sering kali berjalan di jaringan dan project cloud yang berbeda. Pemisahan ini dilakukan untuk menghindari gangguan layanan produksi yang tidak disengaja dan mencegah akses ke data sensitif selama pengembangan atau pengujian.Pemtingkatan beban kerja
Sering kali organisasi yang memiliki banyak aplikasi kompleks tingkat aplikasi mereka memilih untuk menjalankan layanan yang lebih penting di cluster terpisah dari cluster yang kurang penting. Dalam lingkungan seperti itu, layanan yang lebih penting ini dan clusternya diperlakukan dengan pertimbangan khusus seputar akses, keamanan, upgrade, kebijakan, dan lain-lain. Contoh tingkatan ini memisahkan layanan stateless dan stateful dengan menempatkannya pada cluster terpisah.Mengurangi dampak dari kegagalan
Saat ingin membatasi dampak kesalahan operator, kegagalan cluster, atau kegagalan infrastruktur terkait, organisasi dapat membagi layanannya di beberapa cluster.Upgrade
Jika organisasi khawatir dengan potensi masalah terkait upgrade yang diterapkan (yaitu, kegagalan otomatisasi upgrade, ketidakstabilan aplikasi, atau kemampuan untuk melakukan roll back), mereka dapat memilih untuk men-deploy salinan layanan mereka di cluster baru. Mengupgrade dengan cara ini memerlukan perencanaan atau otomatisasi untuk mewujudkannya. Pastikan untuk mengatasi pengelolaan traffic dan replikasi status selama proses upgrade.Pemisahan keamanan/peraturan
Organisasi dapat memilih untuk mengisolasi layanan karena berbagai alasan, termasuk menjaga agar beban kerja tetap tunduk kepada persyaratan peraturan yang terpisah dari persyaratan peraturan yang kurang sensitif, atau menjalankan layanan pihak ketiga (kurang tepercaya) pada infrastruktur yang terpisah dari layanan pihak pertama (cluster).Pemisahan tenant
Memisahkan tenant menjadi beberapa cluster sering kali dilakukan karena berbagai alasan, termasuk isolasi keamanan, isolasi performa, penghitungan biaya, dan bahkan kepemilikan.
Location
Latensi
Layanan tertentu memiliki persyaratan latensi yang harus dipenuhi dengan menemukan beban kerja tersebut secara fisik di lokasi (atau geografi) tertentu. Kebutuhan ini dapat terjadi jika layanan upstream atau pengguna akhir sensitif terhadap latensi, tetapi juga dapat terjadi dengan mudah jika beban kerja itu sendiri sensitif terhadap latensi layanan downstream.Ketersediaan
Menjalankan layanan yang sama di beberapa zona ketersediaan pada satu penyedia cloud (atau pada beberapa penyedia) dapat memberikan ketersediaan keseluruhan yang lebih tinggi.Wilayah Hukum
Residensi data dan persyaratan pemrosesan yurisdiksi lainnya mungkin memerlukan komputasi dan penyimpanan untuk berada di region tertentu, sehingga infrastruktur harus di-deploy di beberapa pusat data atau penyedia cloud.Gravitasi data
Korpus data yang besar, atau bahkan instance database tertentu, bisa jadi sulit, tidak mungkin, atau bahkan tidak disarankan untuk digabungkan dalam satu penyedia atau region cloud. Bergantung pada persyaratan pemrosesan dan penayangan, aplikasi mungkin perlu di-deploy di dekat datanya.Infrastruktur/layanan lama
Sama seperti data yang mungkin sulit dipindahkan ke cloud, beberapa infrastruktur lama juga sulit dipindahkan. Meskipun layanan lama ini tidak dapat diubah, men-deploy cluster tambahan untuk pengembangan layanan baru memungkinkan organisasi meningkatkan kecepatan pengembangan.Pilihan developer
Organisasi sering kali diuntungkan karena dapat memberi developer pilihan dalam layanan terkelola cloud yang mereka gunakan. Umumnya, pilihan memungkinkan tim bergerak lebih cepat dengan alat yang paling sesuai dengan kebutuhan mereka dengan mengorbankan perlu mengelola resource tambahan yang dialokasikan di setiap penyedia.Kebutuhan komputasi lokal/edge
Terakhir, karena organisasi ingin mengadopsi praktik modernisasi aplikasi di lingkungan kerja yang lebih tradisional, seperti gudang, lantai pabrik, toko eceran, dan sebagainya, hal ini mengharuskan pengelolaan lebih banyak beban kerja di lebih banyak infrastruktur.
Skala
Karena GKE dapat menskalakan cluster hingga lebih dari 5.000 node, batas ini jarang menjadi alasan untuk mengoperasikan beberapa cluster. Sebelum cluster mencapai batas skalabilitas, organisasi sering kali memutuskan untuk mendistribusikan layanan di beberapa cluster. Untuk cluster yang mencapai batas skalabilitas, menjalankan aplikasi di beberapa cluster dapat meringankan beberapa tantangan, tetapi dengan kompleksitas tambahan, yaitu mengelola beberapa cluster.