Multi-cluster services (MCS) lets pods in one Kubernetes cluster access Services running in another cluster without creating load balancers. Use MCS when you need to:
-
Isolate workloads across clusters while still sharing internal services
-
Deploy a Service across multiple clusters for high availability and cross-cluster load balancing
-
Connect clusters across separate VPCs without exposing Services through public endpoints
Key concepts
| Term | Description | Created by |
|---|---|---|
| ServiceExport | A custom resource you create in the provider cluster to expose a Service to other clusters. | User |
| ServiceImport | A custom resource representing a multi-cluster Service in the consumer cluster. | User |
| Clusterset | A group of clusters that share Services through MCS. Each cluster can act as a service provider, a service consumer, or both. | — |
| Service provider | The cluster that exports a Service via ServiceExport. | — |
| Service consumer | The cluster that imports and accesses an exported Service via ServiceImport. | — |
Architecture
The MCS feature relies on an ACK One Fleet instance to coordinate ServiceExport and ServiceImport objects across associated Container Service for Kubernetes (ACK) clusters.
Two connections are shown in the diagram:
-
Connection 1 — The ACK One Fleet instance manages ServiceExport and ServiceImport in the associated ACK clusters. You create a ServiceExport in the provider cluster (ACK Cluster 1) and a ServiceImport in the consumer cluster (ACK Cluster 2).
-
Connection 2 — Data flows directly between clusters. After Service 1 is exported from ACK Cluster 1 and imported into ACK Cluster 2, pods in ACK Cluster 2 can reach Service 1.
How it works
The following diagram shows traffic flow across clusters.
-
Create a ServiceExport in ACK Cluster 1 (provider) and a ServiceImport in ACK Cluster 2 (consumer).
-
ACK One Fleet creates a Service named
amc-<service-name>in ACK Cluster 2 and syncs the pod IP addresses from ACK Cluster 1 to its backend. -
Pods in ACK Cluster 2 can access Service 1 using either domain name format:
Format Example amc-<service-name>.<provider-namespace>amc-Service1.provider-ns<service-name>.<provider-namespace>.svc.clusterset.localService1.provider-ns.svc.clusterset.local
Use cases
Access a Service from a different cluster
Deploy your Service in ACK Cluster 1 and create a ServiceExport. Create a ServiceImport in ACK Cluster 2. Pods in ACK Cluster 2 can then access the Service through DNS. Traffic is load-balanced across the backend pods in ACK Cluster 1, and the pod count scales dynamically.
Access a Service deployed across clusters
Deploy the same Service across multiple clusters for high availability. When a pod accesses the Service, traffic is balanced across pods in all participating clusters.
Network requirements
Pod-to-pod traffic must flow directly between clusters for MCS to work. Before enabling MCS, verify that all three network requirements are met:
| Requirement | Why it matters |
|---|---|
| If multiple virtual private clouds (VPCs) are used, VPC CIDR blocks must not overlap, and all VPCs must be connected via Cloud Enterprise Network (CEN). | Overlapping CIDR blocks cause routing conflicts; CEN provides the cross-VPC network path. |
| Pod CIDR blocks must not overlap across clusters. Node pool security groups must mutually allow traffic between pod CIDR blocks. | Direct pod-to-pod routing requires unique addresses and open security group rules. |
| Pod CIDR blocks must not overlap with Service CIDR blocks in any cluster. | Overlapping pod and Service CIDR blocks break DNS-based Service discovery across clusters. |
For cluster-level network planning, see Plan the network of an ACK cluster.
Limitations
The Kubernetes version of all associated clusters must be 1.22 or later.