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.
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.
- Learn more about Multi Cluster Ingress, which provides Services for north-south and east-west traffic directions.
- Learn more about Anthos Service Mesh, which provides you with finer-grained control over routing and traffic shaping.