Before you begin

Before you begin a multicluster installation, review the deployment models guide which describes the foundational concepts used throughout this guide.

In addition, review the requirements and perform the initial steps below.

Requirements

Cluster

This guide requires that you have two Kubernetes clusters with any of the supported Kubernetes versions: 1.26, 1.27, 1.28, 1.29.

API Server Access

The API Server in each cluster must be accessible to the other clusters in the mesh. Many cloud providers make API Servers publicly accessible via network load balancers (NLB). If the API Server is not directly accessible, you will have to modify the installation procedure to enable access. For example, the east-west gateway used in the multi-network and primary-remote configurations could also be used to enable access to the API Server.

Environment Variables

This guide will refer to two clusters: cluster1 and cluster2. The following environment variables will be used throughout to simplify the instructions:

VariableDescription
CTX_CLUSTER1The context name in the default Kubernetes configuration file used for accessing the cluster1 cluster.
CTX_CLUSTER2The context name in the default Kubernetes configuration file used for accessing the cluster2 cluster.

Set the two variables before proceeding:

  1. $ export CTX_CLUSTER1=<your cluster1 context>
  2. $ export CTX_CLUSTER2=<your cluster2 context>

Configure Trust

A multicluster service mesh deployment requires that you establish trust between all clusters in the mesh. Depending on the requirements for your system, there may be multiple options available for establishing trust. See certificate management for detailed descriptions and instructions for all available options. Depending on which option you choose, the installation instructions for Istio may change slightly.

If you are planning to deploy only one primary cluster (i.e., one of the Primary-Remote installations, below), you will only have a single CA (i.e., istiod on cluster1) issuing certificates for both clusters. In that case, you can skip the following CA certificate generation step and simply use the default self-signed CA for the installation.

This guide will assume that you use a common root to generate intermediate certificates for each primary cluster. Follow the instructions to generate and push a CA certificate secret to both the cluster1 and cluster2 clusters.

If you currently have a single cluster with a self-signed CA (as described in Getting Started), you need to change the CA using one of the methods described in certificate management. Changing the CA typically requires reinstalling Istio. The installation instructions below may have to be altered based on your choice of CA.

Next steps

You’re now ready to install an Istio mesh across multiple clusters. The particular steps will depend on your requirements for network and control plane topology.

Choose the installation that best fits your needs:

For meshes that span more than two clusters, you may need to use more than one of these options. For example, you may have a primary cluster per region (i.e. multi-primary) where each zone has a remote cluster that uses the control plane in the regional primary (i.e. primary-remote).

See deployment models for more information.