All Products
Search
Document Center

Container Service for Kubernetes:MCS overview

Last Updated:May 31, 2024

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 multi-cluster Services (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.

image
  1. Connections marked with 1 in the preceding figure are used by the Distributed Cloud Container Platform for Kubernetes (ACK One) 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.

  2. 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.

image
  1. 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.

  2. The ACK One Fleet instance creates a Service named amc-Service1 that is prefixed with amc- in ACK Cluster 2 and synchronizes the IP addresses of the pods in ACK Cluster 1 to the backend of the amc-Service1 service.

  3. The client pod in ACK Cluster 2 can access Service 1 in ACK Cluster 1 in one of the following ways:

    1. Access the domain name that starts with amc-, such as amc-Service1.provider-ns.

    2. 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.

image

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.

image

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:

  1. 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).

  2. The pod CIDR blocks in the clusters must not overlap with each other.

  3. 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.