This page provides you with an overview of how GKE multi-cluster
Services (MCS) works. To learn how to use MCS, see
Configuring multi-cluster Services.
Overview of MCS
Kubernetes' familiar Service
object lets you discover and access a Service within the
confines of a single Kubernetes cluster. However, sometimes you might want to
split applications into multiple clusters, to address state management, privacy,
scalability, availability, and data sovereignty requirements. With MCS, you can
build Kubernetes applications that span multiple clusters.
MCS is a cross-cluster Service discovery and invocation
mechanism for Google Kubernetes Engine (GKE) that leverages the existing Service
object. Services enabled with this feature are discoverable and accessible
across clusters with a virtual IP, matching the behavior of a
ClusterIP Service
accessible in a cluster. Just like your existing Services, MCS is
compatible with community-driven and open APIs, ensuring your workloads remain
portable.
MCS is a feature of GKE. MCS configures Cloud DNS zones and
records for each exported Service in your fleet clusters. 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.
Exported 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.
Using Cloud DNS incurs additional charges. You are billed according to
Cloud DNS pricing.
To export a Service with MCS, create a ServiceExport custom resource using the same
namespace and name as the Service. MCS automatically imports the Service to each
cluster in the fleet. When MCS imports a Service, it creates:
A ServiceImport custom resource using the same namespace and name as the Service.
An Endpoints object using the same namespace as the Service and a random name.
Benefits of using MCS
Using MCS provides you with the following benefits:
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.
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.
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
or using secrets management with Vault
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.
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.
What's next
Learn more about Multi Cluster Ingress,
which provides Services for north-south and east-west traffic directions.
Learn more about Cloud Service Mesh, which provides
you with finer-grained control over routing and traffic shaping.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 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."]]
