Due to the wide adoption of Kubernetes, enterprises need to run and manage multiple Kubernetes clusters to meet the requirements for Service isolation, application deployment, and O&M. In addition, a cluster may need to access Services that are deployed in another cluster. The multi-cluster Services (MCS) feature allows you to access Services across Kubernetes clusters without the need to create load balancers. This topic describes the architecture, scenarios, and network design of the MCS feature.
Architecture
The MCS feature allows you to access Services across clusters. You can create an application that spans multiple clusters. The following figure shows the architecture of the MCS feature.
Connections marked with 1 in the preceding figure are used by the Fleet instance to manage the ServiceExport and ServiceImport in the associated Container Service for Kubernetes (ACK) clusters.
A ServiceExport is created in ACK Cluster 1 to export Service 1. ACK Cluster 1 serves as a Service provider.
A ServiceImport is created in ACK Cluster 2 to allow ACK Cluster 2 to access Service 1 exported by the Service provider. ACK Cluster 2 serves as a Service consumer.
The connection marked with 2 in the preceding figure is used for data exchange. After Service 1 is exported in ACK Cluster 1 and imported in ACK Cluster 2, you can access Service 1 in ACK Cluster 1 from ACK Cluster 2. This way, you can access Services across clusters.
How MCS works
The following figure shows how MCS works.
To enable pods in ACK Cluster 2 to access Service 1 in ACK Cluster 1, you can create a ServiceExport in ACK Cluster 1 and a ServiceImport in ACK Cluster 2.
The ACK One Fleet instance creates a Service named
amc-Service1that is prefixed withamc-in ACK Cluster 2 and synchronizes the IP addresses of the pods in ACK Cluster 1 to the backend of theamc-Service1Service.The client pod in ACK Cluster 2 can access Service 1 in ACK Cluster 1 in one of the following ways:
Access the domain name that starts with
amc-, such asamc-Service1.provider-ns.Access the domain name that ends with clusterset.local, such as
Service1.provider-ns.svc.clusterset.local.
Scenarios
Access a Service from a different cluster
Create a ServiceExport in ACK Cluster 1 and a ServiceImport in ACK Cluster 2. ACK Cluster 1 serves as a Service provider and ACK Cluster 2 serves as a Service consumer. The client pod in ACK Cluster 2 can access Service 1 exported in ACK Cluster 1. Service 1 is accessed based on domain name resolution. Traffic is balanced among the backend pods in ACK Cluster 1 and the number of pods is dynamically scaled. The following figure shows how a Service is accessed across clusters.
Access a Service that is deployed across clusters
Service 1 is deployed across multiple clusters to ensure high availability. When the client pod accesses Service 1 across clusters, traffic can be balanced among multiple pods of the clusters. The following figure shows how Service 1 that is deployed across clusters is accessed.
Network design for MCS
To access Services across clusters, make sure that the networks of the pods in the clusters are connected so that the pods can access each other. The following requirements must be met:
If multiple virtual private clouds (VPCs) are used, the VPC CIDR blocks must not overlap with each other. The VPCs are connected by using Cloud Enterprise Network (CEN).
The pod CIDR blocks in the clusters must not overlap with each other.
The pod CIDR blocks must not overlap with the Service CIDR blocks in the clusters.
For more information, see Plan CIDR blocks for an ACK cluster.
Limits
The Kubernetes version of the associated clusters must be 1.21 or later.