Meskipun umumnya praktik terbaiknya adalah menggunakan cluster sesedikit mungkin, organisasi memilih untuk men-deploy beberapa cluster guna mencapai tujuan teknis dan bisnis mereka karena berbagai alasan. Setidaknya, sebagian besar organisasi memisahkan layanan non-produksi dari layanan produksi dengan menempatkannya di cluster yang berbeda. Dalam skenario yang lebih kompleks, organisasi dapat memilih beberapa cluster untuk memisahkan layanan di berbagai tingkat, lokalitas, tim, atau penyedia infrastruktur.
Sebagian besar alasan untuk mengadopsi beberapa cluster terbagi menjadi 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, menskalakan layanan di luar batas praktis yang diberlakukan oleh satu cluster
Kita akan membahasnya secara lebih mendetail di bagian berikut.
Dalam banyak kasus, organisasi perlu menyeimbangkan beberapa persyaratan ini secara bersamaan. Saat Anda memikirkan organisasi Anda sendiri, ingatlah bahwa rekomendasi umum kami adalah menggunakan cluster sesedikit mungkin. Tentukan kebutuhan multi-cluster mana yang merupakan prioritas tertinggi bagi organisasi Anda dan tidak dapat dikompromikan, lalu buat kompromi yang sesuai untuk membuat arsitektur multi-cluster.
Jika organisasi Anda mempertimbangkan mode cluster per model layanan atau cluster per tim, sebaiknya pertimbangkan beban pengelolaan yang diberlakukan pada operator sistem tersebut. Fleet dan komponen serta fitur Google Cloud yang mendukungnya berupaya membuat pengelolaan beberapa cluster semudah mungkin, tetapi selalu ada beberapa kompleksitas pengelolaan tambahan dengan lebih banyak cluster.
Isolasi
Dalam konteks ini, isolasi mengacu pada pemisahan bidang kontrol dan/atau bidang data, yang keduanya dapat dicapai dengan menjalankan beberapa cluster. Namun, bergantung pada implementasi, pemisahan ini mungkin juga meluas ke isolasi data plane. Isolasi biasanya muncul saat mempertimbangkan hal-hal berikut:
Lingkungan
Sering kali, organisasi menjalankan layanan pengembangan, staging/pengujian, dan produksi mereka di seluruh cluster terpisah, yang sering kali berjalan di berbagai jaringan dan project cloud. Pemisahan ini dilakukan untuk menghindari gangguan layanan produksi secara tidak sengaja dan mencegah akses ke data sensitif selama pengembangan atau pengujian.Tingkat beban kerja
Sering kali organisasi yang memiliki banyak aplikasi kompleks membuat tingkat layanan, dengan memilih untuk menjalankan layanan yang lebih penting di cluster terpisah dari layanan yang kurang penting. Dalam lingkungan seperti itu, layanan yang lebih penting ini dan cluster-nya diperlakukan dengan pertimbangan khusus terkait akses, keamanan, upgrade, kebijakan, dan lainnya. Contoh tingkatan ini adalah memisahkan layanan stateless dan stateful dengan menempatkannya di cluster terpisah.Dampak kegagalan yang berkurang
Jika 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 in-place (yaitu, kegagalan otomatisasi upgrade, aplikasi yang tidak stabil, atau kemampuan untuk melakukan rollback), mereka dapat memilih untuk men-deploy salinan layanan mereka di cluster baru. Mengupgrade dengan cara ini memerlukan perencanaan atau otomatisasi agar dapat dilakukan, dengan memastikan untuk menangani pengelolaan traffic dan replikasi status selama proses upgrade.Pemisahan keamanan/peraturan
Organisasi dapat memilih untuk mengisolasi layanan karena berbagai alasan, termasuk menjaga beban kerja yang tunduk pada persyaratan peraturan terpisah dari beban kerja yang kurang sensitif, atau menjalankan layanan pihak ketiga (kurang tepercaya) di infrastruktur terpisah dari layanan pihak pertama (tepercaya) (cluster).Pemisahan tenant
Memisahkan tenant ke dalam beberapa cluster sering dilakukan karena berbagai alasan, termasuk isolasi keamanan, isolasi performa, pencatatan biaya, dan bahkan kepemilikan.
Lokasi
Latency
Layanan tertentu memiliki persyaratan latensi yang harus dipenuhi dengan secara fisik menempatkan beban kerja tersebut 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 di satu penyedia cloud (atau di beberapa penyedia) dapat memberikan ketersediaan yang lebih tinggi secara keseluruhan.Yurisdiksi
Residensi data dan persyaratan pemrosesan yurisdiksi lainnya dapat mewajibkan komputasi dan penyimpanan berada dalam 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, mungkin sulit, tidak mungkin, atau bahkan tidak disarankan untuk digabungkan di satu penyedia cloud atau region. Bergantung pada persyaratan pemrosesan dan penayangan, aplikasi mungkin perlu di-deploy di dekat datanya.Infrastruktur/layanan lama
Sama seperti data yang sulit dipindahkan ke cloud, beberapa infrastruktur lama juga sulit dipindahkan. Meskipun layanan lama ini tidak dapat dipindahkan, men-deploy cluster tambahan untuk pengembangan layanan baru memungkinkan organisasi meningkatkan kecepatan pengembangan.Pilihan developer
Organisasi sering kali mendapatkan manfaat karena dapat memberikan pilihan kepada developer dalam layanan terkelola cloud yang mereka gunakan. Secara umum, pilihan memungkinkan tim bergerak lebih cepat dengan alat yang paling sesuai dengan kebutuhan mereka dengan mengorbankan kebutuhan untuk 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 retail, dan sebagainya, hal ini memerlukan 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 dalam mengelola beberapa cluster.