Cluster network

A multi-cluster mesh connects multiple clusters into a single service mesh. The topology of the mesh – how the different clusters are grouped into networks and how each cluster connects to the mesh – determines how the clusters connect to each other and how the pods, services, and workloads can access resources in other clusters.

Communication between clusters

In a multi-cluster mesh, every cluster belongs to a specific network. Clusters belonging to the same mesh can access the services of each other, but how this happens depends on which network the cluster belongs to.

• If the clusters belong to the same network, their pods can access each other directly over a flat network, without using a cluster gateway.
• If the clusters belong to different networks, the services of the cluster can be accessed only through the gateway of the cluster. Since Service Mesh Manager assigns each cluster to its own network by default, this is the default behavior.

The networkName label of the cluster determines which network the cluster belongs to. By default, every cluster belongs to its own network, where the name of the network is the name of the cluster.

Note: If the name of the cluster cannot be used as a Kubernetes resource name (for example, because it contains the underscore, colon, or another special character), you must manually specify a name to use when you are attaching the cluster to the service mesh. For example:

smm istio cluster attach <PEER-CLUSTER-KUBECONFIG-FILE> --name <KUBERNETES-COMPLIANT-CLUSTER-NAME> --active-istio-control-plane

Otherwise, the following error occurs when you try to attach the cluster:

could not attach peer cluster: graphql: Secret "example-secret" is invalid: metadata.name: Invalid value: "gke_gcp-cluster_region": a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.'**

You can specify the network of the cluster when you are attaching the cluster to the mesh.

Assigning clusters to different networks allows you to optimize the topology of your mesh network. Depending on your cloud provider, there might be differences in cross-cluster latencies and transfer costs between the different connection types.

Network connectivity requirements

For a multi-cluster scenario the necessary networking configurations are listed in this section.

• If the clusters belong to the same network, then network connectivity should be fine nothing else needs to be done.
• If the clusters belong to different networks, and the endpoints in the networks are publicly accessible without restrictions, then again nothing needs to be done.
• If the clusters belong to different networks, but there are restrictions on which endpoints can be accessed, at least the following endpoints must be accessible for a proper multi-cluster setup with Service Mesh Manager:
  • From all clusters:
    • All other clusters' k8s API server address (to meet the Cluster registry controller Networking requirements)
  • From the primary cluster(s):
    • All peer clusters' k8s API server address
    • All IP addresses or host names of the meshexpansion-gateway LoadBalancer type services on the peer clusters on port 15443
  • From peer clusters:
    • IP address or host name of the meshexpansion-gateway LoadBalancer type service on the primary cluster(s) on ports 15443,15012
    • IP address or host name of the meshexpansion-gateway LoadBalancer type service on the primary cluster where Service Mesh Manager is installed on ports 50600,59411