Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
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 Google Cloud
komponen serta fitur yang mendukungnya
berupaya membuat pengelolaan beberapa cluster semudah mungkin, tetapi selalu ada
beberapa kerumitan 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 workload 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.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-07-31 UTC."],[],[],null,["# Multi-cluster use cases\n\nWhile it is generally a best practice to use as few clusters as possible,\norganizations choose to deploy multiple clusters to achieve their technical and\nbusiness objectives for a variety of reasons. At a minimum, most organizations\nseparate their non-production from their production services by placing them in\ndifferent clusters. In more complex scenarios, organizations might choose\nmultiple clusters to separate services across tiers, locales, teams, or\ninfrastructure providers.\n\nMost reasons for adopting multiple clusters fall into three categories\nof requirements:\n\n- **Isolation:** separating the control plane and data plane of services, primarily to improve reliability or address security needs\n- **Location:** placing services in specific locations to address availability, latency, and locality needs\n- **Scale:** especially in the context of Kubernetes clusters, scaling services beyond the practical limits imposed by a single cluster\n\nWe look at these in more detail in the following sections.\n\nIn many cases, organizations need to balance several of these requirements\nsimultaneously. As you think about your own organization, remember that our\ngeneral recommendation is to use as few clusters as possible. Determine which\nof the multi-cluster needs are the highest priority for your organization and\ncannot be compromised, and then make appropriate tradeoffs to create a\nmulti-cluster architecture.\n\nIf you find your organization considering a *cluster per service-model* or a\n*cluster-per-team* mode, you might want to consider the management burden\nimposed on the operators of such a system.\n[Fleets](/kubernetes-engine/fleet-management/docs/fleet-concepts) and the Google Cloud\n[components and features that support them](/kubernetes-engine/fleet-management/docs)\nstrive to make managing multiple clusters as easy as possible, but there is\nalways some additional management complexity with more clusters.\n\nIsolation\n---------\n\nIn this context, *isolation* refers to separation of the control plane and/or\ndata plane, both of which can be achieved by running multiple clusters. However,\ndepending on implementation, this separation likely also extends to data plane\nisolation. Isolation usually comes up when considering the following:\n\n- **Environment** \n\n More often than not, organizations run their development, staging/test, and production\n services across separate clusters, often running on different networks and cloud\n projects. This separation is done to avoid accidental disruption of production\n services and prevent access to sensitive data during development or testing.\n\n- **Workload tiering** \n\n Often organizations that have many complex applications tier their\n services, choosing to run their more critical services on separate clusters from\n their less critical ones. In such an environment, these more critical services\n and their clusters are treated with special consideration around access,\n security, upgrades, policy, and more. An example of this tiering is separating\n *stateless* and *stateful* services by placing them on separate clusters.\n\n- **Reduced impact from failure** \n\n When organizations want to limit the impacts of an operator mistake, cluster\n failure, or related infrastructure failure, they can split their services\n across multiple clusters.\n\n- **Upgrades** \n\n When organizations are concerned about potential issues with upgrading in-place\n (that is, upgrading automation failure, application flakiness, or the ability to\n roll back), they can choose to deploy a copy of their services in a new cluster.\n Upgrading in this fashion requires planning or automation to make it possible,\n being sure to address traffic management and state replication during the\n upgrade process.\n\n- **Security/regulatory separation** \n\n Organizations can choose to isolate services for many reasons, including keeping\n workloads subject to regulatory requirements separate from less-sensitive ones,\n or running third-party (less-trusted) services on separate infrastructure from\n first-party (trusted) services (clusters).\n\n- **Tenant separation** \n\n Separating tenants into multiple clusters is often done for a variety of reasons,\n including security isolation, performance isolation, cost accounting, and\n even ownership.\n\nLocation\n--------\n\n- **Latency** \n\n Certain services have latency requirements that must be met by physically\n locating that workload in a specific location (or geography). This need can\n occur if upstream services or end-users are sensitive to latency, but can also\n easily occur if the workload itself is sensitive to downstream service latency.\n\n- **Availability** \n\n Running the same service across multiple availability zones in a single-cloud\n provider (or across multiple providers) can provide higher overall availability.\n\n- **Jurisdiction** \n\n Data residency and other jurisdictional processing requirements can require\n compute and storage to live within a specific region, requiring infrastructure\n to be deployed in multiple data centers or cloud providers.\n\n- **Data gravity** \n\n A large corpus of data, or even certain database instances, can be difficult,\n impossible, or even inadvisable to consolidate in a single cloud provider or\n region. Depending on the processing and serving requirements, an application\n might need to be deployed close to its data.\n\n- **Legacy infrastructure/services** \n\n Just as data can be difficult to move to the cloud, some legacy infrastructure\n is similarly difficult to move. Although these legacy services are immobile, deploying additional clusters for the development of new services allows organizations to increase development velocity.\n\n- **Developer choice** \n\n Organizations often benefit from being able to provide developers choice in\n the cloud-managed services that they consume. Generally, choice lets teams move\n more quickly with tools that are best-suited to their needs at the expense of\n needing to manage additional resources allocated in each provider.\n\n- **Local/edge compute needs** \n\n Finally, as organizations want to adopt application modernization practices in\n more traditional work environments, like warehouses, factory floors, retail\n stores, and so on, this necessitates managing many more workloads on many more\n pieces of infrastructure.\n\nScale\n-----\n\nBecause GKE can scale clusters to more than\n[5000 nodes](/kubernetes-engine/docs/concepts/planning-large-workloads#above-5000),\nthese limits rarely become a reason to operate multiple clusters. Before a\ncluster reaches scalability limits, organizations often decide to distribute\nservices across multiple clusters. For clusters that do reach scalability\nlimits, running an application across multiple clusters can ease some\nchallenges, but with the added complexity of managing multiple clusters."]]
