Halaman ini menyediakan ringkasan tentang cara kerja
Service multi-cluster GKE (MCS). Untuk mempelajari cara menggunakan MCS, lihat
Mengonfigurasi Service multi-cluster.
Ringkasan MCS
Dengan objek Service Kubernetes yang sudah dikenal, Anda dapat menemukan dan mengakses Service dalam cakupan satu cluster Kubernetes. Namun, terkadang Anda mungkin ingin
membagi aplikasi menjadi beberapa cluster untuk memenuhi persyaratan pengelolaan status, privasi,
skalabilitas, ketersediaan, dan kedaulatan data. Dengan MCS, Anda dapat membangun aplikasi Kubernetes yang mencakup beberapa cluster.
MCS adalah mekanisme penemuan dan pemanggilan
layanan lintas cluster untuk Google Kubernetes Engine (GKE) yang memanfaatkan objek
Service yang ada. Service yang diaktifkan dengan fitur ini dapat ditemukan dan diakses
di seluruh cluster dengan IP virtual, yang cocok dengan perilaku
ClusterIP Service
yang dapat diakses dalam cluster. Sama seperti Service yang sudah ada, MCS
kompatibel dengan API terbuka dan berbasis komunitas, sehingga memastikan workload Anda tetap
portabel.
MCS adalah fitur GKE. MCS mengonfigurasi zona dan kumpulan data Cloud DNS untuk setiap Service yang diekspor di cluster fleet Anda. Dengan fleet, Anda dapat mengelompokkan dan menormalisasi cluster GKE secara logis, sehingga mempermudah administrasi infrastruktur dan memungkinkan penggunaan fitur multi-cluster seperti MCS. Anda dapat mempelajari lebih lanjut manfaat fleet dan cara membuatnya di dokumentasi pengelolaan fleet.
Apa pun jenisnya, apa pun jenisnya selalu memiliki satu data Cloud DNS, dan layanan jenis Headless yang diekspor memiliki data untuk setiap Pod backend dengan nama host, termasuk Pod di StatefulSets.
Penggunaan Cloud DNS akan dikenai biaya tambahan. Anda akan ditagih sesuai dengan harga Cloud DNS.
Untuk mengekspor Service dengan MCS, buat resource kustom ServiceExport menggunakan namespace dan nama yang sama dengan Service. MCS akan otomatis mengimpor Service ke setiap cluster dalam fleet. Saat MCS mengimpor Service, MCS akan membuat:
Resource kustom ServiceImport menggunakan namespace dan nama yang sama dengan Service.
Objek Endpoint menggunakan namespace yang sama dengan Service dan nama acak.
Manfaat menggunakan MCS
Dengan menggunakan MCS, Anda akan mendapatkan manfaat berikut:
Ketersediaan tinggi: Menjalankan Service yang sama di seluruh cluster di
beberapa region akan memberi Anda fault tolerance yang lebih baik. Jika Service dalam
cluster tidak tersedia, permintaan dapat gagal dan disalurkan dari cluster
lain. Dengan MCS, Anda dapat mengelola komunikasi antara Service di berbagai cluster untuk meningkatkan ketersediaan aplikasi dalam container Anda.
Service stateful dan stateless: Service stateful dan stateless
memiliki dependensi dan kompleksitas operasional yang berbeda serta memiliki
berbagai kompensasi secara operasional. Biasanya, tidak adanya pengelolaan status
akan mempermudah penskalaan, upgrade, dan migrasi workload dengan ketersediaan
yang lebih tinggi. MCS memungkinkan Anda memisahkan cluster untuk workload stateful dan stateless serta membuatnya independen, terisolasi, dan lebih mudah dikelola.
Service Bersama: Membuat cluster Kubernetes terpisah
untuk mendapatkan ketersediaan yang lebih tinggi, pengelolaan Service stateful dan stateless
yang lebih baik, serta kepatuhan yang lebih mudah terhadap persyaratan
kedaulatan data adalah hal yang umum. Namun, banyak Service seperti
pemantauan dengan Prometheus
atau menggunakan pengelolaan rahasia dengan Vault
sering kali dibagikan di antara semua cluster. Karena setiap cluster memerlukan replika Service lokalnya sendiri, MCS mempermudah penyiapan Service bersama yang umum dalam cluster terpisah yang digunakan oleh semua cluster fungsional.
Migrasi: Memodernisasi aplikasi yang ada ke dalam arsitektur berbasis
microservice dalam container sering kali mengharuskan Anda men-deploy Service
di beberapa cluster Kubernetes. MCS memberi Anda mekanisme untuk
membantu menjembatani komunikasi antara Service tersebut, sehingga memudahkan
migrasi aplikasi Anda. Hal ini sangat membantu karena Anda dapat men-deploy
Service yang sama ke dua cluster berbeda dan traffic dapat beralih
dari satu cluster atau aplikasi ke cluster lain.
Langkah berikutnya
Pelajari Multi Cluster Ingress lebih lanjut,
yang menyediakan Service untuk rute traffic utara-selatan dan timur-barat.
Pelajari Cloud Service Mesh lebih lanjut, yang memberi Anda kontrol lebih mendetail atas pemilihan rute dan pembentukan traffic.
[[["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-09-04 UTC."],[],[],null,["# Multi-cluster Services\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page provides you with an overview of how GKE multi-cluster\nServices (MCS) works. To learn how to use MCS, see\n[Configuring multi-cluster Services](/kubernetes-engine/docs/how-to/multi-cluster-services).\n\nOverview of MCS\n---------------\n\nKubernetes' familiar [Service](/kubernetes-engine/docs/concepts/service)\nobject lets you discover and access a Service within the\nconfines of a single Kubernetes cluster. However, sometimes you might want to\nsplit applications into multiple clusters, to address state management, privacy,\nscalability, availability, and data sovereignty requirements. With MCS, you can\nbuild Kubernetes applications that span multiple clusters.\n\nMCS is a cross-cluster Service discovery and invocation\nmechanism for Google Kubernetes Engine (GKE) that leverages the existing Service\nobject. Services enabled with this feature are discoverable and accessible\nacross clusters with a virtual IP, matching the behavior of a\n[ClusterIP Service](/kubernetes-engine/docs/concepts/service#services_of_type_clusterip)\naccessible in a cluster. Just like your existing Services, MCS is\ncompatible with community-driven and open APIs, ensuring your workloads remain\nportable.\n\nMCS is a feature of GKE. MCS configures Cloud DNS zones and\nrecords for each exported Service in your [fleet clusters](/kubernetes-engine/fleet-management/docs). A fleet lets you logically group and normalize your GKE clusters, making administration of infrastructure easier and enabling the use of multi-cluster features such as MCS. You can learn more about the benefits of fleets and how to create them in the [fleet management documentation](/kubernetes-engine/fleet-management/docs).\n\nExported Services regardless of type always have one Cloud DNS record, and exported Headless type services have records for each backend Pod with a hostname, including Pods in StatefulSets.\nUsing Cloud DNS incurs additional charges. You are billed according to\n[Cloud DNS pricing](https://cloud.google.com/dns/pricing).\n\nTo export a Service with MCS, create a ServiceExport custom resource using the same\nnamespace and name as the Service. MCS automatically imports the Service to each\ncluster in the fleet. When MCS imports a Service, it creates:\n\n- A ServiceImport custom resource using the same namespace and name as the Service.\n- An Endpoints object using the same namespace as the Service and a random name.\n\nBenefits of using MCS\n---------------------\n\nUsing MCS provides you with the following benefits:\n\n- **High availability**: Running the same Service across clusters in multiple regions provides you with improved fault tolerance. If a Service in a cluster is unavailable, the request can fail over and be served from other clusters. With MCS, it's possible to manage the communication between Services across clusters, to improve the availability of your containerized applications.\n- **Stateful and stateless Services**: Stateful and stateless Services have different operational dependencies and complexities and present different operational tradeoffs. Typically, the absence of state management makes it easier to scale, upgrade, and migrate a workload with higher availability. MCS lets you separate clusters for stateful and stateless workloads and make them independent, isolated, and easier to manage.\n- **Shared Services** : It's common to create separate Kubernetes clusters to get higher availability, better management of stateful and stateless Services, and easier compliance with data sovereignty requirements. However, many Services such as [monitoring with Prometheus](/stackdriver/docs/managed-prometheus) or [using secrets management with Vault](https://www.cloudskillsboost.google/focuses/1210?parent=catalog) are often shared among all clusters. Instead of each cluster requiring its own local Service replica, MCS makes it easier to set up common shared Services in a separate cluster that all functional clusters use.\n- **Migration**: Modernizing an existing application into a containerized microservice-based architecture often requires you to deploy Services across multiple Kubernetes clusters. MCS provides you with a mechanism to help bridge the communication between those Services, making it easier to migrate your applications. This is especially helpful as you can deploy the same Service to two different clusters and traffic is allowed to shift from one cluster or application to another.\n\nWhat's next\n-----------\n\n- Learn more about [Multi Cluster Ingress](/kubernetes-engine/docs/concepts/multi-cluster-ingress), which provides Services for north-south and east-west traffic directions.\n- Learn more about [Cloud Service Mesh](/anthos/service-mesh), which provides you with finer-grained control over routing and traffic shaping."]]
